在我寫了10來年程序之后，或多或少有一些心得，希望在這里做一個總結分享給大家，為了不讓本文變成一篇和其他總結問類似的水文，我盡可能用自己的親身經歷來告訴大家編程中遇到的問題和解決思路。

[[321138]]

1：磨刀不誤砍柴工

磨刀不誤砍材工這個故事相信很多人都聽過，但是用到自己身上可能就是失效了。

我們很多時候都是在邊寫程序邊思考如何去寫，中途遇到問題又可能會推倒重來，不管軟件開發的規模大小，一開始都需要對需求做詳細的分析和設計才能開工。

多花時間在傾聽用戶的需求和問題上。

“思考-編碼-測試-改進“，不斷的重復這條路去做。

2：自動化一切

作為程序員，我們干的事情本質上是讓世界的所有事物變得高效、有序，但是很多時候我們自己的工作過程卻不是這樣的。

比如我寫完代碼后通常會重復以下一系列的操作：提交代碼庫--合并分支--檢查沖突--集成測試--登陸線上服務器--拉取最新的代碼--重啟服務實現版本更新。

這些操作都是重復而機械的，每一步操作可能都要噼里啪啦敲半天鍵盤，輸入大段大段的命令才能搞定，看起來很酷很炫，其實非常低效，畢竟我們是程序員，不是演員(黑客娛樂圈。。。。。。)

每次做完這些事情，起碼要花掉我1-5分鐘的時間，如果每天重復10次，可能最多需要花掉我接近1小時的時間在這上面，完全不值得。

而把它自動化之后，我可能只需要敲擊幾下鍵盤就可以迅速把最新的代碼變成產品上線了。

自動化的方案有很多：大到各類CI/CD工具，小到一些具體的自動化工具，例如(Fabric、Ansible等等)都可以幫我們自動化這些瑣碎重復的事情，不要嫌編寫自動化腳本很麻煩，你只需要編寫一次，但是永遠受益。

3. 最小可行性產品

什么是最小可行性產品?以下這個圖所表現出來的現象經常出現在軟件開發領域。

客戶以為的產品和我們做出來的產品完全不同，究竟是需求不明確、研發能力有限還是什么?

其實換個角度想想，如果我們一開始就把最小可行性的產品以最小代價、最快速度拿出來給客戶演示也許效果更好，他會更加了解自己想要究竟該是什么樣子的產品。

4：有效的調試

軟件開發離不開調試，很多人都習慣用print在程序里到處輸出變量值來調試(當然我很多時間也這樣，因為簡單)。

通過輸出日志或者編輯器自帶的各種調試功能，可以更方便的我們收集錯誤信息。

習慣用調試工具來尋找問題吧，print真不是個好選擇。

5：代碼優雅與有效的平衡

作為一個有追求的程序員，我們無時無刻都在追求代碼的優雅簡潔。據我自己的經驗，通常我們在做出復雜問題思考的時候寫的代碼都是測試性的代碼，它可用，但是不好看，因為通常在思考復雜問題時寫簡潔優雅的代碼，會加重我們的大腦負擔。

最終當我們把問題解決完之后，之前測試性的代碼已經作為正式代碼開始工作了，我們又舍不得或者說懶得刪掉它重新用簡潔優雅的方式來寫。

這需要我們給自己設定一個下限，哪些代碼是必須要馬上重寫的，不能欺騙自己說一個月之后再來重寫，相信我兄弟，一個月之后你早忘了這件事了。

你能說出以下兩段相同功能的代碼哪段更優雅，哪段更適合閱讀嗎?

if obj.is_anonymous: 
  return obj.user.nickname 
else: 
  return '匿名用戶' 

return obj.user.nickname if not obj.is_anonymous else '匿名用戶' 

6：良好的溝通與交流

作為程序員要記住一個準則，同事和客戶不是敵人，他們只是想以自己擅長的方式完成工作。

我們也是一樣，可是不同背景、經驗的人出發點可能是不同的、程序員經常覺得產品、市場的同時都是智障，相反他們也是這么認為程序員的，矛盾通常在工作中產生

學會以溫和的方式傾聽訴求，克服自己的不適感，當我們真正理解對方的想法時，我們也就知道該如何做事情了。

7：完善的技能棧

程序員除了編程語言之外，感覺還要學很多東西才能滿足工作的需要。

實際上是這樣的，如果我們的經驗和知識只是在程序如何編寫上，其實不配稱之為一個程序員。

網絡你要不要了解?操作系統一些基本原理呢?編譯性語言語言和動態語言是不是都得會一點?數據庫要不要了解一下?

有些工具型的知識我們不需要了解，但是有些基礎型的知識我們必須知道。

8：學習能力與技巧

遇到一門新的技術，我們最快多久能學會它并開始做出產品來?

學習一門新的語言，學的不是語法，那玩意大同小異，我們學習的是它的特點是什么、在什么時候最適合用它、它和別的語言最大的區別是什么。

在技巧方面我其實沒太多可說的，只有一句話 帶著問題去學，當我們抱著解決問題去有針對性的學習新知識，效率會更高。細枝末節太多，需要優先找到主干。

9：分享精神

我們在網上遇到了問題就去搜索，嚴格來說很多程序員都是面向百度編程，面向google、stackoverflow編程。想象一下，如果沒有人分享自己的心得，把解決問題的方法貼出來，我們去哪里搜索，只能自己抱著書慢慢看了吧?

有人說我怕寫出來寫得不好或者懶得寫，其實分享自己知識的過程就是一次學習提煉的過程，你可以通過這個過程來回顧整理自己的知識點，看看是否有盲區。

10：好的產品定義

能解決問題的產品就是好產品，不在于它的界面多么精美、操作多么順暢、功能多么強大。

用戶希望做一個電商小程序，讓他的客戶通過小程序選擇商品、下單購買，如果用戶能建立幾個微信群，他所有的客戶都在里面，然后每天發幾個表格收集、用戶微信轉賬就能完成商品的選擇和購買行為，是不是一定要做一個程序才能解決問題?

個人好的產品在于解決問題，不在于程序員的自我滿足。