[译]从《孙子兵法》到软件开发
/**
* 谨献给可爱的小黑
*
* 原文出处：https://www.toptal.com/agile/art-of-war-software-development
* @author dogstar.huang <chanzonghuang@gmail.com> 2016-04-02
*/如果你工作在软件行业里，很可能你已经听说了 分解 和 征服 设计范例，基本上包含了递归地把一个问题 划分成两个或者多个子问题（_分解_ ），直到这些问题变得足够小可以直接解决为止（_征服_ ）。
你可能不知道的是这个范例来源于一个古老的政治策略（名字来自拉丁语_分而治之_ ），此策略提议有可能通过 鼓励异议来维持对一个人的下属或者受控者的控制。
在历史的长河上，无数的政治家和军事领导人都使用此策略，诸如凯撒大帝（在高卢战记中使用此策略击败了强 壮的高卢）和拿破仑（这位法国炮兵专家把敌军进行了分解从而没有任何一部分能比他自己的军队更强壮，然后 扰乱他们的通信，以阻止敌人进行协调和执行攻击的努力）。
《孙子兵法》：把远古的原则应用到软件开发
然而，_分解_ 和_征服_ 不是唯一可以应用到软件开发的政治策略。尽管政治和战役与软件开发之间没什么关 联，但是就像政治家与将军们一样，开发人员必须领导下属，协调团队的努力，找到解决问题的最佳策略，并且 管理资源。
孙子兵法的原则和教诲已经在政治、商业、体育和软件开发中都得到了实际的应用。
《孙子兵法》是一本写于公元前15世纪的关于古代军事著作，并 且归因于孙子，一位中国古代军事策略家，他的理论对于东方和西方的哲学都产生了巨大的影响。
除了那个时代外，这些内容仍然包含在了很多亚洲东部军事学校的教学大纲里，并且在西方的某些军事学院里作 为推荐读物之一。
然而，在战争之外，孙子的原则和教诲已经在政治、商业、体育， 以及，不管你信不信，软件开发中都得到了实际的应用。事实上，你可能正在你的日常事务里应用其中某些原则， 而不知道其来源。
在下面的细节中，你将找到基本谋略的一个简短列表以及在《孙子兵法》中解析的技巧。他们很可能可以应用到 你在软件行业的工作中，或者任何其他行业中。
在任何战争中时间都是至关重要的
第二章 作战篇，第二段
“其用战也胜，久则钝兵挫锐，攻城则力屈，久暴师则国用不足。”
这个原则可以应用到软件开发，作为描述开发周期的长度与开发人员情绪之前关系的一条规则。
如果一组开发人员在相同的项目上工作数月，没有明确的目标也看不到明显的尽头时，他们将可能会变得沮丧并 且生产力下降。
把你的开发路线图划分成容易实现的目标和里程碑。对情绪是有好处的。
软件开发是一项智力活动，所以驱动力是生产力的主要燃料。每天工作而感知不到你的工作正在产出实际的结果 会让人士气低落。
正如在某些敏捷方法中暗示那样，开发路线图应该划分成若干个团队可以在 短时间内完成的目标和里程碑，并给他们提供关于进度和成就的感知。
第二章 作战篇，第18段
“故兵贵胜，不贵久。”
这句短语可以两种解释的方式：
首先，它可以看作是UNIT哲学的先导：_编写只做一件事并把它做好的程序。_ 在开发软件时，你要时刻关注程序 的主要目标，它要提供的关键特性，或者它需要解决的最大问题，并且确保正确地实现。
有时，你可能会很振奋以及想要添加一个很酷的特性，但是不要忘了有大量不常用特性的应用有一个贬义的名字：英国媒体报道 （译者注：又长又臭又没人看）。
其次，此声明也可以考虑作为这条精益软件开发原则的先导：_快速交付_ 。
越快交付没有重大缺陷的软件，你就能越快从客户那获得反馈，并且可以把这些变化合并到下一次迭代中。
另一方面，如果交付了不能工作的软件，你将会错失有价值的反馈，因为客户没有正确测试它的机会。这会使得 开发的下一阶段更为困难，或者不可能假若你的下一次迭代依赖于客户反馈的话。
无领导，则无结果
第三章 谋攻篇，第11段
“故上兵伐谋，其次伐交，其次伐兵，其下攻城。”
此引用描述了在开发团队中管理者角色的重要性：一个项目的成功依赖于_全部人员_ 参与的力量，而管理者则是 这个项目的壁垒。责任自上而下。
责任自上而下。如果你的团队领导差强人意，再多有天赋的工程师也无能为力。
尽管开发人员经常独自工作（每个人都坐在电脑后面，与同伴进行有限的沟通），但这不意味着他们不需要好的领 导。项目管理者负责维持团队在正常的轨道上，确保有效的沟通和解决方案的讨论，并且领导，明显地，要定义项目 （在其他任务中）的优先级，所以他们的角色不应该被低估。如果出现某些问题也不应该是他们的责任。 想象一下对于在战役中他的单位执行任务失败的话对于军事领导会发生什么？
即使在开发位置上有一些坏苹果，一个团队还是可以产出伟大软件的，但是如果_项目管理者_ 本身就是坏苹果，那么 基本就是不可能了，不管这个团队有多少明星级开发人物。
第六章 虚实篇，第28段
“故其战胜不复，而应形于无穷。”
有时，当开启一个项目时，会倾向于使用我们在先前成功项目中所用到的技术系列（相同编程语言，相同类库，相 同有服务器，等）。然而，除非新项目的需求与前面的那些_完全_ 相同，否则这可能是错误的方式。
在编程的世界里，正如有大部分领域里，没有灵丹妙药（包治百病的东西）。没有一个简单的技术组合可以用于解 决全部的问题；每一种技术都各有所长，也各有所短。
当然，学习一门新的编程语言或者使用一个未知的API在最初可能是高成本的，但从长远的角度来考虑，软件的质量 会优质的而你会成为一名更好的开发人员。
第十三章 用间篇，第27段
“故惟明君贤将，能以上智为间者，必成大功。此兵之要，三军之所恃而动之。”
此短语可以解析理解为在维护阶段使用监控工具和日志类库的重要性。
忙乎有时客户并不这么想，开发并不是结束于获得一个稳定以及经过完整测试的发布版本。软件总是在不断演进，或 者通过修复bug，或者通过添加新的特性或者是提高效率。
而且也没有比间谍监控生产环境软件更好的信息来源来知道变化了什么，检测哪一个特性被用得最多，最公共的错误 和最具长度的操作。
由于并不总是能够在测试环境重现相同的场景，错误报告、日志条目和用法数据是检测bug、识别瓶颈和其他问题的基础。
团队合作与驱动力
第十章 地形篇，第24段
“故进不求名，退不避罪，唯民是保，而利于主，国之宝也。”
基本上来讲，这是古代中国“团队不分你我”的版本。相比追求个人收获，与其他人一起工作更重要。
软件开发是一项需要开发人员进行高效团队合作的复杂的活动。一位好的开发人员不是修复最多bug的那个人，不是实 现了最多特性的那个人，也不是超前完成任务的那个人；_一位好的开发人员是帮助团队完成目标的那个人。_
团队合作能赢得战争。记住，最好的开发鼓舞了帮助其他团队成员实现他们的目标的个体。
为你所做的事情夸夸其谈，而没有意识到自己的错误或者责怪他人，或者自称为代码_忍者_ ，这可能会愚弄到某些 没有经验的管理者甚至可能得到加薪，但是你将会成为团队中格格不入的一位。
第七章 军争篇，第21段
“悬权而动。”
这句短语暗示了团队开发会议的重要性，例如敏捷方法建议的那些。
当在一个团队中工作时，在实现前讨论全部重大变化是很重要的。不管你是不是一个team leader，也不在乎你是否 有着与主题相关的最为丰富的经验，你都应该与人交谈，或者最起码地，知会团队的其他成员。
记住其他开发人员可以为你提供你所不熟悉的软件部分的见解。这意味着他们能比预期更快地开始实现这些变化， 因为他们可能已完全意识到了对于所说的变化需要做的努力。
第十章 地形篇，第25段
“视卒如婴儿，故可以与之赴深溪；视卒如爱子，故可与之俱死。”
这句引用暗示了驱动力的重要性，一条有些会被管理者和team leader忽略的原则。有驱动力的开发人员会把代码 写得更好，工作更快，提交更少错误并且更愿意加班。
驱动力必须由管理者来创造，通过掌握下属真正的兴趣，聆听他们的声音，关心他们工作与生活之间的平衡，构建 积极的工作环境以及关心他们的职业生涯发展路线。
并且，你也不应该把驱动力和报酬混为一谈。最近的研究表明金钱并不能驱动大部分工作者，金钱对于吸引和留住员 工是最好的，但并不能让他们对工作感到开心。所以升职加薪不应该作为驱动力的工具。
跳出箱子思考
第五章 兵势篇，第7、8、9段
“声不过五，五声之变，不可胜听也；”
“色不过五，五色之变，不可胜观也；”
“味不过五，五味之变，不可胜尝也；”
关于编程一个好的方面是可能性是无穷无尽的；你基本上可以在任何地方进行开发（至少，只要不是NP完全问题即可）。
（译者注：NP表示为不确定是否容易解决）。
手机应用，网站，游戏，桌面应用... 如果你知道编程，全部这些都是唾手可得的。
如果你是一位有天赋的开发人员，你需要跳出箱子来思考。这个箱子是用来预防不能胜任者乱来的。而不是为你准备的。
第三章 谋攻篇，第1段
“夫用兵之法，全国为上，破国次之；全军为上，破军次之；全旅为上，破旅次之；全卒为上，破卒次之；全伍为上，破伍次之。”
当工作在一个有大量代码库的项目时，通常会发现用错误的实践或者使用废弃类库实现的代码模块或部分。尽管可 以倾向于擦除（或者毁灭）这些代码，但出于以下几点理由最好不要这么做：
遗留代码不一定是坏的，有时当考虑了其他方法和技术的话这些代码是好的。然而，老并不意味着不能工作。
你可能浪费了时间去_修复仍然可以工作_ 的代码而不是修复其他更严重的问题。
除非你确切知道你正在做什么，替换一段可以工作的代码意味着你面临着引入新的错误或者bug的风险。
这并不意味着短语 “如果没有坏，就不修它。” 是一个好的策略，但每一个项目都有其优先级，目标和时间约束。 所以，如果你找到了可以改进的代码，和团队的其他成员或者和项目管理者讨论一下以便知道何时优化之。
第八章，九变篇，第3段
“途有所不由，军有所不击，城有所不攻，地有所不争，君命有所不受。”
即使它没有明说，但我们可以解析此原则为对反模式的一个警告。
虽然使用反模式可以解决一个短期的问题，但你应该记住在长期上它是适得其反的。所以，不管你节省了时间， 修复了多少个bug或者对于你来说是多么的方便，避免之。
纵使这样，你还是会一次又一次地倾向使用一个反模式来解决一个紧急的任务，并对自己承诺你会当你有更多的 时间时会实现一个合适的修复，但请记住墨菲定律之一：_ “所有的事都会比你预计的时间长（All quick fixes become permanent changes）。”_
结论
尽管开发软件有别于在战争中指挥士兵或者领导一个国家，但是全部这些都是需要团队合作，杰出领导力，高效 和长期的解决方案来解决问题。
然而，《孙子兵法》并不是唯一一本包含了可以应用到软件开发的原则的书。例如还有尼科洛·马基雅维里的__《君主论》__。
事实上，这里列出了马基雅维里相关的一些引用。试着猜想一下哪些是软件开发世界中合作的原则。
1、狮子不能保护自己免受陷阵之灾，狐狸不能保卫自己免受狼的追捕。所以要同时像狐狸一样识别陷阱，又要像狮子一样吓退狼。
2、永远不要试图通过欺骗来赢得胜利 。
3、不经历风雨,又怎能见彩虹。
4、想要获得持续的成功就得要随着时代改变自身的行为。
5、人们通常是以貌取人，而不是根据本质判断。人都有眼睛，但有洞察力的却很少。
6、深谙将道方能号令三军。
7、智慧在于知道如何辨别故障的性质，以及选择两害取其轻的。
8、没有可以避免的战争；它只能推迟到你的敌人的优势。
9、自然创建了为数很少的人；工业和训练则创建了很多。
------------------------
本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 未本地化版本许可协议进行许可。本文翻译作者为：dogstar，发表于艾翻译(itran.cc)；欢迎转载，但请注明出处，谢谢！
312
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
