【4.2】
代碼風格非常重要。我自己寫時會嚴格注意這一方面。閱讀他人代碼時也是同樣。里面提到了一些規范，可以此為范本。代碼可讀性太重要了。
【4.3】
摘：關于函數，最重要的原則是：只做一件事，并且要做好。
關于4.3.4中“如何處理C++中的類”這一部分沒太讀懂，有一些概念還不太清楚，這里先留下疑問，等全書讀完再來釋疑。
【4.4】
代碼復審的目的之一，查錯是必然的，但是如果編譯通過，想要發現邏輯錯誤、算法錯誤就會相對比較困難，也很容易被忽視。針對此處，結對編程的優勢就體現出來了。或者在做項目時由團隊復審也可達到比較令人滿意的效果。
代碼復審的步驟很詳盡，可做參照。代碼復審時必須具備的一種能力——大局觀。這跟玩游戲一個道理，重局部而輕整體有時會導致很致命的錯誤。另外，在代碼初步完成之后，復審或調整階段最好做好相應備注標記，以便后續再次檢查閱讀。
針對代碼復審的核查表部分，我有個很強烈的感受，那就是我對于程序開發和產品設計的共通性的體會越來越強烈。 這份核查表和設計方法論的checklist核心功能完全一致。階段、步驟、及每階段每步的主要考量方向都是一致的。概念探索期、產品設計初期、成熟期、內測期、公測期，包括產品需求分析、目標用戶分析、干系人分析、競品收集拆解、功能列表等，諸多理念在精神上都保持了高度一致。
【4.5】
初初接觸到結對編程是婁老的課上，當時對軟件開發的思考和領悟還不夠深刻，只覺得這名詞很新鮮、這種形式很有趣，并不能很好的體會到結對編程真正給編程帶來的良好影響是什么。但就當時的那門課程來說，我認為雖然我們都規規矩矩的按照老師的要求兩人一組，看似很和諧的在實踐著結對編程，但幾乎沒有人能真的說從這種模式中受益。在我看來，最大的問題當然是出在我們自己身上，對自我要求太低、學習目標不夠明確等等。然而還有另外一部分原因我認為也不可忽視，課前對結對編程理解太淺，結果就是要么兩個程度相似的同學結對但分工不甚合理，或者說僅有分工沒有合作；要么兩個程度相差較多的同學結對出現“一邊倒、一頭重”的現象，程度較差的同學簡直成了后勤人員，只負責端茶送水按摩揉肩，依賴性極強。我想想要在大學教學中推廣這種編程方式，還需在實踐之前做足功課，“前戲”做足，學生才能知道“噢，原來不是一人只負責一部分功能代碼，編完拉倒那么簡單，還需要互審、代碼還需要拼接嵌入，也不是一人負責編一人負責看這種等等”。引導，就是要學生"知其然"，"知其所以然"，然后才能"知其如何然"。
現在回過頭來反思，對照書中關于“如何結對編程的步驟和要求”，我和薛薛兩人在大學后半段做的大創課題還是比較好的踐行了結對編程的理念的。效率高，代碼質量較好，彼此都從對方身上學到很多、受益很多，也樂于其中。
【4.6】
和薛薛的結對編程過程很順利，在溝通這方面沒出現什么問題。代碼的嵌入和整合也沒有大的阻斷性問題出現。非要說的話，我覺得有一點可以在以后加以改進，結對編程前需要對軟件設計、項目需求達成一致，相關變量可在編程開始前就做好約定，這樣省去了代碼嵌套時的工作量，也一定程度上減少了語意模糊或定義不清導致的bug。
還有就是我和薛薛的代碼風格不是特別一致，她趨向于緊湊型，而我是較為寬松型的。也許未來風格統一會更優。
文章列表
留言列表
