開發組長，在軟體開發部門中屬於最基層的管理者， 相對於部門經理、專案經理，其位算不了什麼，但在參與共事的小組成員中有著其特殊地位。 首先，對上一級，需要通過開發組長或者專案組組長了解整個專案的進度情況以及小組各成員的工作情況，很多時候上一級都會比較忙，而他要了解底下的人員做得怎麼樣，大多數時候都得靠小組長提供這些資訊。另有什麼新的任務，也需要通過小組長去具體的分配，因為小組長可能更瞭解專案組成員的特長及任務的熟悉情況，只有找對了人，完成任務的效率和質量才能得到保證。 其次，對於專案組成員，需要通過開發組長了解專案的總體規劃與安排，同時在具體實現的過程中可能會遇到一些困難，同樣需要通過開發組長向部門經理或專案經理彙報、尋求解決方法。日常中的意見、建議大多時候也可能通過開發組長向上去傳達，因此，開發組長有點像一箇中間件，起到很好的銜接作用。 與此同時，開發組長也有自己的工作需要做，但他必須得顧及上述的兩點，因此，對於自身參與開發的部分應該是一些介面性質的，類似整合，相對而言，實際工作量不會太多，但需要綜觀全域性、綜合起來應用。在技術上，開發組長的知識面、深度都極其重要，只有能普遍的把問題解決，才能在專案組中贏得威信、樹立起榜樣。業餘時間必須得多鑽研、多測試，隨時都可以為專案組成員解決一些問題。 作為組長，是一名基層管理者，除了技術上要求有過硬的本領之外，必須得學習、領悟、運用一些管理學的知識，在日常工作中，注意留意專案組各成員的工作情況、態度、情緒，這些都必須有所瞭解，否則將直接影響到整個專案組的工作進度及良好工作氛圍的營造。 雖說上有老大，下有手下，但真正做好一個開發組長並不容易，需要在平時多加琢磨、總結、領悟；既要注意提高技術水平，也要留意管理學知識，作好基層的管理工作，處理好專案組成員間的關係；只有這樣，才能帶領好整個專案組完成一個又一個開發任務。 程式設計師(英文Programmer)是從事程式開發、維護的專業人員。一般我們將程式設計師分為程式設計人員和程式編碼員，但兩者的界限並不非常清楚，特別是在中國。 

作一個真正合格的程式設計師，應該具有的素質。 

1：團隊精神和協作能力 

團隊精神和協作能力是作為一個程式設計師應具備的最基本的素質。軟體工程已經提了將近三十年了，當今的軟體開發已經不是程式設計了，而是工程。獨行俠可以寫一些程式也能賺錢發財，但是進入研發團隊，從事商業化和產品化的開發任務，就必須具備這種素質。可以毫不誇張的說這種素質是一個程式設計師乃至一個團隊的安身立命之本。 

2：文件習慣 

文件是一個軟體系統的生命力。一個公司的產品再好、技術含量再高，如果沒有缺乏文件，知識就沒有繼承，公司還是一個來料加工的軟體作坊。作為程式碼程式設計師，必須將30％的工作時間寫用於技術文件。沒有文件的程式設計師勢必會被淘汰。 

3：規範化的程式碼編寫習慣 

知名軟體公司的程式碼的變數命名、註釋格式，甚至巢狀中行縮排的長度和函式間的空行數字都有明確規定，良好的編寫習慣，不但有助於程式碼的移植和糾錯，也有助於不同技術人員之間的協作。 一些所謂的高手甚至叫囂高手寫的程式碼一般人看不懂，我只能說他不是一名合格的程式設計師。 

4：需求理解能力 

程式設計師要能正確理解任務單中描述的需求。在這裡要明確一點，程式設計師不僅僅要注意到軟體的功能需求，還應注意軟體的效能需求，要能正確評估自己的模組對整個專案中的影響及潛在的威脅，如果有著兩到三年專案經驗的熟練程式設計師對這一點沒有體會的話，只能說明他或許是認真工作過，但是沒有用心工作。 

5：模組化思維能力 

作為一個優秀的程式設計師，他的思想不能在侷限當前的工作任務裡面，要想想看自己寫的模組是否可以脫離當前系統存在，通過簡單的封裝在其他系統中或其他模組中直接使用。這樣做可以使程式碼能重複利用，減少重複的勞動，也能是系統結構越趨合理。模組化思維能力的提高是一個程式設計師的技術水平提高的一項重要指標。 

