1. 程式人生 > >《構建之法》第四章讀後感

《構建之法》第四章讀後感

導致 錯誤 但是 inf 很多 修改 讀後感 alt info

問題1:

我對於書中的一段

技術分享圖片

有些疑問,這段書中說,不要註釋程序是怎麽工作的,而要讓程序本身來說明這個問題。

我認為比較簡單的代碼確實不需要解釋程序是怎麽工作的,但是有時候為了兩個人更好的配合,對於較負責代碼,也需要解釋一下程序是如何工作的,這樣子有利於對方更快的理解你的代碼。

我從網上找的對於註釋的作用如下:

代碼註釋的重要性


其實代碼註釋的重要性我倒是覺得沒必要在這過多的解釋,我們只要回想一些情景就能知道其道理:

1、當你經過一段時間後,發現哪兒出問題或需要調整功能的時候;

2、當你去改別人代碼的時候(你的代碼也會被別人改);

3、當你需要補一些設計文檔的時候(比如現在的我);

我發現很多時候註釋有利於他人去改你的代碼,而我覺得如果不去註釋代碼是如何運行的,而只是註釋代碼是做什麽的,為什麽要這麽做的話,肯定是不夠的,改代碼的人可能憑借著自己的主觀想法就去修改,然後產生的後果可能會很嚴重。

問題2:

我對這段存有疑問

技術分享圖片

這段的重點是通過不斷的復審來減少代碼的錯誤,我覺得不要的復審時應該的,但是像文中如此的復審實在是太多浪費時間了,盡管後文有說了很多避免陷入浪費時間僵局的方法,但是我覺得在實際操作中一定會或多或少的陷入不斷的開會,開發人員在一個簡單的地方浪費非常多的時間導致項目的進展非常的緩慢,其花費的時間可能比文中所說的可能出現的危機所花費的時間花的多得多。

《構建之法》第四章讀後感