2015第31周周记：“斯达不留”代码架构的问题

这么快就一周了，原来，一晃也可以是一周，还可以是一个月。 南宁最近的天气时热时凉，时而细雨，时而暴雨。把我躁动的心绪浇掉了很多。项目也进行这么久了，该批评的批评，该加班的加班，该学到的也学习了。当这过程是一个难忘的经历——就好像2013年那个无法忘怀的岁月一样。

项目例会上，项目代表说，PM其实不用负责具体的开发。只做技术的统筹，至于具体模块的问题、联调，就分派给具体的负责人。原来，PM可以这样！只怪自己too young。但后来一想，好像哪里不对。别人做PM时，把系统整合、测试的任务分给我，到了我做PM时，还是把系统整合、测试的任务分给我。原来，本质上还是人手的问题。人手不够，PM不得不上。比如，周末队员有事无法加班，而周一又要给版本，怎么办？只好自己去加班了。

在公司的另外一个关于技能的问题。虽说很久以前，公司前辈已经把代码重构，已经把分层思想放到架构里了。但几经人手，加上各种分支维护，构架已经支离破碎了。目前公司似乎还没有想过由专人统一维护——对此疑问曾在部门群里发出来，但主管说，各个方案不同，都有修改，每个方案负责人维护各自的方案代码。架构是一种设计实现思想，是规范。在这点上，我和领导的认知是不同的，以我现在的水平，只能从实实在在的代码去理解。

我不由得想到当年对架构的评价，我评分很低，然后招了各人的围攻，说，我提的问题与架构无关，而是开发人员的执行问题，于是架构给出了10分。后来想想好像说得有道理。对于公司既定的流程执行问题，其实也是与流程无关，有关的是人员的执行。比如，流程规定要先把概要设计写了才能写代码，但实际无法很好做到这一点，因为实施过程中的代码实现，不一定是当初的设计文档里的东西。

现在的问题是，架构的代码分出了很多个方案，每个项目的人员水平是不同的，毕竟每个人专长不同。像我，对业务代码熟悉度就不够——正如搞业务的人对内核不了解一样。但现在，由于做项目，要在架构里写代码，有很多函数没有注释，后人无法快速了解，即使使用，也可能会出问题。项目初期出现的内存泄漏问题，就是因为有个函数内部申请空间，需要调用者来释放，但却无对应的说明，以至于很久后才定位到问题。这周也遇到一个公共模块的问题。我和其它人找了一天多，无法找到原因，后请教其它熟悉架构的人，2分钟就搞定了。当然，项目人员本身就少，而代码模块那么多，出问题是很正常的(人员使用问题，本身模块遗留的问题)，但却无法找到具体的负责人，如上面所说，不是PM上，还有谁？

这周无法参加部门例会，因为开会时，我正在独自一个人在外场数车牌，看看有没有漏的。而同来的测试人员要去找新的测试点，因为公司快搬家了。

昨天依然加班，另外2个同部门的同事在加班赶工加一个项目。而我这个项目只剩下一个人加班。下午去万达和覃博士、韦行长、南宁的各老总、行长会面，吃了个饭，聊了个天，玩了几局游戏，归家已是三更。

李迟 周日