软件工程驻足篇章：第十七周和BugPhobia团队漫长的道别

标签：

0x01 ：序言

I am a slow walker,

but I never walk backwards.

成长于被爱，学着爱人

成长的故事

也是年少的星期六结束的故事

就仿佛我和BugPhobia团队共同的成长

从模仿到拒绝模仿

任由挑灯、辗转、迷茫、前进的无数日夜

令那些岁月的烦恼和喜悦控制住自己

在耳边轻唱

祝你万事胜意

一切终比想象的，好一点点

                     ——致以BugPhobia团队的Beta阶段软件开发的终结篇章

0x02 ：软件工程项目经理的理解

To the world,you maybe a person.

But to a person,you maybe the world.

0x0200：软件工程Beta阶段的工作模式

在团队项目从Alpha阶段到Beta阶段的开发过程中，笔者由前端设计/开发工作转型为团队的项目经理。在这篇文字的初稿定型时，团队Beta阶段的项目的对接和发布尚处于微妙的状态：

ü  前端ReactJS页面已经由“举步维艰”的摒弃jQuery机制，迁移大量CSS和JS/JSX的过程，过渡到基本完工的工作状态

ü  后端Django的基本接口书写完成，但由于数据库的完整性约束条件的限制，正处于紧张的单元测试和错误排查阶段

ü  前后端的基本对接工作，从理论上，由于此前协商的定义应当不存在任何问题，但由于后端的测试过程因此尚未进入成功对接的阶段

ü  文档方面，由于此前工作的部分延误，大量的文档积累在complete文件夹，未完全排版和整理

而在最后一周的短暂开发时间中，此前疑虑的“前后端对接可能会浪费大量时间”由于单元测试的完备，此部分时间被大量节省，因此在开发后期，团队能够专注完成此前预计的各方面工作，虽然与此前Beta阶段初期预想的最终结果有所差距，即由于开发时间的急剧压缩，数据量的积累程度未达到预期，但已尽力而为，问心无愧吧~

同Alpha阶段的前端开发成员不同，在Alpha阶段，笔者本身更注重去后端驱动、架构驱动模式下的前端开发，在此阶段，如何根据具体的用户调研情况进行设计，并时刻注重与后端进行一定的沟通，保证后端所提供的基本数据能够完全展示在前端页面，这里笔者也将当时自己写的一部分感想链接此处：http://www.cnblogs.com/panacea/p/4966144.html

但在Beta阶段，以项目经理的身份去参与BugPhobia团队的Beta阶段的开发。在经历了Alpha阶段相对集市式的开发模式，Beta阶段更倾向于采取教堂模式为基础的集市开发，因此，笔者作为项目经理首先确定基本的沟通方案和团队进度管理。在初期，笔者对项目经理的职务仅限于文档的整理、进度的协调，但真正参与其中却又不尽相同，笔者也就项目经理本身的参与的全部开发过程进行说明：

0x0204：团队Beta阶段的身份转换

事实上，在Alpha阶段，团队本身已经经历了基本代码的全部重构工作，当时团队在讨论的过程中，简单浏览了学长的部分代码，考虑到学长所留存的代码的相关的说明和开发文档缺失，而历史代码的测试和调试也会耽搁团队的开发进度等问题，直接选择了采用新的技术栈：Semantic UI的前端页面，Django渲染模板方式的后端架构，Solr完成搜索引擎搭建的全部更新；同时，团队所包含的更多的是初生牛犊不怕虎的倔强，无论是沟通或是协作工作都充满着强势的感觉，直接向其他团队提出采用SOLR架构和NUTCH插件开发完成最后的对接工作，而在其他团队中途“弃坑”放弃这一计划方针的时刻，选择独立完成数据库的搭建、SOLR数据的插入工作，极大地增加了工作量，但也确实独立完成了基本需求的解决方案，甚至笔者当时还有种“愤世嫉俗”的感觉，认为是其他组没有配合上游团队提出的需求。

实际，项目经理的身份更需要注重组间协作的沟通劝导，和决策。因此，抛却基本的个人情感因素，在Beta篇章的启程工作时，作为项目经理，笔者总结了基本的组间协作的矛盾，记录如下表：

