关于将软件交给他人维护所引起的问题

2016-08-18关于将软件交给他人维护所引起的问题

Alternative: 昨天新人自己改代码改到凌晨，然而，还是一样的乱七八糟

拉二胡的LOKI: 新人也不容易 多给点帮助

Alternative: 我给了很多帮助了

hmhao: 没有足够多的全局知识，去修改局部，挺容易出问题的。
最近越觉得没有好的软件文档是不行的。。。

Alternative:一步一步怎么做，都讲明白了。他确认也没问题了。最后做出来跟说的完全不一样
简单来说就好像，没听进去？

hmhao: 记得以前刚来的时候，有几个模块的逻辑很复杂，也很混乱，当时就有人写了怎么一步步添加新接口的流程。

学习OS的Phonzia: 沟通有时候是很困难的事情

hmhao: 我觉得，'讲'明白是不行的。我跟我的组员讲过N次了，上去搞一样懵逼。原因还是说，理解的不够多，改起来必然麻烦多。

学习OS的Phonzia: 你讲完让他讲,否则完全不知道他听进去了什么的

hmhao:大P说的是一种好的检验听没听懂的方法。我觉得，没有文档的前提下，只能通读代码才能开始部分修改。

我做sip，用的sofia-sip库，里面的doxygen格式的注释，以及必要的说明有一些了，但是遇到API，还是得阅读源代码菜之后究竟哪些是可用的。

细致的东西没法说清楚，要是有文档，估计文档也很长。

Anders：画个流程图给他

hmhao：公司做流处理，里面涉及同步，打包，解包，传输控制。以前的代码画了流程图了，理解必要容易，改起来还是不行。

我的想法和作法是，软件模块化对降低复杂度不明显

我认为更重要的是分层要做好，禁止跨层交互。

把常用的API做简单，把可配置的API留在内部由专人维护。

还是要把'用'和'修复改进'分开，用的人不负责改BUG。

几年前的代码重构，把一些重要的概念都统一化了，比如以前的模块有消息队列、内存共享、管道、udp通讯和tcp通讯，重构后统一使用可通讯的缓冲队列表示，缓冲队列由内部维护，外部不关心通信过程。

就好比log4c吧日志统一，配置系统把可调参数统一，WEB系统把可视化统一。接口都足够简单，每个人负责维护一块。

后记

工作中的总结，Alternative说，工作中跟组员沟通N次了，结果完成的代码，依然不是想要的。这里将交流的一些文字记录在这。

说点什么

在多人维护的代码工程中，git已经为大家解决了代码管理层面的技术问题，是的大家可以同时工作，也可以将编码的工作延续给他人。

代码都是英文字母累积的，个体的技术差异，除了广泛的编程技术积累，还在于对业务流程、代码框架和细节实现的熟悉度上。

业务流程可以通过平时的使用来理解。软件系统通常会假设用户为小白鼠，用户可以理解的内容，研发人员都没有大问题。

代码框架的事情可以通过技术交流来探讨。这里最大的障碍在于，学习的人无法去试验和验证整体的框架，因此无法通过流程的方式来深刻的熟悉大多数的环节。一个经验是，如果系统是成熟的，员工除了看看文档熟悉下部署之外，对细节知悉的更少。

细节实现是最为困难的，但是代码的维护和更新总是从细节开始的，在没有足够的上述二者的知识储备下，细节的把控就是一个难点。

细节怎么办

现代的软件工程思想，为大家提供了一个思路，做好项目的管理，比如文档管理，leader做好团队管理和培训，项目生命周期的前期要做好设计和归档。

软件工程的一大障碍在于，软件开发由于人员系统培训较少，小团队的管理成本高，使得管理流于形式，连最后团队的知识资产也在口语相传中流失。

我的想法是，码代码和使用VIM一样，有着陡峭的学习曲线，通过将零碎的问题进行记录，逐步梳理，最终形成一个稳固的研发技术（VIM使用技术）。而为了加快这一进度，必须有足够的交流，不仅仅是vim的tutorial，也需要在Vimer群中对问题进行交流，对必要的交流环节进行记录。

VIM、markdown、gitlab、uml（staruml）及其他工具，为更规范的表述软件研发思路提供了支撑，快速的交流表达离不开工具的熟练使用。虽然彼此话能听懂，但仍然需要翻阅记录来查证和知新。

当然，可以想法将细节屏蔽，那么就需要将细节进行隐藏，然后导出足够简单的接口。在软件的架构设计中，针对消息的处理，首先应当考虑分层处理，两个层次间，除了唯一的接口，不应该有互相关联的多个模块存在。将分层模型做好，做稳定，即使没有文档，也不会有人关心实现如何，因为，其他人不需要修改它。