i am freshman

及時回報問題：程式員都是樂觀的，認為自己的程式沒問題，報喜不報憂，

其實leader希望能了解項目的進度，有問題困難瓶頸拿出來大家一起分析。

論單元測試的重要性，單元測試可能測出80%的bug，剩下的bug可能是業務沒有搞清楚的原因，程式架構的原因，網路，硬體的原因。

問題永遠存在，解決問題會把這個棘手的問題變的不棘手，帶來别的問題，是以解決後應該多問問自己肯呢個會帶來什麼問題，沒有意識到的潛在問題才可怕。

人月神話中的人月概念，一個項目再裡程碑呃時候延期了，解決辦法是什麼，增加人員是蠢的，應該把工作劃分的關聯性很小，不然一項12月的工作，

1個人需要12個月，12個人還是需要12個月，因為每個人都需要解決所有的問題。這就是人月的概念

外科手術團隊，這個概念我也有所體會，參與過一個100人的項目團隊，每個産品線的負責人每天都要在一個小屋裡碰頭，吧項目的進展和問題說出來，這可以避免有些細節

主治醫生保證産品的概念一緻性~~~~

上述的概念一緻性在實踐中是可取的，但是帶來了後面一章的主治獨裁，那程式員還能有自己發揮創造的空間麼，

我自己的結論是服從指令。如果感覺不對可以讨論，把自己的想法告訴主治醫生，但是服從，這就是軟體工程。

畫蛇添足說的是一個系統架構師在做第二個産品的時候，由于喲第一個項目的經驗，非常細化在他的第二個

版本或者項目中加上很多他想到的但是實際上沒用的都系，畫蛇添足，回頭留一下是不是這樣。

代碼大全：

代碼變量和方法名字的藝術性，最好的代碼是不需要注釋，先從需要注釋開始。

多看些優秀開源項目的源碼，學習變量方法起名。

開發人員時間花費問題：

1/3需求設計

1/6開發

1/4調試

1/4測試

個體與團隊人員的開發效率上也有研究表明存在二八原則，即20%的人開發出80%的代碼。

管理你的管理者：

管理人員可能是不懂技術或者技術很老的人員，如果是這種，你需要用你的觀點去影響他。

在類似有開會讨論問題頭腦風暴這種場合下，他會問你的想法，在這種場合下發表自己的觀點影響他是最合适的時機。

過濾髒資料

釋出上線有一點跟做飯很像，做飯前把食材準備好，不會導緻手忙腳亂