編程中，有哪些好的習慣從一開始就值得堅持？

11-26

之前問了一些個問題，從而想到這個更大的問題，請大家各抒己見，為初學者提供參考。感謝各位，我會為每一個回答者點贊。

之前的問題請見鏈接C 語言運算符或賦值符兩邊是否該寫空格？ - C++

重視模塊化，重視抽象但不濫用

我剛接觸編程的時候，在網上看到許多大牛寫程序都十分注重模塊化，因此我就下意識的模仿他們；後來看SICP，知道了抽象的好處，因此在寫程序的時候會仔細思考抽象的問題。這些對我都有著非常大的幫助。

在一篇講述程序員代碼行數瓶頸的博客中（程序員的成長和代碼行數的關係）提到，程序員在2k行、20k行、200k行等若干程序規模時會遇到瓶頸，如果不用更科學有效的方法，超過了這個行數代碼就會混亂到難以維護。但我第一次寫很大的程序時（8k+）並沒有感覺到文中提到的瓶頸；我目前接手的項目有近900k行，我自己寫的部分也已經快上10k，但我仍然沒遇到文中提到的瓶頸。

針對這一現象，我做過一些實驗。我在很不認真的寫一些小程序時，也總是寫的混亂不堪，我發現，這種情況下，程序行數超過200行我就覺的很難受了，在需要進行一點小的修改時，我往往需要花很長時間去尋找到底該改哪裡，十分吃力——這種吃力感是我在那些精心思考的大項目里從未感受過的。這說明了，我並沒有過人的天賦能在混亂中輕易找出清晰的脈絡，那就是說，之前的如魚得水，是因為好的習慣。

後來，我進行了深入的思考。在模塊劃分合理、抽象合理的程序里，我可以簡單的把一個個功能抽象為一個簡單的黑盒，我不需要知道他們內部發生了什麼複雜的反應，我只需要知道他們對什麼樣的輸入會做出什麼樣的輸出。這種抽象極大的減輕了大腦的負擔，讓我可以把精力更多的投入到真正需要考慮的地方。而那些混亂的程序里，我需要理清每一句話之間的關係，這無疑會極大的消耗腦力。這種情況下，200行就渾身難受就可以理解了——因為我用於維護項目關係所消耗的腦力已經遠遠大於了那些好程序里的消耗。

這個習慣，真的讓人十分受益，請一定堅持。剛開始的時候，你或許覺得花很長時間去思考程序的模塊劃分、抽象層級是十分浪費時間的無用功；但久了以後，你就會感受到這種習慣帶來的好處：它會在無聲無息之間幫你消除掉許多瓶頸。而且還有額外的好處：當你習慣用模塊化組織你的思維時，思維能力也會有一定的增強。

寫Unit Test!
很難堅持，但是一旦這麼做了就會覺得當初的決定太正確了。
（有空再補充）

哈，這真是一個有意思的問題。

一些朋友說的比如儘早習慣做版本管理，一開始就形成良好的代碼風格，我很贊同，另外一些朋友提到DRY原則，大括弧對齊，甚至還有free(p);p=NULL;這樣的建議，都是很容易誤導人的，這裡希望剛入門或者入門不久的朋友們學會獨立思考，凡事打個問號，不要盲目遵循。

我個人覺得最重要的一個習慣其實有不止一個人說了，就是想清楚之後再動手。這裡我稍微展開說一下，因為「想清楚」其實是一個很模糊的概念。怎樣才算想清楚了呢？

我常常有這樣的經歷，對一個難題，經過了一番思考之後覺得自己想到了一個比其他人好得多的方法，結果去實現的時候，發現原來是想的時候疏漏的一個細節，方法不可行，感到很挫敗，不得不回頭過去重新審視問題，浪費了很多時間。

怎樣才能想清楚呢？

Leslie Lamport在斯坦福做了一個講座（底下有鏈接，推薦）。裡面引用了一句話： 「Writing is nature『s way of let you know how sloppy your thinking is」 我深有同感。怎麼才能知道自己是否想清楚了呢？最自然的方式就是寫下來。怎麼寫呢？這個因人而異，比如我在編碼之前，會在如下兩個問題裡面迭代幾次。

0. 做什麼？（需求：白話）
1. 怎麼做？（方法：偽碼）

