編程的一些小習慣

作者：曹政

原文鏈接：編程的一些小習慣

說來很久沒有寫關於技術的分享了。

主要是每次寫技術相關，訪問量，轉發量，讚賞，都很差，好吧，都是借口，還是自己不夠淡定，寫的不夠好。

今天寫一點很久之前，自己還在做程序員的時候，一些編程的習慣，希望對剛進入技術領域的朋友，一些可以參照的經驗。

1、先做核心模塊的壓測

在對整個項目做設計，做規劃的時候，第一步，先要對系統負載最高，開銷最大，或者可能請求量最高的部分，先把這部分最基本的數據結構和操作邏輯寫出來，然後壓力測試。

嗯，應該是我水平不夠高吧，一直對很多這種問題信心不足。所以對一些沒有把握的地方，會提前做壓力測試，做性能測試，確保都ok後，才正式完成數據結構設計和系統的設計。如果發現有問題，就一直調整，測試到符合預期為止。

我覺得很多程序員，習慣把東西做完，然後等著快上線的時候才做性能測試，那麼如果前面設計出了問題，這個就很頭大了。當然，後期快上線的時候也要做性能測試，但前期的我認為還是很重要的。

當然，做好這一點，需要懂一些業務，你要知道業務壓力在哪裡，業務請求的重心在哪裡，很多時候，產品經理不講，你也要問清楚。

2、確保過程可控

以前做數據分析的時候，經常要對數億條日誌做分析，做處理，包括基本的分析，關聯規則等等。（那時候也沒大數據的概念，少了很多吹牛逼的資本）

那麼完成一次全日誌的分析，通常可能需要幾個小時，如果代碼再出一點狀況，或者有什麼差錯，那一天就荒廢進去了。

我養成的習慣是這樣的。

第一，先從小數據量做測試，驗證分析的代碼，和測試數據返回結果，是否符合預期，策略和步驟是否合理。

第二，代碼執行時一定要保持中間的輸出，比如說，每處理10萬條日誌，寫一條狀態日誌，記錄處理的日誌條目數和當前的執行時間，有的時候也記錄一下資源開銷（有時候跑不完資源會崩潰掉，比如內存溢出，這時候需要回訪一下，評估一下並想想如何優化調整）。這個執行時間記錄也很關鍵，基本上可以在執行的時候，預估大概的結束時間，比如出去喝個咖啡，找人扯個需求，知道程序大概多久可以執行完。

如果一個分析程序跑著，沒有進度展示，不知道幾個小時可以跑完，可能會非常浪費時間。

第三，斷點可續，因為日誌的數據量非常大，內存有大量的中間數據需要保存，有時候，代碼跑著跑著，內存就崩潰了。

話說，我老說自己是經濟適用程序員，講真一句，不論是線上的負載應對，還是線下的海量日誌分析，我都是用配置很普通的破伺服器跑的。

那麼這種，一方面代碼去調整，另一方面，如果每次都重頭去跑，那其實反覆花費的時間還是相當長的，所以，分析程序，儘可能做到，可以在中斷的地方，或者上一個可控的斷點重新開始跑。

前段時間在 小密圈 看到有人分享一些mysql的心得，我發現對方分享的幾乎所有SQL技巧都是我當時儘可能避免的操作，比如 通過搜索批量寫入數據表，這個操作我當時很忌諱的，當然，具體看應用場景，因為我們往往涉及十分巨大的數據遷移，這種SQL 很可能導致中間過程不可控，如果在高並發的線上操作甚至導致資料庫崩潰，所以我們的處理原則往往是分批次導入，並且代碼中會記錄導入的批次和狀態，如果出現中間故障，還可以在斷點繼續導入。

3、預留的地方寫注釋

很多時候，代碼寫的自己也不是很滿意，比如某個處理效率不夠優化，某個處理的方法不夠簡潔，或者擴展性比較差，代碼寫的很弱智，但可能短時間沒有辦法想清楚最合理的解決方案，考慮到上線初期這裡並不是重心所在，所以也不會特意去優化它，但這種情況下我往往會留下注釋，並說明下一步優化的可能思路是什麼，或者想到的可行方案是什麼。

當然，慚愧的說，可能超過一半的預留注釋都沒有真正的改進過，但這個注釋，一旦需要修改，就很重要，因為時間一長，真的很多原委都不記得了，需要調優，需要改進的時候，發現以前其實已經有預案，或者能了解當初設計的原委，都是很有幫助的事情。

4、砍代碼是很爽的事情

幸好我沒遇到以代碼量為kpi的公司，我有一個癖好，就是，一旦有更好的替代方案，就會大段大段的刪除原有代碼。如果能用更簡單的結構和更通用的代碼，替代原有羅嗦和重複的代碼，我會覺得是個很有成就的事情。

5、用人人看得懂的邏輯

我們經常說代碼的可讀性。

我剛畢業的時候，去一個公司寫程序，挺喜歡寫特別繞特別羅嗦的邏輯，覺得自己很牛逼，接手的人看著一頭霧水，我覺得自己成就感滿滿。

