正確的做事，做正確的事
如何應對比較急的代碼交付？
根據急的級別分類。
- 寫代碼，以一次做好的態度，大處思考，小處落筆。
- 語法上仔細，可減少編譯錯誤帶來的浪費與思維中斷。
- coding與單元測試分開，太急的，可跳過自測，編譯通過交付後，由使用者來測試及使用，如有問題，再及時返工處理。以犧牲交付可靠性，來換取速度。但需要通過coding質量提高潛在一次通過率。此爲平衡變通之策。
- 慢即是快，前期注重可複用性，包含代碼層變與環境搭建層面。比如：代碼層面注意宏控制處理好，以少量的時間換取將來大量時間上的節約，實現任務量在時間層面的轉移，與整體上的壓縮。尤其是需求變動大的情況。環境搭建層面，成員以git來共享個人環境搭建成果，在搭建環境過程，避免低效的重複，第一次搭建環境的人，每一步要記錄下來，最好的情況，搭建完成形成一鍵配置腳本或者文檔或者git固化勞動成果。
- 越快越好，臨時性，是欺騙你的良好接口。糟糕和越來越大的浪費就是因爲臨時性的心態引入的。永遠不要被欺騙了，程序員的個人素養需要自己去守護，在進度和代碼質量上的平衡，需要程序員的堅持。差的程序員的退讓，會讓代碼最終陷入不可維護的地步，也就是維護的成本越來越高，速度越來越慢。越忙得像無頭蒼蠅的團隊越糟糕，因爲缺少頂層的方法論與有效的實踐，往往導致“將熊熊一窩”。代碼的風格往往反映的是組織的風格。
- “garbage in, garbage out” 無效輸入，無效輸出
- 將熊熊一窩
- 聰明的做事。高效的做事。於別人失敗處，吸取經驗，避開陷阱，於別人低效處，發現高效的方法，於浪費的環節，發現減少浪費的途徑。
- 垃圾代碼複用之後還是垃圾。對於不整潔的代碼和架構，重要的不是考慮其複用，而是考慮無情的重構。高質量的代碼纔有資格被複用，屎山代碼首要考慮的是代碼質量的提高。
- 將大部分精力用於生產整潔的代碼，而不是用於事後的修補，修補如售後。大量的工作應該在於生產整潔的代碼，避免維護，而不是匆忙上線垃圾，事後維護累死。
- 低質量代碼不畫uml，不值得浪費時間。優秀的代碼畫uml方便共享知識。
- 用Doxygen 生成代碼文檔
- 市場和需求保證做的是正確的產品，是市場需要的產品。開發人員保證正確的做產品，是產品質量達到至少最低標準，缺陷或bug可控，代碼層面要適度兼顧代碼擴展性、可維護性。在進度與質量衝突時，犧牲質量太多，達到可接受標準一下，趕上進度也是表面上的，因爲犧牲的質量依然需要後期的修補。
- 人人都是質量工程師，程序員要捍衛自己的代碼質量，守住底線。如果人人都退讓到底線一下，表面看進度趕上來了，很有可能會害人害己。自己忙於修補，公司資源和個人資源很可能無法創造出來價值。目標很重要，目標要始終保持在產品具有最低保證的價值。
- 只有在自己跌倒的時候，才能學會如何爬起來。聰明的做法是，在別人跌倒的時候，觀察和學習別人的經驗，把防線向前移，儘量不讓自己走到跌倒那一步而被動，掌握主動權，始終牽住牛鼻子。
- 別人失敗和做的不夠好的地方，就是我們需要琢磨的地方，機會就在這裏。
- 兩種不同需求，前期用兩個分支來管理。需求變更，變更需求用新分支來做。最終確認後，決定用哪個分支或者做兼容。
- 誰負責、誰決策。負責人與處理人分開時：處理人需要有效的輸入，處理後，將有效的輸出輸出給負責人。負責人與處理人是同一人時，負責、處理、決策由一人承擔。
19.做長期有價值的事，固化重複的事，固化重複的知識，用個人知識庫快速索引。 - 聰明而高效的做事。高效的分步驟完成任務，高效利用碎片時間，減少浪費和無效。
- 強調正面和積極的方法，避免負面的概念與詞彙，以免因隱含信息缺失情況帶來的誤解。
- 更持久的關注正面的意義與方式，朝着理想態小步快走。重要的是朝好的方向變化。
- 面向長遠做事，做可持續積累的事情。
- 注意合適的言語，合適的場合與溝通方式
