如何評價在GitHub 上 3000 fork庫的代碼水平？

01-28

gdby/NewEBuy · GitHub
國人沖榜速度最快的一位吧！！

相信我，你不會想看這樣的代碼的。

我不是說這個代碼寫的不好，而是說這樣的項目會不可避免的枯燥無味。

本身一個規模還算大的公司裡面做了幾年的項目，水平一定會參差不齊。

更重要的是，這樣類型的項目本身就沒什麼可看的，除非你要找他的漏洞什麼的。

這類項目只是翻來覆去在做一件事情，就是完成他的業務邏輯。

既不會犯什麼大錯，也很難有出彩的地方。

想學點什麼還不如找個牛逼的開源庫讀讀來得實在。

就這件事情而言，他的代碼水平遠不如這件事情的八卦有意思。

非要強行回答的話，我覺得風格比較糟糕。當然我也說了，這是很難避免的。

實力黑了一波蘇寧啊，哈哈哈哈

跑個題，這麼多研發資料，是不是創業者的春天來了，又可以各種自主知識產權了

下午down下來大概看了一下，某寧某購的

項目結構：比較規整，基本上按照業務功能分組（也可以理解為按頁面劃分），每個分組裡包含頁面vc，tablecell，model對象等，按照功能找到相應代碼比較容易；

代碼風格：嚴格上來講一般般。各種magic number，各種莫名其妙插進來的補丁，各種廢棄代碼，各種不對齊。。。不過從工程的角度來看，也說的過去，畢竟是一個業務導向型的app，維護了好幾年，由很多參差不齊的人接手過，演化到目前這個樣子，也算正常。就像樓上鍾穎Cyan說的，很難避免，因為新接手的人，即使有心完全重構一遍，但是在需求排期的壓力下，也挺難真正動手的，況且誰能保證重構後代碼風格好了，但是功能不出問題呢？基於這一點，一般領導也不會支持以代碼風格為目的的重構。。。

結論：正常代碼，沒啥高大上的東西，正常實現業務功能，應該代表了國內90%以上公司的情況。

當我嘗試打開這個頁面的時候，它是404

沒有命名潔癖的碼農，不是好碼農代碼結構一般，標準業務代碼