後來慢慢自己做事情，自己懂一點真正的技術的時候，才意識到那些羅嗦的邏輯其實都是屎，性能低下，毫無意義，而且非常難以維護。

再往後就撿著怎麼簡單怎麼寫，就好比我們說話，把邏輯複雜的長句，分成幾個簡單的短句，更容易理解，也更容易表達，寫代碼也是同理，很複雜的邏輯，拆解一下，分成幾個簡單的邏輯寫出來，很清楚，也很有效率。

而且，從整個架構的擴展性而言，取消連表操作，取消一些關聯度較高的邏輯，更容易實現架構擴展。

6、不要沉迷於框架

很多人寫程序言必稱框架，似乎沒有框架就寫不了程序。

沒必要，比如，就常見的php來說，本身就可以認為是一種框架了，你再套一層，其實也是傷害了這門語言的活力。

團隊開發，用框架，也不是說不可以。但你要知道你需要的是什麼，你遇到的障礙是什麼。

框架最大的問題是什麼？過於繁冗的嵌套。為什麼我一直很煩框架？因為經常遇到需要一秒鐘幾千次請求的處理場景，那麼，調優的時候，有框架真的很頭大，要從數不清的框架中尋找數據處理的邏輯，尋找性能卡點，可能改動代碼只有兩行，但是找問題需要兩天。

框架不是越牛逼越好，所謂牛逼的框架，往往結構更加複雜，特別難以理解其中的數據調用過程。

此外，很多公司會要求員工統一用某一種框架，你倒是熟悉了，出去再找工作，對不起，別的公司不用這個，記住，你的技術能力絕對不能被框架約束住。

7、使用熟悉，成熟的技術。

聽到很多創業公司，因為技術負責人一時興起，用了mongodb，然後就進坑了。

當然，我不是說mongodb不好，而是相關負責人只是聽說還不錯，指標很好，然後就興沖沖的去學習。

現在很多技術人員，習慣說，php太low，mysql太弱，apache太落伍，好，你知道這些玩意的極限性能么？如果你用到了極限性能，發現不行，你去用別的，或者你的業務場景，確實這些不適合，你去用別的，這都合理。我們也是，遇到實際問題，mysql確實不行，加一層redis解決，這沒問題。

很多人，根本沒搞明白自己的障礙和問題在哪裡，根本不知道相關技術產品的優勢和劣勢在哪裡，看一堆第三方的數據測評，腦子一熱，去學新技術，然後，掉進坑裡出不來，如果是創業公司，可能項目就死在裡面了。不開玩笑，我都遇到過好幾個這樣的了。我說你們要是mysql，我隨時可以幫你們分析一下，做個優化方案，你搞個mongodb，真的愛莫能助啊。

使用新技術前，建議全面了解該技術的特徵，適用範圍，以及不適用的範圍。

比如，mysql的幾個存儲引擎，Redis的四種數據結構，都有什麼特點，各適用於什麼場景，不適用於什麼場景，如果這個都沒搞清楚，拿過來就用，那麼能不能靈，就只能靠運氣了。

8、細節沒優化前，別談架構。

負載高了，系統穩定性差了，換伺服器吧，架構調優吧。

真不是這麼說的，先把問題搞清楚，看看到底具體原因在哪裡，單伺服器的瓶頸和壓力在哪裡，再來談這個問題。

好多人也來問過我這個問題，想搞個大系統，寫個架構的說明，讓我看看，說有什麼建議，文檔看上去虛的很，每句話都對，每個方案都靠譜，問題是，我說的特別不客氣，我說這玩意一文不值。你先有最基本的系統分析能力，有最基本的調優和應對問題的能力，再來談架構。

好吧，作為經濟適用程序員，我是比較喜歡壓榨單機的性能，但話說回來，單機優化的好和壞，對負載的支撐能力，差距可能是一個數量級，甚至不止。也就是你需要十倍的伺服器來支撐，而且伺服器多了後，各種其他詭異現象，通訊問題，以及內網的數據流量壓力，也都會出現很多風險，並不是說你有錢，加伺服器就能解決的。單機優化到位，然後再針對性能瓶頸，有目的性的擴容，有目的性的擴展架構，這才是真正的架構之道。

9，多留日誌

我特別在意問題回訪，因為經常會遇到線上詭異的問題，那麼核查是非常麻煩的，因為自己總是無法復現，一個無法復現卻又時不時出現的bug是最難處理的。所以，代碼里，以及webserver，以及在系統運維的腳本里，多增加一些日常的日誌輸出，對異常多一些自動的信息採集，這樣，出問題的時候，可以回訪問題時間的信息，對定位問題，分析問題，解決問題，幫助極大。

研發和運維，其實很難分的開。一個複雜的線上bug，需要運維和研發一起協作，才能找到真正的原因。

就這樣吧，如果您不是研發，煩請轉給您熟悉的研發的朋友。

不過，本文並非針對高手的，如果您是高手，很抱歉耽誤了您的寶貴時間。

閱讀原文