關於做什麼，其實就是分析需求，這裡跟那個「需求分析」過程有些區別。怎麼舒服怎麼來，大白話，不拘一格，理清楚問題就行。我通常的做法就是以自言自語自我審問的方式把整個過程理出來，為了不至於特別無聊，這部分通常會寫得十分口語化。等這部分弄清楚之後，基本上偽代碼的框架在心裏面就有眉目了。接下來會嘗試著寫偽代碼，寫偽代碼的途中通常會不斷的進行重構或者跟第一步進行迭代，直到偽代碼比較精簡，邏輯上沒有冗餘的時候，就去喝杯咖啡，小個便，回來開始實現。實現的過程中難免會有需要回到第一個步或者第二步進行迭代的時候，隨著經驗的提升，迭代的次數會變得越來越少。

實際上0,1兩步我都是在代碼的頭部大塊注釋裡面完成的，這個部分可以直接成為十分容易理解的文檔。實際中除了這塊注釋，我幾乎不在代碼裡面寫注釋。除了少數實現的trick外。

另外剛才提到寫偽代碼，引出了一個潛在的問題：怎麼寫偽代碼？建議不要嘗試著用演算法導論或者一些論文裡面的方法。那些數學符號或者不容易敲打的符號會嚴重的影響寫偽代碼的快感。我覺得《The algorithm design manual》裡面的偽代碼格式就不錯，但是因為實際中的偽代碼可能比寫一個演算法複雜一些，所以還需要添加一些其他元素，比如我自己的偽代碼格式其實有點像是Python代碼。寫偽代碼的主要目的是弄清楚實現的邏輯。

在第0步，其實不是每個人一開始都能寫得清晰的，需要通過長期寫作來鍛煉。所以無論是寫日記，寫博客還是寫情書，堅持下去，都能對日後寫代碼的能力有所幫助。

時間不早了，最後再附送兩個程序員生活小貼士：
0. 做筆記，OneNote或者EverNote，把遇到的bug，看到過的好trick，好文章，好照片都記錄下來。
1. Eat your own dog food. 那些自己寫過的可以抽離出來重用的代碼或者腳本整理好同步到github或者bitbucket上去，不斷增加和改善自己的dog food。

Update 2015-07-22:
評論里幾個人提到free(p);p=NULL;是一個合理的建議。我想支撐這一點的理由是「懸空指針被複用的話很危險」。但是在你的程序裡面每一個p都存在被複用的可能嗎？並不是。所以每一次寫下free(p)的時候就應該想這個問題。然後再考慮是否寫p=NULL；因為害怕而寫下的這些冗餘代碼會極度影響代碼的美觀，這也是我認為從free(p)到p=NULL不應該成為一個順手的習慣的原因。
---
https://www.youtube.com/watch?v=6QsTfL-uXd8

原回答就一句話：請堅持：不要追求完美。

我解釋一下。

我說兩個比較虛的回答：

一、請堅持：不要追求完美。

不要有代碼是「在一開始時設計好」的想法。

相反，請相信軟體應用系統是自己有生命的。它會在自身成長到一定程度時，反過來作用於它的設計。為什麼？雖然程序員看起來像是程序的上帝，但其實軟體應用系統會發展成什麼樣子，本來就至少由寫程序的，提需求的，以及軟體自己的現狀決定的。

所以，微信為什麼是這樣子，QQ 又為什麼會是這樣子，微軟的Window 10又為什麼會是這樣子，等等等等，都不是當初最早那位設計者完全能想到的。

再者，就算你真能決定一切，但當下的你哪怕作為一個程序員，也不是完美的，不完美的你怎麼可能寫出完美的代碼？事實上有十分本事的程序員，也應當堅持從寫六分（及格）的代碼開始。

堅持不追求完美，和你的代碼一起成長，多少擁有一點產品經理的思維方式。

二、請堅持：寫代碼的時候不要掏鼻孔。

