有人說軟體開發是從古老的建築學中走出來的，並學習了其不少思想、方法。但是軟體的開發要比建築學來的不明確、不具體，怎麼說呢？建築房子無非是鋼筋、水泥、沙子、石頭、磚塊等材料根據力學或其他的原理合理的堆積組合而成的。建築用的這些東西是看得到、摸得著的實實在在的東西，放在**還是那些東西，而構成軟體的材料卻是看不見、摸不到的、是抽象的，依賴於認識它的角度，在不同的系統中抽象出來的東西是不同的，這就一下子將軟體開發中使用的「材料」增加了乙個很高的認識難度。軟體領域裡儘管很想搞出一些無形零件，組裝起來就能變身為滿足各種要求的軟體成品，但至少目前不是很理想，偶爾有做的比較好的也是在某乙個特定的領域裡，估計要造乙個放在各個領域都能使用的零件的話，規格也不好定，為什麼呢？原因可能是即便是同乙個事物在不同的領域裡的抽象角度也是不同的，比如說：手機吧，在手機銷售的系統中關心的是品牌、電池容量、顏色、聲音和鉉、**、是否雙卡雙待等功能性和方便性；而在手機生產系統中的抽象角度應該關注在材料、晶元、模具等其他的元素了；或許在其他的系統中手機由於個大、沉重而被抽象成防身用的**了呢。再比如吧：銀行系統對客戶的姓名、收入情況感興趣，而對於他的鞋子的尺寸和腳的大小不感興趣，那是鞋子銷售系統應該關心的事情，同樣是一客戶在不同的系統中卻得到了不同的抽象元素。你說了，我考慮到所有的抽象角度來定義乙個通用的手機的乙個零件。先拋下不可能的因素，即便成功了，那麼對不起，針對單一的系統來說，由於抽象過量造成系統增加了不必要的資訊而可能複雜了。我們常說物件導向，將現實中的實物抽象成軟體系統中的物件，這裡更多講究的是抽象的角度，同乙個事物在不同的系統中認識的角度是不同的，如果角度選擇錯誤了，後續的很多任務作做起來很是彆扭，甚至偏離方向。如果客戶花錢買了的東西還感覺到彆扭，提出一些變更，誰有理由怪他們呢。
這裡其實還有另外乙個意思，客戶花錢要買乙個系統，可能他自己都不知道這個系統是什麼樣子的，客戶的腦子裡有自己想象的乙個系統的樣子，做系統的人的腦袋裡同樣也有乙個系統的樣子，那麼這兩個「樣子」是不是一樣的呢？如果做系統的也不及時的告訴他，像個寶似的捂著，等系統都做好了再拿給客戶看，客戶確實嚇了一跳，不過跳的是和他想象的「樣子」完全不符合。不管採用什麼方法，將系統是什麼樣子的盡早的告訴客戶，就可能將變更在早期進行，減少風險和成本。很多的時候客戶真正的需求是從他看到系統的樣子才開始的。
既然軟體注定是「軟」的、多變的，變化也就越來越被作為乙個事實被更多的人接受了，並想法設法的去適應這種不可預知的「變化」，將因變化造成的傷害減到最低，甚至有的過程思想還提出擁抱變化，讓變化來的更猛烈些吧。
****************************
小菜這段時間所在的專案是個稱之為「
2.0」的公升級改造專案，為了從客戶那裡挖來點銀子好讓大家今年生活無憂，當然最重要的還是為了滿足客戶在新的形式下更好、更方便的開展業務，為客戶創造更大的利益。利益是互相的，任何一方沒有利益都不會促成要做的事情，無論是短期的還是長期的。目前專案已經接近尾聲了，大點的業務需求已經都基本結束了。這天
psm王老師將大家喊在一起，告訴大家目前基本上是乙個成型的版本了，今後的工作要更加細心，後期的工作重點轉移到需求變更的處理上，並強調制更是不好處理的，為了不至於因為變更造成錯誤問題，要求大家按照兩種方式進行： 1
、「半結對程式設計」的方法。 2
、所有的變更都要經過
ccb的評審。
小菜知道有個「結對程式設計」的方法，講究的是對於一段**的編寫任務兩個人同時進行，乙個人敲鍵盤寫**，另乙個人看，看到人能檢測到寫**的人的**的完整性，保證**沒有漏洞，邏輯的、合理性的、功能性的問題等。那麼「半結對程式設計」是怎麼回事呢？後來小菜了解到是這樣的：編碼的工作還是由乙個人單獨完成，完成後的**交給另外乙個人進行**走讀（
review
），為了防止
review
的人敷衍了事，如果這段**出現問題，同時追究兩個人的責任。小菜覺得這種方式對**
review
的人的要求比較高，果然這類
review
的人基本都是那批戴的帽子比較多的「需求分析設計人員」，原先小菜一直覺得部分人出方案還行，編寫**不怎麼地，通過這次「半結對程式設計」的實施，小菜的想法改變了，原來這部分人也有編碼的高手啊，並且有的思想也挺高的，很多的時候都能給出**不合理的地方，給出點重構的意見。 談到
ccb（
change control board
變更控制委員會），很多的專案團體處理需求變更的時候都有這個組織，小菜在一些書上也看到過，知道這個小組的作用是什麼，雖然大家都知道這個小組的作用，但是具體的實施卻是各有不同的，適合的就是合理的。
2.0的需求變更分兩種情況：客戶提出的變更、開發人員自發提出的變更。 1、
客戶提出的變更申請，此時的處理流程是這樣子的：
1)客戶提出需求變更，提交給
psm。這裡
psm做的是否有點多呢？可以交給配置管理員做嗎？估計可能是
psm對業務較熟悉，能從客戶提出的變更裡獲得更多的資訊吧。 2)
psm記錄到需求變更文件中，並提交給
ccb。 3)
ccb對變更進行評審，可行性了、影響面了、負責程度了等。評審結果分兩種： 1.
不通過、更新需求變更文件，給出不可行的原因。 2.
通過，指定開發人員進行**編寫。指定的**
review
人員進行**
review
。編碼人員和
review
人員完成後分別更新需求變更文件， 4)
通知客戶最終的結果。 2、
開發人員自發提出變更（也包括設計人員的變更），這類的變更一般都是系統存在的
bug或者為了更優化程式結構提出的。其處理流程是這樣的：
1)開發人員將變更填寫到需求變更文件中，並提交給
ccb。 2)
ccb對變更進行評審，可行性了、影響面了、負責程度了等。評審結果分兩種： 1.
不通過、更新需求變更文件，給出不可行的原因。 2.
通過，指定開發人員進行**編寫。指定的**
review
人員進行**
review
。編碼人員和
review
人員完成後分別更新需求變更文件，如果涉及到客戶操作性和體現元素類的變更要通知使用者的，使用者如果建議不改，那麼也就終止了。 3)
通知客戶最終的結果，通知客戶這塊是有選擇性的，並不是所有的變更都通知客戶，對於客戶接觸到的頁面啦什麼的肯定要通知客戶，否則你私下改了使用者還不知道，可就麻煩了。如果是後台邏輯**重構之類的改動，就不要通知客戶了，乙個原因是他們不關注這些，再乙個原因就是可能會引起他們對系統穩健性的懷疑：怎麼總是改動呢？是不是還存在很多問題呢？別讓客戶引起猜測而失去對系統的信心。
這裡的ccb成員有十來個，一般是各個模組的負責人，乙個變更有可能引起幾個相關模組的改動，模組負責人就是要看一下變更是否對自己的模組有影響並安排相關的人員進行對應。測試負責人、系統架構師、
psm、某個關心專案的領導、一般還有個配置管理員，告訴大家文件在**了，什麼角色的人應該填寫哪些。看情形是否還包括客戶，有的變更是客戶提出的，有的涉及到客戶看到的內容的都要通知到客戶的。
1.「半結對程式設計」的方法，保障釋放的**更準確。
2.ccb
的作用，如果乙個專案成立了這樣的小組，並規定了乙個做事的流程，最好這麼做。
3.如果覺得**需要修改，如果沒有
ccb這樣的小組，至少要告知模組負責人，你的考慮可能是欠缺的，其他的相關的模組沒有考慮到。千萬不要以為改動很小而偷偷的改了。
蔣濤 從程式設計師到老總經歷
對於每乙個程式設計師來說都是尷尬的年齡，彷彿舞台上不知不覺間已經謝幕，而自己仍在獨舞 創業，對於每乙個程式設計師來說都是曾經想過或者正在憧憬的夢想，可是夢想與成功之間難以逾越的距離卻也讓多少人望而卻步 蔣濤，這位曾經的程式設計師，如今的csdn掌門人 程式設計師 雜誌總編輯，當他一路走過時，也許我們...
菜鳥程式設計師的半年成長經歷
十月一總結會，主要目的是為了幫助大家解決一下十月一長假大家學習上的問題，大家都挺積極發言，並且每個人都能發現自己學習上的問題。能發現自己的問題就是不是問題，一次次的改正，相信一定可以更好。這次會議讓我思考了很多，經歷半年的成長，五步學習讓我真正的成為了菜鳥程式設計師。2011年的寒假我們真正開始對v...
程式設計師老兵的十點工作感悟
程式或者功能模組在開始編碼前，要先完成概要設計和詳細設計，小組討論通過後，再開始編碼。要 想在前，做在後 程式或指令碼的注釋要盡可能寫全，不然日後，即使作者自己也不能夠明白當時的用意。寫明檔案頭注釋，函式頭注釋，全域性變數注釋，結構體 類變數注釋，段增改注釋。程式 指令碼檔案和重要的工作文件，完成後...