本人大資料開發一枚

這個，不敢苟同，寫程式碼，很多時候不是寫hello word 就完事了，更多的時候要考慮程式碼的其他方面，比如，資料一致性，線上資料有問題，程式碼怎麼辦，程式碼的分散式鎖，請求過多打爆了資料庫怎麼辦等等等等，所以，程式碼越少，意味著，你考慮的越少，遇到情況就會出問題維護，這樣，問題一多，維護成本就會很高，所以，程式碼並不是越少越好

通常，一個正常專案不是所有的程式碼都是自己寫的。會引用很多框架frame work。這些框架是其他程式設計師寫的，但它們迭代了多個版本，負責這些框架的程式設計師可能本身水平就高……最終，這些框架通常會比現寫的程式碼更穩定，更容易維護。

對於平均水平及以下的程式設計師，或者專案週期短，應該儘量使用框架，儘量減少自己寫的新程式碼。這樣可以在可接受的時間內，獲得一個平均水平的軟體。

對於有更高要求的專案來說，通用框架很難達到要求（安全，速度，可維護性等）。而且，能召集更多高水平程式設計師的情況下，要發揮這些程式設計師的價值，以獲得一個競爭能力更強的軟體，就必須重新構架了。當然，更少程式碼，通常會有更快的執行速度，更少bug。對於高階程式設計師來說，簡潔，明快，有欣賞性的程式碼，也是骨子裡的追求（否則不可能到高階）。

寫程式碼和做產品一個意思，一開始做加法，然後開始做減法！

就我個人而言，能用一行程式碼搞定的事，休想騙我用十行！

但是在剛開始做開發的時候，由於對語言特性，思想，基本資料結構，API的不熟悉，我們可以寫更多的程式碼來增加自己對程式語言的理解，但是此時的多不應該理解為程式碼量的多，而是實現方式的多，比如說map的遍歷就有多種方式，ketSet，entrySet，迭代等多種方式，如果在一開始使用的時候就只會一種，那麼在某些特定的場景裡可能並不適用，所以做程式設計一開始應該學會做加法！

等到熟悉了基本的開發，怎麼能用最簡便，最清晰的方式做開發變為重點，應該使用最簡單的方式實現業務程式碼。

舉個栗子:一個物件list<Man>按照某個欄位進行分組，需求很簡單，怎麼實現呢？

首先new一個map<string，list<Man>>，遍歷list，new一個list1，將物件欄位作為key，物件放入list1，然後作為value放入map，遍歷第二個元素的時候，需要判斷這個key是否存在，如果存在，取出存在的list1，將物件放入，如果不存在，new一個list2，將欄位作為key，list2作為value放入map，程式碼實現大概有10行的樣子(具體程式碼不想寫)。

但使用JAVA8的流式處理，就一行程式碼如下:是不是超級簡單？

很多時候，我們程式碼的簡化，得益於源語言的不斷升級，所以在實際開發中我們需要不斷的擁抱語言帶來的新特性，和別人分享的開發技巧，來簡化開發流程！

就JAVA語言而言，相對其他的go，scala等都略顯笨重，比如使用設計模式進行開發，很多程式碼都是一開始看沒有必要的，但是在後期擴充套件的時候，會發現十分容易，整個架構也很健壯，使用必要的更多的程式碼換取程式的健壯性，可擴充套件性是值得的！

綜上，程式碼並不是越少越好，切勿偏離了程式碼設計最基本的原則(可擴充套件性，單一原則，健壯等)，更多的程式設計技巧，敬請關注。。。

程式碼的長度決定不了程式設計師的水平。比如有的任務一開始需要寫20行，封裝後用一行程式碼就可以完成。但是有的任務需要更高的精度和執行速度，你就必須對底層操作，比如指標，彙編，封裝反而影響了執行速度，你需要寫更多的程式碼。

程式碼長度取決於任務需求。

並且在團隊裡，為了程式碼的可讀性，不能太長，因為記不住。也不能太短，因為看不懂。

講真，一開始我也天真的以為程式碼越少越好，覺得程式碼少就表示學的東西更加的先進，更加的優質，不過表面上是如此，但是實際上並非如此。好的程式碼並不在於少，而是在於其健壯性、可拓展性、關鍵部分有註釋、有邏輯性、方便除錯、容易維護等等。

個人經驗，程式碼，就是對現實世界的虛擬，什麼物件，函式，類，介面，等很多概念。用現實世界的一件事來表述，做汽車，a廠做鈑金，b廠做發動機，c廠做輪胎。程式設計師把各廠生產的部件弄起來，那些廠有的已經有了，如果沒有，那就先成立一個。就這麼簡單，

是有那麼回事，否則不會有面向物件的光輝，和元件化、服務化等設計思想了。它們是為了程式碼重用，解藕而生。試想一下，相同程式碼無數次重複出現，這樣的程式碼量絕對夠多，但是無法維護。只不過，你呼叫不是你寫的程式碼的話，就是依賴，過分的依賴也不好維護，升級困難，衝突多。看你怎麼權衡吧。

兵無常勢水無常形，程式碼多還是少，要看需要，比如在某些極度追求效能的C程式核心演算法點，做20個元素整型陣列每個元素的逐個處理，也許一個迴圈一個函式三十行程式碼就完事，為了效率可能會換成在一個程式碼片段內逐個寫每個元素的處理程式碼，雖然單調重複，但也比編譯器自動最佳化要高出零點幾個到近一個百分點的效能。必要的時候還可能把那個重複的程式碼段換成彙編語句內嵌以期再提升一個百分點的效能，如此一來程式碼量更大了。

這個例子也要分兩面來看：如果認為為了提升效能產生的程式碼是必要的，則我們提到的“程式碼量更大”這個判斷不成立——幹這活本來就需要這麼多的程式碼，還能在效能保障的前提下有程式碼的精簡末？如果有，Do it。這麼看的話，又是程式碼越少越好了。

當然多數時候，程式碼的簡潔、維護性好是優先順序更高的事情。程式設計師往往會有個習慣，對自己寫的程式碼隔一段時間重構一次——因為對業務更熟悉、演算法的構思更精煉了，有了更好的結構、更便於維護、風險更小，重構的念頭就會產生。