API 設計的黃金準則是:只為你開發的API 編寫測試是不夠的;你必須為使用API 的程式編寫單元測試。你必須親身體驗,一旦你體驗過了,就可以面對每一種設計挑戰
專心在專案上,尋找聰明的解決方案來盡可能做出貢獻,提升你的技巧,反省你所做的,然後調整你的做法。別工作的像在籠子裡跑的倉鼠,每週工作超過60個小時是不明智的。要用專業的方式去做:準備、實現、觀察、反省與改變
一份好的bug report 需要包含三件事情
如何重現bug 以及出現的頻率
預期原本應該要發生什麼事情
實際上發生什麼事情
IDE 工具的存在是為了讓開發更容易,並增進程式設計師的生產力。但是有時候妳應該掀開引擎蓋,了解你的IDE 為你做了什麼,最好的方法就是學習command-line tools。之後回過頭來使用IDE 就會更了解他正在為你做什麼,以及如何控制建置的過程。
評估、目標和承諾是彼此獨立的。但是,目標和承諾是建立在可靠的評估之上。軟體評估的主要目的並非預測專案的成果,而是為了判別專案的目標能否實現,讓專案得以掌控
評估時程的用意是為了使適當的專案管理與規劃成為可能,允許專案的利害關係人將於實現目標做出承諾
專案經理常對程式設計師要求的不是一個評估的時程,而是要對管理者內心不確定的目標做出承諾
一個好的interface 應是容易被正確的使用、難以被誤用。故你必須要事先預想到並避免使用者可能犯的錯誤,並觀察早期釋出的interface 如何被誤用並修改interface ,避免發生同樣錯誤
雖然在一般遇到的案例裡,使用 if - then - else 比多型更實用些,但絕大多數用 polymorphism 的寫作風格會讓程式碼更精簡、更易讀,且更少脆弱的程式碼。所以在我們的程式碼裡,要是錯過使用 polymorphism 的機會,便會逐漸增加 if - then - else 敘述句的數量。試試 command pattern 吧
deployment的環境資訊也要保持在版本控制之下。沒有比破壞一個環境設定,卻沒辦法知道哪裡被改變過還糟。環境資訊應該要與程式碼分開控制版本,因為他們改變的頻率與理由接不相同
如果你的程式碼需要註解來解釋,請考慮把它 refactor 到不再需要註解
專業程式設計師唯一最重要的特點就是個人的責任感。他們對自己擁有的職業負責,對確認自己的程式碼可以良好的運作負責,對自己工作產出的品質負責,即使當截止日期迫在眉睫,他們還是不放棄自己的原則。當壓力日益增加時,專家要比以往任何時候都更嚴格堅持著原則,他們知道這樣才是正確的
試圖挽救糟糕程式碼所浪費的時間,會比預想的多更多。一旦遇到怎麼修改都毫無起色的程式碼,應該立刻丟棄。修改糟糕程式碼的最好的方式就是換個做法,將程式碼無情的refactor 、移到別的地方或乾脆把它刪除掉。
SRP(Single Responsibility Principle) 是良好設計的最基本原則,即將那些為了相同的理由而改變的東西聚集在一起,並將那些為了不同的理由而改變的東西獨立出來。
越接近交付期限,壓力越大,人本能的就開始偷工減料略過測試,所以你要想辦法把測試自動化,執行完就知道測試結果
你可以把 soak test 設定在假日執行 (如星期五半夜到下週一早上六點),藉此查看是否有 memory leak 的問題
當一個程式設計師,做個有經驗的技術專家已經不夠了,你還必須能與其他人有效率地一起工作
程式碼不會說謊,但是它卻會自我矛盾。有時候,錯加上錯就會變成對的,但它會變成更難以修復
良好的測試就像受測程式碼的文件一樣,它描述了程式碼如何運作。在每一個使用情境中,測試可以
描述出這些程式碼的執行脈絡、起始點或者必須滿足的前置條件
說明軟體如何被調用
描述出預期的結果或是需要驗證的 post condition
在測試的過程中,過多的程式碼會把閱讀你程式碼的人轉移到無關緊要的瑣事上,盡可能把這些瑣事使用具有意義命名的方法隱藏起來,這樣的方法稱為 extract method,這個 refactor 技巧會是你最好的朋友
你想要寫出良好的程式碼,並希望能成為一位好的程式設計師,你必須
在任何情況下,拒絕用 hack 的方式做出那種只是看似能夠運作的程式碼
你所寫的程式碼是淺顯易懂、易於維護、正確及確認已經解決問題
考慮到團隊的其他程式設計師,讓其他人可以讀懂你建構的程式碼
check in 程式前,要讓程式碼比當初 check out 時來得更好 (如更好閱讀、更好的結構、更容易測試等)
持續學習新的語言、方法和技術,在適當的時機就可以派上用場
盡早挑戰你的客戶,並且要經常挑戰他們。別輕易的用他們的話重述他們告訴你的需求。請記住:客戶所告訴你的,不一定是他們想要的。客戶無法告訴你全部的事實,只是以客戶的方式陳述自己的想法,而非以開發人員的方式