把工程實踐中遇到的問題，從問題型別和解法型別兩個角度去歸類，總結出一些有限適用的原則，就從點到了面。把諸多總結出的原則，組合應用到自己的專案**中，就是把多個面結合起來構建了一套立體的最佳實踐的方案。
model 設計，是形而上思考中的乙個方面，乙個特別重要的方面。在自己的 coding/code review 中，站在巨人的肩膀上去思考。不重複地發現經典力學，而是往相對論挺進。
工程和設計的每個分支都有自己的技術文化。在大多數工程領域中，就乙個專業人員的素養組成來說，有些不成文的行業素養具有與標準手冊及教科書同等重要的地位(並且隨著專業人員經驗的日積月累，這些經驗常常會比書本更重要)。資深工程師們在工作中會積累大量的隱性知識，他們用類似禪宗』教外別傳』的方式，通過言傳身教傳授給後輩。軟體工程算是此規則的乙個例外：技術變革如此之快，軟體環境日新月異，軟體技術文化暫如朝露。然而，例外之中也有例外。確有極少數軟體技術被證明經久耐用，足以演進為強勢的技術文化、有鮮明特色的藝術和世代相傳的設計哲學。 ----《unix 程式設計藝術》常見原則：
keep it ****** stuped!（kiss原則）
作為初級開發人員來說，能做到在規定的時間內完成需求、解決問題，然後在後續**迭代中找到更加簡潔並且行之有效的**去替換原來的，這需要漫長的積累知識的過程，不可一蹴而就。
原則 3 組合原則: 設計時考慮拼接組合
各種不同的組合，簡單，卻又滿足了各種需求，靈活多變，要實現乙個外掛程式，不需要事先掌握乙個龐大的體系。將**外掛程式化、工具化，減少重複**。
原則 6 吝嗇原則: 除非確無它法, 不要編寫龐大的程式
原則 7 透明性原則: 設計要可見，以便審查和除錯
我們要寫好程式，減少 bug，就要增強自己對**的控制力。寫的函式，必須具備很高的透明性，使用通俗易懂的函式分組分層方式，使自己的**讓人一看就懂；如果問題比較複雜，要準備好對應的文件資料。
原則 10 通俗原則: 介面設計避免標新立異
在通類的**和結構，不要標新立異獨出心裁。設計過程中應該按照使用者最可能熟悉的同樣功能的介面和相似的程式來進行建模。
原則 11 緘默原則: 如果乙個程式沒什麼好說的，就沉默
若程式沒有什麼特別之處可講，就選擇保持沉默。一切從簡是unix的優良傳統。
不要胡亂列印log，如果你的程式』發聲』了，那麼它丟擲的資訊就一定要有效 !
原則 12 補救原則: 出現異常時，馬上退出並給出足夠錯誤資訊
rob pike, 最偉大的c 語言大師之一, 在《notes on c programming》中從另乙個稍微不同的角度表述了unix 的哲學：code review確實是一項很有意義的事情，code review對於**作者，審查人以及團隊都是有益的，經常閱讀自己**並修改重構自己**的習慣，因為編寫者都會覺得自己**寫的很完美，這是正常的現象。不過如果你過段時間再次看自己當初以為寫的很牛的**可以發現好多吐槽點，好多可以優化重構的地方，保持這種經常閱讀自己**並重構的習慣可以提高自己的**能力。也可以經常閱讀別人的**看別人的**風格有何借鑑之處，正所謂三人行必有吾師。
如何做 Code Review 讀後感
最近在看一篇文章 如何做 code review 原文，文章裡面大佬的一些總結很經典很明了，值得我學習和借鑑。通過幾個知識部分做一下總結。什麼是code review code review是 評審,評審也稱 複查，是指通過閱讀 來檢查源 與編碼標準的符合性以及 質量的活動。keep it stup...
如何做好Code Review？
一 背景 最近隨著交易業務快速擴充套件，研發組內新專案及新成員越來越多，如何做好code review，把控研發人員開發 質量很是關鍵。對於大部分業務團隊，談到code review就會面露哀狀 上線時間倒排，研發工期這麼緊，連碼 的時間都不夠了，你還要我cr？上版的需求，這版就變了，生命週期太短，...
如何做研究
來自 在研究生期間，一開始大家都很迷惑，都不知道自己要幹什麼 該幹什麼？即便知道自己要幹什麼，也不知道從哪幹起？上次兩位老師跟我們交流了一下，下面是他們的心得 給乙個專案 解決方案 問題分塊 任務明細 一開始並不是所有的問題都會想到，但是起碼要有乙個大體的框架在心中，然後細化模組，對每乙個功能進行細...