因此，最终，BugPhobia团队依据矛盾的说明，最终完成了矛盾的协调工作，并真正以合理的架构完成了学霸全部项目的高聚合低耦合的设计，而非“愤世嫉俗”的抱怨工作；

这里也非常鸣谢其他团队共同的努力（学霸爬虫组：http://www.cnblogs.com/cnmxfd/，学霸数据组：http://www.cnblogs.com/cheneygroup/，学霸APP组：http://www.cnblogs.com/groupofdream/）

因此，团队的项目经理需要根据团队整体的开发程度和需求，完成基本的调研工作，并给出合理的解决方案；同时，与其他团队不同，团队技术方面的决策基本交由团队的架构师GNU_Linuxer（http://www.cnblogs.com/fzyz999/，这里致敬团队的架构师，能够从技术的角度提供非常完善的解决方案~），而项目经理仅根据进度做出部分的干预工作，这大抵是由前端开发人员向项目经理转型努力的第一步吧~

在笔者看来，团队项目间的协作，重点在于真正的信任和工作进度的基本对接；既然将基本的任务和进度交付其他团队共同协作，就应当对另一团队的工作致以全部的信任，而最理想的方式是双方能交换一部分成员参与到结对开发的过程中，能大幅降低团队间的沟通成本；当然，信任并不等价于放任不管，毕竟笔者在Beta阶段的开发阶段也曾因编译原理、数据库等焦头烂额的课程而一度陷入“伪罢工”状态，因此能够保持定期的进度交流和对接，能使得最终的对接工作，快速完成

0x0208：团队Beta阶段的重构工作的得失

这里首先引用团队架构师的部分博客，其对重造轮子、架构方面的见解简洁易懂：

事实上，本身能在两轮迭代中均进行重构的团队，可能在软件工程的课程设计中，基本不存在；而在Beta阶段，团队继承了此前Alpha阶段对学长遗留代码的重构工作，再次重构了Alpha阶段的代码的全部迁移工作。实际上，在初期的讨论工作中，团队本身提供了相对简洁的衔接方案，甚至能够使得Beta阶段团队本身的工作量大幅降低：

但事实上，Alpha阶段团队所构建的页面，由于HTML代码的重复率相对较高，因此全部页面均处于混乱的泥球状态；这里仅从笔者Alpha阶段负责的前端代码谈起：

n  HTML的代码复用相对较差，由于Django模板的渲染，能够通过{% include %}的方式完成一部分的代码复用，但由于后期敏捷开发时间紧迫，因此大量代码片段被复制粘贴插入其中

n  CSS代码机制混乱，这里完成是前端开发人员（笔者）的锅，在代码中存在大量的<script><type/css>的代码段，使得整体代码在维护上存在较大困难，降低了可读性

n  即便在文档齐全的情况下，接手团队维护混乱的HTML页面也是巨大的负担，且对于相同的页面元素，可能需要更改多个页面才能完成最后的修改工作，即前端元素冗杂

n  若选用共用后端的解决方案，必须放弃Django的模板渲染方法，改用JSON完成数据的交互

因此，在Beta阶段，BugPhobia团队最后协商决定完成全部代码的重构工作，保证学霸全部项目的耦合和对接。

首先不得不承认，Beta阶段，团队重构的压力巨大，团队成员不仅需要协调编译原理、数据库课设等编码工作，还需要保证软工的基本进度稳步进行，而非继续拖延。因此，在第15~16周左右，团队几乎全部成员均处于刷夜状态，且尽可能细致地分割时间，保证当前任务基本完成，这里笔者感触颇深，大学的大三上学期以前，笔者仅因为某次答辩而刷夜一次，而大三上学期阶段，连续48小时睡眠不足5小时的状况在后半学期经常发生。而同时，ReactJS框架体系对jQuery的使用有着严格的限制，$document的初始化问题、javascript代码的迁移工作、部分刷新机制，由于数据单向流动和本身体系的限制，部分前端的JS代码需要迁移为ReactJS框架下的JS/JSX代码，而此部分的工作量非常巨大，在学习成本上团队几乎消耗了大量的时间去避免使用Semantic UI内封装的jQuery代码，尽可能兼容部分JS代码。

幸运地是，依赖全栈工程师兼架构师的GNU_Linuxer驱动，依赖独立后端开发成员Fizhero（http://www.cnblogs.com/Fengzr）的驱动，团队依旧处于高速的运转之中，而在后期近三天的对接工作，几乎承担了绝大多数的工作，最终团队完成了基本的重构工作：

