指挥官必须有良好的精神素质，必须具备果敢、坚定的性格和冷静的智慧；必须了解和 学习控制部队对于死亡和痛苦的反应。
                                                                                                           — 克劳塞维茨 《战争论》

指挥，看起来并非是程序员的本职工作。

在公司里我是一个技术管理者，更多地从事技术研究、项目管理、团队建设、任务分配以及员工辅导等方面的工作，有时又兼职需求分析或产品经理等。但 在产品大版本的现场实施环节，我会临时被赋予一个新工作 – 指挥。这次新系统在客户现场上线，我就体验了一把指挥官的角色。

相信没有哪个程序员在学校里学过指挥课程，基本都是“跟着感觉走”。这次实施后我恰好读了《安德的游戏》一书，读到安德的指挥经历，产生了一些 共鸣。遂想在这里说道说道。

归纳起来，一名合格的现场指挥官至少应该具备以下条件：

* 切实地掌控全局信息

如果用战争来做比喻的话，作为指挥官的你要知道战场范围、敌我实力态势、战役目标和战略意图、意义和策略、敌方惯用战术、我方的优势与不足等。这些信息是你指 挥决策的基础。作为系统现场实施这种“战役”而言，指挥者应切实了解系统能力、上线策略、业务影响、实施人员水平、保障准备、“战役”进展、问题现状与影响、回退时机等。这些信息可以保存在指挥者的大脑里，也可以通过工具可视化的展示出来。

如果大家对指挥没有概念的话，可以回顾一下近期大家在媒体上看到过的指挥场面，比如双十一的淘宝/天猫；比如嫦娥3号落月等。

* 准备、准备再准备

“大军未动，粮草先行”。各种准备工作是否科学精细、周全完备，是任务是否能顺利完成的关键前提。在书中安德为新战术、新策略组织针对性的演练，指挥官在演练中找问题，寻求更合理的组队分工以及对突发情况的处理预案。

* 充分了解下属个体的特点，让任务有的放矢

这点在安德身上体现明显。书中安德经过观察发现飞龙战队中的比恩更适合带小部队突击，而哥们阿莱更擅长战略，甚至可以是自己的替身。只有充分了解下属的特点后，才能让他们发挥出自己100%的水准，任务的分配也就自然很清晰了，指挥官的战术意图更易达成。

* 指挥官应该快速做出最优决策，切莫受他人的影响，必要时让其他人闭嘴

既然被任命为指挥官，你拥有最大的权力，当然也有最大的责任。任命你为指挥官，显然大家认为你是最优秀的，体现出上下对你的信任。你的决定会被认为是当时的最优决策。因此在实际临场指挥中，切记保持清醒的大脑，根据得到的真实信息，快速作出决策。

切记决策莫受他人影响，必要时让所有人闭嘴。当然其他人可以提出自己的意见和建议，但关键时刻，你要坚持你的想法和判断，坚持你自己的原则。一般来说你总是对的。相反，有原则，不坚持都是白扯。

书中虽然没有强调过安德的决策受到过其他人的影响，但对安德决策产生过程的描述还是很扣人心弦的。

* 打破常规，破除思维定势和规则束缚

“按部就班”的指挥只能让你达到普通指挥官的水准（比如书中的火蜥蜴战队的队长马利德），一流的指挥往往内含创新。这样的指挥官敢于打破常规，破除思维定 势和规则束缚。就像书中安德那样，先后发明了“脚前身体在后”、“绳索”、、灵活使用集群进攻模式、“小队”突击、“四小队改五小队“等极具创新的新颖的 指挥战术。在这些新战术下，那些墨守成规的战队一一败下阵来。

* 学会观察团队成员表现

越是在关键的“战役”中，越能看到团队成员的真实实力和表现。越是繁忙、越是压力山大，我们看到的就越真实。观察大家是如何在过程中完成他们各自的任务的？他们的抗压能力如何？是否临阵不乱，触乱不惊？是否是传说中的“大赛型选手”？等等。

作为指挥官，你拥有这样一个好机会去了解你的团队成员。安德是这方面的高手，他善于在战斗比赛过程中观察队员的表现，并根据个人特点在后续委以重任。

* 持续总结与改进

