編程隨感

1 在你覺得需要寫註釋的時候寫註釋：

首先你需要爲方法，類或者模塊起個簡單易懂的名字

如果必須通讀一個方法的代碼才能瞭解它做什麼，那麼開發人員先要投入大量時間和精力才能使用它。反過來說：只需要短短几行註釋說明方法行爲，就可以讓生活更輕鬆

在class或者module中上部寫註釋：

說明這個class或者module的用途，並試着用例子來演示使用方法（一個文件中只應該有一個class，module，除非多出的那些類非常簡短）


2 通過編寫高內聚，低耦合的類，實現關注分離

簡單的面向對象分析

oop的原則

1 開閉原則（OCP）

禁止爲修改而關閉

允許爲擴展而開放


通常來說：一旦有了有效的類並且在使用它，你就不會想要動他，除非有必要。但是記住，改變是軟件開發中的一項不變的真理。使用ocp，我們允許通過擴展而改變，而不是回頭修正你現有的程序代碼。子類能增加並擴展基類的行爲，而無需弄亂已知有效且讓客戶高興的程序代碼

擴展其他類並不是ocp的唯一方法。例如：假如你在類中有一些private方法，那些方法就是禁止爲修改而關閉，沒有其他程序代碼可以弄亂它。

但你可以增加一些以不同方式調用這些private方法的public方法。你正在擴展這些private方法的行爲，而無需改變它們


2 不自我重複原則
通過將共同之物抽取出來並置於單一地方來避免重複的程序代碼
次數是3


3 單一職責原則
你的每一個對象都只有一個改變的理由
在良好的應用程序裏，一個類只做一件事且把事情做好，並且沒有其他類共同分擔此行爲


4 liskov替換原則（LSP）

子類型必須能替換父類型（否則，當引入新的類之後，調用代碼必須經常評估並修正，而且，你也讓契約不一致了）

能快速響應需求變化纔是好的軟件


模式的原則

1 隔離變化之物

2 針對接口編程，而不對實現編程

if is_car

my_car = Car.new

my_car.drive(200)

else

my_plane = AirPlane.new

my_plane.fly(200)

end

my_vehicle = get_vehicle

my_vehicle.travel(200)


3 組合優於繼承（汽車）


4 委託（鏈接和聚合）


3 代碼複審

A -》 B

一段時間後

A -》 C

讓別人審覈自己的代碼，但是別人是不固定的


4 測試驅動開發

先用它再實現它


消除那些還沒有編寫的類，這會很容易簡化代碼。相反，一旦你已經編寫了代碼，也許會強迫自己保留這些代碼，並繼續使用它

讓你的測試作爲你的代碼的第一個用戶


5 度量真實的進度


我們不應該去計算工作量完成的百分比，而應該測定還剩下多少工作量沒完成。如果你最初估計這個任務需要40個小時，在開發35個小時後，

你認爲還需要另外30個小時的工作，那就得到了很重要的度量結果（這裏誠實很重要，隱瞞真相毫無意義）


6 什麼是完成

1 寫完

2 測完

3 交付完


在要求時間的時候還要爲意外考慮（容錯機制，避免在壓力中開發），而意外是不可預估的，我個人是一切順利的時間 * 1.5


7 開發時的注意事項


不要讓瀑布思維侵蝕迭代項目

需要強調的是：瀑布思維仍然時常侵蝕着迭代項目。“讓我們在開始編程前編寫完所有的測試“，或者“讓我們在開始編程前完成全部設計“


變更對於軟件項目是永恆的，之所以用迭代，最常見的情況是：“不錯，這是我要求的；但現在我試用過後，發現和我現在真正想要的有一些差異。“

這種不錯……但是的過程並不是失敗的標誌，與之相反，早期頻繁地在不錯……但是中循環，正是改進軟件和發現什麼是真正有價值需求的途徑


所有的大型系統都非常複雜，因此沒有一個人能完全明白所有的代碼。除了深入瞭解你正在開發的那部分代碼外，你還需要從更高的層面來了解大部分代碼的功能，這樣就可以理解系統各個功能塊之間是如何交互的


需要讓團隊其他人瞭解你負責的代碼架構和你當前的工作進度。幫助團隊識別是否在某些東西上有重複勞動而耗費精力，或者是不是某個問題有人已有現成的解決方案。所以每日立會是必要的，立會上要注意細節。例如：“我正在開發登錄頁面“就不夠詳細。要達到“登錄頁面目前接受guest/guest作爲登錄用戶名和密碼，我今天會連接數據庫來做登錄驗證“，這樣的詳細程度才行。同理，changelog也是必要的。重大的提交，必須有詳細的提交信息，方便別人瞭解你的開發情況和代碼複查


8 專家的態度

如果你沒有犯過任何錯誤，就說明你可能沒有努力工作

沒有任何計劃在遇敵後還能執行，所以，改動計劃，不一定是壞事。但是做計劃還是有必要的。即使初始的設計到後面不再管用，你仍需要設計：“計劃是沒有價值的，但計劃的過程是必不可少的“。在設計過程中學習是有價值的，但設計本身也許沒有太大的用處

如果一個團隊成員誤解了一個需求，某個部分的架構，或者最近一次會議做出的決定，那麼也許意味着其他成員也有相同的誤解。要確保整個團隊儘快消除誤解


防微杜漸，不要容忍破窗戶

脫離實際的反方觀點會使爭論變味。若對一個想法有成見，你很容易提出一堆不太可能發生或者不太實際的情形去批駁它；再者，你基本無法贏得爭論。通常，有個好技巧：引導性地提出一個疑問，讓他們自己去意識到問題。


9 系統分析


聚集在那些表示系統本質，最具有商業價值，和最具風險的功能上

在項目架構階段，你所做的每一件事情都應該減少項目的風險

假如你不需要用例的所有細節，編寫詳述軟件能如何被運用到的場景可幫你快速蒐集好需求