某项目总结分析(吐槽)

本人来上海参与某个银行的某个项目将近一年，针对甲方提出的三个点做具体的分析。这三个点是（这三个点应该是整个行业的通病）：

• 开发效率低
• 系统运行效率低
• 质量差（BUG多）

在分析这三个问题之前，我需要先阐述本项目的开发流程。如下图：

由于系统还未上线，所以以上流程不够全，只能发现现有流程的问题，同时本人毕竟只负责一部分，遇到的问题并不全，仅拿自己遇到过的作分析。

这么长的流程，有句话说得好，有人的地方有有江湖，在软件这个行业，有人的地方就会出错。每一个环节都会出错，每一个环节的出错都会影响进度。

首先分析开发效率低

关于木桶理论，我觉得它不是适用于提高开发效率的理论。开发是一个非常复杂的流程，效率低的因素很多，但是都被忽视，领导关心的就是最明显的那个因素，似乎解决了最明显的那个效率就是提高，其实不然，这些问题都得解决，因为只有量变才会发生质变。

影响开发效率低的原因如下（以下为思维导图，图后会详细分析每一条原因）:

对日志的要求前期要求越少越好，但是真正去做到日志又少同时又能很快排查问题很难，需要很强的技巧，像刚工作两三年的很多人都没有这个意识，所以在前期应该允许日志量多，在功能稳定没有bug后再去优化日志。因为按他们的要求去掉很多日志，导致前期排错困难，有时少打一个字段都要花费近20分钟的排查时间。

前期过份追求性能，而不是业务的准确性，可读性，可维护性。比如RPW改造直接破坏了系统的可读性，可维护性，其中账单RPW改造直接将两三个功能耦合在一起，维护起来真是个坑，在这种业务逻辑相当复杂的项目中，应该是准确性第一，可读可维护性第二，性能第三。

非功能任务插入到开发期。非功能的任务插入到开发期，势必压缩业务逻辑开发优化的时间，在人力资源时间有限的情况下肯定会以牺牲代码质量作为代价，然后低质量量的代码出现bug拖慢开发和测试，同时低质量的代码使可读可维护变差。为什么优先级不能排到最后？每个迭代测试都要测试一遍，因为有大量改动，最后一次测试才是最终测试，测试人员在这个过程中除了验证部分代码正确，最重要的是熟悉了整个业务，在最后一次测试中发力，所以优先级放到后面是可行的。

大方案变更，小方案变更，数据结构变更。大方案如分库分表，小方案如批量查询，数据结构变更更是因为没有数据字典字段名变来变去，数据类型，数据是否为空各种变。这些变更时刻打断开发人员。

方案讨论耗时。像函数式编程、springbatch封装这样的问题还要去深入讨论，去质疑可读性和性能，完全没有必要浪费时间。

直接分配一些非计划内的任务。比如某某直接给迁移组分配任务。有些不合理的任务完全可以拒绝掉，本不属于自己负责范围内。还有在应该执行内部测试案例执行的时候强行插入联调任务（最终联调质量不行）。

缺少能把控全局的架构师，即懂业务又懂技术。有些方案都是各自为各自组，很多时候基于工作量的考虑而不是从整个系统的层面考虑，设计出来不好的方案让开发人员买单。

某些任务不放权给乙方，甲方事情太多，导致甲方成为瓶颈，出错次数增多，导致乙方花更多时间弥补。比如甲方某某负责数据结构维护，经常出错，出错后直接影响开发人员。

很多方案没有人拍板，都怕担责任，迟迟不定。很多方案后面一直没有结果。

任务分配不合理。比如让账务帮发卡用卡开发了一部分功能，占用账务的人力资源。

内部消化的东西随时改标准。比如数据库文件同步一周联调，四天成功都说慢。

部署流程太长，耗时太长，一天发布两次，次数少。其实前期最重要的是测试业务的准确性，规范之类的可以滞后。

日志权限不给开每次都要申请，还有有效期。都是内网搞什么权限？流程繁琐浪费时间。

新同事入场后账号开通太慢，无法提代码，影响进度。比如我组某某两三个星期后才提代码。

概设详设没有意义还要占用开发时间。概设详设要有指导意义的话，给的这点时间，这点人力，根本不够。给一部分时间搞个交付物实在不是务实，浪费时间。

