外包十年

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了外包十年相关的知识,希望对你有一定的参考价值。

老猿信息
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/结对编程/方法论
    一个团队需要不同的人,假设你的五个手指一样长,能称之为健全的手么?有的人喜欢安静独立,有的人喜欢结对,没有一种方法论是银弹,最终结果更多在于是谁来做,而不是怎么做,项目的成功是团队中各种人团结努力的结果。
  • 会议
    无效会议多,不相干的人集中在一起开会。在工位几句话可以说清楚的事情,没必要到会议室。
  • 信任
    程式化方法论,防御式管理,缺乏信任,过多干涉技术细节。

学习

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

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

以上是关于外包十年的主要内容,如果未能解决你的问题,请参考以下文章

VR视频外包公司(长年承接虚拟全景外包虚拟现实视频外包)

U3D外包Unreal4外包VR外包就找北京动点飞扬软件

外包公司到底能不能选择

VR外包AR外包公司(虚拟现实外包公司)承接虚拟现实项目开发(企业教育游戏)

外包公司面试门槛高吗?软件测试员进外包公司容易吗?

7.企业安全建设指南(金融行业安全架构与技术实践) --- 外包安全管理