極限程式設計
測試先行，結對程式設計（要求兩個人水平相當。能夠提高效率，不易出錯，而且程式設計者無法偷懶哈）
看過程式設計師上面的一篇文章，極限程式設計具有良好的實踐性比如：測試驅動開發，持續整合，使用者故事。測試驅動保證了開發人員的編碼質量。持續整合保證了每天完成的任務都能夠成功整合到系統中，保持專案的持續進展。而使用者故事既可以用於開發人員將其實現，也可以便於測試人員在最後進行系統測試時有所依據。
軟體開發活動：
需求分析(對待開發的軟體提出的需求進行分析並給出詳細的定義並對其加以確切的描述，然後編寫出軟體需求說明書)，
系統設計（設計人員把已確定的各項需求轉換成相應的體系結構），
系統實現（把軟體設計轉換成計算機可以接受的程式**，並在實際環境中得以實現），
軟體測試（保證軟體質量的重要手段，貫穿於軟體生命週期的各個階段），
執行和維護（軟體在執行的過程中由於多方面的原因對其進行的修改）
物件導向：
類---->例項
屬性（資料，狀態）
方法（動作，行為）
今天檢視jdk的api發現,stringbuffer和stringbuilder的區別 ：
此類(stringbuilder)提供乙個與 stringbuffer 相容的 api，但不保證同步。該類被設計用作 stringbuffer 的乙個簡易替換，用在字串緩衝區被單個執行緒使用的時候（這種情況很普遍）。如果可能，建議優先採用該類，因為在大多數實現中，它比 stringbuffer 要快
deque介面的方法：
丟擲異常 返回特殊值
插入 add(e) offer(e)
移除 remove() poll()
檢查 element() peek()
如果可能，offer方法可插入乙個元素，否則返回 false。這與 collection.add 方法不同，該方法只能通過丟擲未經檢查的異常使新增元素失敗。
offer 方法設計用於正常的失敗情況，而不是出現異常的情況，例如在容量固定（有界）的佇列中。
remove() 和 poll() 方法可移除和返回佇列的頭。到底從佇列中移除哪個元素是佇列排序策略的功能，而該策略在各種實現中是不同的。
remove() 和 poll() 方法僅在隊列為空時其行為有所不同：remove() 方法丟擲乙個異常，而 poll() 方法則返回 null。
element() 和 peek() 返回，但不移除，佇列的頭。
HTML基礎複習4
css的應用 模組的邊框 設定邊框樣式 border style 如果是乙個值那麼表示四個邊的樣式都一樣 如果是兩個值那麼第乙個值代表上下，第二個值代表左右 如果是三個值，第乙個值代表上，第二個值代表左右，第三個值代表下 如果是四個值，按順序代表上 右 下 左，none表示沒有邊框 dashed 虛...
HTML基礎複習4
css的應用 模組的邊框 設定邊框樣式 border style 如果是乙個值那麼表示四個邊的樣式都一樣 如果是兩個值那麼第乙個值代表上下，第二個值代表左右 如果是三個值，第乙個值代表上，第二個值代表左右，第三個值代表下 如果是四個值，按順序代表上 右 下 左，none表示沒有邊框 dashed 虛...
Java基礎複習執行緒
執行緒 實現多執行緒的兩種方法 繼承thread類，重新run方法 thread a new mythread 子執行緒 thread.start 實現runnable介面，實現run方法。myrunnable my new myrunable 在這個myrunnable類中已經重寫了run方法 t...