外包十年

Posted 2020-11-19

老猿信息
ID：川川
曾用ID：比尔板三
出生年月：1979年11月
星座：天蝎
专业：工业设计
职业：程序员
爱好：马拉松、越野跑
博客：奔跑的猿

---

工业设计是非常好的专业，但我没有这方面的天分。大学时认识一位同学自学编程通过了高级程序员考试，我对计算机也颇有兴趣，开始学习，先后考过三级、四级、高程。毕业后一直从事软件开发工作，08年奥运前夕来到北京，开始了近10年的外包生涯。

来北京之前，在东北工作六年，从事过ERP实施及维护，开发过自控、病案管理等软件，涉及PB、VB、JAVA等技术。七月份的北京，天气闷热、潮湿，住在地下室的小旅馆，到网吧更新简历找工作。月底确定了一家公司，开始了第一份外包工作。

东家I
NO. 1 H公司
之前，真正的JAVA开发经验不过1个多月，大部分时间是修修补补。只会SSH这一种模式，脱离这种模式单独开发某一部分代码，如何设计类都不知道，加之项目刚刚开始，基础架构没有搭建，需求也不清晰，近两周几乎没写出什么代码。好在领导又安排了一个小项目，让我使用SSH开发，自己按着以前的模式搭建框架，和一位同事一起顺利完成任务。后又加入另一项目组，主要应用SSH2、Ext、JFreeChart、Open Flash Chart等技术，架构基本上模仿江南白衣的Spring Side。在前一项目中我曾使用过JFreeChart、Open Flash Chart，在这一项目中主要负责这方面的技术。合同到期，没再续签。

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等），但没有被采纳。项目源代码管理存在问题，从SVN下载的代码常常不能成功编译，我又经常在原型和正式代码中切换，往往花费大半天的时间解决代码问题，好在后来这一问题得到了解决。Seam简化了代码的开发，但学习起来较难，其双向注入、事务处理等也带来较多问题。

合同到期后，未续签，也未找新工作，开始整理一些文档，此后习惯记录一些资料。

东家B
只在一家公司干了一个多月被解雇^0^。使用的技术主要是RCP，那时我不看好RCP的前景，最初是不想到这家公司的。被解雇的原因是我迟迟未解决RCP的一个技术问题，安排学习Mule ESB也没进行，解决RCP问题钻进牛角尖，只想通过RCP本身而不想通过其他方式。在这家公司时间虽短，但学习了一些知识，公司采用测试驱动开发(TDD)，重视代码风格与质量，鼓励重构，重视测试，特别是功能测试(使用的fit)。也有一些理念或方法，我不大认同，当时团队刚刚实施Scrum、结对编程，本来几分钟的站会往往持续一上午；结对编程我认为是互相学习的好方法，但我不认为适用于正常编程，不适合所有人，我更需要安静的环境；加班成常态，效率低下，有很多时候很多人是不必要加班的。

东家S
一直在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代码开发，新技术研究等（比如drools），但不参与项目的开发。

近两年，主要负责多个项目的升级工作，从JDK 1.5/1.6升级到1.7，从Ant升级到Maven，从Jboss 4升级到EAP 6，部署环境调整到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资源。另有一系统，数据库从Oracle迁移到PostgreSQL。之后，参与了一个项目的重写，使用了Spring Boot 1.5 + Angular 4架构。

今年，使用Spring Boot 1.5 + Angular 5开发了一个项目的POC代码，升级了框架 和Demo工程，使用Primefaces 6替换了Richfaces 4。最近又开始了新一轮的项目升级，从JDK 1.7升级到1.8，从Jboss EAP 6升级到EAP 7。重写框架和Demo工程，改为使用Spring Boot 2 + Angular 6。

在升级过程中，发现了一些问题，整理如下：
代码

• 编码
  开发人员IDE的编码设置不统一，有的UTF-8，有的GBK，同一工程多种编码，造成乱码，编译错误。
• 代码风格
  不使用IDE格式化代码（特别是未格式化的页面代码，难以维护），无空格、不规则的缩进、过多的空行、错误的拼写、无意义的变量名、方法名、大段注释掉的代码（查看历史完全可以通过版本管理工具，保留不利于后期维护，建议删除，不要保留垃圾）、字段和方法排列混乱等。