n  架构的可扩展性、可维护性相对较高，技术栈整体较易适应于分布式等方面的加速

n  学霸APP组和学霸WEB组能够完成共用后端的操作，且经过团队的测试，后端接口单元测试完全通过，而测试时也并未发现较大的异常

n  代码可读性和复用性大幅提高，且文档齐全并包含部分用于上手的的学习文档

0x020c：团队Beta阶段项目经理的职责

这里先引用此前SivilTaram的吐槽（http://www.cnblogs.com/SivilTaram/p/4966026.html）：

这里是此前在Alpha结束阶段他对我们当时团队的一段吐槽内容，事实上这一部分的吐槽反映了团队当时的开发状况，但在言语上也有所区别，这里在团队的配合中也感受到Alpha阶段心得，并将其应用到Beta阶段：

n  Alpha阶段团队是架构、后端驱动的TDD开发模式，因此，这里所谓“实际上的项目经理没有完全发挥项目经理的职能，没有一个整体的规划和组织“其实在Alpha阶段后期团队也已经正面了这一问题，并开始将项目经理的部分工作进行转移，交付架构师，根据团队前后端的对接情况进行项目进度的管理；

n  Alpha阶段团队的灵魂并非项目经理，而是架构师，他作为团队的灵魂核心根据对接情况将前后端的进度进行协调，使得团队最后完成项目的Alpha迭代开发

n  Alpha阶段对部分工作的责任相对不明确，因此，部分成员后期由于工作调度的问题，未能完全参与到开发过程中

因此，在Beta阶段，项目经理开始真正发挥其职能，尽可能保证团队在集市开发模式中能够按照教堂模式进行规模化的搭建：

0x0210：团队成员，特别鸣谢的篇章

在第16周左右，笔者的状态几乎接近崩溃，团队的开发进程由于各事项的并行几乎进入了阻塞状态，而由于团队沟通此前消耗了大量的时间成本，开发时间也被急剧压缩，甚至一度想完全放弃软工这一项目；这里真的感谢团队成员每一个人的协作和沟通。在繁忙的考期中，并非一两个人支撑地团队，而是全体成员共同完成最后的重构到发布工作。（当然，这里也有建议，在团队初期规划设计方案、选取项目时，应充分考虑团队本身的能力）

记得当时答辩前夕，自己静坐在电脑前想着答辩时可能的细节，软工这一路团队走过来顺利吗？

是啊，顺利吗？当打出这三个字后我又写了一长篇文字，还是高中时稚嫩的排比句呢，用分号连接的，都是经历的矛盾和纠结，然后就全删了。可能2015年的自己最大的不同是删除痛苦，我永远不会将两种悲伤放在天平上评判褒贬（此时音乐：《Blessing(World Edition)》），我只是希望，新的一年，团队依然可以对自己有信息，相信我会继续努力，成为漫长道路的那个安好的人。

再见了，这场漫长的道别，和软件工程BugPhobia团队，你给我很多的矛盾和希望，挫败感和喜悦感，我很喜欢，真的很喜欢~

谢谢BugPhobia团队这一路的协作和沟通，就像自己一直喜欢星期六的自己，相对年少，尽情睡懒觉，把一切推给明天，没有忧虑，也没有愤懑；这是成长的故事，也是星期六即将结束的故事~

最后，链接如下，BugPhobia团队的致谢：

Beta阶段项目经理、前端开发的少年PocketPanacea：http://www.cnblogs.com/panacea/

平台沟通、后端开发的少年When：http://www.cnblogs.com/whenever

前端开发、页面设计的少女someonefighting：http://www.cnblogs.com/someonefighting

前端开发、测试担当的少年-OwO-：http://www.cnblogs.com/-OwO-

前后端对接、架构担当的少年GNU_Linuxer：http://www.cnblogs.com/fzyz999

后端开发、后端担当的少年Fihzero：http://www.cnblogs.com/Fengzr

Alpha阶段项目经理、颜值担当的少女summerMTY：http://www.cnblogs.com/summerMTY

0x03 ：解决的问题

To the world,you maybe a person.

But to a person,you maybe the world.

首先设置此前提出问题的传送门：http://www.cnblogs.com/panacea/p/4832903.html

