剛寫了一百萬行代碼，現在迷之自信！
剛學 C 語言的時候有種上下求索，欲上九天攬月的豪情壯志，結果老師的冷水當頭潑下：剛開始寫代碼會覺得很有意思，等寫了一百萬行后，其中滋味自己體會吧!
搞程序的累計寫到一百萬行代碼，到底是什么體驗呢?
如果一百萬是標量的話，我來和大家研究一下這個數據：
假設***的情況，一天 100 行高質量代碼，一年 36500，100 / 3.65 = 27 年多。即便從 20 歲開始編碼，要到 50 歲左右方可完成。
但實際上關于平均代碼量的問題，即便把所有工作日都算上，大概也就是 20 - 30 行的樣子;如果僅討論集中的開發期，高峰也不會超過 200 行。
一百萬代碼就像找女朋友一樣不靠譜。。。。
看完之后小編就頭皮一陣發麻，讓我寫一萬行的代碼?!are you kidding me?我估計寫到 20 萬的時候就會突然有個疑問----“咦?我的頭發呢?”。
針對累計寫到一百萬行代碼，看看網友們怎么說：
網友 A
我寫兩千行代碼功能都得琢磨個兩三天，一百萬行真的是好多啊，最多了五年寫了也就 20 - 30 萬行代碼左右，還是有任務在身的情況被逼著寫的，讓我寫一百萬行代碼，恐怕這輩子得死在電腦前了...
網友 B
我是覺得如果說你一個工作寫了一百萬行代碼，那你在公司的地位應該算資深員工了。如果你一個項目寫了一百萬行，那你肯定是參與了一個比較大的項目了。
如果你一個類寫了一百萬行，請問你用的是什么編輯器?如果你一個方法寫了一百萬行代碼的話，請問你有沒有被同事打死?
網友 C
據說要從初學者成長為程序員，那個得需要 10 萬行代碼的積累才可以呢。不過話說回來這樣說也很對，畢竟入門階段嘛，確實需要多打代碼才能積累經驗。
不過修煉一段時間之后，再注重代碼的量，那就不對了。這時候肯定是注重數學還有算法思維，按這樣算的話，假如 20 萬是修煉門檻，真積累到了一百萬行代碼，肯定代碼質量越來越高了，估計是某個領域的小專家也說不定。
至于真敲了一百萬行低質量代碼，聽哥一句話，還是轉行吧。程序員不適合你這種鍥而不舍的精神。
網友 D
切，一群渣渣。給你們看看一張網圖就知道我連續熬夜寫幾千行代碼是什么狀態了。我感覺我快要窒息了，如果時間可以倒流，我希望我不做程序員!!!
網友 E
這簡直就是一個偽***啊，哪有什么人能打一百萬的代碼，從業五六年的程序員，如果按正常工作量的話一天也就一百多行，這五六年估計也就五六萬行吧。
如果是外包公司代碼量估計翻倍了，那就按五十萬行來算。但是誰會那么拼命去奮斗在一線一天一千行的去工作啊。寫五六十萬行肯定都轉行創業了，還繼續下去不猝死估計也脫一層皮了。
當一個項目里的代碼超過一百萬行……
關于代碼的量，從初學者成長為程序員，需要代碼的積累，而以后數學功底和編程思維的深化更加重要。
一味的追求量并沒有任何實際意義，通常，越核心的部分代碼量越小，越容易寫大量代碼的，大概是沒什么技術含量的 UI、業務邏輯。而一些部分，用腳本或 DSL 實現可以更精簡。寫代碼和考試一樣，做題最多的不一定是成績***的。
怎么做高質量的代碼
打好技術基礎
寫出高質量代碼，并不是搭建空中樓閣，需要有一定的基礎。
這里我重點強調與代碼質量密切相關的幾點：
- 掌握好開發語言，比如做 Android 就必須對 Java 足夠熟悉，才能夠寫出高質量 Java 代碼。
- 熟悉開發平臺，不同的開發平臺，有不同的 API，有不同的工作原理，同樣是 Java 代碼，在 PC 上寫與 Android 上寫很多地方不一樣。
要去熟悉 Android 編程的一些特性，iOS 編程的一些特性，了解清楚這些，才能寫出更加地道的代碼，充分發揮各自平臺的優勢。
- 基礎的數據結構與算法，掌握好這些在解決一些特定問題時，可以以更加優雅有效的方式處理。
- 基礎的設計原則，無需完全掌握 23 種經典設計模式，只需要了解一些常用的設計原則即可，甚至你也可以只了解什么是低耦合，并在你的代碼中堅持實踐，也能寫出很不錯的代碼。
代碼標準
代碼標準在團隊合作中尤為重要，誰也不希望一個項目中代碼風格各異，看得讓人糟心，即便是個人開發者，現在也需要跟各種開源項目打交道。
標準怎么定是一個老生常談的話題，我經歷過很多次的代碼標準討論會議，C++，C#，Java 等等，大家有時會堅持自己的習慣不肯退讓。可現如今時代不一樣了，Google 等大廠已經為我們制定好了各種標準，就用這些業界標準吧。
想好再寫
除非你很清楚你要怎么做，否則我不建議邊做邊想。你真的搞清楚你要解決的問題是什么了嗎?你的方案是否能有效?有沒有更優雅簡單的方案?
準備怎么設計它，必要的情況下，需要有設計文檔，復雜一些的設計需要有同行評審，寫代碼其實是很簡單的事情，前提是你得先想清楚。
代碼重構
重構對于代碼質量的重要性不言而喻，很難一次把代碼寫得讓自己滿意、無可挑剔。
技術債務
很多問題歸根結底都是技術債務，這在一些大公司尤為常見。技術債務話題太大，但就代碼質量而言，我只想提一下不要因為這些債是前人留下的你就不去管。
現實是沒有多少機會讓你從一個清爽清新的項目開始做起，你不得不去面對這些，你也沒法完全不跟這些所謂的爛代碼打交道。
當你負責一個小模塊時，除了把它做好之外，也要順便將與之糾纏在一起的技術債務還掉，因為這些債務最終將是整個團隊來共同承擔，任何一個人都別想獨善其身，如果你還對高質量代碼有追求的話。
作為團隊的技術負責人，也要頂住壓力，鼓勵大家勇于做出嘗試，引導大家不斷改進代碼質量，不要總是畏手畏腳，停滯不前，真要背鍋也得上，要有擔當。
代碼審查
我曾經聽過一些較高級別的技術分享，竟然還不時聽到一些呼吁大家要做代碼審查的主題。
我以為在這個級別的技術會議上，不應再討論代碼審查有什么好，為什么要做代碼審查之類的問題。同時我接觸過相當多所謂國內一線互聯網公司，竟有許多是不做代碼審查的，這一度讓我頗為意外。
這里也不想多談如何做好代碼審查，只是就代碼質量這點，不客氣地說：沒有過代碼審查的經歷往往很難寫出高質量的代碼，尤其是在各種追求速度的糙快猛創業公司。
靜態檢查
很多代碼上的問題，都可以通過一些工具來找到，某些場景下，它比人要靠譜得多，至少不會出現某些細節上的遺漏，同時也能有效幫助大家減少代碼審查的工作量。
Android 開發中有 Lint，Find bugs，PMD 等優秀靜態檢查工具可用，通過改進這些工具找出的問題，就能對語法的細節，規范，編程的技巧有更多直觀了解。
建議***與持續集成(CI)，代碼審查環境配套使用， 每次提交的代碼都能自動驗證是否通過了工具的代碼檢查，通過才允許提交。
單元測試
Android 單元測試，一直備受爭議，主要還是原生的測試框架不夠方便，每跑一次用例需要在模擬器或者真機上運行，效率太低，也不方便在 CI 環境下自動構建單元測試，好在有 Robolectric，能幫我們解決部分問題。
單元測試的一個非常顯著的優點是，當你需要修改大量代碼時，盡管放心修改，只需要保證單元測試用例通過即可，無需瞻前顧后。
充分自測
有一種說法：程序員最害怕的是他自己寫的代碼，尤其是準備在眾人面前 show 自己的工作成果時，因此在寫完代碼后，需要至少跑一遍基本的場景，一些簡單的異常流。
在把你的工作成果提交給測試或用戶前，充分自測是基本的職業素養，不要總想著讓測試幫你找問題，隨便用幾下就 Crash 的東西，你好意思拿給別人嗎?
善用開源
并非開源的東西，質量就高，但至少關注度較高，使用人數較多，口碑較好的開源項目，質量是有一定保證的，這其中的道理很簡單。
即便存在一些問題，也可以通過提交反饋，不斷改進。最重要的是，你自己花時間造的輪子，需要很多精力維護，而充分利用開源項目，能幫助你節省很多時間，把精力專注在最需要你關心的問題上。
從另一個方面來說，開源項目中的一些知名項目，往往是領域內的翹楚所寫，學習這些高手的代碼，能讓你了解到好的代碼應該是怎樣的，培養出更靈敏的嗅覺，識別代碼中的各種味道。
