摘要：解決問題的心態軟件工程師不認為編程是他們事業的全部。好的軟件工程師以經驗和直覺判定。環境與測試軟件工程師寫的程序要保證在不同環境，不同時區正常工作。軟件缺陷是不可見的，我們預測和避免缺陷的能力也是有限的，所以軟件工程師懂得利用工具矯正代碼。

原文 Software Engineering is different from Programming

一些人因為“工程”這個詞而不喜歡軟件工程師這個術語。這篇文章跟這個術語沒什么關系，你不喜歡的話完全可以把這個詞替換掉，改成軟件作者、軟件冒險家或者軟件藝術家！

軟件工程師，把編寫高質量軟件作為他們的專業，把科學和統計學融入其中，而不只是把寫軟件當成賺錢工具。

知道怎么編程不代表你就是軟件工程師。

誰都可以學習編程，這很簡單，每個人都可以寫一些簡單的代碼，這些代碼可以運行在他們的機器上，但不能保證其他機器能否運行。

類比一下：

我們可以學數學但是這不一定能讓我們編程數學家

大多數人都可以學會煮飯，但是正式場合我們還是會請廚師做這件事

你不能叫住你隔壁的勤雜工給你蓋個房子

我是想告訴大家，構建一個軟件比編程難多了。

最簡單的編程是，輸入數據到電腦，處理后輸出數據。

而構建一個軟件是集設計、編寫、測試和維護于一身的，其目的是要滿足用戶的需求。這要求創建健壯的代碼，經得起時間考驗的安全解決方案，有時候還不得不面對一些未知的問題。

軟件工程師要深入理解他們要解決的問題、他們要提供的解決方案、這些方案的局限，以及一些隱私安全問題。

如果一個人沒有深入了解一個問題，他們就沒辦法讓程序去解決這個問題。

軟件工程師不認為編程是他們事業的全部。他們要思考的是如何滿足需求和解決問題。不是每個問題都需要寫程序解決的，而是依賴現成的程序，或者結合多個程序。提早的準備可以避免很多問題，好的程序通常需要詳盡的計劃來預防未來出現的問題。

知識分子解決問題，而天才會防止問題出現。 -愛因斯坦

復雜的問題需要多個程序組合才能解決，有的需要程序并行運行，而有的需要順序運行。當然還有一些問題，可以通過教育用戶來解決。（譯者：所謂的解決提出問題的人嗎?）
寫程序及構建軟件之前先問自己：

我需要解決什么問題？

除了寫代碼還有什么方法解決問題？

用代碼如何讓問題變得更容易解決？

好程序是簡潔易讀的，容易擴展的。他們可以和其他程序協作得很好，維護起來也很舒服。高質量代碼是必須的，因為死線和心情不好而偷工減料是絕對不可取的。

構建軟件重要的一點是貫徹可延展性，你總要更新軟件以滿足用戶更多的要求。

一個多帶帶的軟件有時可能不是很有用。當多個軟件互相交流，交換數據，合作呈現數據和與用戶交互，這個軟件才會變得有意義。

程序設計要時刻思考這些問題。他們接受什么信息？應該監聽什么事件？什么信息被觸發？通信間授權怎么做？

另一個重點是代碼要清晰，而不是給出一大堆測試結果。這段代碼可以被別人簡單理解嗎？你今天寫的代碼，幾個星期后的自己能看懂嗎？

計算機科學里只有兩大難事：命名和緩存失效。 -Phil Karlton

代碼可讀性比你想象的更重要。但是很不幸的是，沒有很好的準則判定代碼可讀性。記住一些設計模式和更多的實踐會帶來幫助，但這不一定足夠。好的軟件工程師以經驗和直覺判定。（要不要寫得這么玄學）

我沒時間寫一封短信，所以我決定寫一封長的。 -馬克吐溫

出錯時容易修復的程序才是好程序。發生錯誤時我們應該可以清晰地看到錯誤報告，并且可以從錯誤報告定位到程序出錯位置，修復人員可以很容易地看懂上下文并修復系統。

軟件工程師寫的程序要保證在不同環境，不同時區正常工作。軟件要運行在不同大小的屏幕，還包括屏幕旋轉，甚至還要考慮機器性能和功率問題。

例如我們為網絡瀏覽器設計一個軟件，我們就要考慮到適配所有主流瀏覽器。桌面應用就要考慮到Mac和Windows甚至是Linux用戶。一個依賴數據的軟件在處理無法檢索數據或檢索緩慢時應有對策。

要寫一個軟件，軟件工程師需要考慮各種不同的應用場景，然后測試這些場景。雖然意外沒有發生，但是仍要列出這些可能發生的意外，測試他們。右側軟件工程師會先寫測試用例，然后讓他們的目標代碼都通過這些測試。

工程師知道軟件需求有時候是模糊或者不完善的。有天賦的工程師的獨有技能不是知道怎么寫解決方案，而是清楚有什么問題需要解決。

