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

[[321138]]

1：磨刀不誤砍柴工

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

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

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

“思考-編碼-測(cè)試-改進(jìn)“，不斷的重復(fù)這條路去做。

2：自動(dòng)化一切

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

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

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

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

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

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

3. 最小可行性產(chǎn)品

什么是最小可行性產(chǎn)品?以下這個(gè)圖所表現(xiàn)出來的現(xiàn)象經(jīng)常出現(xiàn)在軟件開發(fā)領(lǐng)域。

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

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

4：有效的調(diào)試

軟件開發(fā)離不開調(diào)試，很多人都習(xí)慣用print在程序里到處輸出變量值來調(diào)試(當(dāng)然我很多時(shí)間也這樣，因?yàn)楹?jiǎn)單)。

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

習(xí)慣用調(diào)試工具來尋找問題吧，print真不是個(gè)好選擇。

5：代碼優(yōu)雅與有效的平衡

作為一個(gè)有追求的程序員，我們無時(shí)無刻都在追求代碼的優(yōu)雅簡(jiǎn)潔。據(jù)我自己的經(jīng)驗(yàn)，通常我們?cè)谧龀鰪?fù)雜問題思考的時(shí)候?qū)懙拇a都是測(cè)試性的代碼，它可用，但是不好看，因?yàn)橥ǔＴ谒伎紡?fù)雜問題時(shí)寫簡(jiǎn)潔優(yōu)雅的代碼，會(huì)加重我們的大腦負(fù)擔(dān)。

最終當(dāng)我們把問題解決完之后，之前測(cè)試性的代碼已經(jīng)作為正式代碼開始工作了，我們又舍不得或者說懶得刪掉它重新用簡(jiǎn)潔優(yōu)雅的方式來寫。

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

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

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

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

6：良好的溝通與交流

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

我們也是一樣，可是不同背景、經(jīng)驗(yàn)的人出發(fā)點(diǎn)可能是不同的、程序員經(jīng)常覺得產(chǎn)品、市場(chǎng)的同時(shí)都是智障，相反他們也是這么認(rèn)為程序員的，矛盾通常在工作中產(chǎn)生

學(xué)會(huì)以溫和的方式傾聽訴求，克服自己的不適感，當(dāng)我們真正理解對(duì)方的想法時(shí)，我們也就知道該如何做事情了。

7：完善的技能棧

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

實(shí)際上是這樣的，如果我們的經(jīng)驗(yàn)和知識(shí)只是在程序如何編寫上，其實(shí)不配稱之為一個(gè)程序員。

網(wǎng)絡(luò)你要不要了解?操作系統(tǒng)一些基本原理呢?編譯性語言語言和動(dòng)態(tài)語言是不是都得會(huì)一點(diǎn)?數(shù)據(jù)庫要不要了解一下?

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

8：學(xué)習(xí)能力與技巧

遇到一門新的技術(shù)，我們最快多久能學(xué)會(huì)它并開始做出產(chǎn)品來?

學(xué)習(xí)一門新的語言，學(xué)的不是語法，那玩意大同小異，我們學(xué)習(xí)的是它的特點(diǎn)是什么、在什么時(shí)候最適合用它、它和別的語言最大的區(qū)別是什么。

在技巧方面我其實(shí)沒太多可說的，只有一句話 帶著問題去學(xué)，當(dāng)我們抱著解決問題去有針對(duì)性的學(xué)習(xí)新知識(shí)，效率會(huì)更高。細(xì)枝末節(jié)太多，需要優(yōu)先找到主干。

9：分享精神

我們?cè)诰W(wǎng)上遇到了問題就去搜索，嚴(yán)格來說很多程序員都是面向百度編程，面向google、stackoverflow編程。想象一下，如果沒有人分享自己的心得，把解決問題的方法貼出來，我們?nèi)ツ睦锼阉鳎荒茏约罕е鴷戳税?

有人說我怕寫出來寫得不好或者懶得寫，其實(shí)分享自己知識(shí)的過程就是一次學(xué)習(xí)提煉的過程，你可以通過這個(gè)過程來回顧整理自己的知識(shí)點(diǎn)，看看是否有盲區(qū)。

10：好的產(chǎn)品定義

能解決問題的產(chǎn)品就是好產(chǎn)品，不在于它的界面多么精美、操作多么順暢、功能多么強(qiáng)大。

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

個(gè)人好的產(chǎn)品在于解決問題，不在于程序員的自我滿足。