1.需求未完成澄清以前，沒有必要進行開發，這是禁忌
2.開發的時間在預估需求時間上至少新增1.2倍
3.明確需求者的本意；明確本次開發是按照其任務佈置進行開發還是自己獨立進行開發
4.雖然沒有實現不了的技術，但是引入新技術的時間成本和人力成本以及後續的維護成本是極其高昂的；要在合適的時間內給出最完美的技術架構是不可能的，但要拿出行業標準方案，且在單位成本時間內可控；技術誰引入誰負責
5.Git提供了大量的日誌記錄，非特殊情況下，一般要避免引入非語句註釋，註釋都是要有意義的
6.大塊程式碼段複用要封裝，大塊程式碼段可以直接C/V，但是細節語句要通讀一遍，檢查一遍。
7.程式碼的書寫方式不是寫好一點就測試一點，是要在內心整理好步驟，書寫出一個基礎的版本在進行測試和修改。寫一句程式碼就進行測試，那是小學生入門初級的做法。
8.程式碼環境要獨立起來；程式碼的託管要採用分散式Git或者是GitLab；且要有備份的習慣，管理好許可權和分支，按照最小許可權的原則進行分配操作；程式碼的分支管理要分為開發分支，測試分支，預釋出分支，線上master分支，，還有hotfix修bug的分支，只有hotfix是可以直接合併到主Master分支的。程式碼的環境，開發是開發分支；測試是測試分支，業務分支和預釋出黑盒環境，每一個環境都是獨立的箱子，相關內容的人應該有相對應的許可權。
9.技術開發首先是人才的選擇，開發意味著負責，也意味著對人才的信任，要對開發的內容負責，未經過測試的內容禁止釋出，隨性而發未經過評審，設計，共同探討，文字留存的內容不上正式環境，只允許在測試環境及以內釋出，因不遵守所產生的連帶責任由主張者自行承擔。
10.在創業公司或者任務期間內，都是快速出效果，出產品，快速上手，架構的優先順序是低於上線日期的，所以快速迭代尤為重要；技術架構要有專人強制推行，如原來已經有程式碼風格的則按照以往的風格來開發。
11.產品經理是需求的提出者，開發時間的預估值來源於自己的開發速度能力和對開發任務的理解和對開發任務的專注程度，還有需求者所能給的時間來權衡，最終按照自己的開發能力60%加上開發者給的時間40%然後給出對應的開發時間。
12.程式碼的複用性，美觀可讀性不是一梭子就幹；是要有一定尺度的，能複用的地方要複用，能抽象的地方要抽象，可以給出更加優等方案的需要優等演算法，解決問題固然重要，程式碼複用和結構可讀也十分重要，這兩者的比例還是6、4開，先實現功能，然後對於特定的規範引入也要加強。