dwater 2005-04-26
[2003
年度建議
]
1．加強對單元測試的重視，鼓勵程式設計師進行嚴格的單元測試，測試**入庫；
2．對每個專案安排全職人員扮演「客戶」的角色，捕獲需求、編寫功能測試，進行業務決策；
3．「整個」系統盡早地、小步驟地整合，以早日暴露風險、穩步前進；
4．減小同一專案組相關人員的溝通障礙，特別是物理上的障礙，比如距離；
5．將專案管理人員融入到團隊中來，觀察、記錄、反饋，而不僅僅是在遠處做文案工作；
6．減少形式化、不必要的文件；鼓勵簡短、清晰、有價值的文件。
1．一名全職客戶，負責業務、功能測試用例。
2．「整個」專案盡早整合。
3．任何**上的變化，先單元測試，再整合。單元測試上的一分鐘，可能是整合測試上的乙個工作日。
4．編碼規範、檔案目錄組織、配置管理策略。
5．保證用例文件一定的抽象性以應對需求變化。
6．尊重、謙遜、傾聽。
[phone gal 0.2 2004/01/16-2004/02/23]
1．全體成員坐在一起，面對面的交流；
2．在團隊中引入專職業務人員；
3．測試與開發緊密結合；
4．盡早交付，養成良好的交付習慣；
5．提倡乾淨簡潔的文件，減少中間產品；
6．反對加班；
7．領導給團隊始終如一的支援；
8．寬容，而不是抱怨，每個人都會犯錯；
9．指導，而不是越俎代庖；
10．警惕對「簡單」的掉以輕心；
11．輕裝上陣，信心、樂觀，但不失危機感；
[phone gal 1.0 2004/03/16-2004/05/07]
1．複雜的流程會嚴重打擊人員的積極性；
2．需求不明朗時的進度安排：列舉要完成的
task
，盡量細化、合併至1到
2個工作日；
3．時刻不要忘記專案的第一目標是交付軟體；
2004/05/17--至今
]
1.交流、傾聽！勇於提出自己的想法，且不要輕易否定別人的想法。
2.專案中的各項活動、決策要有自己的想法，必要的時候堅持己見。
3.「聞道有先後，術業有專攻」。要清楚，很多事情別人可以幫你。
4.如果你想改變他人的想法，首先你應該喜歡他，了解並讚賞他的過去。
5.如果你討厭乙個人，他也會同樣討厭你。
6.勤奮學習、積極進取是乙個開發人員的優良品質。
7.**、測試、產品應該先建立好驗收標準。
8.除了要分清哪些是重要的事情，哪些是緊急的事情外，還要思考哪些是其他人可以做，並不是非自己做不可的事情。
9.注意資訊的傳遞時機！並不是越早越好。
10.不要期望讓你的上司來管理你，重要是自己來管理自己。
聊天專案引發的思索
1.socket pair的實現方式？2.什麼是i o的同步非同步，什麼是網路的同步非同步？3.解釋什麼是i o復用？4.libevent底層實現 5.如果沒有i o復用如何實現併發？6.tcp ip協議配合json會出現什麼問題?如何解決驚群現象？這裡為什麼使用多執行緒？完後什麼需求 解決什麼問題...
專案移植點滴
15.1.29 以前沒接觸過專案移植的工作。之所以會有移植是因為我們自主開發的底層平台變化了，底層平台從3.2一下子跳到了5.0，從版本號看得出來這是一次巨變，所以直接導致以前的做過的專案無法使用，但客戶不會管換架構的問題，這是軟體公司內部的事情，客戶要的就是和之前一樣的結果，如果錦上添花也可以，但...
專案經驗點滴積累
1.實事求是，不去實踐，永遠不知道事物的真實一面，之前聽別人說公司各種不好之處，如今親身感受，公司不錯，險些誤了這乙個寶貴的實習機會 2.實驗室沒有老師的輔導，自學效率極低，環境很重要 要跟著老師虛心向每一位前輩學習 1.一句一句地研讀專案 不放過一處不懂的地方，細扣！以專案的 來迅速學習 研究別人...