專案開發過程中，注重實效的途徑？？？
下面是來自《程式設計師修煉之道》中，自己的一些總結：
重複的危害
系統中的每一項知識都必須具有單一，無歧視，權威的表示。
不要重複你自己
重複是怎樣發生的
讓復用變得更容易
正交性
正交性：從幾何學中借來的術語，如果兩條直線相交成直角，他們就是正交的。兩個事物中乙個發生變化，對其他無影響，這兩個事物就是具有正交性
在設計良好的系統中，資料庫**一使用者介面是正交的，你可以改動介面而不影響資料庫。更換資料庫而不改動介面。說白了：就是不相依賴性和解耦性。
正交的好處：
- 消除無關事物之間的影響。
- 提高生產率：
- 正交性使問題區域性化，乙個模組的問題不會擴散到其它模組;
- 促進復用，便於與其它元件組合在一起；
- 使系統更健壯；更利於測試。
- 降低風險
- 正交的途徑能降低任何開發中固有的風險
- 有問題的**區域被隔離開
- 使系統更健壯
- 正交系統很可能得到更好的測試
- 不會與特定的**商、產品、平台緊綁在一起
專案團隊:團隊的設定也有正交性的問題，盡量不要讓2個團隊的責任重疊。如果團隊的組織有很多重疊，各個成員就會對責任感感到困惑。
分層：分成降低了模組間依賴關係失控的風險；一旦設計好元件，如果我顯著地改變某個特定功能背後的需求，有多少模組會受到影響？在正交系統中，答案只有乙個。
工具箱與庫：在你引入第三方工具箱和庫時，要注意保持系統的正交性。
編碼：每次你編寫**，都有降低應用正交性的風險
測試：正交的設計和實現的系統也更易於測試。
文件：正交性也適用於文件。其座標軸是內容和表現形式。
可撤消性
如果某個想法是你唯一的想法，再沒有什麼比這更危險的事情了。
不存在最終的決策。要把決策視為是寫在沙灘上的，而不要把他們刻在石頭上，大浪隨時可能到來把它們抹去。
靈活的架構:
曳光彈
在黑暗中發光的**：
用曳光彈尋找目標
曳光開發和專案永不結束的理念是一致的：總有改動需要完成，總有功能需要增加，這是乙個漸進的過程！
就是敏捷開發的理念，要即時反饋。
曳光**與原型系統不是一回事，曳光彈是乙個可以運轉的整體，雖然功能不全；而原型通常只是乙個介面，原型**通常要丟棄。
原型與便箋
原型製作是一種學習經驗，其價值並不在於所產生的**，而在於學到的經驗教訓，那才是原型製作的要點所在。
為了學習而製作原型。
領域語言
靠近問題領域程式設計。
不同語言有不同的優勢，關鍵在於揚長避短，合理運用，有時候組合起來事半功倍。
估算
估算以避免發生意外。
關於估算一件有趣的事情是：您使用的單位會對結果的解讀造成影響。
我們應該這樣估算:1~15天，3~8周等等，讓估算的時間有彈性。
乙個基本的估算訣竅,就是去問乙個已經做過這件事的人。
估算的步驟:
我們發現為專案確定進度表的唯一途徑，常常是在相同的專案上獲取經驗。
通過**對進度表進行迭代。
在被要求進行估算時，要學會說:」我等會兒再回答你。」，要學會放慢估算速度。
來自《大魚海棠》
優雅程式設計之這樣處理邊界，你就「正常」了！
貓和狗結婚，不久鬧離婚。法官問原因，狗說 貓婚後每晚都不回家，行為不軌。貓大喊 冤枉啊，我只是去追老鼠。狗說 法官你聽聽。如何優雅處理與第三方api的邊界問題？1 學習性測試 在專案中引入第三方api的新版本，測試專案是否正常工作，當然我們基本上沒有時間去重頭學習和研究第三方工具或者自己寫 來實現第...
你是注重實效的程式設計師嗎？
在 程式設計師修煉之道 這本好書中列出了注重實效的程式設計師應具備的特徵，你能對號入座嗎？1 早期的採納者 快速的改編者 你具有技術和技巧上的直覺，你喜歡試驗各種事物。給你一樣新東西，你很快就能把握它，並把它與你的知識的其它部分結合在一起。你的自信出自經驗。2 好奇 你喜歡提問。那很漂亮 你是怎麼做...
優雅程式設計之這樣組織資料，你就「正常」了（二十五）
馬雲有1500億。中國有13億人 他每人發一億 他還有1487億 這樣他還是中國首富 全中國都是億萬富豪。我要不是數學系的都看不出裡面的道道 專案中如何重新組織資料?以下來自 重構 這本書的讀書筆記，歡迎留下寶貴意見。self encapsulate field 自封裝字段 你直接訪問乙個字段，但與...