Week4-做業1：閱讀與博客

第四章、兩人合做

一、原文：

       在變量面前加上有意義的前綴，程序員就能一眼看出變量的類型及相應的語義。這就是「匈牙利命名法」的用處。還有一些地方不適合用「匈牙利命名法」，好比，在一些強類型的語言（如C#）中，對類型有嚴格的要求，不一樣類型的值是不能作運算的，例如C#中，if（）語句只能接受bool值的表達式，這樣很大程度上就杜絕了上面的問題。在這類語言中， 前綴就不是很必要，匈牙利命名法並不適用。微軟的.NET框架就不主張用這樣的命名法則。

問題與思考：

       既然匈牙利命名法在必定程度上並不適用，那麼它出現的意義是什麼？

       「匈牙利命名法」是由匈牙利程序員Charles Simonyi發明的一種編程語言中對變量進行命名的規範。基本原則是：變量名=屬性+類型+對象描述，其中每一對象的名稱都要求有明確含義，能夠取對象名字全稱或名字的一部分。要基於容易記憶容易理解的原則，保證名字的連貫性是很是重要的。例如：nFoo，szFoo，pFoo，cpFoo分別表示整型變量，字符串型變量，指針型變量和常指針型變量。

       能夠看出，匈牙利命名法將變量的類型信息從單一地點(聲明變量處)複製到了多個地點(使用變量處)，這是冗餘法。冗餘法的成本之一是要維護副本的一致性，這個成本在編寫和維護代碼的過程當中須要改變變量的類型時付出。冗餘法的成本之二是佔用了額外的空間，一個優秀的書寫者會自覺地聽從一個法則：代碼最小組織單位的長度以30個天然行如下爲宜，若是超過50行就應該從新組織，一個變量的書寫空間會給這一法則添加沒必要要的難度。

       可是使用匈牙利命名法的好處是看代碼的人知道這裏發生了一個整型變量的複製動做，聽起來沒什麼問題，能夠安心了。匈牙利命名法有其優勢但也有缺點，這就須要在使用中揚長避短，合理應用它。

二、原文：

     結對編程不是成與開發者獨到的發明，在現實生活中，也存在着相似的搭檔關係：越野賽車（駕駛，領航員）；駕駛飛機（駕駛，副駕駛），這些任務都有共同點：在高速度中完成任務，任務有較高的技術要求，任務失敗的代價很高。

問題與思考：

       爲何說結對編程「任務失敗的代價很高」？

       咱們都能明白越野賽車和駕駛飛機時任務失敗極可能致使兩個合做者的性命安全獲得威脅，可是結對編程任務失敗的代價以及後果究竟是什麼呢？在結對編程中的角色分別是：駕駛員（控制鍵盤輸入）；領航員（起到領航、提醒的做用）。與以前提到的搭檔關係不一樣的是，在結對編程中這兩個角色是能夠互換的。在結對過程當中，任何一段代碼都至少被兩雙眼睛看過，被兩個腦殼思考過，代碼被不斷地複審，這樣使得代碼的責任不屬於某一我的，而是兩我的共同的責任。

       所以，結對編程十分忌諱我的英雄主義，它須要的是創建集體擁有代碼的意識。因此，若是兩人因爲配合不當致使代碼沒法融合，沒人負責，就會使編程進度大大降低。而且結對編程的過程也是一個相互督促的過程，這樣使得程序員除了技術以外，對心智的要求也比較高。所以，結對成員如果作不到絕對的信任與高強度的配合，就會使結隊任務沒法進行，並從中還可以看出程序員的「不足」。

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

一、原文：

       有時候一個企業也會展示出「假團隊」的特性：領導很是努力地讓員工相信公司很是關心員工；員工也很是努力地讓領導相信本身徹底領會了公司的大愛。私下裏雙方都不相信對方說的話，也看不起對方。

問題與思考：

       如何使本身的團隊不變成「假團隊」？若是本身在的團隊是一個假團隊是該力挽狂瀾，仍是拂袖而走？ 

       「假團隊」是指名義上有團隊的組織，可是成員相互掣肘，面和心不和，有人打醬油，這樣的團隊的效率還不如各人單幹的工做組。那麼， 如何使本身的團隊不變成「假團隊」？就應該在這個團隊組成的萌芽階段作好預防措施，在剛剛開始組隊時就應該分配好各自的職責，制定好相應的規章制度，從根源上杜絕一切「混子」行爲。在團隊的磨合階段，你們應該作到坦誠相對，積極溝通與交流。不要因工做理念或者習慣的不一樣而產生不滿甚至隔閡，這樣就不會有成員由於對內衝突而抵觸工做。

       可是萬事都有一個萬一，若是本身在的團隊變成了一個假團隊那麼應該怎麼作？是該力挽狂瀾，仍是拂袖而走？首先，咱們要清楚本身在這個團隊的位置，以及本身對待這個團隊的情感是什麼。若是你是一個剛剛加入的新成員，那麼我認爲本身的去留對這個團隊影響不大，那麼我選擇離開。可是若是我是這個團隊的老成員，我爲了這個團隊付出了不少，那麼我可能會思考問題的所在，爲咱們的團隊的將來作一個整治以及改變。

二、原文：

     有些人把團隊成員分爲A、B、C這樣的等級，而且認爲A類員工最優秀，B類員工通常，並且B類員工會把更差的C類員工招入團隊，急劇下降團隊質量，所以要儘可能只保留A類員工。

問題與思考：

      爲何B類員工願意招入C類員工來下降團隊質量呢？將員工分類對績效管理有何做用？

       在我看來人類老是願意與比本身「低」的人做比較，從而來加強本身的自信心。B類員工會把更差的C類員工招入團隊，也許是因爲本身的能力實在是超不過A類員工，所以想選擇C員工做爲本身的最低標準。因此，若是一個團隊若儘可能保留A類員工，就會激發B類員工的自尊心與求勝欲，從而使得團隊的工做效率獲得大幅度的提高。

      一個團隊中的每一個人都有各自的努力和做用，如何衡量我的在團隊中的績效呢？有的人說根據工做量來算，可是代碼雖多，仍是要看結合起來在團隊中的做用。有人建議按照角色來定位，有人建議根據工做時間來衡量……可是這些都是很片面的，在評定員工績效時，仍是應該從多維的角度思考。所以，雖然說員工進行了分類，但並不表明A類員工的績效就要比B、C類的好，咱們還要看每一個等級的員工在該等級的貢獻與能力的提高。