（大概）20年前，我身邊就有一位少年科大出來的高材生。他曾是我的偶像，剛認識他時，他負責做一個某產品的動畫。他負責演算法方面的數學知識。他總是下午3點才出現在位置上，他不拘小節，一件外套能從今年10月穿到來年5月。他寫演算法或寫代碼時，總是不斷地掏鼻孔，彷彿那些美妙的演算法思路，總是要伴隨著鼻里的掏出一顆比較大的成果一起出現。有一天作為低好幾個級別的我有幸和他結對編程（後來這麼叫的，當初我們只是出於原始需求地結對，並不懂「結對編程」的理論）。我覺得我苦練五筆字型一分鐘200個字元的指法跟不上他的思路，一切卡卡的……終於發現原因，是鍵盤裡有太多泥垢，打著字生生是「嘈嘈切切錯雜彈」的感覺。只好將鍵盤翻個身於背後猛拍，看著「大珠小珠出鍵盤」，我心想這是師兄一年多的心血吧？作為新人我一定要努力。

後來我離開師兄，離開那家公司，但後面有十年時間，不管到哪家公司，我都永遠斜挎一個長長的電腦包，電腦包的背帶必然要松得很長很長，以確保包能夠在我膝蓋那個位置不羈地晃蕩著。曾經有一位領導在電梯里看到我這形像，善意地提醒我改進。我嘴上沒說，卻在心裡懟他（「真正的技術牛人，不都這樣嗎？」）。

至於鼻屎……那當然是我編程時的標配，桌面上一杯劣質咖啡。桌底下是從賓館裡帶回來的拖鞋，拖鞋裡的襪子時有破洞，偶爾寫代碼寫得急了煩了燥了，直接把腳丫子放到椅面上當一回扣腳大漢……寫的是代碼，心裡卻以為是《廣陵散》。

那十年我一事無成。幸好因緣巧合，我突然間醒悟過來，程序員，特別是優秀的程序員不一定要這樣子。於是我開始在寫代碼前，檢查一下指甲是不是太長，照個鏡子看看是不是鼻毛外露需要修理；我開始有人生中第一雙上千元的皮鞋（我知道很便宜，但這是相對於我一直穿2，3百元的），開始穿西褲，開始學扎領帶，開始自己買咖啡豆，開始願意去發現原來有針對瘦子的修身的襯衣；我甚至開始交錢去學習如何發聲，如何習慣性地對眾生（其實主要是屏幕）露出微笑。

關鍵是，當我微笑著面對屏幕時（當然，也不扣鼻孔和腳，上半身直挺了，下半身伸展了），我發現我寫的代碼也不那麼極端了，我用的設計模式明顯地少了；我的代碼質量和效率居然雙高了，我開始擁抱「代碼並不是一開始你就能把它寫優秀」的想法了……終於，我記得有那麼一天，獨自一人代碼寫著寫著寫著，感覺很爽時，突然間有個85後過來叫我「總監，有個演算法我們總是搞不定，能不能支持下？」

「嗯？」

我居然是總監了？我下意識是收緊了自己因為長年掏鼻屎而變大的鼻孔。因為去年年底員工意見總結中，有幾位匿名意見反應說，技術總監總是一對大鼻孔向下，不僅顯得傲慢，而且很醜。

我有些懊惱，我本應在十三年前就是技術總監了，那時候我鼻孔並不大。

所以我覺得要向新人建議：從你寫代碼的第一天開始，就堅持寫代碼的時候不要掏鼻孔。

好的代碼讓人賞心悅目。我在Google經過training之後，對代碼格式很苛責。寫點我的淺見：

1 代碼格式，哪裡空格，哪裡縮進，確定清楚。
2 變數，函數名命名規則，下劃線還是駝峰，產量vs變數，定清楚。
3 注釋。世界上最痛苦的事情，也是經常發生的事情，就是發現自己讀不懂自己3個月前寫的代碼了。尤其是一些臨時處理的地方，或者是一些拐了很多彎的地方，尤其要加註釋。
4 模塊化。能提取公用邏輯的地方盡量提取，千萬不要copy paste，出bug的幾率極高。
5 注意效率。寫代碼的時候需要時刻考慮效率問題，盡量採用簡單的辦法。對於耗時的操作，最好紀錄中間結果，方便後面reuse，而不需要從頭再算。能用庫里的n log(n)的快排，就別自己手寫buggy的冒泡。
6 節省空間。有時候空間和效率是矛盾的，但很多時候都不一定。節約空間，減少不必要的內存使用，一些內存，比如map，不用了記得清空（如果不被自動gc的話）
7 多考慮corner case。異常情況對考慮一下，邊界情況多考慮一下，這是最容易出錯的地方。

