最近看到美團的技術團隊所寫的一篇文章有感，特此分享 傳送門: https://tech.meituan.com/10_principles_for_engineers.html 裡面提到有幾點也是現在我的團隊所缺乏的，藉此也可好好檢視下自己的不足  

以终为始

“以终为始”（Begin With The End In Mind），是史蒂芬·柯维在《高效能人士的七个习惯》中提到的一个习惯。它是以所有事物都经过两次创造的原则（第一次为心智上的创造，第二次为实际的创造）为基础的。直观的表达就是：先想清楚目标，然后努力实现。

很多時侯工程師的壞習慣就是想到就動手做，但沒規劃好做出來的其實跟需求相去甚遠 先想清楚，制定好一個能量化的目標 然後以該目標為前題把需要的步驟詳列出來 為做而做並不會為項目帶來什麼

闭环思维

真正的闭环，要求我们对工作中的事情都能够养成良好的思维习惯，沟通要有结论，通知要有反馈，To Do要有验收。

跟一直以來提倡的TDD很相似，現實卻是時間不容許 很多時侯跟別人討論一大輪結果卻不了了之，這個時侯就應該由Owner主導，訂下相關的目標及驗收準則 好讓一件事有一個『閉環』，這就跟scrum的workflow類似 PENDING>IN PROGRESS>WAITING FOR REVIEW> CLOSE 永遠需要一個CLOSE，否則issue只會無限的累積下去

事不过二

  一层含义是**“所有的评审与问题讨论，不要超过两次”。 …… “事不过二”原则的另一层含义，是“同样的错误不能犯第二次”**。每次故障之后，Casestudy都必须进行深刻的总结复盘，对故障原因进行5Why分析，给出明确可执行的To Do List。

事不過二是一個重要的思維，無論是討論還是除錯。工作上無數次出現過就同一事情發生N次的討論，最後也沒有結論。問題重心其一是缺乏Owner主導，沒有明確的討論方向，很多時侯討論到流於表面，或只就眼前發生的事情討論，沒有定論也就不能閉環；其二是缺乏文檔，導致之後會忘記以前所討論的內容。 解決方案是加入Owner思維，及每次討論都需要有一個明確的TODO，並需要把結論寫進文檔   而除錯亦是另一個問題所在。每當有BUG出現時，大多都沒有詳細把該問題分級，而是選擇立即去解決，事後也沒有詳細的記錄相關的步驟。而之後同樣的問題再次出現時，就是憑經驗去解決，但很多時侯都會重新思考一些曾經經過的步驟，做成浪費。 解決方案當然是把除錯步驟寫進文檔，但亦需要拿捏當中的程度，考慮什麼類型的BUG才需要詳列其步驟。  

设计优先

“设计优先”这条原则，相对来说更加具体一些。之所以单列一项，是因为架构设计太重要了。Uncle Bob曾说过：“软件架构的目标，是为了让构建与维护系统的所需人力资源最小化。” …… “设计优先”这一原则，要求写别人看得懂的设计。我们了解一个系统最直接的途径就是结合设计文档与代码。

MD>5就需要文檔，絕對同意  

空杯心态

“满招损，谦受益”，“空杯心态”是最后一项原则。我觉得这也是一个人能够持续成长的前提。做技术的人，骨子里通常有股傲气，并且会随着资历、成绩的提升而不断增加。

常言道：學而後知不足 你懂的再多，但每個人也肯定會懂一些你不懂的事 擺正心態，你需要的是進步，而不是自滿 

以上，共勉之