聊天工具只能保存7天的记录。有时候更早的信息是很有用的，但是找不到以前的聊天记录。重新找回会有困难，也会浪费时间。

开发软件不全，电脑装软件有限制。比如想装一个新版本的ue看字符编码，但是不好装，各种限制。得有Administrator用户权限。大文件传输聊天工具和邮件大小都有限制，太费劲，也不让装飞秋。

邮件太乱，无关的邮件也会收到。各种无关的会议邮件天天收到，一天几十个邮件，真正有用的就那么几个，找有用的邮件也费劲，这种协作方式有待改善。

Jenkins机器配置低，集成慢。加点硬件资源能花多少钱?硬件成本高还是软件成本高？算不清账？

maven有时不能用，git挂掉，conflunce没有下载权限。

sonar规则跟本地不一致，导致本地扫描结果跟集成时扫描结果不一致，只能在上面看。一些不合理的规则没人排除掉，比如返回克隆后的list对象。

早上看新闻。开那个早会看新闻有啥用？

各种考试。形式主义的考试有什么用？

各种账号过期，账号锁定，一锁定半小时干不了活。在内网里，这么不相信开发人员为什么不让自己人干？

不能热部署，启动太慢，启动加载好多不属于自己的job。底层包我看过源码，没法去掉这些无关的job，话说底层包写个了啥。

底层改动后导致项目无法启动。无法执行全流程测试。

未连数据库的单测，无法进行全流程测试，导致改bug后很难自测。只测service层属于残疾测试，自欺欺人的做法，自己Mock返回自己断言，也就测一些低级的问题。不好自测导致bug重现。本来这种批量测试跟联机不一样，每一次跑批机会非常珍贵，这样浪费掉机会。

ERM生成dao，每次编译dao，浪费时间。不能单独打包放到私服上，其它工程引用吗？

通过ERM生成脚本，不能通过EXCEL或直接读数据库生成吗？否则多一层就多了出错的概率。

框架没有文档说明，有的源码还拉不下来，没有培训，很多东西不知道怎么用。比如自带的RestTemplate，分页接口，总是开发完了有人才说底层包里有，可以直接用，然后再改，浪费时间。

测试人员无法理解业务来找开发解释，浪费开发人员的时间。尤其是pre-uat的测试人员，能力不行。

测试人员无法看懂日志，明显的数据问题还要找开发解决。sit和pre-uat都有，有的很明显的哪个参数不存在还要找开发确认，白白浪费开发的时间。

开发中遇到问题没有寻求其它同事的帮助，一个人死抠。开发人员要有确认问题是否应该自己解决的能力。有的问题可以在网上搜找到答案，有的需要问别人，开发人员要拿捏好，需要问别人的应该及时问，保证进度。

排查问题效率偏低，日志打印不够好。很多日志都是想当然的去打，并没有考虑，假如我抛异常的地方抛了出去断批了，测试人员还有自己是否能够根据日志快速定位问题。很多异常并没有抛出关键信息导致排查困难，浪费时间。

测试问题修复后没有自测。对于小改动还好，但是对于大改动，出错的概率就是很大，没有自测让测试人员再打回来，白白浪费测试人员的时间，影响整体进度。

开发人员一个人不细心导致代码编译问题，影响其它人。漏提交代码等等原因导致编译问题，如果出错地方少还好，其它开发人员可注释掉，继续自己的工作（比如自测），但是如果是大范围的报错，其它开发人员就是只能等待。

部分开发人员git使用不熟练，覆盖他人代码。有同事这样做过，发生过几次，其它开发人员只能被动等待。

部分开发人员没有提问题解决开发效率的意识。很多开发人员只是把任务完成后就下班，平时以及日报中也没有提及遇到的问题，如何去解决，主动性不够，只是把自己当成一个镙丝钉，但是即使是镙丝钉也要做一个积极的镙丝钉。

日志打得不够详细导致测试一断批就找开发。打出日志量少并且足以让测试和开发快速排查问题的日志并不简单，很多人以为随便打出一个字段就OK，其它这个字段对后面的排查根本没什么作用。每次打日志应该能预见到代码里可能发生的问题。