祝大家happy coding！

有很多：

先弄明白軟體產品要解決的業務問題
先搞明白自己負責的部分對應的業務
先想清楚邏輯和設計，再開始寫代碼
類、函數、變數的命名要有意義
文件名要有意義
先和與自己有交互的隊友討論介面
關注隊友的進度，協調一致
代碼自己測試通過再提交給測試
每次提交代碼（svn、git），要寫日誌
遇到困難，先搞一搞想一想，再請教他人，不要不想就問，不要悶頭搞不問
預判任務要延期，提前告知領導
有進展及時告知領導
有問題及時告知領導
每天早上先想想今天做什麼，1、2、3，列出來，每天晚上下班時回顧完成了什麼、什麼沒完成、遇到什麼問題
每周總結工作，彙報工作
每個項目做完，回顧一下，看看用到了什麼知識、技能、工具，總結、記錄，和以前積累的知識、技能做關聯；有教訓也記錄下來；有經驗也記錄下來。
用小白的態度和需求、產品交流，不要用技術懟人家
把自己當作用戶，每天用用自己寫的軟體
加班前通知對象（男朋友或女朋友或老婆或老公），保持手機暢通
保持頭髮乾淨整潔，不要油膩和頭皮屑

遇到不清楚或不懂的知識點，先去看官方文檔！
先！去！看！官方！！文檔！！！！

很多官方文檔是英文的，硬著頭皮也要看！看著看著就習慣了。

剛開始讀英文文檔會費時間和精力，但是等你回過頭來再看，你會覺得這才是最恰當的選擇。

為什麼醬講？
且不說你的英文水平得到提升（這是程序員無法迴避的問題），耐性得到鍛煉，什麼叫官方文檔？！兩個痣：權威！準確！當你習慣了在百度上百度一些似是而非，似懂非懂的答案時，甚至有的文章觀點完全不一樣，你就會懂我在說什麼了。
當然，我並沒有否認網上有好的答案和文章，我自己也經常看別人的博客。只是，作為初學者，你的水平很難去辨別一些文章，觀點的好壞對錯，而這可能會對你理解一些知識帶來致命的誤導！

所以，作為初學者，我們應該多讀官方文檔，不要浮躁，要知道任何成長都沒有捷徑！

共勉。

講一個最好的習慣：

不管是寫代碼還是做一件事情，都可以隨意拿支筆、拿張紙，一開始勾畫一下思路，或者有條件就用白板最好了，可以隨意塗鴉與擦拭。

我就是這樣應對一些比較煩心的思路，往往理一理就清楚許多。

還有一個習慣，也跟編程有點關係，就是沒思路了就去打一套太極拳，然後洗個澡，往往豁然開朗。

其實只要堅持一點，你就完勝80%程序員

先想清楚再動手

不要把目標設定為「學會」，而是要「做好」。

注意這裡的區別：一個是「學」，一個是「做」；一個是「會」，一個是「好」。

應該是 @姚冬說過的吧？

編程本質上是一門手藝。

什麼是手藝？「三天不練手生」的功夫。是手上的功夫，不是嘴皮子上的功夫。不是「我覺得我懂了」：第一「你覺得」不靠譜，第二「懂了」也沒用，必須要「做」出來才行。

這就是我為什麼在視頻里苦口婆心一遍又一遍的要求大家「不要只是看我做，要自己去敲一遍代碼……」的原因。

為什麼用人單位這麼看重工作經驗？你說我語法都會了呀，原理我也懂了呀，為什麼呀？

為什麼？你自己想一想你和多年工作經驗的前輩差的是什麼。

我看年輕人，第一就是看他有沒有動手的能力。那種學了一學期的JAVA，自己電腦上連個環境都搭不起來的人，連IDE都沒玩兒熟，斷點調試啥都不會的人，基本上都是不適合做開發的。

一開始就能夠把代碼擼起來的人，往往能夠走得更遠，更穩。

當然，只知道擼代碼，可以成為一個很不錯的匠人，但怎麼才能成為一個巨匠，成為一個大師呢？

