第4章 兩人合作
書中引用：函式最好有單一的出口，為了達到這一目的，可以使用goto。只要有助於程式邏輯的清晰提現，什麼方法都可以使用，包括goto。疑問1：在實際的專案中，真的建議使用goto嗎？想法：在大一的c語言課堂上，老師告訴我們盡量不要使用goto，因為goto跳來跳去，會影響程式的可讀性，顯得很亂，而且goto可以被其他語句代替。因此我對goto也有了「偏見」，而在《構建之法》中竟提及goto有助於程式邏輯的清晰提現，我便不得不重新認識一下goto。我在知乎上看了各路大神的回答，這是相應的鏈結截幾張圖比較有代表性的回答：——p69
將所有回答都瀏覽了一遍後，我對goto有乙個比較初步的了解，不知對不對：goto主要用於跳出多重迴圈和效能提公升，而且常見於底層**。而在實際的普通專案開發中，goto是很少用的，雖然它邏輯性強，但因為他的可讀性不高（尤其對同事來說），可維護性也不高，而且它可以被do
while break代替，因此平時的開發中是不建議使用goto的，但這並不代表goto沒用。
書中引用：疑問2：對於結對專案，**複審的效率很高，但在普通的團隊開發要如何做到高效的**複審呢？想法：在結對專案中，每一行**都由兩個人思考過，且雙方都十分熟悉**，所以不必過多的介紹就可以開始進行細緻的複審。而在團隊合作中，往往是一人負責乙個模組，其他人對自己的**沒有深入的了解，在《構建之法》書中對團隊複審的描述中，並沒有讓複審者詳細了解**細節，而是讓程式設計師自己先一行行測試，然後再去找複審者對程式設計師提出一系列問題，可我認為光問這些問題並不能很好的起到複審的作用，最多起到提醒的作用，因為複審者並沒有了解**細節，很難發現邏輯上的錯誤及優化的空間等。我覺得複審者不能只提問，在提問後應該具體檢查**，因為很多問題程式設計師都認為自己做好了，但其實並沒有做好，然而他並沒意識到自己沒做好，回答複審者的問題時卻說做好了。再加上引用中提到的團隊複審的缺點，我認為團隊複審的效率很低。不知真正的企業團隊都是怎樣進行高效的團隊複審呢，會讓複審者一行行檢查**，還是只是看程式設計師演示+提問呢？複審者：你在這裡申請了這個資源，你是如何保證它在所有路徑下都能正確釋放的？
複審者：這一段**可能會被多個執行緒呼叫，**是執行緒安全的麼？我怎麼沒看到對共享資源的保護？
複審者：這麼修改之後，有沒有別的功能會受影響？
複審者：專案中還有別的地方需要類似的修改麼？
複審者：有沒有留下足夠的說明，讓將來維護**時不會出現問題？
複審者：對於這樣的修改，有沒有別的成員需要告知？
——75
團隊複審的缺點在於：
（1）要找到乙個所有人都能出席的時間並不容易。
（2）牽涉的人員眾多，理解程度不一，複審的速度和效果不能得到有效的平衡。
（3）由於成本問題，無法對所有的設計和**進行深入的複審。
（4）由於人員眾多，有面子問題。
——p80
第17章 人，績效和職業道德
書中引用：問題3：在乙個團隊中，個人績效應處於什麼地位，發揮著什麼作用？想法：本章多次提到個人績效的考評，可見個人績效考評是團隊中一項重要的環節。書中提到了多種個人績效考評方式，個人比較推崇的是進行兩個維度的評價：完成任務維度和團隊貢獻維度，隨後評出團隊中最好的20%、中間的70%、最需要改進的10%。但個人績效公布後，它應該處於什麼地位，對團隊的影響如何呢？我搜尋了相關的資料對其中乙個回答比較贊同：乙個團隊即使業績不好，團隊領導也不會承認自己團隊有問題，而是找很多別的理由。在績效評估的時候，每個成員被展示為高大全的英雄人物，都要排在別的團隊人員的前面。
——386
其次是要完善團隊業績和個人績效相結合的考評體系，最大限度地呼叫團隊成員的積極性。
——392
看完這段話後，我對團隊的個人績效考評有了新的看法：個人績效考評是為了提高團隊效率，但要採用恰當的方式，否則會適得其反。過於量化指標其實對團隊的效率並沒有好處，反而會增加許多繁瑣的工作，且會加強團隊成員的競爭關係，可事實上團隊成員是合作關係，競爭氛圍過於濃厚會影響團隊成員之間的交流與互幫互助。我更傾向於基本量化指標+領導的觀察評判+團隊成員互評的模式，但即便如此，個人績效僅做乙個參考，起到提醒和驅動的作用，不能被過度放大，否則績效高的成員容易驕傲，績效低的成員容易失去信心。因為乙個團隊更重要的是合作精神，而不是個人主義。
書中引用：問題4：如何做到與公眾利益一致？想法：我覺得軟體產品很難顧及到所有人的利益，往往對公眾利益的利與弊是相伴而生的，關鍵是看它的利是否大於弊及社會接受度。如**的出現，讓大量實體商家受挫甚至倒閉，卻又衍生出了快遞行業，給予了更多人工作的機會，顯然**改變了人們的生活方式，它的利是大於弊的，因此被社會接受。再如即將來臨的人工智慧時代，機械人代替工作的時代，定會使更多基層人員失業，那我們如何衡量人工智慧是否與公眾利益一致？肯定會有一部分人從中受益，也會有一部分人因此失業，它並不能完全地做到與公眾利益一致。我的觀點是，只要不違背基本道德，那麼我就能接受這款產品的存在。因為公眾利益十分複雜，並不能完全地兼顧，關鍵還在於它的社會接受度和貢獻度。原則1 公眾：軟體工程師的行為應與公眾利益一致。
原則2 客戶與雇主：軟體工程師以其客戶和雇主利益最大化的方式做事，與公眾利益保持一致。
——406
以上就是我的疑問和想法，感謝閱讀！
讀《構建之法》第4，17章有感
讀 構建之法 第4，17章有感 第四章 兩人合作 原文 另外，注釋 包括所有的源 應該只用ascii字元，不要用中文或其他特殊字元，否則會極大地影響程式的可移植性。我的問題和看法 對於英語水平沒有那麼高的人來說，不允許中文注釋真的太難了。剛開始學習 的時候，老師就教導我們程式設計的時候一定要寫注釋，...
構建之法第4 17章讀書筆記
第四章 兩人合作 問題1 4.2中注釋這一版塊，因為之前有學長跟我強調過 規範的問題，所以對這方面比較重視，後來當使用每個ide的時候，都會去注意 縮排的快捷鍵，比如idea的ctrl alt l等等 我對自己寫的 還算比較滿意，但是在注釋這一塊確毫無頭緒，不知道什麼是標準，以前看過標準的注釋，記得...
構建之法4 17章觀後感
第四章 question1 對於4.3.4中提到的折構函式和虛函式這兩個概念，我完全不知道它們是什麼。不知道它們的定義和存在的作用。通過查詢，我知道了這兩個函式的定義和作用。析構函式名也應與類名相同，只是在函式名前面加乙個位取反符 例如 stud 以區別於 建構函式。它不能帶任何引數，也沒有返回值 ...