没有什么“最后的战斗”！因此我们总是要为下一次战斗做好准备。这就要求指挥官们在每次战斗结束后，学会总结，发现不足，思考改进。长此以往，你会取得一 个又一个胜利。书中的安德是整个战斗学校最擅长在每次战斗比赛后复盘并自我总结和改进的选手，他知道如何从敌人的视角发现自己指挥上的不足和漏洞，思考在 下次战斗中如何规避和改进。他还会复盘和分析其他指挥官在比赛使用的战术，并消化、改良后为自己所用，他也因此了解其他指挥官的指挥弱点。

* 其他

指挥官在指挥过程中务必得到真实准确的信息反馈，错误的、有偏差的信息将导致指挥者作出错误的决策。因此在准备工作中，就应该建立好真实信息的反馈渠道，定义信息的反馈频度和展现形式。

指挥的成功还依赖团队成员的执行力。没有好的执行力，再好的指挥可能都不会达成理想的战术意图，甚至可能因此而输掉全局。执行力不会在实施过程中突然迸发出来，显然它需要在平时养成。个体执行力强弱取决于两个要素：个人能力和工作态度。其中能力是基础，态度是关键。个体执行力是指挥官在日常准备、训练过程中务必要关注的。

说实话，指挥官这个角色的确能给我带来一些小兴奋，事成之后的成就感也是蛮充实的。以后再有机会偶尔客串一下，也未尝不可^_^。

一切没有目标的努力，都是瞎忙活儿。
                                                    - Tony Bai

刚实施回来，就又投入到新工作中，到今天才有那么一点点时间写写这件事儿。

* 缘起

我们的遗留系统性能一直不高，导致这一局面的因素有很多，比如最初设计和实现的“考虑不足”、后续维护人员的“随波逐流”甚至缺少勇气对影响性能的关 键代码进行重构等等。技术债务就这样一直积累着。直到两年前，我们终见其导致的巨大的影响了。

由于客户方成本压缩，单节点性能低意味着需要更多的硬件投入，并连带着报价升高，导致我们的产品市场竞争力下降。而竞争对手产品的性能是我们的 3-5倍，这终于引起了领导的重视，并下达了开发高性能版本的任务命令。

* 抉择

遗留系统的问题有很多，性能差仅仅是表象之一。可维护性差更让人印象深刻。遗留系统就像一件打满补丁的旧衣裳，虽然依旧能穿着遮体御寒，但却让我 们时刻战战兢兢，生怕一个动作会导致它解体，变得支离破碎。

对于我们这样一个mission-critical的系统来说，开发周期显然是不会短的。在性能达标的同时，更为重要的是保证产品的质量，确保上 线后运行稳定。因此摆在我们面前有两条路：
    1、在遗留系统上做“大修” – 大规模重构；
    2、重写，把构成系统的骨架重新设计和实现，使它能够足够坚固，满足在“高速公路”上驰骋的要求。

我们最终选择了重写，也就是风险较大的那条路。在我们的理解中，重写软件就好比汽车升级平台，就像大众将传统的PQ25、PQ35等统统升级为 MQB平台那样。平台的升级，不光影响技术，还会影响方方面面，比如团队的能力、思维方式、合作模式以及团队过程改善等等。做 得好的话，会使整个团队迈上一个新台阶，这是原地修补所不能够带来的。

对于我个人来说，这也是我期望中的实验田，我将把之前研究的诸多实践落地，帮助团队提升能力。

自私地说，重写系统也是我的一个小理想，能遇到这样一个从无到有构建一个系统的机会是不多的，因此很是希望能看到一个系统一点一点的在自己的呵护 下“成长”起来。虽然我也清楚完成这样一个系统需要很长时间，而这期间我可能需要时刻紧绷着神经，直到系统正式上线后，才能感受到那一抹释然。

* 建立“骨架(skeleton)”

我们将项目分成两个阶段：建立系统“骨架”和为系统“添肉”，即添加业务逻辑。

系统的性能目标是原遗留系统的10倍，这样我们建立的骨架的性能至少要高于原遗留系统的10倍。在“添肉”之前我们要充分证明骨架的设计是合理、 有效、稳定和高性能的。

