天天看點

《建構之法》第四章讀後總結

前言

  一個人的力量無法将阿波羅十一号送上月球

  實際上參與阿波羅計劃的人數最多高達三十萬人,現代的衆多龐大的軟體項目也是需要成百上千的程式員組成的研發隊伍才能勝任。

  代碼從不是一個人的事情

  那麼最小的能夠展現合作機制的開發模式莫過于————結對程式設計。

  之前也有與同學合作完成項目的經曆,當時也是遇見類似代碼風格統一規範之類許多問題,由于沒有接觸過體系的軟工程知識,那時候也是在黑燈瞎火的情況下勉強把項目完成,但最近學習了《建構之法》的第四章,才恍然大悟,原來還有這種規範,若是當時能有這種成熟的規範作為參考,那麼必定是事半功倍。

在學習本章時學生做了一個邏輯圖,因為不是理論性非常強的知識點,是以并沒有加入各種小知識點的聯系(不是很精細,因為本章内容大都是要求了解而已,如果是數學等理論知識整理詳細思維導圖對理清知識網絡有很大幫助)。制作導圖工具是xMind,表格如下:

《建構之法》第四章讀後總結

分析與了解

代碼風格規範:

  • 代碼風格規範是為了代碼的可維護性與易讀性,在團隊合作中尤其重要
  • 認識了很大之前都沒有注意的寫代碼的細節

代碼設計的規範

  • 代碼設計規範主要是為了保證代碼的安全性以及友善調試
  • 書裡隻是簡單介紹了一些通用的代碼設計規範原則,針對自己經常使用的語言還是需要自己去找文檔學習

代碼複審

  • 代碼複審的意義有二:
  1. 盡早發現問題
  2. 互相學習
  • 仔細通讀了代碼複審的步驟,這次的結對項目先實踐下

結對程式設計

  • 結對程式設計産出的代碼能比單獨程式設計的代碼擁有更好的設計品質和代碼品質
  • 對團隊的能力提升大有裨益
  • 學習了兩個人之間的合作,有技術上的,也有交流上的,受益良多