10+年程式設計師總結的20+條經驗教訓(轉)
以下是我作為一名程式設計師經過 10 幾年時間總結出的一些有關於軟體開發的經驗規則:
開發
1. 從小事做起,然後再擴充套件
無論是建立一個新的系統,還是新增功能到現有的系統中,我總是從一個簡單到幾乎沒有任何所需功能的版本啟動,然後再一步一步地解決問題,直到滿意為止。我從來沒有妄想過能夠一步登天。相反,我一邊開發一邊學習,同時新掌握的資訊還可以用於解決方案中。
我很喜歡 John Gall 的這句話:“複雜系統總是源於簡單系統的演化。”
2. 一次只改變一件事
當我們在開發時,碰到測試失敗和功能無效的情況,如果你一次只研究一個問題,那將會更容易找到問題的關鍵。換言之,就是使用短迭代。必須確保這個問題解決之後,再轉移到另一個問題上。這適用於向下提交。如果在你新增新功能之前需要先重構程式碼,那麼先提交重構,然後再新增新的功能。
3. 儘早地新增日誌記錄和錯誤處理
在開發新系統時,我做的第一件事就是新增日誌和錯誤處理,因為這兩者從一開始就非常有用。如果系統不能照常工作,那麼你就需要知道程式中發生了什麼——這是日誌的作用。錯誤處理也是如此——錯誤和異常越早處理越好。
4. 每一行新程式碼必須至少執行一次
在你真正完成一個功能之前,你必須對它進行測試。不然,你怎麼知道它是不是按照你的想法在執行呢?通常情況下,最好的方法是通過自動測試,但並非總是如此。不過,不管怎麼說,每一行新程式碼必須至少執行一次。
5. 在整體測試之前先進行模組測試
先進行部分模組測試可以節省時間。通常說來,我們在整合不同的模組時也會出現問題,例如模組之間的介面不匹配。但是如果我們能夠信任各個元件的話,那麼跟蹤整合問題就會變得簡單得多。
6. 所有事情所花費的時間總是比你預期的要長
特別是在程式設計中,即使一切進展順利,我們也很難對功能所需的時間做出正確的預算。並且,開發軟體時碰到各種意想不到的問題是非常常見的。
侯世達定律其實道出了真諦:做事所花費的時間總是比你預期的要長,即使你在預期中已經考慮了侯世達定律。
7. 先了解現有的程式碼
大多數的編碼都需要以某種方式改變現有的程式碼。即使是新功能,也需要適應現有的程式。所以,在你加進去新的內容前,首先需要了解當前的解決方案。否則,你一不小心就很有可能會打破現有的功能。這意味著,閱讀程式碼和編寫程式碼都是必要的技能。這也是為什麼看似微小的變化仍可能需要很長時間才能解決的原因之一——你首先必須瞭解上下文。
8. 閱讀和執行
幸運的是,對於理解程式碼,我們有兩種互補的方法。你可以閱讀程式碼,也可以執行程式碼。執行程式碼的確是個非常棒的好方法。所以,請確保充分利用這兩種方法。
故障排除
9. bug 總是難免的
我不喜歡那些宣稱軟體開發可以“一蹴而就”的高談闊論。不論你再怎麼費盡心機,bug 總是難免的。最好能夠做成可以快速故障排除、修復 bug 和部署修復的系統。
10. 解決故障報告
每個開發人員都應該花時間去處理來自客戶的故障報告,並修復 bug。這能讓你更好地理解客戶的意圖,明白如何使用系統,知道排除故障的難易程度,瞭解系統的設計情況。這也是為自己的開發成果負責的好方法。
11. 重現問題
修復 bug 的第一步就是重現問題。然後你得確保修復之後,問題能夠徹徹底底地消失。這樣一個簡單的規則可以確保你不會誤將非問題當作是問題,並確保解決方案真的能夠奏效。
12. 修復已知錯誤,然後再看看有沒有遺漏的地方
有時候,可能同時存在著幾個不同的問題。它們之間的互相作用,可能會讓你毫無頭緒,束手無策。不要糾結於搞清楚發生了什麼,先去解決所有已知的問題,然後再看看還有什麼不對的地方。
13. 沒有巧合
在測試和故障排除時,不要相信會出現什麼巧合。就像你改變了定時器的值,那麼就會改變系統重啟的頻率。所以一切都並非是巧合。新增新功能,另一個不相干的功能變慢了?這絕對不是巧合。相反,是你應該仔細調查的內容。
14. 關聯時間戳
在故障排除時,事件的時間戳可以作為你的好幫手。尋找偶數增量。例如,如果系統重啟了,並且剛剛發出過一個 3000 毫秒左右的請求,那麼可能是觸發了某個定時器,才導致出現重啟的動作。
團隊合作
15. 面對面的交流最有效
當我們需要討論如何解決問題時,那麼面對面的交流比視訊、打電話和電子郵件都要好。
16. 橡皮鴨法
遇到你絞盡腦汁也解決不了的問題時,不妨找一個同事,然後將問題解釋給他們聽。很多時候,當你在敘述時,即使你的同事一言不發,你可能也會突然靈光乍現找到問題的關鍵。
17. 問問題
閱讀和執行程式碼往往非常有助於指出程式碼的目的和它的工作原理。但是如果你有機會諮詢那些更為了解的人(例如原來的程式設計師),那麼千萬不要錯過。
18. 共享榮譽
不要貪圖榮譽,該是誰的就是誰的。例如:“Marcus 想出了這個主意……”(如果真是他想的話),而不要說“我們想出的……”。
其他
19. 嘗試
如果你不知道某種程式語言功能的工作原理,那麼不妨寫一個小程式來理解它是如何工作的。這同樣適用於測試你正在開發的系統。如果我將引數設定為-1,會發生什麼?當我在重啟系統時,如果服務當掉,會發生什麼?以此來研究它的工作原理。
20. 帶著問題睡覺
如果你正在解決一個很難的問題,那麼不妨帶著問題睡覺。有科學研究表明,這樣做雖然你表明上並沒有在主動思考,但你的潛意思卻這麼做了。其結果就是,第二天再去研究問題,解決方案已經呼之欲出了。
21. 跳槽
不要害怕跳槽。和不同的人共事,開發不同的產品,感受不同的公司文化是非常有意思的。
22. 不斷學習
我們需要不斷地學習和了解軟體開發。你可以嘗試不同的程式語言和工具,閱讀軟體開發的書籍,接受 MOOC 課程。相信我,量變才能達到質的飛躍,這些小小的學習積累,終有一天會大大地提高你的知識和能力。
希望這些經驗能對大家有用。如有不當之處,敬請指正。
譯文連結:http://www.codeceo.com/article/10-years-20-tips-programmer.html
相關文章
- 10+年程式設計師總結的20+條經驗教訓程式設計師
- 10+年程式設計師總結的20+經驗教訓程式設計師
- 10+年程式猿總結的20+條經驗教訓
- 20+條軟體開發的經驗教訓
- 12年程式設計師得到的12個經驗教訓程式設計師
- 19歲程式設計師在谷歌學到的5條經驗教訓程式設計師谷歌
- 程式設計從業5年總結的14條經驗程式設計
- 12年程式設計師職業生涯得到的12個經驗教訓程式設計師
- 程式設計師程式設計知識經驗總結程式設計師
- 程式碼審查的5點經驗教訓總結
- 給年青設計師們的10個經驗教訓
- 程式設計師的十大經驗和十大教訓程式設計師
- Go 併發程式設計中的經驗教訓Go程式設計
- 30多年程式設計師生涯經驗總結程式設計師
- 從我一年程式設計生涯中得到的經驗教訓程式設計
- 10 年 Amazon Web Services 總結得到的 10 個經驗教訓Web
- 程式設計師自我修養之程式設計經驗總結程式設計師
- 10年學到的程式設計經驗總結程式設計
- Supercell成立10週年的10條經驗和教訓
- 回顧15年程式設計師生涯,我總結的7點經驗程式設計師
- 程式設計師創業五年學到的 5 條經驗程式設計師創業
- 我2年學習程式設計的經驗總結程式設計
- 17 年程式設計生涯的三大經驗總結程式設計
- 17年程式設計生涯的三大經驗總結程式設計
- SOHO設計師的多年工作經驗總結
- 作為專案經理的7個經驗教訓總結
- 如何像程式設計師一樣思考 - 解決問題的經驗與教訓程式設計師
- 總結經驗教訓 給你預防病毒的八個忠告(轉)
- AWS 運營 10 週年學到的 10 條經驗教訓
- 攜女友創業者的年終總結:經驗和教訓創業
- 十年開發的程式設計師,總結出了這些開發經驗程式設計師
- 12年經驗老程式設計師5次轉型程式設計師
- 經驗教訓,慎用Oracle的審計Oracle
- 程式設計從業五年的 14 條經驗程式設計
- 來自10位 IT 大牛的23條經驗教訓
- MySQL 效能優化的最佳 20+ 條經驗MySql優化
- MySQL效能優化的最佳20+條經驗MySql優化
- 作為老司機使用 React 總結的 11 個經驗教訓React