• 日志
  大量使用System.out、e.print，导致无法控制日志的输出，输出的日志不规则，不利于查看。不合适的日志级别，debug、info、error乱用，在循环中输出大量日志，造成性能下降，过多无效的日志，不利于错误排查与分析。
• 注释
  过多的注释，大量注释未必能提高程序的可读性，也不利于维护，常发现注释与代码不一致的情况。有意义的变量名、方法名，清晰的结构，具有良好可读性的代码不需要过多的注释，甚至根本不用注释。
• 错误
  大量存在IDE能检查出错误的代码，比如错误的注释变量名、页面标签、无效CSS链接等，这些错误虽然不会影响编译，不会影响当前功能，但造成后期排错困难，或者有潜在的风险。
• 库
  lib中存在不需要的jar，在升级分析中浪费时间。代码中存在乱用库的情况，使用internal类，使用容器特有的类，或某一框架特有的类，而没有使用通用的标准类库。
• 访问权限
  过多的使用public、protected，应遵循类和成员的可访问性最小化的原则。
• 重复的代码
  大量Copy/Paste的代码，而没有进行提炼，发现bug时要多处修改。
• 多余的代码
  大量存在不再使用的代码，没有被调用的类，没用的页面等。确定不用的代码应果断删除，减少以后的维护工作。
• 过长的代码
  一些类有数千行代码，这些类大多如经重构后能大为缩减，每个方法功能类似，有些代码本应通过SQL实现，有些可利用反射机制。有的项目管理者关注代码行数，简单的以代码行数衡量工作量。
• 异常
  忽略异常，不输出错误日志，使用错误的级别输出日志，没有输出完整的错误信息，造成查错困难。
• 模块
  项目模块拆分不合理，各个模块/子系统间相互依赖，共用部分未分离。
• 过度设计
  简单问题复杂化，过多非必要的设计

管理

• 加班
  重复性的劳动，短期内通过加班可以追赶进度，长期加班势必导致效率下降。解决技术问题，需要劳逸结合，往往是在放松时想起问题所在。
• 进度
  开始每项任务之前一般会预估一个时间，既然是预估就会或长或短，特别是遇到技术坑可能会逾期，项目管理者应掌控全局，而不是纠结于一个任务，更不应该公司内部和外包人员区别对待。
• 代码质量
  平时谈要重视质量，制定质量目标，但开发时往往牺牲质量赶进度，要求先完成功能后期再完善代码，甚至说通过测试来保证质量。有多少程序员在项目成功上线后，有时间或者有意愿再去调整优化代码、修改潜在的问题呢？质量和进度是矛盾的么？从长远看高质量意味着高产能，特别是项目初期的代码往往对后面代码有很大的影响，初期代码有良好的设计与质量，后面的开发会节约大量时间，良好的质量也会减少测试、返工、维护的时间。一旦大量低质量的代码堆积，就积重难返了。
• 性能
  花费大量时间进行性能测试，但没有真正关注性能。很多代码实现方法、处理逻辑或数据库有性能问题，没有从本身解决，只是考虑增加硬件。
• Workshop/结对编程/方法论
  一个团队需要不同的人，假设你的五个手指一样长，能称之为健全的手么？有的人喜欢安静独立，有的人喜欢结对，没有一种方法论是银弹，最终结果更多在于是谁来做，而不是怎么做，项目的成功是团队中各种人团结努力的结果。
• 会议
  无效会议多，不相干的人集中在一起开会。在工位几句话可以说清楚的事情，没必要到会议室。
• 信任
  程式化方法论，防御式管理，缺乏信任，过多干涉技术细节。

学习

• 注重基础知识，多看官方文档、样例。遇到疑难问题时，如网上没有同样的问题，很大可能是最基本的东西弄错了。
• 欲速则不达，磨刀不误砍柴功
• 大胆重构，不断改进
• 行百里者半九十

而立之年到北京，十年过去，没有什么进步，仍无以立......