但我這裡要特別特彆強調：請首先成為一個合格的匠人！我明顯的感覺到，太多的同學太多的浮躁。不屑什麼「一輩子也就是個碼農」，「碼農」也不是你想做就做的，碼農也分「好碼農」和「爛碼農」，恐怕很多人一輩子也做不成一個合格的碼農。

以下僅供參考，別人也還在路上。

多問幾個為什麼，學習工作中始終帶著問題。

我只能從工程開發的角度來舉例子。

比如你學語法，學了抽象類和介面，很多面試都會問你他們的區別。掌握他們語法上的區別是第一步，但你有沒有一個問題：有了抽象類不就夠了么，為什麼還要介面呢？為什麼呢？

因為這涉及到「用」的問題，當你自己寫代碼的時候，你是該用抽象類呢，還是用介面，你應該有一個說法。不能隨便啊！這個東西。當然，我知道，很多人其實就是「隨便」的。

比如你學設計模式，知道了可以用一個Factory，從Factory裡面Create一個對象。但你有沒有問過：為什麼要弄這麼一個Factory出來呢？你有沒有在項目中真正的嘗試過這樣做呢？結果如何呢？

比如，……，太多比如了。

你要明白，是這一個又一個的問題，引領著你在技術的道理上一步一步的前行。有問題，才有可能有答案。自己提出問題，自己找到答案，才會是你自己的知識。

日復一日的重複勞動，只是因為你沒有主動的去思考，絕不是因為你沒學什麼「數據結構和演算法」（當然，有空了了解一下也可以，但哪裡算得上什麼大事？）

+++++++++++++++++

參考：講課這些天（五）怎麼才能把代碼寫好？·一起幫

收錄於：野生程序員，歡迎關注。

代碼風格。
少用讓人一眼看不明白的技巧。

我結合自己和從同事學來的經驗總結了一下：

認識和熟悉所在團隊中的成員（筆者之前一直做得不夠好，這一條遠比想像中重要，內向性格有時候會比較吃虧），良好的溝通和協調能力能幫助你更快完成(或者委託)任務。
確保正確了解需求，確保熟悉所做的業務；需求分析；適當設計。流程圖或者文檔有時候可以幫助理清楚業務。比如知乎有 rfc 機制，每次做一個稍微大點的需求都需要寫設計文檔。
番茄工作法，勞逸結合(working smart rather than working hard)，一次只做一件事(do one thing and do it well)。長時間專註寫代碼是非常消耗精力的。確保編碼期間足夠專註。快速迭代。
邊寫邊測，增量式編程。雖沒有使用 TDD 開發的習慣，但是對於稍複雜的邏輯就要寫單測，以便及時發現錯誤，越早發現越容易修復(修復成本隨時間指數增加)。我習慣用文件變動監控工具(when-changed fswatch等)檢測文件變動，每次保存文件自動跑相關測試(比如 nose pytest 等都可以執行單個文件或類的測試,你可以快速驗證當前代碼是否有問題，及時修改或者重構)。TDD 的好處之一就是改善設計，自頂向下考慮，筆者有時候也會嘗試用 TDD。
注釋先行，意圖導向，牢記可讀性可維護性。寫一個模塊、類或者函數之前先想好它的功能，按照功能命名，之後寫簡單的注釋描述其意圖和功能，通常不超過三句話，雖然大部分時間只有一句話(只做一件事) ，但是能快速讓後來的維護者了解你的意圖。讓別人快速了解你代碼的意圖
文檔驅動編程(Document Driven Development):比如寫一個腳本的時候，應該在文件頭部註明需求地址 url(保證代碼功能、意圖等是可追溯的)，寫下實現方式和目的等。有時候對於很複雜的業務邏輯筆者會用自然語言描述步驟，之後再用代碼實現。對於需要經常維護的代碼，必要的文檔是值得的。
邊開發，邊重構。如果有代碼寫糙了（圈複雜度太高、可讀性差、代碼重複等壞味道），應該及時重構不好的代碼，這時的重構成本是最小的。代碼寫得複雜到自己都快看不懂了是個危險的信號。
善用工具。比如筆者使用的 vim 插件 python-mode 集成了 pylint、pep8、pyflakes、autopep8、isort 等工具，方便快速檢測代碼是否有語法錯誤和規範問題。每次保存文件後我都會在 vim 里執行一遍 pylint 和 pep8 檢測，確保代碼在規範上沒問題。 (即便如此動態語言依舊很容易犯錯，比如使用了未定義的屬性，參數個數不一致等開發工具都不會報錯，但是一上線就報了異常，所以動態語言編碼還是需要很謹慎，同時通過良好的編碼習慣、測試和 code review 來消除缺陷，有些同事說用動態語言寫大型項目會睡不好覺，不無道理。目前筆者所在的小團隊就在 CI 上加了 flake8，pylint 檢測，代碼寫糙了過不了，同時所有同事提交之前用 autopep8 格式化代碼，用 isort 整理導入包順序，避免了風格不統一的問題)
結對編程。結對編程和TDD是極限編程中大力提倡的，國內似乎沒有多少公司在實踐，一般幫助新人了解項目或者帶實習生的時候，結對能幫助新人快速上手。最簡單的方式兩個人共用一台電腦，或者使用 tmux attach 到同一個 session 里（可以用 vim/emacs 等終端編輯器，新時代的編輯器 vscode, atom 已經支持共享編輯了），兩個人可以同時編輯代碼，相當基情。

