項目回顧

6月項目開始

初始狀態：

maven環境，karaf環境已經建立好

心得

1.熱心的拋磚引玉，想把自己看到的總結提出來討論。（時機不成熟，應該等大家都到場，至少相關人員到場，不然白講）

2.6月底第一次提出Interface的問題，到了9月才修改（反思自己提出問題的時候，出來領導不重視，還是自己當時對問題了解不深刻，應該提出問題的完整描述，而不是只簡單說那樣的Interface不滿足實際使用中的要求，提出Sample和使用場景加深大家的了解）

3.先有框架還是先有實作（教訓是先框架）

有經驗的幾位同事建議先確立框架，在調動人力進來實作。我當時做事風格還是覺得做中學習，做中了解，所以讚成先實作。我以為大家實作是為了優化框架，但其實實作的人太多有壞處，如果讓大家了解，不如不寫code，而只是了解，不然沒有經過確立Interface的code很多最後都是無用的。實作時候發現什麼都沒有，最后為了實作而是做，為了串接而做。（應該站出來說那種情況沒辦法繼續做下去，及時停止）

實作是為了優化框架，但是連框架都沒有，談何優化

先有Design再實作，如果Design不能最終實作，再修改Design滿足實作。。不能信手塗鴉提交到項目中。

我以為每個人都會把流程看一遍，來考慮我們的框架如何建立。但是團隊中每個人的想法和態度是不同的，有的人可能就是追隨者，不是每個人都會用主人翁的心態去參與。我理想的是每個人把自己遇到的部分提出來，怎樣好怎樣不好，去分擔框架設計者的負擔，但是沒有幾個人提。所以團隊中，不可避免有的人loading太重，即使他可能考慮不全面。

我希望每個人在開始時候盡可能都了解全部，之後再專注到自己的分工中，這樣Design review的時候，大家才可以討論，去review。。事實上很多人都是自己編程時候遇到了再了解其他人做的東西。確實大家的精力有限，後期分工去做的時候，會不了解其他人具體怎麼做，但是大局觀，項目開始時候，需要有。（後期時間緊張時候，大家會專注自己的事情的完成）

還是需要把問題看清楚再做，學事情邊學邊做和寫code是有區別的（）

我們應該有效率！ 弄懂是第一位，然後是寫code~~

4.明確需求，有客戶的時候不是我們想當然，客戶會按照他們習慣和固執的方式堅持，這種情況就可能白寫，然後按照他們修改。

遇見新知識

maven 使用

java 8 新特性，lumda

karaf 

Spring和Hibernate了解

osgi 希望bundle相對獨立，所以不要有繼承關係

aspect 去統計各種時間

java promise

java beanutil

JAXB: xjc

還需要學習

Annotation

karaf update bundle SOP

MS甘特圖

openJPA的manual

---------------------------------------------------------------------------------------------------------------------

七月

1. 客戶希望我們八月底把框架定好,有明確的長期目標和短期目標

2. 7月在做一個場景，但是因為框架沒有定好，其實代碼也算浪費了。（場景邏輯不變所以不算浪費這個說法被打臉）

3. 同事希望有代碼的一致性，優雅性（這裡什麼是好的code），code review，Design review，提交code之前。先明確了在寫code。先明確步驟，再開發

4.提交之前一定要謹慎，確保可以運行

八月

1. 真實意義上的開發開始

2. 領導說不知道專案結束共完成什麼東西

3. SM感覺雲裡霧裡，沒有比較領導的任務出現，從開始凝聚向心力去做

SM建議所以owner要開始design review，安排人員上下游，安排討論，指定計劃，計劃要相對寬鬆，來應對臨時的任務，找領導確認什麼時間點確認什麼東西

沒有時間走錯路，不確定的東西找PM或者客戶確認（這時候只有先求有再求好）

4. 關於traning：SM說大家只有在做的時候才去學習，所以開頭的Training效果不大~（喜歡aspect官網的一句話，有時候為了快，少了一些前言或者基礎性的講解，遇到問題后可能解決問題還是要花很多時間，有的路是不能省掉的。對於別人的training，是需要有時間去消化，真正要做，還是要花同樣的時間走那人走過的知識。所以一個人會不代表團隊所有人就會了，下一個人還是要花時間學習，除非第一個人總結的比較好，下一個人不需要知道為什麼，按照模式去實現就好了，這樣節省時間，但是第一個人如果也只是入門，那遇到問題，第二人即使請教第一個人，它也是花時間去學習。）

5. J:因為時間的壓力，你可以一個個實現，最後提取再調試，也可以按照你比較直覺好教給別人的方式做。多開Interface，因為未來換線，做法不一定先提個醒

6. W:不要只顧著眼前，最好抽取成可複用的，移到其他項目的東西

7.提出问题的时候要提出完整描述，应用场景是什么，不要一知半解。J：发现问题，可以发起一个讨论，个人draft一个自己觉得最好的solution，遇到前后相关的，把isue report出来。

8.给领导演示，即使轮不到自己讲解，也要想想该怎么讲。不然临时发挥，太草率。

9.J：做完和做是两个层次，最好找人review，找同伴确认，再把这个项目关了

心得

1. 官網上的html比pdf要完善，內容更新

想要學習的：

osgi& karaf configAdmin， config中使用變量