1. 解釋你在幹什麽

解釋軟件開發過程是1個很艱難的事情。那些非程序猿崗位的人或許了解許多有關編程的事情，但很顯然，他們不會編程。對於他們而言，我們的生活只是在一間漆黑的房間內趴到鍵盤前消耗著咖啡。

你會在你的朋友、親人和同事中遇上這樣的人，他會覺得編碼並不是1個合理的崗位。

2. 形象的說出軟件解決方案

依據某些簡短的要求——一般是一知半解的，你需要設計出數據結構，軟件架構，代碼算法，通信協議，以及別的任何針對商業問題的解決方法各種構成。並且你必須用某種外行人聽的懂的用語將它們表達出來，並需要在要求的時間裏提交給客戶。

非常少有程序猿能做到這些。

3. 評估工期

這是程序猿痛苦的本源。在開發任務沒有完成以前，你是絕對沒有可能確定完成這個任務需要的時間。或許程序跟之前寫的很類似，但環境變了，問題變了，限定條件變了。

工作經驗會提供一定的辨別力，但多數的程序猿都習慣於低估問題難度。這其中的緣故是他們只考慮到編碼這方面的要素，而忽視了這個任務清單上的其余事務。

應對1個問題可能會有一萬種解決方法，一萬種寫法。接手其他人寫的代碼，代表你要花很多的時間在無數的代碼行裏探尋，了解當時原作者的基本思路。並且，要是是1個不相信註釋和文檔的程序猿留下來的半個工程項目，麻煩事就更大了。

5. 軟件邊界的模糊蔓延和讓人吐血的奇怪功能需求

盡管敏捷開發方法給軟件範圍的膨脹提供了一定的預備空間，但這並沒有帶來任何的功效——特別是在是當你碰到某些由一時興起的怪念頭形成的功能需求。你知道這樣做一定會失敗。你的團隊判斷這樣做一定會失敗。但客戶認為不錯，而當失敗不可避免的出現時，全是你的錯，因為是你沒有了解他們的真正意圖。

6. 在缺少優化和過度優化之間找到平衡點

復雜的軟件永遠不會作到極致；總會有一些更好的實施方案。你完全可以不停的優化下去，這就是說為啥軟件項目從來都沒有提早完工的。

而另一面，“這樣就行——我之後會優化它的”這類心態也是普遍的。代碼今日好使，但你知道明日可能會出現麻煩或不能用。當然了，你是不需要去修改它的，它將會交給下一個倒黴鬼程序猿。

7. 測試你的代碼
單元測試你也寫了，軟件也提交了測試組，但Bug仍舊存有……

軟件是復雜的，將會含有成百上千行代碼。系統中或者存有千萬的各類交互和邏輯路徑；你不可能徹底測試它們。

相似的，軟件會在不一樣的條件下跟不一樣的平臺上的不一樣的軟件交互。你不可能所有的都測到。

寫出好的單元測試是一種乏味且艱辛的工作。理想狀況下，測試應當在著手開發設計前就早已寫好——但你如何向客戶解釋為何4個禮拜結束了依然沒有能用的軟件？

單元測試並不能覆蓋每個問題點。在理想的世界裏，應該有一個獨立的團隊來寫測試並積極的去發現問題。不幸的是，對大多數項目來說，這樣成本太高，時間不夠，於是用開發團隊來寫測試程序。而開發團隊潛意識的會避免很多極端的邊界情況。

程序員喜歡用符合邏輯的方式處理所有問題。但用戶很少是這樣的。他們會發現你永遠意想不到的問題。

8. 寫軟件文檔

給代碼寫文檔是一項費力耗時的工作。很少有程序員擅長這個、喜歡這個的，並且很少有程序員會花時間去讀它們。

9. 處理IT問題

你每天都在研究技術。你也許是一個前端或PHP程序員，但你很可能會遇到一些例如硬盤損壞、驅動沖突或軟件崩潰的問題。解決這些事情不是你的主要責任，但是，除非你解決了這些問題，否者你將無法繼續你的開發工作。

不幸的是，對於IT圈外的人來說，程序員應該是軟硬件都精通的人。當他們遇到了問題，他們自己不花時間就解決，直接會找你。不論是遇到什麽問題：你是用計算機的，你一定知道如何將預算表導入Sage，如何配置Oracle，或為何在他們的黑莓手機上發不出郵件。

當然了，這些打攪絕對不能成為你完不成工作的理由，也沒有報酬，不是嗎？

10. 處理人的問題

上面的這些難題都可以總結為“人的問題”。很少有外行人會去建議1個飛行員如何開飛機或建議一個電器工程師如何布線。但很多人卻會興致勃勃的勇敢的建議如何開發軟件。

我相信對於這些人沒有什麽好辦法。你需要接受這樣的事實：這世界上有一半的智商是低於平均水平的！

自己是一個五年的前端工程師，不少人私下問我，2019年前端該怎麽學，方法有沒有？

沒錯，年初我花了一個多月的時間整理出來的學習資料，希望能幫助那些想學習前端，卻又不知道怎麽開始學習的朋友。

這裏推薦一下我的前端學習交流群：784783012，裏面都是學習前端的從最基礎的HTML+CSS+JS【炫酷特效，遊戲，插件封裝，設計模式】到移動端HTML5的項目實戰的學習資料都有整理，送給每一位前端小夥伴。最新技術，與企業需求同步。好友都在裏面學習交流，每天都會有大牛定時講解前端技術!

點擊：加入

困擾了百萬程序員20年的10大難題！