关于公司客户端部门的几点想法

背景：

上一代的软件是Q4，下一代的软件叫Q5，是类似于工具类软件，跟WPS很像

现状的问题：

1、客户端代码集成度高

目前客户端的集成度非常高，地区的集成，不同功能的集成，都在一起，说是叫平台，但是实际上随着规模的扩大，代码变得越来越耦合，越来越不可控，修改起来极其困难，开发起来及其难受，中间是乾沟河的，并没有约定的接口，也没有约定的通讯流程，导致开发效率极低

2、打版本成本高（时间，金钱，人力）

无论是C++语言的特性也好，还是打本的机器不够给力也好，无论是开发代码太多还是拆分的不够彻底，从打版本的角度上来看，至少效率不能比Q4差（单台机器15-20分钟），无论你要用什么样的方式。先说下打版本慢的缺点，第一，交付周期长，遇到问题等待时间太长，浪费开发效率，测试效率；第二，依赖高配置机器，导致没有高配置，玩不转；第三，维护成本高，维护这么一套大版本工具，花费的精力太大。打版本成本高的最根本的原因，我个人认为就是代码的问题，还是一个办法，那就是中国特色的拆~（后边继续讨论这个问题）

3、结构组织有问题

（待定）

4、研发管理跟不上生产力

从开发的角度上看，第一：自测不够充分，没有衡量自测的一个硬性标准（写自测列表之类的不靠谱）；第二：开发不了解整个代码的框架，也没有机会和时间去了解；第三：代码的质量纯粹靠经验；第四：代码的执行效率完全靠猜测，也没有给出内部依赖产品的一个效率文档，反正方法很多，就随便写吧；第五：代码结构有问题，耦合度太高，容易互相干扰。

从测试的角度上看，第一：没有进行分层测试，现状是开发简单测试（跟没有一样），手工测试进行功能验证（UI测试），自动化冒烟（UI测试），然而集成测试，性能测试，一概没有（掐表测效率的那种不算，实在是太low了。。。。）；第二：手工测试只是进行功能验证，他们对计算机，软件，代码的知识不够明白（举个例子：当前明白10%，需要明白40-60%），导致在测试的时候，只能看到功能测试的部分，对其他地方覆盖不到；第三：测试的覆盖率低，就当前的软件来说，基本上只有UI测试，随着多线程，多进程的使用，有些情况，UI是无法进行测试的，导致覆盖率越来越低，问题越来越多

研发管理跟不上当前的生产力，导致的后果就是开发和测试无尽的加班，软件无尽的不稳定，无限的Bug

我思考的解决办法（不全，也不一定对，只是想表达出来）：

1、降低客户端代码集成

解耦，拆分当前的客户端代码，在拆分的时候，要有有一个整体的构思，比如，我们有自己的约定，有自己的配置，各个模块之间如何进行配合，我们的配合规范是什么，这个非常重要，不是说把DLL简单的查分出来就OK了，这样是解决不了根本问题的

约定优于配置，现在连配置都没有。。。。

2、打版本成本高

根本解决办法还是从代码的角度上来，做功能模块的拆分，做类似于互联网微服务的结构，不要全量进行，分布式的优化等等，这些全部都要进行考虑

3、组织结构问题（待定）

4、研发管理问题

按照功能模块拆分出的代码，进行持续集成，跑自测用例，自动化冒烟，每日构建；功能测试协助开发进行自测，功能测试进行功能验证；开发可以测试性能的工具，使用工具进行新能测试（如果有第三方的自然更好），以代码作为维度，不要说几秒钟，避免扯皮现象；模块之间的测试需要进行集成测试，可以使用自动化手段或者人工手段均可以，这个要看如何进行代码的拆分。进行代码测试覆盖率的检测，有针对性的提高代码覆盖率。总的来说就是，模块拆分，持续集成，分层测试（自测，集成测试，功能测试，性能测试，其他等），这样提高测试覆盖率，提前发现问题，把风险前移。

未完待续。。。。。。