这里阐释个人理解，首先需求的急剧调整是需要分情况探讨的；这里由于笔者的理解有限，因此只能从团队协作和设计两方面阐释这一问题；

n  对于团队协作方面：如果需求急剧改变，从项目经理的角度，只能尽可能确保整个团队在正确的时间做正确的事情；遇到紧急需求的改变，首先需要通过Design Change Request的分析，充分验证更改需求的必要性后，协商技术负责人去探讨合理的解决方案（这里引用了助教的解答）。而技术负责人需要去探讨这一解决方案的实现成本，并根据实际情况进行一定的妥协。这里笔者根据Alpha阶段和Beta阶段之间的过渡阶段，给出一定的解释和说明。实际上，在Alpha阶段到Beta阶段，团队的需求由“自主搭建“到”协调沟通“，由面向用户的开发模式，向面向开发人员对接适应接口的模式进行转换；团队整体做出重构的决定后，最重要的是留出学习成本的时间，同时架构师尝试了代码迁移ReactJS的demo试验，在经历一段时间的实践过程，最终决定完成需求的变更和搭建工作（http://www.cnblogs.com/bugphobia/p/5118599.html）

n  对于接口设计方面：笔者感觉这一问题尚未弄清，毕竟仅仅但从这一次团队的项目中不能立刻给出定论，但至少在高聚合的设计上，可以考虑成熟的架构，在数据传输时设计松耦合的接口，可能对需求变更这一问题有着较好的解决方案

这里阐释个人理解，事实上，暂且不谈软件工程的课程设计，编译原理的代码优化笔者在代码生成阶段预留了一部分设计保证后期代码生成的快速修改（然而最后还是没有冲击代码优化部分，还是蛮遗憾的QAQ）

int handle_add() {      //ADD SRC1，SRC2，DST

……  //achevie value/address of SRC1/SRC2/DST

#ifdef DEBUG_OPTIMIZE

……  //Code Block with optimize in global register or temporary register

#else

……  //EAX with DST

}

实际上，笔者在设计阶段很少考虑后期优化的优化点，因为在后期维护代码时很可能会增加重构的难度且降低代码可读性；但编译原理这一部分实际上是可以预见的后期修改过程，因此预留一部分的扩展空间自然无可厚非

最后回到此问题的核心，其实此问题和第一个问题有着相似之处，仅从笔者这一阶段的理解，可扩展性尽可能搭建在数据传输时的松耦合接口，并根据需求对高聚合的其他架构做出一定的修改去适应，是较为合适的解决方案

这里先引用当时助教的吐槽，如今回顾自己提出的问题发现果然是若合一契，“同学你对需求改变这个问题很敏感啊……“。其实这里和笔者的个人经历有关，笔者本身曾全程参与到某一智能插座的开发过程中，在初期的设计雏形时始终考虑对电器本身的芯片进行一定的函数编程，在后期的设计后则改变这一做法，用最简单的”遥控器“控制模拟过程去完成插座节点的搭建。但最后，由于需求变更这一部分浪费了一定的时间，因此最后这一项目处于流产状态，而最后将demo做出自己玩玩就不再开工了。实际上，开发后期可以暂且理解为”产品的雏形基本完成，已经处于基本的测试和宣传阶段“，那么遇到用户需求急剧变化的情况，笔者感觉这里问题应当由宣传人员和项目经理共同给出一套成型的解决方案，而非在产品上胡乱添加内容：

笔者暂时想不到一定的案例，但不妨虚构一案例以笔者的角度理解，进行大致的说明：

l  背景：现在处于一个国家，松茸是稀缺的珍馐，而恰巧国家由于资源充裕，国民整体的福利较好，松茸这种高昂的食品有着广阔的市场

l  团队：我们尝试人工种植松茸，并假设技术上取得突破，松茸价格是A万元/克

l  实例：运输成本取得突破性进展，松茸运输过来不过B千元/克，而人参反而成为了稀缺产品，显然松茸的栽培技术迁移到人参是个巨大的屏障（10B<<A，谁把<<符号当成左移位操作符了囧RZ）

l  策略：天然、现场采摘、游客参观并以纪念品的方式销售产品，以全新的需求推广产品

