十个月的时间，辗转六七个项目，虽以普通开发人员的视角管中窥豹，但项目中的问题弊病依然可见一斑.从几个方面写写自己的见闻和浅析吧

问题

1. 人天问题

软件开发项目最大的成本就是人。人天预估的高了不容易中标，人天预估的低了又难以保证质量，其中的权衡拿捏不是我一个小技术能涉及的。
但是真正落地实际情况并不理想，在许多项目的承包上，项目预估的人天与实际所需严重不符，甚至有项目刚开始做需求分析的时候，工期已经过去了一半多。所以即使已经疯狂压榨开发人员(个别项目整月整月的加班到12点)，很多项目还是不得不延期，仓促赶工导致项目质量不行与延期之后带来的成本提升都在降低甲方的满意度，同时也降低了乙方的利润

2. 业务能力不足

多数项目中缺少能从整体角度辅助客户完成业务功能设计的出色业务顾问.很多项目中，甲方业务需求自己想方案完成方案设计，乙方业务能起到的作用小.

3. 盲目推行新模式

从项目中期开始赶鸭子上架推行DDD，领域驱动设计的确要求与业务加强沟通，双方共同设计出领域模型.但是在双方对领域驱动设计都缺乏了解的情况下强行推进DDD很容易弄巧成拙.

一方面业务人员容易落入原本瀑布式开发的窠臼中(视各种需求分析文档\开发文档为项目进度的里程碑)(这也有甲方的领导很难转变思维的原因:有时候业务角色接受了新型的软件开发方法，而他们的领导却不能紧跟这种变化)

另一方面，DDD要求技术人员也要转变思维，系统的设计，尤其domain层的实现，与原本的mvc模式完全不同.而且，领域模型驱动代码的实现要求保证领域模型的设计是正确的.否则我们无法确定领域模型可以解决领域中的核心问题

这就导致甲方因为缺乏项目产出(特别是在项目前期，DDD因为重产品而轻文档，缺少能向甲方说明的项目进度的标的)会开始怀疑乙方的进度，而双方对领域的不擅长导致迟迟不能推演出正确领域模型设计又继续加重这种不信任，然后因为时间有限，仓促赶出一个领域模型并进行开发，以至于模型无法符合实际业务需要反而增加了开发难度…而项目的延期又会导致甲方进一步怀疑乙方能力…

总而言之，我认为在实施DDD的过程中，我们缺乏一个领域专家的角色带领我们向DDD过渡.

4. 技术与业务之间的隔阂

在项目中，业务在完成了项目前期业务模型设计之后的主要角色就变成了监工和功能测试人员.

许多业务顾问除了催进度之外就只会甩锅，说什么什么问题是开发的问题，是他们写的bug.而技术人员同样会把锅甩给其他:比如设计的时候没写清楚，比如这个代码不是我写的而是之前的人写的等等.

互相甩锅推诿导致乙方内部都无法通力合作，大把的时间用来互相扯皮推脱任而不是解决问题.

5. 规范与标准化的缺失

基本情况是代码仓库管理分散，各个项目组有各个项目组的svn服务器.虽然很早就在客户部署了统一的gitlab服务，但是项目迁移缺乏动力，进展缓慢。问题主要表现在以下几个方面：

1. 项目文档管理混乱，这个比代码管理还要混乱，代码最差的情况也至少有svn中央仓库，而文档要么直接缺失，要么就只保存在个别几个人的本地电脑中.

2. 项目文档没有标准化，每个项目的文档都使用不同的模板，而且当代码功能变更时，文档通常没有跟着变更.这给后续接手运维或者升级的人员带来了非常多的困难.

3. 缺乏代码审计流程.大多数项目没有代码review环节，代码质量完全依赖开发人员自查，关于安全性的缺陷检查与编程规范基本无从谈起.

4. 缺乏测试，大多数项目没有规范的测试流程，大多数开发人员不写测试类.单元测试无从谈起.测试人员通常由甲乙双方的业务人员兼任，通常也只是在页面上点点点的黑盒测试.

5. 缺乏开发规范，包\类\方法\字段的命名没有规则，数据库设计字段命名随意，对如何拆分数据表缺乏清楚的逻辑.

6. 人员变动大
   项目成员来源复杂，组织结构复杂，项目成员来自公司内不同的事业部，直接汇报的领导各自不同。而且，因为工作压力和福利待遇问题种种原因，项目内持续有人离职，所以项目组不得不从公司的其他部门调人的同时从外面临时招人，而新招聘的员工质量无法保证，从企业内其他部门调来的员工又因为跨部门，带来了管理上的麻烦

尝试的改变与局限

1. 推行容器化技术改造

容器化是从技术方面提供了一个标准化的契机，因为容器化的推进工作中要求使用gitlab的CI/CD功能，所以倒逼各个项目组从各自的svn或者不同时期部署的git向统一的gitlab仓库迁移代码。而容器化也同时简化了发布流程，提高了标准化。推行容器化的局限在于以下几点:

• 很多老项目部署在weblogic环境中，迁移难度大，而且部分老项目长期没有技术人员维护，从接手到升级成本很高.

• 即使是使用了gitlab管理代码的项目，但是很多项目没有严格执行gitflow的流程，导致分支管理混乱，各个分支代码不统一，部署版本不确定等等问题依然存在

2. 推行敏捷开发

在一些新项目中使用敏捷工具如看板等推进项目进展取得了不错的成效，客户可以通过看板直观的看到项目的进展，开发上的进度也更容易掌握. 局限性在于推行敏捷需要有懂敏捷的人员参与，而很多项目人员没有敏捷的培训对敏捷工具不熟悉，也不了解敏捷方法.这就意味着敏捷开发难以大规模推广.(频繁的人员更迭也加剧了这一点，因为新加入项目的同事普遍并不了解敏捷)

3. 成立了测试小组专职进行自动化测试

这肯定是一件好事，但是目前的测试还是依旧停留在表面，使用的是eggplant模拟点击网页操作的测试工具做黑盒测试，虽然在一定程度上节约了测试时间成本.但是局限性依旧很大:

• 一方面是软件学习成本高，原本做功能测试的业务人员很难学会使用.
• 一方面这种测试依旧是黑盒测试，而且难以测试边际值，只能测试正确的流程能否完整执行. 另外以我们项目来看，测试人员在项目中地位不高，而且通常还需要兼职做开发工作.

4. 安排开发人员互审代码

这项工作初衷很好，但是实际执行中，代码审计的优先级远远低于功能开发，在开发进度压力大的情况下没有人在乎功能是如何实现的，因为能按期交付就已经用尽全力了.