軟件工程師在大多數情況下可以快速解決問題。如果你覺得聘請一個優秀工程師成本很高，請你三思。你聘請優秀的工程師，他們提供健壯、精準、可信、可維護的解決方案。這以為這長期成本的大大降低。你需要考慮運營軟件的成本。每個程序都要占用電腦資源，但是高效的軟件可以大大節省資源。如果你雇一個初學者給你構建軟件，價格可能很便宜，但是后來的支出可能會非常高，還有一大堆遺留問題。

好的程序需要考慮用戶體驗。人機交互是一個大熱點，無數研究都與他有關。

讓我給你一下例子讓你感受一下這一點：

設計輸入表單時，如果是郵箱地址，就應該無視大小寫，并去除頭尾空格。如果是接受一個新的郵箱地址，提早驗證是否可用并給出清楚的信息。重點不只是判斷有沒有@，也應該順便判斷用戶有沒有像“gmail.ocm.”的錯誤輸入

使用重定向的時候，一個好程序會記下重定向前的地址，重定向處理完成之后應該回到原來的地址。更好的話，應該吧之前的表單信息也記錄下來。例如你要買機票，找好了某一班機，但是注冊之后又要重新搜索，這樣用戶體驗就不是很好。

好程序為用戶場景設計。站在用戶的角度思考。不要只加 feature 不管后事！一次我訂機票忘了我的飛行常客號碼。前前后后搞了十分鐘。我在網站找這個號碼，沒有明顯路徑可以讓我找到，在找到的那個頁面還把這個選項埋在一個大表格里面，進去之后我還填了 20 個選項甚至是手機號碼都填了，最后才搞定，這就是不為用戶設想的例子。

這可能是區分軟件行業專業和業余的重要一點。他們知道他們要提供安全和穩定的解決方案。

好的軟件對惡意輸入、錯誤狀態和錯誤交互都有所對策。這很難全部做到，也因此讓大家覺得軟件錯誤讓人痛不欲生。

用戶會對軟件進行錯誤的輸入，有些情況是惡意輸入，目的是破壞軟件或者是黑一些數據。最近的 Equifax 事件負責人就被指責沒有盡職于惡意輸入的對策。

安全問題不只是關于惡意輸入，普通輸入也有注意點。如果用戶忘記密碼，你會允許他們嘗試輸入多少次？會凍結他們的賬號嗎？如果是其他人讓他們凍結呢？你會不會讓你的用戶在非加密鏈接輸入密碼？不在常用地點又怎么辦呢？

你如何保護用戶，避免跨站腳本、偽造請求、中間人攻擊和網絡釣魚？后臺有對抗DDoS攻擊的策略嗎？這都是一些常見問題的名字，我們應該首先關注的。安全的程序不會明文儲存敏感信息而是用復雜的算法加密數據，這樣黑客拿到數據也沒什么用。

軟件會犯錯，并且必須要修正。即使是最好的軟件也會出問題。如果你沒有意識到這個，而沒有為此做計劃和對策，那么你就不是軟件專家，只是一個不安全程序的寫手而已。

軟件缺陷是不可見的，我們預測和避免缺陷的能力也是有限的，所以軟件工程師懂得利用工具矯正代碼。

毫無疑問我們需要更多更好的工具。工具十分有用，但卻常常被低估。試想一下我們沒有 Chrome 開發者工具 debug 和檢測性能表現！試想一下沒了 ESLint 和 Prettier 我們的效率會多么低！

如果你是個 JavaScript 開發者，被迫只能在編輯器裝一個插件，那么你應該選擇 ESLint。

可以在你編寫代碼時縮短反饋回路的工具，我們都可以嘗試使用。Bret Victor 的 inventing immediate visual representations 觀點讓我大開眼界。擁抱和改善工具讓我們有一個美好的前程，如果前面的視頻你沒看過，那就趕緊觀看學習一下。

每當我找到一個好工具，我的感覺都是相逢恨晚，好工具能幫助你成為更好的程序員，找到他們，使用他們，欣賞他們，如果可以的話，你甚至可以完善他們，幫助更多的人。

對于類型安全問題，在JavaScript領域最好的就是TS和Flow了。靜態類型的重要性比你想的更重要，如果不是這樣，你的代碼未來可能會很脆弱。盡量不要使用動態類型，如果你的語言是動態的話，最好換一個語言，或者找個轉譯器。現在的轉譯器已經智能到從注釋入手轉譯，我覺得未來動態語言都需要這東西。

兩個月，半年，甚至一年精通軟件工程是不可能的，你別去上什么培訓班去學這個。我學了二十多年，直到現在還在學習。而我學了十年，構建和維護了上千上萬人使用的程序，才敢自信地說一個有經驗的軟件工程師。

不是每個人都要當軟件工程師，但是每個人都應該學會用電腦解決他們的問題。你應該力所能及地學習一下寫程序。問題層出不窮，軟件工程也應不斷進步。這個行業的未來是讓普通電腦用戶可以不用學習很久就能簡單完成一些工作，可以讓用戶用一些簡單工具解決他們的問題。軟件工程師則是研究更好的工具，解決更多已知問題，然后避免未知問題的發生。

感謝閱讀這篇文章。