老猿信息
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不再更新，需要修改源码时，可先在老环境下调试跟踪，帮助理解程序逻辑。
- 大胆重构，不断改进
- 行百里者半九十
- 尽力做好
而立之年到北京，十年过去，仍无以立，希望十年之期有一个好的开端。
一个人跑的快，一群人跑的远