6：測試習慣 

測試是軟體工程質量保證的重要環節，但是測試不僅僅是測試工程師的工作，而是每個程式設計師的一種基本職責。程式設計師要認識測試不僅是正常的程式除錯，而要是要進行有目的有針對性的異常呼叫測試，這一點要結合需求理解能力。 

7：學習和總結的能力 

程式設計師是很容易被淘汰的職業，所以要善於學習總結。許多程式設計師喜歡盲目追求一些編碼的小技巧，這樣的技術人員無論學了多少語言，程式碼寫起來多熟練，我們只能說他是一名熟練的程式碼民工，他永遠都不會有質的提高。一個善於學習的程式設計師會經常總結自己的技術水平，對自己的技術層面要有良好的定位，這樣才能有目的地提高自己。這樣才能逐步提高，從程式設計師升級為軟體設計師、系統分析員。 


作為高階程式設計師，乃至於設計師而言，除了應該具備上述全部素質之外，還需要具備以下素質： 

1、 需求分析能力 

2、 整體框架能力 

3、 流程處理能力 

4、 模組分解能力 

5、 整體專案評估能力 

6、 團隊組織管理能力 


1，激情。 

我曾經遇到許多“職業程式設計師”，他們從事IT是因為覺得這是一種職業，他們只在工作時間程式設計，除非送去培訓否則他們不會學習新東西，這不是好的程式設計師。我認為一個好的程式設計師總是對程式設計充滿激情，而且好的開發者會做一些程式設計工作即使這沒有報酬。激情是一個優秀程式設計師的重要指標。 

2，自學好學 

程式設計領域始終發展變化著，不出一年有些新技術就變成了老技術，這並不是說好的程式設計師要對所有新技術跟進，但有些卻對學習任何新技術都沒有興趣。他們通常在學校學習了程式設計，然後工作後單位安排學什麼就學什麼。如果在招聘中你聽到“讓我培訓一個星期我就會勝任這個工作”那不要僱傭他。實際上，真正優秀的程式設計師始終談論著你所不知道的新技術，向人們解釋為什麼你必須用這個技術，哪怕沒有聽眾聽得明白，哪怕他自己也不明白。 

3，聰明 

聰明包括很多因素，情緒和社會交際只是其中之一。好的程式設計師絕不木訥，他們是最聰明的人，他們中的許多善於交際，健談、興趣廣泛。 

4，隱性的經驗 

—好的程式設計師通。常有自己的私人的一些研究、愛好、專案，而這些是他們不寫在簡歷上 (通常覺得不值得寫)，但表現出來卻可能恰恰是他的潛能、深度和後勁所在。 

5，技術多樣性 

由於好的程式設計師喜歡學習和涉獵新技術，所以一般來說超過22歲的都熟知很多新技術，而且對多種技術的長短有 “強烈”的個人意見/見解，喜好嘗試新鮮技術。 

6，資格證書 

資格證書並不是識別真正程式設計師的方法，MCSE、SCJP、說明不了什麼，它們只是讓別人認識和獲取的，頂多代表這個人在某個技術有一定的知識。 

原文作者在文末寫道：以上所說的標準並不是絕對的，因為有些優秀的程式設計師確實不符合上述，而有些bad程式設計師卻符合了。但相信這些對大多數真正的程式設計師都適用。 

總結而言，優秀的程式設計師通常有一下特點： 

n 對技術充滿激情； 

n 將程式設計作為一種愛好 

n 如果你允許會滔滔不絕地跟你談論技術 

n 有過個人的開發經歷（與4意思相同） 

n 堅持認為某種技術最好 

n 如果讓他用他認為不好的技術他會非常彆扭 

n 聰明、健談、興趣廣泛 

n 在大學和工作前就開始接觸程式 



只有做一個專業的程式設計師，才有可能有希望。 