遗留系统性能低，并非因为当初的设计者能力有什么问题，更多是局限于当初的设计目标。系统初期业务量不大，接入的外部网元不多，因此系统大量使用 了链表这种简单但低效的数据结构；为了easy coding，当初的设计者选择了全局大锁；在客户端-服务器处理模型上，选择了一个连接一个进程的“高耗能”模式。最初这样的设计应对当年的业务量也是 绰绰有余的，但应付今天的业务规模就显得颇为捉襟见肘了，以至于我们不得不通过罗列机器来满足业务增长的状况。服务器增多，却导致了我们维护 和监控难度的增加。

为了应付现有业务量规模以及未来若干年的业务量增长，我们的新系统的骨架在设计时显然要扬长避短：
    – 我们重新设计了通用的服务端框架和客户端框架，使得系统各个业务模块采用相同的通信处理机制；
    – 我们没有选择线程，而是依旧采用成熟的进程（资源隔离式） + IO多路复用（linux下epoll机制）的服务器-客户端模型，与以往不同的是，我们在每个进程中处理多个链接，设定进程数量在合理水平，避免大量上下文切换带来的性能损耗；
    – 将传统的全局big lock更换成了细粒度锁；
    – 采用高效的数据结构和算法，比如用hash和array替代掉list等；
    – 用简单队列替换掉原先复杂的队列调度结构，降低代码理解难度和后续维护门槛。
    – … …

我们要求对骨架代码进行严格的单元测试，通过lcut为骨架代码建立起单元测试集，并结合持续集成对骨架代码进行持续的单元测试验证。

骨架完成后，我们对其进行了全面的压力测试，确保其性能水平达到我们设计要求，这是我们进入下一阶段的前提条件。

* 添肉(business logic)

有了稳定、可靠、高效的骨架，我们在”添肉“阶段就更加有信心了。用C写纯业务逻辑是苦逼了一些，但还好我们没有全部将以前遗留代码扔掉，我们为了保证功 能Feature不丢失，我们会尽量复用之前的业务逻辑，当然是“规范地”搬到新系统中的，尽可能地去除原有代码中的Bad smell。

与骨架相比，业务逻辑相对复杂，且耦合较多，因此对这些业务逻辑做单元测试真是一件让人头疼的事情。不过这也和我们最初的估计相符，最初制定的策略就是对骨架代码做高覆盖，对业务代码则宽松些，尽量覆盖即可。

* 附加实践

就像前面所说的那样，围绕着这次重写系统，我策划了很多实践有了落脚之地，包括：
    – 试点知识管理 ：通过这次重写，建立起关于该系统的知识库；
    – 增加基于ReviewBoard的在线代码评审环节；
    – 引入基于Jenkins的持续集成；
    – 重新思考和设计构建环节，通过buildc提高构建效率；
    – 重新设计通用安装包；
    – 使用LCUT对骨架进行单元测试覆盖；
    – 规范commit log以及代码提交流程；
    – 应用代码风格检查工具，使得所有代码风格一致。

事实证明上述实践在这次系统重写的过程中产生了很好的效果，尤其在代码质量保证方面，系统上线后的结果也恰恰印证了这一点。

* 上线

“丑媳妇总要见公婆”。我们的新系统也到了该上线服务的时候了。为了这次上线，我们做了较为充分的实施准备，无论是人员还是时间，都有倾向性的向这个系统 投入。我们也提前做好了应对各种突发问题的预案。可实际情况出乎预料，与遗留系统的版本升级相比，这次全新系统上线显得十分顺利，系统的核心相当稳定，出 现的一些问题也都比较边缘，对这次成功上线已经不构成什么影响了。

* 那一抹释然

在实施人员庆贺上线成功时，在领导口头表扬时，我的内心却显得十分平静。对于新系统来说，这是一个好的开始。对我个人来说，我感受到了那一抹期望已久的释 然。在这个领域里这个方向上已经摸爬滾打了多年，虽然还有好多地方需要改进，好多实践需要完善，但我的内心告诉我：“够了”、“已经没什么牵挂了”、“是 时候换换方向、换换领域了”、“让其他人去做吧”。我已经在产品和团队中融入了我的思想，我相信他们都能很好的演化和发展。而我则为接受新思想、新领域做 好了准备。

的确也到了为自己设立新目标的时候了！