老猿信息
ID：川川
曾用ID：比爾板三
出生年月：1979年11月
星座：天蠍
專業：工業設計
職業：程序員
PMP
愛好：馬拉松、越野跑
博客：奔跑的猿(原博客地址)
工業設計是非常好的專業，但我沒有這方面的天分。大學一位同學自學通過了高級程序員考試，我對計算機也頗有興趣，開始學習，先後考過三級、四級、高程。畢業後一直從事軟件開發工作，08年奧運前夕來到北京，開始了近10年的外包生涯。
來北京之前，在東北工作六年，從事過ERP實施及維護，開發過自控、病案管理等軟件，涉及PB、VB、JAVA等技術。
外包十年
東家I
NO. 1 H公司
之前，連續的JAVA開發經歷不過1個多月，僅熟悉SSH框架，設計能力很弱。項目剛剛開始，沒有基礎架構，需求也不清晰，脫離SSH模式開發某一部分代碼，如何設計類都不知道，近兩週沒有什麼產出。領導又安排了一個小項目，由我搭建基礎框架，使用SSH、JFreeChart、Open Flash Chart等技術，和一位同事一起開發，順利完成任務。後又加入另一項目組，主要應用SSH2、Ext、JFreeChart、Open Flash Chart等技術，架構基本上模仿江南白衣的Spring Side。
NO. 2 S公司
到了S公司才知道，項目是H公司開發的，要感謝H的推薦。工作內容主要是編寫Oracle存儲過程、Java後臺調用程序。同事部署時採用逐一替換類的方式，經常出錯，這也導致不能確定生產代碼是否與開發代碼完全一致。爲解決這一問題，我開發了Ant打包腳本，再將兩者打的包反編譯後比對修改，確保了代碼一致。工作中，往往一些小問題不去花時間解決，造成浪費更多的資源，產生更多的問題。
NO.3 T公司
開發維護過三、四個項目，涉及Socket編程、Eclipse RCP、SSH等技術。期間對新開發項目的前後臺結構進行了調整，去除了不必要的邏輯，分離出公用代碼，引入JQuery重寫了JS代碼，自定義了常用組件，使代碼結構更簡單清晰。
NO.4 A公司
主要負責前臺原型開發及加密、壓縮等一些技術的研究，涉及Seam 2.2、JSF 1.2、Richfaces 3.3、Hibernate 3、JBoss 4、Maven、Hudson等技術。當時JSF 2.0、Richfaces 4、Hibernate 4、JBoss 7已推出，我曾建議採用新技術並重構一些基礎代碼（如表單驗證、DataModel等），但未被採納。Seam簡化了代碼的開發，但學習較難，其雙向注入、事務處理等也帶來較多問題。
合同到期後，未續簽，也未找新工作，整理了一些資料，此後形成記錄文檔的習慣。
東家B
在一家公司工作一個多月後被解僱。主要使用RCP技術，那時我不看好RCP的前景，最初是不想到這家公司的。工作中遇到一個RCP問題，我只想通過RCP本身而不想通過其他方式解決，遲遲未找到辦法，安排學習Mule ESB也沒進行。在這家公司時間雖短，但學習了一些知識，公司採用測試驅動開發(TDD)，重視代碼風格和質量，鼓勵重構，重視測試，特別是功能測試(使用的fit)。有一些理念或方法，我不大認同：當時團隊剛剛實施Scrum、結對編程，本來幾分鐘的站會往往持續一上午；結對編程我認爲是互相學習的好方法，但我不認爲適用於正常編程，不適合所有人，我更需要安靜的環境；加班成常態，效率低下，有很多時候很多人是不必要加班的。
東家S
在I公司工作至今。到I公司破費周折，原本定好4月份上班，結果拖延到8月份。好在有失有得，這段時間養成了跑步的習慣，至今已參加過幾十場馬拉松和越野跑，跑了大半個中國。
五年的時間，參與了多個項目。
第一個項目主要負責前臺開發，使用的技術主要有CDI、JSF 2、Richfaces 4、Hibernate 4、Concordion、MySQL、MongoDB、Jenkins、Sonar、Jboss EAP 6、Linux，後因有圖表的需求，又引入了Primefaces。項目由thoughtworks主導，是迄今我參與的項目中管理最好的一個。
接下來，獨立開發了一個小項目，基本延用上一個項目的技術CDI、JSF 2、Richfaces 4、Concordion、Jenkins、Sonar、Jboss EAP 6，新引入了DeltaSpike和BootStrap。
後來，在前兩個項目的基礎上開發了一個框架和Demo工程，編寫了框架和環境配置用戶手冊，供其他項目使用。在新項目開始時負責培訓，POC代碼開發，新技術研究等。
近兩年，主要負責多個項目的升級工作，從JDK 1.5/1.6升級到1.7，從Ant升級到Maven，從Jboss 4升級到EAP 6，數據庫從Oracle遷移到PostgreSQL，部署環境調整到AWS，SVN、Git、Nexus、Jenkins、Sonar、Nagios等都遷移到AWS。這些項目涉及的技術主要有：Seam 2、JSF 1.2/Richfaces 3、Struts 1/2、Spring 3、Hibernate 3、EJB、JMS、ESB、JP1等。因EAP 6不再支持Jboss ESB，刪除了ESB，重寫了相關代碼。另外，所有系統進行了SSO改造。AWS是升級中使用的新技術，編寫了CloudFormation、CLI等腳本管理AWS資源。之後，參與了一個項目的重寫，使用了Spring Boot 1.5 + Angular 4架構。
今年，使用Spring Boot 1.5 + Angular 5開發了一個項目的POC代碼。框架 和Demo工程進行了兩次升級，先用Primefaces 6替換了Richfaces 4，後又用Spring Boot 2 + Angular 6重寫。以前升級的項目又進行了升級，從JDK 1.7升級到1.8，從Jboss EAP 6升級到EAP 7。
軟件升級與維護
在升級過程中，發現了一些問題，整理如下：
代碼
- 編碼
開發人員IDE的編碼設置不統一，有的UTF-8，有的GBK，同一工程多種編碼，造成亂碼，編譯錯誤。 - 代碼風格
不使用IDE格式化代碼（特別是未格式化的頁面代碼，難以維護），無空格、不規則的縮進、過多的空行、錯誤的拼寫、無意義的變量名、方法名、大段註釋掉的代碼（查看歷史完全可以通過版本管理工具，保留不利於後期維護，建議刪除，不要保留垃圾）、字段和方法排列混亂等。 - 日誌
大量使用System.out、e.print，導致無法控制日誌的輸出，輸出的日誌不規則，不利於查看。不合適的日誌級別，debug、info、error亂用，在循環中輸出大量日誌，造成性能下降，過多無效的日誌，不利於錯誤排查與分析。 - 註釋
過多的註釋，大量註釋未必能提高程序的可讀性，也不利於維護，常發現註釋與代碼不一致的情況。有意義的變量名、方法名，清晰的結構，具有良好可讀性的代碼不需要過多的註釋，甚至根本不用註釋。 - 錯誤
大量存在IDE能檢查出錯誤的代碼，比如錯誤的註釋變量名、頁面標籤、無效CSS鏈接等，這些錯誤雖然不會影響編譯，不會影響當前功能，但造成後期排錯困難，或者有潛在的風險。 - 庫
lib中存在不需要的jar，在升級分析中浪費時間。有的jar同時存在兩個版本，代碼中存在亂用庫的情況，使用internal類，使用容器特有的類，或某一框架特有的類，而沒有使用通用的標準類庫。 - 訪問權限
過多的使用public、protected，應遵循類和成員的可訪問性最小化的原則。 - 重複的代碼
大量Copy/Paste的代碼，而沒有進行提煉，發現bug時要多處修改。 - 多餘的代碼
大量存在不再使用的代碼，沒有被調用的類，沒用的頁面等。確定不用的代碼應果斷刪除，減少以後的維護工作。 - 過長的代碼
一些類有數千行代碼，這些類大多如經重構後能大爲縮減，每個方法功能類似，有些代碼本應通過SQL實現，有些可利用反射機制。有的項目管理者關注代碼行數，簡單的以代碼行數衡量工作量。 - 異常
忽略異常，不輸出錯誤日誌，使用錯誤的級別輸出日誌，沒有輸出完整的錯誤信息，造成查錯困難。 - 模塊
項目模塊拆分不合理，各個模塊/子系統間相互依賴，共用部分未分離。 - 過度設計
簡單問題複雜化，過多非必要的設計
管理
- 加班
重複性的勞動，短期內通過加班可以追趕進度，長期加班勢必導致效率下降。解決技術問題，需要勞逸結合，往往是在放鬆時想起問題所在。 - 進度
開始每項任務之前一般會預估一個時間，既然是預估就會或長或短，特別是遇到技術坑可能會逾期，項目管理者應掌控全局，而不是糾結於一個任務。 - 代碼質量
平時談要重視質量，制定質量目標，但開發時往往犧牲質量趕進度，要求先完成功能後期再完善代碼，甚至說通過測試來保證質量。有多少程序員在項目成功上線後，有時間或者有意願再去調整優化代碼、修改潛在的問題呢？質量和進度是矛盾的麼？從長遠看高質量意味着高產能，特別是項目初期的代碼往往對後面代碼有很大的影響，初期代碼有良好的設計與質量，後面的開發會節約大量時間，良好的質量也會減少測試、返工、維護的時間。一旦大量低質量的代碼堆積，就積重難返了。 - 性能
花費大量時間進行性能測試，但沒有真正關注性能。很多代碼實現方法、處理邏輯或數據庫有性能問題，沒有從本身解決，只是考慮增加硬件。 - Workshop/結對編程/方法論
一個團隊需要不同的人，假設你的五個手指一樣長，能稱之爲健全的手麼？有的人喜歡安靜獨立，有的人喜歡結對，沒有一種方法論是銀彈，最終結果更多在於是誰來做，而不是怎麼做，項目的成功是團隊中各種人團結努力的結果。 - 會議
無效會議多，不相干的人集中在一起開會。在工位幾句話可以說清楚的事情，沒必要到會議室。 - 信任
程式化方法論，防禦式管理，缺乏信任，過多幹涉技術細節。 - 責任
管理者應有擔當
老猿
- 注重基礎知識，多看官方文檔、樣例，磨刀不誤砍柴功。遇到疑難問題時，如網上沒有同樣的問題，很可能是最基本的東西弄錯了。
- 查看源碼，有些lib不再更新，需要修改源碼時，可先在老環境下調試跟蹤，幫助理解程序邏輯。
- 大膽重構，不斷改進
- 行百里者半九十
- 盡力做好
而立之年到北京，十年過去，仍無以立，希望十年之期有一個好的開端。
一個人跑的快，一羣人跑的遠