像題主說的代碼格式的問題，能用工具就用工具格式化，就能少操心這種問題。比如 go 語言的 gofmt，python 的 autopep8。

下面這些原則能了解下更好，都是前人總結出來的：

KISS原則，Keep It Simple, Stupid。能簡單的絕對不要複雜，不要炫耀代碼技巧，簡單可讀最重要，後人會感謝你的，軟體構建的核心就是控制複雜度。開發可以工作的、最簡單的解決方案。除非有不可辯駁的原因，否則不要使用模式、原則和高難度技術之類的東西。
DRY原則，Don』t Repeat Yourself。代碼複雜重複了就及時抽取出來，至少不會碰到大問題。當然不要矯枉過正，過度追求設計和通用可能導致難以維護和理解。重複代碼一旦介面變動的時候就是災難，要修改很多地方，一定要十分警惕代碼重複(警惕複製粘貼)。事不過三原則。Prefer duplication over the wrong abstraction. - Sandi Metz
YAGNI(You Aren』t Gonna Need It)，不要猜測性編碼，不用的及時刪除，估計以後也不太可能會用到，冗餘的無用代碼會給維護者帶來很多混淆和麻煩。Build the simplest thing that we need right now。『少即是多』
SLAP(Single Level of Abstraction Principle): 保持一個方法中的代碼在同一個抽象層。
Clean Coder Rule: Always leave the code cleaner than you found it. 不用的代碼及時清除，留著只會造成冗餘和誤解。
快速失敗，靈活使用斷言。契約式編程(先驗條件和後置條件)，越早失敗，越容易排查錯誤。
增量式編程。及時清理技術債務，代碼壞味道，防止『破窗』。及時重構不合理代碼，及時進行測試，『慢即是快』，越早發現錯誤修復成本越低。很多統計數據的結果都顯示，一名程序員在公司每天能產出的工業級別的代碼不會超過百行。
隱藏複雜性。如果複雜性避免不了，應該盡讓內部複雜，介面要保持簡單易用，而不要因為業務邏輯複雜就堆砌一堆shit。合理抽象，隱藏細節。
一次只做一件事(Do one thing, and do it well)。盡量避免複雜度過高的邏輯，盡量做到代碼簡單，意圖明確。
高內聚，低耦合。模塊化。層次化。意義相近的東西應該放到同一個地方。寫代碼的時候想著怎麼測試它就能避免過度複雜，耦合嚴重的代碼。
代碼應當易於理解。《代碼大全》、《編寫可讀代碼的藝術》、《代碼整潔之道》啥的都是告訴你代碼最好自解釋，好理解。記住代碼首先是給人看的，其次才是讓機器執行的，不要過度設計。同時警惕你覺得過於『精巧』的實現，很有可能成為以後代碼維護的大坑。可讀性基本定律：代碼的寫法應該使別人理解它所需的時間最小化。聰明的程序員可能寫出複雜、精巧的代碼(但是對於整個團隊的維護來說未必是好事)，專業的程序員會寫出可讀性高的代碼。
不要過早優化，最小可用原則。先測量(profiler)，後優化。根據二八定律，大部分性能瓶頸只在20%的部分，這些才是真正需要優化的地方。
不要炫技，可讀性最重要。合適的地方使用合適的技巧，不要過度炫耀語法糖導致維護和理解困難。大部分人不是造輪子的，你用不著太多奇淫技巧。
不要重複發明輪子。遇到問題首選穩定可靠的解決方案。比如處理excel報表等直接用pandas提供的函數非常方便，我經常看見還是有人自己寫一堆噁心的處理函數而不用pandas。如果自己造輪子確保測試和文檔，否則後續維護和上手會有很大成本。
自動化。重複執行的任務應該使之自動化，你用的python是寫自動化腳本最合適的語言。
Think about future, design with flexibility, but only implement for production. 盡量設計良好，避免繁雜和冗餘。好的架構和設計都是不斷演進的。
文檔化。哪些東西該文檔化，哪些該注釋需要做好，以便新手可以儘快上手。盡量做到代碼即文檔，tornado的文檔和代碼就是典範。
服務化。項目做大了以後及時拆分業務，保持單個代碼倉庫大小在一定規模。超大規模的代碼倉庫在部署和維護上會遇到很多問題。
不要直接吞掉任何非預知錯誤和異常，一定要做好記錄。血淚教訓，使用Sentry或其他工具記錄好異常發生的信息，為定位bug提供便利，web端的bug一般不好復現。
墨菲定律：只要有錯誤發生的可能性，這種錯誤就一定會發生。所以對代碼質量要嚴格要求，不要心存僥倖。
單元測試:F.I.R.S.T原則(Fast，Independent，Repeatable，Self-Validating，Timely)

