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

44.林集團發表於2016-04-05

前言

一個人的力量無法將阿波羅十一號送上月球
  實際上參與阿波羅計劃的人數最多高達三十萬人,現代的眾多龐大的軟體專案也是需要成百上千的程式設計師組成的研發隊伍才能勝任。
程式碼從不是一個人的事情
  那麼最小的能夠體現合作機制的開發模式莫過於————結對程式設計。
  之前也有與同學合作完成專案的經歷,當時也是遇見類似程式碼風格統一規範之類許多問題,由於沒有接觸過體系的軟工程知識,那時候也是在黑燈瞎火的情況下勉強把專案完成,但最近學習了《構建之法》的第四章,才恍然大悟,原來還有這種規範,若是當時能有這種成熟的規範作為參考,那麼必定是事半功倍。
在學習本章時學生做了一個邏輯圖,因為不是理論性非常強的知識點,所以並沒有加入各種小知識點的聯絡(不是很精細,因為本章內容大都是要求瞭解而已,如果是數學等理論知識整理詳細思維導圖對理清知識網路有很大幫助)。製作導圖工具是xMind,表格如下:
《構建之法》第四章讀後總結

分析與理解

程式碼風格規範:

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

    程式碼設計的規範

  • 程式碼設計規範主要是為了保證程式碼的安全性以及方便除錯
  • 書裡只是簡單介紹了一些通用的程式碼設計規範原則,針對自己經常使用的語言還是需要自己去找文件學習

    程式碼複審

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

    結對程式設計

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

相關文章