前言
這個星期我仔細閱讀了《構建之法》的第四章與第十七章，感觸頗深，學習了很多，在此提出自己的問題和部分看法。
第四章 兩人合作
P74 注釋
注釋（包括所有源代碼）應該只有ASCII字符，不要用中文或其他特殊字符，否則會極大地影響程序的可移植性。
我覺得是否使用中文應該視情況而定。
像我們，英語畢竟不是母語，有很多詞並沒有掌握甚至使用。在團隊合作中，成員間的英語水平也不同。注釋，是為了方便程序員了解部分程序的功能便於測試修改的，他十分的重要，一旦有歧義，便會造成問題。難道編程時要為了一句注釋應該如何表達去搜索之后再繼續編程？如果因為注釋為英語而看不懂，反而增大結對時編寫代碼的難度，浪費了去翻譯單詞的時間。
再者，程序如果是編寫給國人使用的，使用過程全為英文會加大國人閱讀的難度，許多不曾學過英語的人更無法使用，如計算器中如果希望使用者輸入題數，源代碼應有輸出語句：
1 System.out.println(“請輸入題數：”);
若所有源代碼為ASCII字符，則無法使用中文，語句則為：
1 System.out.println(“Please enter the number of questions：”);
但不懂英語的人可能就無法了解這句話的意思，也許以為是出現了什么故障（在我沒學英語甚至初學英語時，看到別人的電腦里出現一大串的英文都覺得是電腦壞了）。所以，給國人使用的程序，各種提示，我覺得應該使用中文，若要推廣，則有譯文版。
使用中文最大的問題是編碼亂碼，我覺得從一開始便設置為UTF-8編碼，並在編程過程中注意編碼不弄錯，一般不會出現什么問題，也更方便於了解修改。
P75 goto
函數最好由單一的出口，為了達到這一目的，可以使用goto。
這一觀點與我初學C語言時老師的教導不同，老師說，最好不要使用goto，或者說不要用，普遍的做法是用if-then-else這種結構來代替goto。goto語句為無條件轉移語句，在Dijkstra的《go to statement considered harmful》提到它的弊端：
The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. Usually, people take into account as well the values of some well chosen variables, but this is out of the question because it is relative to the progress that the meaning of these values is to be understood! With the go to statement one can, of course, still describe the progress uniquely by a counter counting the number of actions performed since program start (viz. a kind of normalized clock). The difficulty is that such a coordinate, although unique, is utterly unhelpful. In such a coordinate system it becomes an extremely complicated affair to define all those points of progress where, say, n equals the number of persons in the room minus one!
In Guiseppe Jacopini seems to have proved the (logical) superfluousness of the go to statement. The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one.[1]
概括主要為降低代碼的可讀性。在結構化程序語言中使用goto語句， 容易造成程序流程的混亂，使理解和調試程序都產生困難。另外，因為java語言講究簡單、方便，在java語言中，goto這個詞只是作為了保留字，還沒有使用。
P77 析構函數
書中提到了析構函數，但我對析構函數並不熟悉，在室友曉真的博客[2]中看到了她的搜索結果，讓我較為清晰的理解了析構函數，我將在文章尾附上她的博客地址。
P85 為什么要結對編程
在結對編程模式下，一對程序員肩並肩、平等地、互補地進行開發工作。他們並排坐在一台電腦前，面對同一個顯示器，使用同一個鍵盤、同一個鼠標一起工作。他們一起分析，一起設計，一起寫測試用例，一起編碼，一起做單元測試，一起做集成測試，一起寫文檔，等等。
在結對編程中，因為有隨時的復審和交流，程序分方面的質量取決於一堆程序員中各方面水平較高的那一位。這樣，程序中的錯誤就會少得多，程序的初始質量會高很多，這樣會省下很多以后修改、測試的時間。
我對於兩個人公用一台電腦表示不理解，在我的理解中，結對合作是兩人先分析需求，將所有需求分析完畢，在討論如何實現，把具體的實現方法擇優做好計划，之后兩人分工選擇自己更有能力的方面分開編程，最后合在一起復審、測試。我覺得每個人都有擅長的地方，而不是很擅長的也有靈機一動的可能，既然結對，我們應該相信對方能做好各自的部分，並且經過一開始的討論，方法基本確定，代碼的初始質量並不會因為分開打而受到消極的影響，反而能因每人選擇自己擅長的方面而提高質量與效率。
再聯系前面P79代碼復審表4-1 代碼復審形式中的自我復審：
不一定最有效，因為開發者對自己總是過於自信。
那么兩人同時對一台電腦編程，就有可能因為覺得是在自己眼皮底下打好的自己的代碼而過於自信，兩人都過於大意，反而忽略了很多缺陷，以后修改、測試的時間真的會少很多嗎？分開編程則有自我復審與同伴復審的兩次復審，並且思想的碰撞能夠更好的優化程序，做出的程序難道不會更成功嗎？
第十七章 人，績效和職業道德
P400 豬、雞和鸚鵡的故事
影評家不拍電影，也沒有演技，但是他們對電影的一切都可以指手畫腳，而且不必承擔任何責任，最高領導往往還挺容易受影評家的影響！
雖然影評家不拍電影，也沒有演技，但是影評家真的不重要嗎？或者說他的存在沒有意義甚至是屬於挑刺的呢？
電影評論的目的在於分析、鑒定和評價蘊含在銀幕中的審美價值、認識價值、社會意義、鏡頭語言等方面，達到拍攝影片的目的，解釋影片中所表達的主題，既能通過分析影片的成敗得失，幫助導演開闊視野，提高創作水平，以促進電影藝術的繁榮和發展；又能通過分析和評價，影響觀眾對影片的理解和鑒賞，提高觀眾的欣賞水平，從而間接促進電影藝術的發展。
影評是一種科學的活動，是電影藝術與觀眾的橋梁，是實現電影三重價值（藝術的、社會的、經濟的）的重要手段。國外影評主要作用於票房價值，中國影評側重於社會性，形成中國特有的、最廣泛的群眾影評浪潮，形成中國文藝評論獨特景觀。[3]
可見，影評是有存在的必要的，好的影評能夠帶動電影往更好的方向發展。最高領導實時關注影評，做出正確的判斷，才能進步。左恆、索亞斌、梁文道、賈磊磊等，都是較為有名的影評者，專門研究電影學，評論各類影片，對電影的分析與品論獨到而深刻。如果最高領導不關心，固執己見，一直隨心所欲拍自己的影片，作品能夠一只獲得成功嗎？
P401 豬、雞和鸚鵡的故事中提到
R:Responsible，負責把具體事情做好。
每個環節有且只有一個R。
看到這里時，我有些不理解，很多任務一個人並無法完成，為什么R只能有一個呢？接着我查閱了RACI的資料，在一篇博客中了解到：
每一個流程最好有且只有一個“R”角色，這是RACI的一般原則。 當一個流程找不到“R”角色時，則出現缺口。 當一個流程有多個“R”角色時，則出現交疊。
- 解決缺口問題：如果某個流程找不到“R”角色，這時對流程負全責的權威人士則應該在現有角色中（或者發現新人選）挑選、任命一人擔任“R”。更新RACI表，對各個角色及其相關責任進行闡述。
- 解決交疊問題：如果不止一個“R”存在，那么就要對該流程進行再分解，然而再對“R”進行分配。[4]
從這里，我了解到，它是把所有的任務細分到只需一個人去完成，各擔一職，各司其所，使任務完整的被無縫完成。
P408 用動物來比喻體系
如果業績很好，但價值觀不太對路（不太聽話？），則是一條野狗。要堅決清除，不然功高震主。
一開始我覺得績效好的人應該能挽留便挽留，作為領導不應該擔心下屬功高震主，能為公司做貢獻才是重要的，價值觀不同可以在不傷大雅的情況下求同存異。而后，我在《給馬雲一個團隊，他會怎么管？》中了解到：
傑出企業必須為社會創造價值，同時也要有良好的業績支持。不僅要講理想，同時也要有很好的收入，否則都是空話。也就是說，業績和價值觀要平衡，不能極左不能極右，必須共同前進。
馬雲對於員工的考核，主要有兩個標准，一個是業績，一個是價值觀。他用野狗和小白兔這兩個十分生動的形象，對員工在兩大標准的表現上給予了評判。對於野狗，他給予的定義是：一個人的業績很好，但沒有價值觀。而馬雲對於野狗的態度，是堅決地踢出去。那么小白兔呢，則是業績不怎么好，但擁有非常好的價值觀。對於小白兔，也得毫不留情地堅決殺掉。因為作為一個擁有百年企業的阿里巴巴，它的員工必須是業績、價值觀都好的人。
對於“野狗”和“小白兔”，為什么要殺掉呢？馬雲通過十分形象地舉出實例，給予了解釋：在阿里巴巴公司的平時考核中，業績很好，價值觀特別差，即每年銷售可以賣得特別高，但根本不講究團隊精神，不講究質量服務，這種人我們稱之為“野狗”，我們的態度非常堅決：殺！毫不手軟的殺掉他。因為這類人對團隊造成的傷害是極大的。而對那些價值觀很好，人特別熱情、特別善良、特別友好，但業績卻總是好不起來，我們稱之為“小白兔”的這類人，我們也要殺。我們畢竟是公司，而非救濟中心，不能給企業創造效益，當然也不能在企業。不過，對於“小白兔”，卻可以向領導申請一次“免死金牌”，由主管領導決定是否留用。而“野狗”就沒有這個機會。無論他的職位有多高，能力有多強，一旦違背了團隊的原則，馬雲就會毫不手軟地將其掃地出門。“衛哲離職事件”，就是一個鮮明的例子。
每個成員必須首先對團隊整體保持忠誠。[5]
通過這，我了解到，是我過於天真，一個企業，每一個員工的價值觀都會影響到公司，一旦價值觀出現問題，其帶來的后果往往是難以挽回的，並不是簡單的業績能夠衡量的。
參考：
[1]《go to statement considered harmful》,http://ce.sharif.edu/courses/90-91/1/ce364-1/resources/root/GoTo/Dijkstra.pdf
[2]《構建之法》第四章 第十七章閱讀筆記,http://www.cnblogs.com/ForeverSevrous/p/8660216.html
[3] 百度百科，https://baike.baidu.com/item/電影評論/1202687?fr=aladdin&fromid=10364061&fromtitle=%E5%BD%B1%E8%AF%84
[4] RACI 職責分配矩陣 模型使用詳解及案例分析，https://blog.csdn.net/buding_pmp/article/details/54881486
[5]《給馬雲一個團隊，他會怎么管？》，https://read.douban.com/ebook/34756995/?from=book