作者：zollty，资深程序员和架构师，私底下是个爱折腾的技术极客，架构师社区合伙人！

一、一些不好的现状，及对应的改进方法

1、前后端代码绑定在一起，很难维护，前端UI做得太差，后端也需要大的改善。

前端代码乱，是架构和规范问题。

前端UI做得太差、很掉档次，是因为不够重视和没有专业的人来设计和制作。

改进方法：

1）前后端代码分离，一些人做专业的前端，提高前端UI质量，一些人专注于后端优化。

2）前期可以先重构，先从技术上把前端代码和后端代码分离，然后专注规范和优化前端（包括html、js和css），同时相应地简单重构后端。

3）后期划分人员职责，前端代码交由专门的前端开发工程师维护，新增的页面功能修改也由前端开发人员编写，后端只需要提供数据的接口。

前后端人员比例问题：

对于一些小网站、内部系统，如果后台并不复杂（通常比较独立 几乎不依赖其他系统，而且用户不多），但前端功能、展现层的功能较多，那么前端的工作量会是后端的两倍以上。

这种情况，建议前端开发和后端开发的比例是 2:1，假设一个项目6个人，那么4个前端+2个后端。

另外，针对这种系统，产品很重要，产品需要准确地给出需求，甚至给出功能的原型，如果界面要求高，可以配置专业的美工，否则前端可以直接根据产品的原型设计页面UI。

对于一些后端比较复杂的系统，比如分布式的大型网站，或者后端牵涉多个其他系统，对后端要求较高，则需要较多的后端开发。

所以，前端和后端的人员比例，要看项目情况，是偏UI操作？还是偏后端技术？

客户的关注点是不是在UI上？如果是，那就得加强UI、UX的研发能力。

2、系统有很多明显的BUG，有做过正规的测试吗？

正式系统BUG多，是研发水平低的表现，显得这个系统质量很差。

改进方法：正式投入运营的产品，要有质量保证，原则上要通过测试验收，测试不通过不能上线。

具体方案：

1）测试参与需求评审，测试参与产品评审；

2）测试前置（提前介入），必要时增加回归测试，性能测试，安全测试。

3）测试监督、考核，质量保证。

3、产品水平低，很多地方设计不合理

如果产品设计不合理，那后果是最严重的：

• 要么考虑不全，做出来的东西无法满足要求，甚至漏洞百出；

• 要么不切实际，实际开发过程中困难重重；

• 要么扩展性不好，导致后期增加、修改功能时必须得全部重做；

• 要么用户体验不好，被用户吐槽 难以使用。

改进方法：（注意：下面描述了完整的产品环节，其他方面并不完整）

1、需求收集阶段，广泛征求用户意见，同时产品从专业角度和用户沟通，要注意：很多用户只顾自己，提出的需求有些是不合理的，需要产品人员去正确引导，有些需求是极其片面和个性化的，需要产品综合考虑，有些需求是高难度的，需要从成本、时间、资源等多方面考虑。

2、整理需求阶段，将收集到的需求，转换成专业的产品需求文档，可以拿这份初步的产品需求文档，请求资深产品人员、开发方的项目经理、测试经理给以评审和意见。最终形成较正式的产品需求文档。

3、产品设计阶段，有了产品需求文档之后，对产品进行详细设计，最好是有可视化的产品原型，并对其中产品需求的细节进行清晰、准确的描述。做好之后，将产品需求和原型发送给资深产品、项目经理和测试经理审阅。

4、项目经理和测试经理拿到产品需求和原型后，初步查阅，提前就不明白的地方与产品经理进行沟通，同时就一些技术问题或者业务问题与组内的开发和测试负责人初步商议。

5、产品召开产品宣贯和评审会议，产品、相关开发人员、测试人员全部参加，产品负责对产品需求和原型进行讲解说明，开发和测试一同讨论。如果没有重大修改，会后就一些小的修改项邮件确认即可。如果有重大修改，则产品修改后，找时间再次发起评审会议。

6、项目经理、测试经理就产品需求进行开发、提前测试进行分工、排期，就完成时间节点与产品达成一致。

7、开发完成后，提交测试版本，编写提测文档，交付测试。测试人员介入，验证测试环境是否正常，对比开发的功能是否与需求一致，就不明之处，和开发进行沟通。沟通和初步验证做完后，测试负责人发出接收测试的说明，并安排好测试人员，开始正式测试。同时，通知产品参加初步的验证测试。

8、每次提测之后修改BUG和优化代码，均需升级测试版本，同时附上改动的影响范围，通知测试人员。

9、测试按实际情况可进行冒烟测试、第一、二轮测试、回归测试、自动化测试、接口测试、UI测试、性能测试、压力测试、安全测试。

10、在临近测试结束时，通知产品进行验收测试。

11、准备上线。

二、研发规范太差

1、代码不规范

解决方案：

规范的代码风格，代码质量符合sonar里面的各种规则。

使用sonar等平台和插件自动扫描和判断代码质量。

2、提交到仓库中的代码无法正常编译

版本管理混乱

解决方案：

规范源代码的管理，提交的代码需要有质量保障，主干（master）分支必须是时刻可用的。

版本号管理需要规范。

3、Maven缺乏维护（public居然无只读权限，导致无法构建项目）

从这一点暴露出来的问题：基础设施没有专人长期维护！！

解决方案：

严格保障基础设施的正常运行，指定专人维护（可以是各个开发部门或者运维部门、测试部门的人），包括数据库、jenkins、maven、sonar、redis等。

4、数据库表设计不合理，甚至有些查询需要联合8个表，左连接、内连接一大堆。

SQL严重不符合规范，效率极低，查询3条数据需要50秒钟；可维护性极差，在SQL里面去做各种运算，使用了许多函数。

解决方案：

增强数据库的相关规范，架构评审，DBA评审，SQL评审。

增强开发框架的约束能力，简化SQL编写并保证质量。

使用SQL自动审核工具，例如 Inception。

线上监控，慢查询等。

三、架构能力不足

项目的框架，项目A和B（真实名称略）的都很一般，看得出来，搭框架的水平，差不多是高级工程师的水平。

我不建议由 高级工程师 随便搭一个框架。

一个高级工程师搭的框架，能用，但可能并不好用，框架这东西，是项目的基础，需要进一步优化。

解决方案（一）：由资深工程师和架构师来选型和搭建，并经过评审和实际验证，才开始规模使用。

解决方案（二）：由基础框架团队（一个完整的、专业的团队，包括前端、后端、产品、UI、测试）去开发和维护，这个团队专注于框架的搭建和维护，公司或者部门都使用他们提供的技术体系和解决方案。

长按订阅更多精彩▼

如有收获，点个在看，诚挚感谢