加油，加油，！！！1 軟體研發人員的考核 軟體研發人員的考核一直是軟體企業管理的難點，筆者在長期的研發管理實踐與諮詢實踐中，總結了進行軟體研發人員考核的一些基本原則，整理出來與大家共享： 
　　◆Ø要體現公司的價值觀 　　公司的價值觀體現了公司認可什麼型別的人員？要挽留哪些人？提倡做什麼？對這些人員的認可可以通過具體的考核辦法落實下來。比如企業鼓勵在某一個業務領域內積累豐富的領域經驗，鼓勵在某個技術方向上進行深入鑽研等，對於提倡的這些行為，要有具體的獎勵措施。所以在定義考核辦法時，需要首先考慮清楚要體現企業的哪些價值觀。 　　◆Ø要體現多勞多得，質與量並重 　　不能讓那些完成了大量艱苦工作的人員吃虧，否則就會打擊真正努力工作的人員的積極性。多勞多得原則的實現，基於對工作量的計算。規範的管理都是以人為本、以過程為核心、以度量為基礎的。要做到多勞多得就需要做好對工作量的度量，如果僅僅注重工作量而不關注工作質量，顯然是不對的，而對於質量的考核，可以通過多個渠道來獲得資料，如發現的缺陷個數、客戶的反饋等等。當然多勞多得的前提是團隊的目標達成了，如果目標未完成，多勞未必多得。 　　◆Ø要鼓勵創新與規範管理 　　管理與創新是軟體企業發展的2個輪子，通過規範管理可以確保企業的常規發展，通過創新實現企業的跳躍式發展，管理為創新提供了轉化為生產力的基礎，創新可以快速地提高企業的競爭能力，因此在考核辦法中要體現出來對這2者的認可。有的企業設立了創新基金，專門用來獎勵那些技術創新、管理創新等，有的企業在研發人員的考核指標中加入了對過程改進工作的支援等指標。 　　◆Ø要鼓勵技術複用 　　成功的軟體企業必須在人員、技術、過程三個方面加大投入。軟體複用是目前軟體公司提高軟體生產率的最有效的手段之一，為了在企業內建立組織級的技術複用體系，首先就要鼓勵大家主動去提取可複用的各種構件，主動貢獻可複用的構件。對於這種提取可複用構件的行為，應根據其可能帶來的收益，適當給予獎勵。 　　◆Ø要因時而變，但要儘可能保持連續性 　　考核辦法的制定都有一定的針對性，具有一定時限性，隨著公司內外部環境的變化，隨著公司文化的逐步穩定，對考核辦法要逐步調整，在改變考核辦法時，要注意保持考核辦法的連續性，不要變化太大，否則就會讓被考核人無所適從，產生觀望的心態，或者在研究考核辦法上花費很多時間，造成不必要的生產效率的下降。 　　◆Ø要量化與非量化結合 　　如果沒有量化的考核指標，全靠非量化的指標，對於開發人員來講，很難體現多勞多得的原則，很容易走向吃大鍋飯的模式，無法調動開發人員的積極性。如果全量化也很難，在開發過程中，有很多工作難以量化，比如需求開發的工作，就很難定量的計算工作量。因此在考核時，在儘可能量化的基礎上，也允許有一些非量化的指標的存在。至於2者的比重，可以根據當前企業的管理水平來確定。對於管理比較規範的企業，成熟度比較高的企業，可以採用量化的指標多一些，量化的比重大一些。 要區分不同的崗位，不能一刀切 　　對於專案經理、需求分析人員、設計人員、程式設計師、測試人員、質量管理人員等，工作性質、能力要求、績效表現的特徵都有比較大的差別，因此要區別對待。這樣便於體現考核辦法的內部公平性與外部公平性。比如對於質量管理人員，大部分是日常的事務性的工作，其工作業績的體現是長期的，他們的工作重心是預防缺陷的產生，採用量化的資料就比較困難，可以考慮採用改進率等指標來考核，而程式設計師的主要工作是實現設計，任務的規模與他們的工作效率、質量是可以量化的，這2種類型的考核辦法就應該是不同的。 　　◆Ø要保證被考核人的及時知情權     事先要將考核辦法告知被考核人，考核結果要及時通知被考核人。考核的目的是為了發現改進工作業績的方法，激勵員工更加努力地工作，考核辦法也代表了公司的價值觀，因此要讓被考核人對考核辦法很清楚，讓他們知道什麼是應該努力去做好的，這樣才能起到激勵作用。考核的結果應及時通知被考核人，這樣能夠給他們一個及時的肯定或者否定的刺激訊號。 　　◆Ø不以被考核人自己提供的資料為考核依據 　　如果以被考核人自己提供的資料作為考核依據，則會造成資料的失真。在軟體企業中推行開發人員的個人日誌時，遇到的最大的問題就是日誌的失真問題，為什麼呢？因為開發人員擔心自己填寫的日誌會成為自己的考核依據，會成為評價自己的工作努力程度的依據，因此本能地會傾向於滿負荷地填寫自己的工作量。 　　◆Ø考核指標要和被考核人直接相關，被考核人對考核指標的達成能發揮重要的作用 　　在很多軟體公司中，經常發現員工的考核與公司的利潤、部門的利潤或者專案的利潤掛鉤，對於銷售部門、事業部或者其他直接與市場相關部門，這種考核是有激勵作用的，對於研發人員來講，這種辦法的激勵作用就不那麼明顯了。利潤的形成有多方面的原因，可能大部分原因不是開發人員所能決定的，將不由開發人員所決定的因素與其考核掛鉤，是不合理的，即使開發人員再努力，也不能對利潤的形成起到實質性的幫助作用，為什麼要和利潤掛鉤呢？
 
  　古人云：知易行難。道理很簡單，落實時卻涉及了企業的方方面面，有歷史的原因，有現實的問題，有未來的不確定性，但是這些都不應該成為逃避考核問題的理由，必須去嘗試，才有可能解決這個問題！ 研發經理日記 ENP 1.0釋出一個月了，還是無法推向客戶。 我十分失望。 作為結果來說，4個月前我所設想的利用放權、流程和引入專業使用者介面來達到低成本開發使用者滿意的設想是失敗了。 方蕾已經非常努力了。我真的很難以責怪她。她的人脈，敬業，在處理一些其他問題上的創造性，是使我覺得可以一試的底氣。但就如武林高手對決一樣，無論事先如何能如何策劃周密，動起手來還是要靠武功決定勝負。她畢竟在對軟體產品和技術本身的把握上還是難以達到一流高手的境界。 我也無法責怪柳平。帶著幾個報酬和工作經驗一樣少的研究生，管系統構架，管資料庫設計，管程式碼整合，管技術難點……可是，當我開啟原始碼的時候，還是幾乎大光其火。90％的程式碼沒有任何結構，資料庫查詢語句和其他程式碼混合在一起，業務邏輯處理程式碼和頁面顯示程式碼糾纏不清。我這寫了十幾年程式碼的老程式設計師，花了一天沒看懂一個程式檔案！ 上海的使用者介面設計師呢？我能怪他們嗎？他們反應迅速，設計的模擬軟體在外觀上也中規中距。可是，還是很難用啊！很多東西根本就是牛脣不對馬嘴。 還有測試組，他們有沒有腦子啊？ 算了算了，還是我的問題。我在組建好隊伍，定義了高層需求後，基本上就放手不管了。這顯然給我一個重大教訓。 教訓一：任何下屬，無論多麼敬業和具有其他優良素質，如果專業技能和本身能力尚未達到承擔某一任務時，即使有良好的流程，也不能通過簡單放權來企圖達到一勞永逸的結果。建立週期性的反饋是畢不可少的。這也是上司的責任，通過反饋來培訓下屬。 行動指南：建立針對專案的週期性一對一會議。 明天早上我就去設立一個與方蕾和柳平10分鐘的週會，定在週二吧。 楊疾的人和個性一樣獨特。他是我最近招到ENP小組的高階程式設計師，不過他以前從來沒有開發過Web程式，因此他每天都學習到晚上十點；他上週末回老家了一趟，居然把右手弄骨折了，因此輸入程式只能單手。他說是練拳練的，“醫生說以後再也不能練拳了。”，他跑到我辦公室向我提出ENP中的設計問題的時候，很有點惋惜的說。我很懷疑他和人打架，可也不好說什麼。 “我覺得我到了這個公司就像手腳被捆住一樣，你知道，我從深圳回來損失的不是一點點”，他的話很有點刺痛我。如果我的團隊不能讓新人覺得有益，他們就會離開。他提了一大堆關於設計，產品和程式碼的問題，也讓我覺得他確實很有洞察力。我和他談了一個小時，讓他覺得舒服了一點。可是危機感越來越重的圍繞來我的腦中，我的頭又開始痛了。昨天忘了吃腦心通，今天似乎大腦就有點堵塞。我得做點什麼。 6/1/04 早上起來，天氣非常好。我跨上膝上型電腦包，下樓，出小區，心情非常好。六月天，空氣漸漸變熱，伴隨路邊花樹綻放，蜂蠅倏忽，心情陡然好轉。我決定走路上班，不就二十分鐘嘛！笑。 走了一半路，右邊電腦包沉重，舉手把它甩到左肩。突然，一個想法過電在大腦裡。幹嗎週會？開日會不更好嗎？記得極限程式設計的一個實踐就是每日晨會。以前對EVP專案是太抽象管理了，現在每天十分鐘，迅速Ping一下，可以瞭解專案，也可以觀測每個人的能力品行。實際上，重組換人的決心在我心中已經定了。 早上到了公司，還是得處理完全部的郵件，結束時，已經十點半。趕緊回顧了一下極限程式設計的知識，覺得有底了，召集所有EVP成員開會。 方蕾、柳平、陳丫丫和大部分人都到了。我看到楊疾剃著平頭，斜靠在一張椅子上，面沉似水。 我先敘述了一下當前的問題，我講的很小心，避免講出“你們實在做的太爛”的話來。但每個人還是感到了我不滿。我嗅到空氣中略有些緊張氣氛的時候，話題轉向今後要做什麼。下屬也許是這樣，如果聽到上司對日後的事情還有具體安排，大概會覺得事情還能過得去。我現在還得需要他們齊心協力。 對諸如極限程式設計這些軟體實踐，我向來抱著拿來主義的態度。我特別不喜歡應用的時候，先冠個名，然後再推行。就好像扯塊布當大旗似的。所以我講的內容講完了，一個字沒提極限程式設計，只是告訴大家： 每天早上八點四十五，所有的開發，測試都到EVP開發工作區，開十分鐘的站立晨會。 方蕾還是負責專案管理，產品特性管理並和上海產品設計中心確定所有的UI，每個UI要經過我的確認。 會開完了，我噓了口氣。我看到楊疾還是面沉似水，一隻手裹著繃帶，回到座位去了。 這天晚上，我回到家，繼續處理不停傳來了信件。我想起一句話，這家經理沒有下班和週末，他們的週末只不過是每隔五天有了可以休息的機會。 “Buzz”，我的IM叫喚了。是楊疾。 以下是我們IM對話： 楊疾:      我想和你談談 我：        好啊 楊疾:      但是要找一個相投的人,否則,對牛彈琴 我:          我喜歡和有想法的人溝通 我:          有人能合理地挑戰我,我最喜歡 我:          :) 楊疾:      其實我只是想,在沒有人打擾的情況下,我們就你現在的目標,討論一些實際可以操作的方案,這是我的想法 楊疾:      其實,我曾經做過你的位置,想到一些和你一樣的問題 楊疾:      但是有些想法老闆不支援 楊疾:      很正常 楊疾:      因為,他們要求的就是短時間出產品,怎麼出他們不管, 我:          到目前為止,老闆都很支援我. 我:          他想要的是我給他建設一支上千人的企業 楊疾:      你約個時間,我們好好聊聊,我請你吃飯如何 楊疾:      我確實想好好發展 楊疾:      我現在把你當成我的好朋友 楊疾:      我告訴你,我在這兒的目標是什麼 我:          好啊,你說 楊疾:      從公司角度來說,我要求能夠充分展示我能力的環境和場所 楊疾:      並且能在我和大家的努力下,不斷變好,我會有成就感 楊疾:      從個人角度來說,經常和一些水平高的人下棋,結果是自己的水平不斷的提高 楊疾:      我的能力的提高,使我夢寐以求 我:          其實公司還有很多人很有水平,你可以都看看 楊疾:      我知道,我上次開公司的失敗,告訴我我的能力還是不夠的 楊疾:      我早聽說了 楊疾:      一直無緣套近 楊疾:      是我的失敗 楊疾:      你所說的一切和人好像都是技術上的, 楊疾:      有沒有管理方面的呢 楊疾:      其實,我不知道你有沒有感覺,一個隊伍是不是有戰鬥力,主要看管理 我:          你想,作這些東西,帶這麼多人,沒有管理行嗎? 我:          他們每個人都具有很強的管理能力 楊疾:      你看我們公司現在的隊伍有了這麼多的好手, 楊疾:      我覺得應該會有一個大的發展 我:          我們和Microsoft一樣,需要的是技術和管理都精通的人 我:          我充滿信心 楊疾:      我知道你的意思,但是那你為什麼這麼操心呢, 我:          因為他們包括我還不是世界一流 楊疾:      這其實就是說明,我們公司還有需要改進的地方,特別是管理 楊疾:      我知道了 楊疾:      我本人也想趁上這艘大船,到達彼岸 我:          我們也有打輸的可能噢 楊疾:      扯遠了, 楊疾:      不要這麼想 楊疾:      誰都害怕失敗 楊疾:      就拿我到公司的時候, 楊疾:      我擔心的不是轉不了正,而是怎麼樣才能提前轉正的問題 楊疾:      我不怕失敗,我在深圳的公司,先天夭折,我也只能接受,再去努力, 說實在的，我第一次碰到這麼直接的人，不過，我喜歡。：） EVP專案的本質是工程師的野心。張總讓我啟動這個專案的時候多半剛看過比爾.蓋茨的《未來之路》。 “我們應該建立公司的數字化神經網，你可以讀一讀《未來之路》”，張總是集團技術副總裁，也是公司的奠基人之一。張總從公司一建立就就追隨董事長，在技術口算是一杆大旗。學生時代的張總號稱神童，至今保持著技術人員本色，經常會寫一些程式處理日常事務。 “象你們研發中心，到底現在有多少專案，誰在做，做得這麼樣？現在，”張總笑笑，“我們都很難直接搞清楚”。 我背上一陣緊張，“我每週送到總裁辦的週報應該列出了……”，張總不等我說完，“我沒有批評任何人的意思。我只是在說問題。建立ENP的目的就在建立整個企業神經網路平臺，每個神經末梢的變動都可以讓大腦感知到。” “張總，你知道的，做企業內部系統是最難做的事情。”我說，“為什麼我們不去買一套呢？RUP，或者其他產品。” “呃，”張總髮出他慣有的聲音，我知道這是他思考和準備說服人的前奏。“商業軟體總是不那麼靈活，而且實施也很麻煩。再說，現在是Web時代了。”張總看著我，“如果ENP做的好，可能就進入公司產品線了。你想，這會是件很妙的事情，技術口的想法，能被市場部接受”，張總笑了幾聲，有點幹。 “好吧，能不能再給我幾個編制？”我終於把憋著的話說出來。張總的聲音變得縹緲，“你看，人的問題總是這樣的，你做一點，然後我們一起審查一下，如果結果是好的，那我就再給你加幾個。我們過去不都是這樣嗎？” 看到我有點沮喪，張總最後一句話變成“你現在還可以這樣做嘛。” 我花了幾天天的時間，終於寫完了EVP重構的指導性技術檔案。想來也是受楊疾的影響。這些天，他經常到我辦公室來，和我談EVP系統構架的問題。但是，有時他的思路經常會飄到開發一個全新產品上去。有時我對他的發散思維稍稍鼓勵，他就恨不得馬上就去實現。我很擔心他會偏離了方向。也許是這種壓力吧，我寫完了這篇檔案。（只保留檔案結構框架） EVP重構 日期
 作者
 貢獻者
 註釋
 
