觀談影視
寫代碼和做產品一個意思，一開始做加法，然後開始做減法！
就我個人而言，能用一行代碼搞定的事，休想騙我用十行！
但是在剛開始做開發的時候，由於對語言特性，思想，基本數據結構，API的不熟悉，我們可以寫更多的代碼來增加自己對編程語言的理解，但是此時的多不應該理解為代碼量的多，而是實現方式的多，比如說map的遍歷就有多種方式，ketSet，entrySet，迭代等多種方式，如果在一開始使用的時候就只會一種，那麼在某些特定的場景裡可能並不適用，所以做編程一開始應該學會做加法！
等到熟悉了基本的開發，怎麼能用最簡便，最清晰的方式做開發變為重點，應該使用最簡單的方式實現業務代碼。
舉個栗子:一個對象list
首先new一個map<string>>，遍歷list，new一個list1，將對象字段作為key，對象放入list1，然後作為value放入map，遍歷第二個元素的時候，需要判斷這個key是否存在，如果存在，取出存在的list1，將對象放入，如果不存在，new一個list2，將字段作為key，list2作為value放入map，代碼實現大概有10行的樣子(具體代碼不想寫)。/<string>
但使用JAVA8的流式處理，就一行代碼如下:是不是超級簡單？
很多時候，我們代碼的簡化，得益於源語言的不斷升級，所以在實際開發中我們需要不斷的擁抱語言帶來的新特性，和別人分享的開發技巧，來簡化開發流程！
就JAVA語言而言，相對其他的go，scala等都略顯笨重，比如使用設計模式進行開發，很多代碼都是一開始看沒有必要的，但是在後期擴展的時候，會發現十分容易，整個架構也很健壯，使用必要的更多的代碼換取程序的健壯性，可擴展性是值得的！
綜上，代碼並不是越少越好，切勿偏離了代碼設計最基本的原則(可擴展性，單一原則，健壯等)，更多的編程技巧，敬請關注。。。
此生唯一
作為一名程序員，我來談談我的看法。
其實這種說法是不對的。
程序員寫代碼，其實講究的首先是如何去實現產品的這個功能，然後才是如何使用最優解來實現。記住，最優解不是說代碼越少就是最優方案。這是個大誤區。
好的代碼其實不是說量越少越好，而是說時間複雜度越低越好。比如舉個簡單的例子，你用一行代碼寫了一個功能，但是這個功能十分消耗性能和時間，而你用十行代碼寫了一個一樣的功能並且這個功能不怎麼消耗時間，你覺得哪一個代碼算的上好？
其次，好的代碼他自己會說話。我們在寫代碼的時候對於產量名稱，或者方法名稱都十分有講究，這個不能亂寫，要讓別人接手的人能夠看得懂才行。並且好的代碼的邏輯和條理是非常清晰的，一目瞭然。而不像有些代碼東一點西一點，亂七八糟，看的人頭暈目眩的，這種代碼越少越看不懂，越少越垃圾。
總而言之，好的代碼必須滿足兩點，一點是時間複雜度沒那麼高，不消耗大量的性能。第二點，邏輯清晰，能夠讓人一看就能夠明白。這才是好代碼。
晨雨細曲
個人經驗，代碼，就是對現實世界的虛擬，什麼對象，函數，類，接口，等很多概念。用現實世界的一件事來表述，做汽車，a廠做鈑金，b廠做發動機，c廠做輪胎。程序員把各廠生產的部件弄起來，那些廠有的已經有了，如果沒有，那就先成立一個。就這麼簡單，
明天101434451
兵無常勢水無常形，代碼多還是少，要看需要，比如在某些極度追求性能的C程序核心算法點，做20個元素整型數組每個元素的逐個處理，也許一個循環一個函數三十行代碼就完事，為了效率可能會換成在一個代碼片段內逐個寫每個元素的處理代碼，雖然單調重複，但也比編譯器自動優化要高出零點幾個到近一個百分點的性能。必要的時候還可能把那個重複的代碼段換成彙編語句內嵌以期再提升一個百分點的性能，如此一來代碼量更大了。
這個例子也要分兩面來看：如果認為為了提升性能產生的代碼是必要的，則我們提到的“代碼量更大”這個判斷不成立——幹這活本來就需要這麼多的代碼，還能在性能保障的前提下有代碼的精簡末？如果有，Do it。這麼看的話，又是代碼越少越好了。
當然多數時候，代碼的簡潔、維護性好是優先級更高的事情。程序員往往會有個習慣，對自己寫的代碼隔一段時間重構一次——因為對業務更熟悉、算法的構思更精煉了，有了更好的結構、更便於維護、風險更小，重構的念頭就會產生。
米爸來啦
代碼的長度決定不了程序員的水平。比如有的任務一開始需要寫20行，封裝後用一行代碼就可以完成。但是有的任務需要更高的精度和執行速度，你就必須對底層操作，比如指針，彙編，封裝反而影響了執行速度，你需要寫更多的代碼。
代碼長度取決於任務需求。
並且在團隊裡，為了代碼的可讀性，不能太長，因為記不住。也不能太短，因為看不懂。
小汐vivi
通常，一個正常項目不是所有的代碼都是自己寫的。會引用很多框架frame work。這些框架是其他程序員寫的，但它們迭代了多個版本，負責這些框架的程序員可能本身水平就高……最終，這些框架通常會比現寫的代碼更穩定，更容易維護。
對於平均水平及以下的程序員，或者項目週期短，應該儘量使用框架，儘量減少自己寫的新代碼。這樣可以在可接受的時間內，獲得一個平均水平的軟件。
對於有更高要求的項目來說，通用框架很難達到要求（安全，速度，可維護性等）。而且，能召集更多高水平程序員的情況下，要發揮這些程序員的價值，以獲得一個競爭能力更強的軟件，就必須重新構架了。當然，更少代碼，通常會有更快的運行速度，更少bug。對於高級程序員來說，簡潔，明快，有欣賞性的代碼，也是骨子裡的追求（否則不可能到高級）。
我低端就改我名
是有那麼回事，否則不會有面向對象的光輝，和組件化、服務化等設計思想了。它們是為了代碼重用，解藕而生。試想一下，相同代碼無數次重複出現，這樣的代碼量絕對夠多，但是無法維護。只不過，你調用不是你寫的代碼的話，就是依賴，過分的依賴也不好維護，升級困難，衝突多。看你怎麼權衡吧。
自以為神人的鳥人
本人大數據開發一枚
這個，不敢苟同，寫代碼，很多時候不是寫hello word 就完事了，更多的時候要考慮代碼的其他方面，比如，數據一致性，線上數據有問題，代碼怎麼辦，代碼的分佈式鎖，請求過多打爆了數據庫怎麼辦等等等等，所以，代碼越少，意味著，你考慮的越少，遇到情況就會出問題維護，這樣，問題一多，維護成本就會很高，所以，代碼並不是越少越好
愛動漫的小迷弟
猴子喲吐槽
是的 代碼量越少越好 ！因為代碼量可以看出一個人的技術 也方便 後期軟件修改也有好的幫助
