第四與十七章讀書筆記

第四章：兩人合做

原文：4.2.9 註釋

問題：我看到這一章的時候就很好奇企業對代碼註釋的要求，想現網上的意見有很大的分歧，有人說本身公司要求儘可能少些代碼，有的則對註釋所佔的先去了解一下，慢慢改變本身註釋的風格便於之後工做，而後發篇幅有具體的要求，好比註釋不得低於代碼量的40%，下面是我挑選的幾段有意思的評論：

1.咱們公司代碼沒有註釋的，有也只是 極少部分的 英文註釋。

對此我問了主程，他告訴我幾個緣由。

第一，屬性，方法，類的命名所有都有規律，能看懂英文就知道這個屬性幹嗎的，絕對不會是那些什麼 String a1 = "身份證號碼";List<String> gglist = null; 莫名其妙之類的。

第二，代碼整潔美觀，有註釋會顯得很亂。這是他我的看法，代碼潔癖吧。

第三，若是有些地方要用註釋，也要用英文，考慮到有中文註釋的項目導入別的工程環境裏面會亂碼。雖說能夠從新調整工程環境，可是若是英文看的懂的話，何須用中文。

有時候我用中文註釋 還會被他一臉嫌棄....

2.通常來講，咱們的註釋，要麼是使用文檔，要麼是告訴你爲何要這麼設計。

並且好的設計都是沒有註釋的，由於一個合格的工程師固然要理解好的設計爲何好。咱們只註釋那些設計很差可是又不得不這麼作的。

固然了，這並非什麼好事，你們不要學。我相信大部分公司都不敢由於一個程序員看不懂代碼就開除（逃）

3.以前公司專門有同事寫註釋的.....沒錯，你沒看錯，除了寫註釋他不幹別的。

4.不寫註釋扣你一半工資，本身看着辦。

並且在我看到的評論裏面，發現不寫註釋的要比寫註釋的多，而後我就很迷惑，咱們是應該注重註釋，仍是讓本身成爲別人說的「避免寫註釋的優秀程序員」，其實我本身查了半天資料，內心也沒有一個明確的答案，但感受本身要偏向避免寫寫註釋一點的。

第十七章：人，績效和職業道德

原文：17.4 蘿蔔與白菜

問題：你但願團隊裏白菜多仍是蘿蔔多？

想法:我我的以爲團隊裏仍是白菜多一點好，由於我以爲在項目開始前每一個人的分工，應該負責的工做應該都是已經合理分配好的，大牛分配的工做量多一些，普通員工少一點，沒問題，那麼你最起碼應該先把本身的那部分工做作好，不管你幫助了多少人，但你本身的工做沒作好的話，那就是你的失職，不該該用「功」來掩飾本身的「過」，咱們應該獎勵在作好本身本職工做以後去幫助同伴的人，但毫不是否是「不洗泥的蘿蔔」。