6/6/2004
  Cunruizhai
 楊疾
 初始文件
 
6/10/2004
 Cunruizhai
 張總
 增加SLA
  1.       介紹 本文件描述瞭如何重構ENP系統結構。 1.1.     需要解決的問題 1.2.     效率低下 1.3.     原始碼可讀性差 1.4.     原始碼難於維護 2.       系統構架設計 2.1.     四層結構 2.1.1.   表現層 2.1.2.   業務邏輯層 2.1.3.   資料物件層 2.1.4.   資料訪問層 3.       系統構架實現 3.1.     一般實現過程 3.1.1.   入口點 3.1.2.   UI表現和資料更新 3.2.     例子 4.       系統設計 4.1.     全域性物件 4.2.     安全性 4.3.     那些模組需要重構 4.4.     目錄結構 4.5.     檔案命名規則 5.       程式碼風格 5.1.     一般程式碼規則 5.1.1.   縮排和行長度 5.1.2.   控制結構 5.1.3.   函式呼叫 5.1.4.   函式定義 5.1.5.   註釋 5.1.6.   包含檔案 5.1.7.   檔案頭註釋 5.1.8.   變數命名規則 5.1.8.1. 類 5.1.8.2. 函式和方法 5.1.8.3. 常量 5.1.8.4. 變數 5.1.8.5. 全域性量 5.2.     ENP專門程式碼規範 5.2.1.   類 5.2.2.   變數 5.2.3.   Cookie/Session 5.2.4.   其他風格 6.       白盒測試 7.       任務安排 8.       流程變化 檔案寫完了，就該宣灌了。我召集了方蕾、柳平、陳丫丫和所有的開發員測試員，一段一段的講了一遍。我特別強調了白盒測試：“所有測試員要抽檢開發員的程式碼，不符合程式碼規範的就報告一個20級的Bug！” “另外，我也想謝謝楊疾，他給了我很多建議，也給了我壓力和動力來寫完這些東西”，我看了看柳平和楊疾，似乎看不出什麼反應。
