他山之石，可以攻玉（一）

 

-------澄識-------------------

1、項目要當做產品做。要多想。產品是有延續性的。做項目時要考慮將來的延續，橫向的通用性。並不是所有的業務系統都要一個模式，項目整個代碼拷過來改改就行。把通用的東西抽出來，做成架構，有一定的規範限制，把具體的交給實現人去做。每個項目或日常都這樣想想，都做一些重構，一年下來，也有不少收穫。
2、業務部門做純技術有困難，而且純技術到最後，都是演算法，沒有很好的數學功底不行。如果想把某一門技術磚得很深，工作上需要有實踐的機會，需要對該技術的很 多情境都瞭解，而業務部門通常只是用用，情境也只是一種。業務部門比較好的發展方向，是做系統設計，架構。結合自己的業務，找出最好的系統設計。在做系統 設計時，自然會想到業務。架構師發展到最後，不一定對某些技術瞭解的很深，更重要的是能夠根據一個情境，給出好的解決方案，他甚至可能對JAVA並不熟， 但能給出好方案。
3、關於表達，需要知道對方想聽什麼。同一個問題，對100個人會有100種不同的答案。就是換位思考。有意思的是，當跟一個比自己層級高很多的人溝通時，因為很難知道對方真正想聽什麼，所以你跟他溝通會很難，他跟你溝通不難。

 

-------馮春培-------------------

昨天做了一整天的評委，原來以為6點半結束，卻不知覺的搞到了10點。其間反覆跟每個人都談過我看的標準問題。
理想的P7：
1：把控技術細節（不要只以解決問題為目標，而要深究原因）
2：專業和技術方向上能獨當一面，你的主管把你往那一放，就能放心！
3：能跨團隊協調，能整合技術方案，解決棘手的事情
理想的P8：
1：把控技術細節
2：能有較強的整合跨部門技術和資源整合能力，從問題和價值出發，比較完善的有體系的思考和解決問題，思考問題能覆蓋更廣的維度（包括技術、團隊、公司、客戶）
3：技術方案能考慮到到2--3年的延續性，年初能講清楚年底自己到底要幹成哪些具體可衡量的事情，以及這些事情帶來的價值-------岑文初-------------------

對於業務性需求變更，思維方式應當按如下順序進行：

第一，是否已經有類似功能，需要做些改進就可以滿足需求；

第二，沒有類似功能，是否可以抽取部分已有功能，再做部分封裝即可實現；

第三，完全沒有可以複用的內容，考慮一下後續可能的業務需求。

也許上面的內容比較虛，但業務一定是根據情境來做出實際判斷，而這三點其實就是一個理念——不斷最佳化業務代碼，複用的思考會促進不斷地合理化結構（因為大部分情況下，複用性越小的代碼其結構本身存在耦合性過強的問題）。

非業務性需求變更主要是指由於系統自身應用情境發生變化（包括處理的資料量、商務規則複雜度等），而使得需要對現有系統做結構性調整。