这一问题笔者的确没有弄清楚，因为在整体的开发过程中，团队几乎处于重构操作，仅从需求角度分析了此前团队完成的项目；但笔者这里仅给出一未实践的做法：从单元测试的角度入手分析模块本身的输入输出，依据需求分析的结果去维护旧代码；当然，如果注释相对齐全，也可以先自己做出一部分验证，确保注释的正确性

实际上，这一点是针对软件工程课程设计角度提出的问题，经历了两轮迭代过程，也有一定的感触，这里将当时提出的部分意见再次在此问题上提出：

l  建立软件工程课程的GIT仓库，将技术学习文档、技术新得文档发布在其中（可以每一团队设立一文件夹），这样后继团队能够根据技术栈的情况，量力而行选择合适的项目进行开发

l  Beta阶段开发过程，实际上是考虑采取分工对调机制，但考虑到Beta阶段紧缩的开发时间，未能最后处理，但笔者这里给出一定的解决方案：“分工互换原则”，A和B交换工作开发一段时间，相互学到不同类型的东西，最后每个人给出在团队中两个不同位置的感想，但这样又可能导致外部换了而内部工作不换的问题，既然如此，就优化为A整理B的文档/代码，B整理A的文档/代码，各自给出互评报告

0x04 ：软件工程新的问题

To the world,you maybe a person.

But to a person,you maybe the world.

n  关于学习成本的消化问题：笔者在Alpha阶段就一直思考如何能保证技术的开发成本能够尽可能地交付成员，并快速消化和接受。在Beta阶段，笔者尝试通过Demo的考核方式用以判断成员对这一技术栈的理解程度，并尽可能让熟悉这一框架的旧开发人员带动新开发人员，进行结对编程的方式快速熟悉。但其效果较为微弱，可能成本仅缩短30%左右，与预期的估计值差距较大；软件工程中，旧开发人员应当以怎样的方式带动新的开发人员快速适应这一技术栈并投入开发中？

n  关于车祸系数的问题：团队在Alpha阶段和Beta阶段一直思考如何降低团队的车祸系数，团队初期一直依赖全栈工程师兼架构师（GNU_Linuxer）的带动，而在后续的开发过程中，一直尝试通过开发栈的分离和松耦合保证车祸系数的降低，那么在实际的团队管理中，应如何控制车祸系数维系在项目经理可接受的范围之中？

0x05 ：新体会

To the world,you maybe a person.

But to a person,you maybe the world.

实际上，在经历了两轮重构工作后，团队的开发模式也逐渐走向规范化的集市模式管理，这里笔者根据此前的理解给出集市开发模式必要的因素：

n  合理组间协作沟通负责人：在开发过程中，遇到组间协作的部分，尽可能通过某一架构完成两方面团队工作的协作；而团队建议在此部分架构上安排特定的某一人，去解决这一部分对接工作的全部问题，去直接和下游的团队进行对接，尽可能降低组间沟通消耗的成本

n  开发的直接负责人（单人）：http://www.ituring.com.cn/article/9363，实际上，在开发过程中必须确保每一部分工作的质量均由特定的人进行管理，遇到变更时再优先和负责人讨论后作出妥协或决定

n  时间节点的设置：各任务必须给出预算的时间节点，供项目经理搭建出流水方式的工作进度管理

n  依赖关系的重视：确保架构上的依赖关系，进度上的时间依赖关系有足够的容错能力，保证在后续的调整过程中，不会出现集市的空档期

0x06 ：简洁知识点总结

To the world,you maybe a person.

But to a person,you maybe the world.

以你所在方位画下一个坐标，然后跌跌撞撞杀出一条血路。

第二轮迭代的项目经理，铭记反思，愿一切安好~

0x07 ：软件工程驻足篇章的尾序

To the world,you maybe a person.

But to a person,you maybe the world.

Two strangers fell in love

Only one knows it wasn’t by chance

展信安

快乐和悲伤，挣扎与妥协

成长于亲情，学着追逐爱情

这应当就是少年成长的故事，即便也是星期六即将终结的故事

但至少，不管是爱情、亲情还是友情

只要喜欢一个人，就不要冷冰冰的

你好，驻足的旧时光

teamorl~

软件工程驻足篇章：第十七周和BugPhobia团队漫长的道别

标签：

原文地址：http://www.cnblogs.com/panacea/p/5128024.html