高效團隊之最佳實踐 1. 迭代開發 
2. 優秀框架 
3. Bug和需求管理 
4. 原始碼管理 
5. 高效溝通 
6. 周計劃/總結會議制度 
7. 使用任務列表進行專案管理 我覺得核心的問題是： 
你覺得什麼流程和措施才能使得你自己覺得這個專案是可控的？ 這個隨著開發人員組合、公司的管理制度和文化、專案的要求不同而不同，但是總有一些基本的原則在指導，譬如上面諸位所說的溝通、檢查、最佳實踐等等。 老實說，做了這麼多年系統和程式，對這個問題我也是非常迷茫的，最近帶了一批新大學生來做系統，結果只能用慘不忍睹來形容了。 唉，反思，反思、再反思！！！
個人覺得，專案管理最重要的是人的管理。從這篇日記來看，這位研發經理對人的管理還需要進行改善。在專案進行中，最主要的是能調動所有專案組成員的積極性，尤其是專案管理者。要對專案的發展持有樂觀的態度。如果專案最終失敗，我覺得最後主要的原因肯定是專案管理者的問題，畢竟其他實施人員只是按照管理者的意願進行操作和實現的。 
不過楊疾這名員工我覺得可以好好的利用一下！一方面也是投其所好，會讓他工作時更積極！給他提供一個好的機會。他會為實現自己的目標更賣力。其他的人員，我覺得應該也要好好的進行交流！其實專案時間緊並不能成為不做任何事的理由！ 定出一個具體到編碼細節（類、介面）的開發文件，是不是可以保證專案的進度？ 
但我覺得這種文件要花很長的時間去完成，最後反而編碼的時間不夠了。 
如果文件不細緻，專案經理又要花很多的時間與程式設計師溝通，而程式設計師最後的理解可能會有些偏差，加上沒有全域性架構的意識，雖然功能實現了，但編寫的程式碼與專案經理的計劃相去甚遠，這樣長久累積起來，當需求有變動的時候，重構就成了大麻煩。 程式碼風格這種東西現在才提？在招人的時候從筆試寫的程式碼裡就應該看出來。如果實在工錢低找不到好的人才，那就進來後專門培訓2個禮拜。 另外每次code check in 的時候你經常去做一下code review不是更好？沒時間的話讓下面那些有經驗的leader去review一下也行，不要說你手下沒一個能拿得上臺面。 研發心得 1.不管給別人打工還是自己幹，都要全身全意的工作，因為你所做的任何一點工作都會讓自己的人生多一點籌碼。 2.多與市場人員交朋友。可能覺得他們知識比你少，比你有點黃，但實際上他們比你懂這個社會，參加到他們的圈中去。你會通過他們接觸到另外一個世界。 3. 機會遠比錢重要。如果有機會參與除本職工作以外的一些專案或產品的研發中（包括有人拉你做一點小生意之類的事），那怕是幫忙的性質，也要積極介入。至少你會交到很多朋友，這樣你的人生會多出很多機會。 4.老闆參與專案管理未必都是壞事，也不一定是不信任，要與老闆一起學習，要積極面對，猜測別人的想法是溝通的障礙 5.專案經理要儘量爭取組員的利益，即使他要離開也不能壓其工資，要有自己的“格”。方正為格，如果一個人全是圓的，一點方法都沒有，適合作幕僚。 6.要吸取老闆失敗的教訓，他的投資是你學習教訓的最合適的機會。 7.分配任務,當偏移出現時,要做時間日誌,以備後用,得出實際上團隊只用了五分之五十的工作用來進行實際的程式設計和除錯,其餘時間包括機器的宕機時間,高優先順序的無關瑣碎工作,會議,文字工作,公司業務,疾病,事假等
如何在研發專案中提高RDC的研發能力
ISMP專案的感受