FSD变更频繁。SA的变更不提，只说从旧主机中梳理需求。在这种没有需求文档只有代码的系统里，本人曾经在上个项目梳理过需求，从COBOL语言的代码里反推出原来系统的需求，简单的还好，某些关联性强的需要梳理出其它功能才能理解本功能为什么这样设计。有一些在没有梳理出来之前，自己的理解本身就是错的。在这种情况下写出FSD，后面就有了再改的动作。

数据结构变更频繁。由于主机的设计跟现在新系统的数据库不一样。导致数据结构不能正确映射成新系统中合理的数据结构。比如：日期，字符串，字段命名。

人员不确定性大，开发进行时调走。我组的人变化较大，经常被调走支援其它组或其它项目，而人员补充不及时，即始补充了，因为刚接手，也需要熟悉一段时间，这一段时间拖慢了进度。

没有一套成熟的技术方案，然后各种扯皮摸索耽误时间。老板的战略方向有问题，不应该重业务轻技术。因为毕竟我们是一个实施团队，里面有各种角色，甲方不会仅凭你的业务解决方案来评价系统做的怎么样。另外，我们是根据项目组的团队，虽然同事能力还可以，但是如果是根据团队接项目的话，战斗力会更强，比如拿出一个专门做信用卡的团队。

各种报工，公司管理平台报，行里管理平台报，开发组长报，公司站会报，行里站会报。这些小问题每天发生，乘以两年的天数，可想而知，也会有影响，是不是可以精简一下。

会议时间过长，容易发散，讨论到某个细节，占用开发时间，无关人员参与不懂得主动离席。

一个人好多事，任务没有优先，来回切换。有的功能的实现需要整块时间来思考，各种事情的打断只会让想出的方案变差。机器多线程可以提高效率，但是人不行，人串行做事效率质量最高。

由于各种因素导致的加班使错误更容易产出，错误的增多增加了更多排错工作量，所谓加班写bug，有时会形成一种恶性循环。

对进度的认知。思考也是进度，并不是堆出代码才算进度，思考比写更有技术含量，更有价值。但是行里总认为堆出代码才能算进度。

技术方案的复杂度增加开发工作量，比如分库分表，批前批后同步。

然后分析执行效率低

review不到位，review时应该关注性能问题。比如日志打到双层for循环里，用反射等。

开发人员技能和经验不足。开发人员提前预见，写SQL复杂的需要查看执行计划提前调优。

框架问题。比如甲方给的框架本身启动就耗时较多，开源框架也有相当的耗时。

最后分析质量差BUG多

素质不一，风格不一。根据项目组建团队的方式，认为只要来个人能干活就行，但是能干活的标准如果是实现功能的话也无妨。但是如果要考虑到代码质量，这就是一个比较大的问题，因为新来的人如果是新手，需要一段时间学习，如果是老手，需要一段时间改掉自己原来的习惯。

没有代码洁癖，职业素养不够强。有的连空指针都懒得去判断，空指针这个细节直接能反应出这个人的编程素养。各种重复代码，复种idea提示的问题也不去修复。

对业务的理解不够清楚也不去问BA就开发。这种情况下开发出来的都是业务Bug。

review业务代码不够质量把控不到位。技术上的问题需要review，业务上的也需要，要更细。某些情况下很多活都压到组长身上，组长做了很多简单但是量大的活，而不是关键的活，没时间review。

FSD设计漏洞或描述不严谨被开发误解。

单测方案问题，不连数据库测试的单测方案本身是有问题的。

各开发商从工作量角度设计系统，而不是全局考虑。

技术方案问题。比如RPW改造，尤其是账单部分极大降低了可读可维护性。分库，批前同步，批后同步，这种方案带来了更多的开发量，更多的开发量意味着更多的bug。

文件方式看报表，不能用HBASE？什么年代了还是用文件看。

问题已分析完，但是我不想写解决方案，因为上面的大部分解决不了，大项目，大公司太不灵活。本人乃一个小镙丝钉，有心杀敌，无力回天，只能尽力解决自己能解决的问题。某些分析没有讲具体的例子，是因为回想不起来，但是本人肯定经历过，不会凭空捏造。

最后附一个读书笔记《代码整洁之道-程序员的职业素养》，经典之作，拿来评价这个项目再合适不过了。