序章
有時候，獲取正確決策的唯一途徑，便是勇敢無畏地說出“不”字......我們要明白，委屈專業原則以求全，并不是問題的解決之道，舍棄這些原則，只會制造出更多的麻煩......
第一章：專業主義
所有軟體專案的根本指導原則是，軟體要易于修改，如果違背這條原則搭建僵化的結構，就破壞了構筑整個行業的經濟模型，
不能銘記過去的人，注定要重蹈覆轍，
每個軟體開發人員必須精通的事項：
- 設計模式，必須能描述GOF書中的全部24種模式，同時還要有POSA書中的多數模式的實戰經驗，
- 設計原則，必須了解SOLID原則，而且要深刻理解組件設計原則，
- 方法，必須理解XP、Scrum、精益、看板、瀑布、結構化分析及結構化設計等，
- 實踐，必須掌握測驗驅動開發、面向物件設計、結構化編程、持續集成和結對編程，
- 工件，必須了解如何使用UML圖、DFD圖、結構圖、petri網路圖、狀態遷移圖示、流程圖和決策表，
第二章：說“不”
在發現自己成為笑柄時，專業人士會第一個發笑，他從不會嘲諷別人，自作自受時他會接受別人的嘲諷，反之，他則會一笑了之，他不會因別人犯錯誤就對之橫加損貶，因為他知道，自己有可能就是下一個犯錯的人，
專業人士都清楚自己的自負，也知道上天會注意到這種自負，并加以懲戒，如若果真遭遇挫折，最好的辦法就是按斬訓華德說的-------一笑了之吧！
專業人士敢于說明真相而不屈從于權勢，專業人士有勇氣對他們的經理說“不”，
奴隸沒有權利說“不”，勞工或許也對說“不”有所顧慮，但是專業人士應該懂得說“不”，事實上，優秀的經理人對于敢于說“不”的人，總是求賢若渴，因為只有敢于說“不”，才能真正做一些事情，
第三章：說”是“
今天的程式員坑定得去面對諸如估算、確定最后期限以及面對面交流等溝通活動，做出承諾或許聽起來令人有點害怕，但它能夠幫助程式員解決在溝通中可能發生的不少問題，如果你能夠一直信守承諾，大家會以為你“是一名嚴謹負責的開發人員”，在我們這行中，這也是最有價值的評價，
專業人士不需要對所有請求都回答“是”，不過，他們應該努力尋找創新的方法，盡可能做到有求必應，當專業人士給出肯定回答時，他們會使用正式的承諾，以確保各方能明白無誤地理解承諾的內容，
第四章：編碼
如果感到疲勞或者心煩意亂，千萬不要編碼，強而為之，最終只能再回頭返工，相反，要找到一種方法來消除干擾，讓心緒平靜下來，
疲勞的時候，千萬不要寫代碼，風險精神和職業素養，更多意義上指要遵守紀律原則而非成為長時間作業的作業狂，要確保自己已經將睡眠、健康和生活方式調整到最佳狀況，這樣才能做到在每天的8小時作業時間內全力以赴，
埋頭忙于解決問題時，有時候可能會由于和問題貼得太緊，無法看清楚所有的可選項，由于大腦中富有創造性的部分被緊張的專注力所抑制，你會錯過很棒的解決方案，因此，有時候解決問題做好的方法是回家，吃頓好吃的，然后上床睡覺，再在第二天清晨醒來洗個澡，
第五章：測驗驅動開發（TDD）
測驗驅動開發的三個原則：
- 在編好失敗單元測驗之前，不要撰寫任何產品代碼，
- 只要有一個單元測驗失敗了，就不要再寫測驗代碼；無法通過編譯也是一種失敗情況，
- 產品代碼恰好能夠讓當前失敗的單元測驗成功通過即可，不要多寫，
第七章：驗收測驗
要解決開發方和業務方溝通的問題，我所知道的唯一有效的方法就是撰寫自動化的驗收測驗，這些測驗足夠正式，所以其結果有權威性，這些測驗不會造成模糊，也不可能與真實系統脫節，它們，就是無可挑剔的需求檔案，
第八章：測驗策略
TDD很強大，驗收測驗是表達和強化需求的有效方式，但他們都只是整體測驗策略的一部分，為了更好的做到“QA應該找不到任何錯誤”，開發團隊要和QA緊密協作，創建由單元測驗、組件測驗、集成測驗、系統測驗和探索性測驗構成的測驗體系，應該盡可能頻繁的運行這些測驗，提供盡可能多的反饋，確保系統始終整潔，
第九章：時間管理
關于會議，有兩條真理：
- 會議是必須的，
- 會議浪費了大量的時間，
專業開發人員同樣清楚會議的高額成本，他們同樣清楚自己的時間是寶貴的，他們同樣需要時間來寫代碼，來處理日程表上的事務，所以，如果會議沒有限時且顯著的成效，他們會主動拒絕，
邀請你參加會議的人并不負責管理你的時間，為時間負責的只有你，所以，如果你收到會議邀請，務必確保出席會議可以給自己目前的作業帶來切實且顯著的成效，否則，不必參與，
會議并不總是按計劃進行的，有時候你正參加某個會議，但是發現如果之前對此會議知道的多一點，就不會來，還有時候，會議臨時增加了議題，或者某個討厭的家伙霸占了討論，這些年來，我學到了一條簡單的規則：如果會議讓人厭煩，就離席，你可以解釋說，自己抽不出更多的時間用于這場會議，問問有沒有辦法加快討論，或者另選時間，
敏捷開發的武器庫中包含“立會”：在開會時，所有參會者都必須站著，到場的人依次回答以下三個問題：
- 我昨天干了什么？
- 我今天打算干什么？
- 我遇到了什么問題？
專業開發人員會用心管理自己的時間和注意力，他們知道優先級錯亂的有貨，他們也診視自己的聲譽，所以會抵制優先級錯亂，他們永遠有多種選擇，永遠敞開心扉聽取其他解決方案，他們從來不會執拗于某個無法放棄的解決方案，他們也時刻警惕著正在顯露的泥潭，一旦看清楚，就會避開，最糟糕的事情，莫過于看到一群開發人員在徒勞的拼力作業，結果卻陷入越來越深的泥潭，
第十章：預估
專業開發人員懂得如何為業務人員提供可信的預估結果，以便做出計劃，如果做不到，或者不確定能做到，專業開發人員不會給出承諾，
專業開發人員一旦做了承諾，就會提供確定的數字，按時兌現，但是大多數情況下，他們都不會做這種承諾，二是提供概率預估，來描述期望的完成時間及可能的變數，
對需要妥善對待的預估結果，專業開發人員會與團隊的其他人協商，已取得共識，
第十一章：壓力
在壓力下保持冷靜的最好方式，便是規避會導致壓力的處境，規避的方式也許無法完全檢出壓力，但是可以大大降低壓力并縮短高壓力期的時間，
讓系統、代碼和設計盡可能整潔，就可以避免壓力，這并非是說我們要花無情無盡的時間去清理代碼，而只是說不要容忍混亂，混亂會降低速度，導致作業延誤，承諾失信，因此，要盡力保持輸出成果整潔干凈，
應對壓力的訣竅在于，能回避壓力時盡可能的回避，當無法回避時則勇敢直面壓力，可以通過慎重承諾、遵守自己的紀律原則、保持整潔等來回避壓力，直面壓力時，則要保持冷靜，與別人多多溝通，堅守自己的原則紀律，并尋求他人的幫助，
第十二章：協作
我們并非是喜歡和其他人在一起作業才選擇做程式員的，我們都認為人際關系難以應付而且毫無規律，編程用的機器整潔，行為也可預見 如果一個人可以待在房間里數十個小時沉浸在一些真正有趣的問題上，那將會是最開心的時光，
第十三章：團隊與專案
理想團隊是由12名成員組成的，7名程式員，2名測驗人員，2名分析師和1名專案經理，
團隊比專案更難構建，因此，組件穩健的團隊，讓團隊在一個有一個專案中整體移動共同作業是較好的做法，并且，團隊也可以同時承接多個專案，在組建團隊時，要給予團隊充足的時間，讓他們形成凝聚力，一直共同作業，成為不斷交付專案的強大引擎，
附錄：工具
永遠不要遷入沒有通過全部測驗的代碼，永遠不要，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/501933.html
標籤：其他
上一篇：[筆記]淺談分塊
下一篇：kali下安裝Nessus