編碼之前碎碎念(工程實踐) - python-web-guide 0.1 文檔

坐直

- 初學編程請盡量用有智能提示的ide，並學會看報錯，並且善於使用代碼格式化功能

- 學會用英文搜索問題，bing（國際版）的英文搜索效果還是挺不錯的……比如搜索string to int會像百科一樣直接出代碼

閱讀手冊！閱讀手冊！閱讀手冊！
重要的事情說三遍！
當你遇到問題的時候，第一時間去翻手冊尋找答案，不要google！使用搜索引擎可以更快的幫你找到答案，但是也僅限於給你答案！
簡單來說一句話：read the fucking manual!

很多，讓我一一道來:

任何代碼都不要上來就寫，先想一想，畫個圖，做個規劃；
用有意義的標示符名，別用拼音；
寫代碼之前先寫單元測試；
用機械鍵盤，別用青軸；
不管多投入，每隔一個小時要起來活動一下，望一望遠方；
時不時想想一個代碼重寫一遍會怎麼改進，當然並不意味著你一定要去重寫；
如果你不喜歡一種語言，也不要浪費時間和這個語言的粉絲論戰。

7條，因為我喜歡7這個數字。

了解更多行業道理請關注 @程墨Morgan

使用代碼規約(公司有按公司，公司沒有按微軟谷歌標準)
使用IDE（如果不是IDE那麼請使用幫助編程的插件）
使用調試器
單元測試
自動部署
不要過早優化（不管是性能還是架構設計，除非你水平到達一定水準知道結果必然如此）
結構化思維
多造輪子

總結起來就是做那些事情可以讓編程：溝通（簡單，易懂，易合作）+效率（自動化+技藝）更好
用一個詞總結目標就是：簡單

1.多做筆記，普通的筆記寫成文檔，方便檢索；深入理解的問題寫成博文分享知識。
2.多整理代碼片，提高重用性。
3.多和同伴交流，編程不是為了純粹的打代碼，而是為了完成項目，為了盈利，所以團隊意識很重要，程序員如果見識廣經驗多後很容易自我感覺良好，這樣對團隊是很不好的。

要及時、分多次向代碼庫提交代碼，不要等到最後一次性提交。

0. 版本管理，每天結束工作 push remote
1. 認真對待每個變數名
2. 不要硬編碼
3. 多去 github 和程序員社交

編程中，有哪些好的習慣從一開始就值得堅持？

一、請堅持：不要追求完美。

二、 請堅持：寫代碼的時候不要掏鼻孔。

二、請堅持：寫代碼的時候不要掏鼻孔。