如果你在软件行业工作，你很可能听说过 分而治之 设计范式, 它主要是将一个问题递归地分成两个或多个子问题(分)，直到这些问题变得简单到可以直接解决为止(征服).
你可能不知道的是，这种模式起源于一种古老的政治策略(这个名字来源于拉丁语 分而治之)，这表明可以通过鼓励下属或臣民之间的不同意见来保持对他们的控制.
历史上无数的政治家和军事领导人都使用过这种策略, 比如凯撒大帝(他在高卢战争中使用它来击败军事上强大的高卢人)和拿破仑(法国炮兵专家会把敌人的军队分开，所以没有哪一部分比他自己的军队更强大, 然后破坏他们的通讯, 阻碍敌人协调和执行攻击的努力).
然而, 分而治之 规则并不是唯一可以应用于软件开发的政治策略. 尽管政治和战争与软件开发没有什么关系, 就像政治家和将军一样, 开发人员必须领导下属, 协调团队之间的工作, 找到解决问题的最佳策略, 管理资源.
战争的艺术 是一本写于公元前五世纪的古代军事论文吗.C. 并归功于孙子, 中国古代军事家, 他的理论对东西方哲学都产生了深远的影响.
尽管年代久远, 在东亚许多军事学校的教学大纲中，这本书仍然被列为西方一些军事院校的推荐读物. 全书分为13章，每一章讲述战争的不同方面.
然而, 除了战争, 孙子的原则和教义在政治上有实际的应用, 业务, 体育，还有，信不信由你，软件开发. 事实上, 你可能只是在日常生活中应用了其中的一些原则, 甚至不知道他们的起源.
详细如下，你会发现一个简单的列表的基本战术和技巧，在战争的艺术解释. 它们也许可以应用到你在软件行业的工作中, 或者其他一些行业.
当你参加实战的时候, 如果胜利遥遥无期, 男人的武器会变得迟钝，他们的热情也会受到抑制.
这个原则可以应用到软件开发中, 作为一种描述开发周期长度与开发者士气之间关系的规则.
如果一组开发人员在同一个项目上工作了几个月, 没有明确的目标，也看不到终点, 他们可能会感到沮丧，他们的生产力可能会下降.
软件开发是一项智力活动，因此动机是生产力的主要燃料. 每天工作却没有意识到你的工作产生了真正的结果，这是非常令人沮丧的.
就像一些 敏捷方法, 开发路线图应该分为几个目标和里程碑, 团队可以在短时间内实现哪些目标, 他们会给他们一种进步和成就感.
因此，在战争中，让你的伟大目标是胜利，而不是漫长的战役.
这句话可以有两种解释:
首先，它可以被看作是UNIX哲学的先驱: 编写只做一件事并把它做好的程序. 开发软件时, 你必须时刻牢记这个项目的主要目标, 它提供的关键特性, 或者说它能解决的最大问题, 确保正确执行. 这在定制软件开发中尤为重要, 在哪里为一组非常特定的用户和特定的业务需求开发产品.
在软件开发过程中，有时您可能会受到启发并想到要添加一个很酷的功能, 但要谨慎行事:那些有很多不常用功能的应用程序被称为一个贬义词: 臃肿软件.
其次，这句话也可以被认为是一个精益的前兆 软件开发 原则: 尽可能快地交付.
越早交付没有主要缺陷的软件, 你就能越快从客户那里得到反馈, 并且您将能够将更改合并到下一次迭代中. 这是敏捷软件开发的一个关键假设.
另一方面, 您交付的是无法工作的软件, 你会错过有价值的反馈, 因为客户没有机会对它进行适当的测试. 这将使下一阶段的发展更加困难, 或者在下次迭代依赖于客户反馈的情况下是不可能的.
Now the general is the bulwark of the State; if the bulwark is complete at all points, the State will be strong; if the bulwark is defective, 国家就会衰弱.
这句话描述了开发团队中经理角色的重要性:项目的成功取决于团队的力量 所有的人 参与其中，经理是项目的支柱. 责任从高层开始.
尽管开发人员经常独自工作(每个人都坐在电脑后面), 与同事沟通有限), 这并不意味着他们不需要好的领导. 项目经理负责保持团队的正常运行, 确保有效的沟通和争议解决, 和领导人, 很明显, 定义项目的优先级(在其他任务中), 因此，他们的作用不应被低估. 也不应该 他们的责任 如果出了问题. 想象一下，如果一个军队领导人的部队在战场上未能履行职责，会发生什么?
一个团队即使在开发岗位上有几个害群之马，也能开发出优秀的软件, 但这不大可能发生，如果 项目经理是个坏苹果，不管团队中有多少明星开发者.
不要重复曾经为你赢得一次胜利的战术, 但是要让你的方法随千变万化的环境而变化.
有时, 当开始一个项目时, 使用我们在以前成功的项目中使用的相同的技术集(相同的编程语言)是诱人的, 相同的库, 同一台服务器, 等). 但是，除非新项目的要求是 完全一样 与之前的问题一样，这可能是错误的方法.
在编程, 和大多数领域一样, 万能药(一种据说能治愈所有疾病的药)是不存在的. There is no single combination of technologies that you can use for solving all problems; each technology has its upsides 和 downsides.
当然, 学习一门新的编程语言或使用一种未知的API最初可能会很昂贵，但从长远来看, 软件的质量会更好，你会成为一个更好的开发人员.
因此，只有开明的统治者和明智的将军才会使用军队的最高情报来进行间谍活动, 因此，他们取得了巨大的成果. 间谍是战争中最重要的因素，因为他们决定了军队的行动能力.
这句话可以解释为在维护阶段使用监视工具和日志库的重要性.
虽然有时客户可能不这么认为, 当你得到一个稳定的、经过全面测试的版本时，开发并没有结束. 软件总是在不断发展，要么是通过修复错误，增加新功能，要么是提高效率. 维护是软件开发生命周期中的一个阶段，而且非常重要.
要知道要做什么更改，没有比让间谍监视生产环境中的软件更好的信息来源了, 检查哪些特性使用得最多, 最常见的错误和最长的操作.
错误报告, 日志记录条目和使用数据是检测bug的基础, 识别瓶颈和其他问题，因为在受控测试环境中不可能总是重现相同的条件. 软件开发生命周期确保收集到的任何信息都为未来的开发提供信息.
不求名利，奋发向上, 谁不逃避责备而退缩呢, 他的唯一目标是保护他的人民，侍奉他的主, 他是王国的珍宝.
基本上，这是古代中国版本的 “团队里没有我”. 与他人合作比追求个人利益更重要.
软件开发是一项复杂的活动，需要开发人员作为一个团队有效地工作. 一个好的开发人员并不是修复最多bug的人, 实现最多的功能或提前完成任务; 一个好的开发人员是帮助团队实现目标的人.
为你所做的一切邀功, 不承认自己的错误，也不把错误归咎于别人, 或者称自己为 代码忍者 可能会骗过一些没有经验的经理，甚至可能给你加薪, 但你会成为团队中一个适得其反的成员.
在你采取行动之前仔细考虑一下.
这句话表明了团队发展会议的重要性, 比如敏捷方法提出的那些.
在团队中工作时，在实施任何重大变更之前进行讨论是很重要的. 如果你是团队领导，这并不重要, 或者你是在这个领域最有经验的人, 你应该经常和, 或者至少告知, 团队的其他成员.
请记住，其他开发人员可能会对软件中不熟悉的部分提供见解. 这意味着他们可以比预期更快地开始实施变更, 因为他们可以充分意识到这些变化的影响.
把你的士兵当作你的孩子, 和 they will follow you into the deepest valleys; look upon them as your own beloved sons, 他们必与你同在，直到死.
这句话表明了动机的重要性, 这是一个管理原则，有时会被经理和团队领导所遗忘. 有动力的开发人员会写出更好的代码, 工作速度快, 少犯错误，更愿意投入额外的时间.
激励必须由管理者产生, 通过对下属真正的关心, 倾听他们, 关心工作与生活的平衡, 建立积极的工作环境，关心他们的职业道路.
此外，你不应该把动机和报酬混为一谈. 最近的研究表明，金钱并不能激励大多数员工, 金钱最能吸引和留住员工, 但不能让他们对自己的工作感到满意. 因此，加薪和晋升不应被视为激励工具.
不超过五个音符, 然而，这五种组合产生的旋律比以往任何时候都多.
原色不超过五种, 然而，它们结合在一起产生的色彩比以往任何时候都要多.
基本口味不超过五种, 然而，它们的组合产生的味道比以往任何时候都要多.
One of the good things about programming is that the possibilities are endless; you can develop basically wherever you want (at least, 只要不是np完全问题).
移动应用程序, 网站, 游戏, 桌面应用程序，如果你懂编程的话, 所有这些都是你力所能及的.
在实际的战争艺术中, the best thing of all is to take the enemy’s country whole 和 intact; to shatter 和 destroy it is not so good. So, 太, 与其消灭一支军队，不如俘虏整支军队, 攻占一个团, 一个支队或一个连队比摧毁他们更重要.
当处理一个有大量代码库的项目时, 通常会发现使用不良实践或使用不推荐的库实现的模块或代码段. 尽管擦除(或销毁)这些代码可能很诱人, 这可能不是最好的主意，原因如下:
遗留代码不一定是坏的, 有时，在考虑其他方法和技术的情况下编写的代码是好的. 然而，仅仅因为它老了并不意味着它不起作用.
你可能会浪费时间 修复仍然有效的代码 而不是专注于修复其他更关键的代码部分.
除非你真的很确定你在做什么, 替换一段有效的代码意味着你有引入新错误或bug的风险.
这并不意味着这句话 “如果没有坏，就不要修理它” 是一个好的策略，但每个项目都有优先级、目标和时间限制. So, 如果你发现可以改进的代码, 与团队的其他成员或项目经理讨论，以便找出何时优化它.
有些路是不能走的, 不可攻击的军队, 不能被围困的城镇, 不得有异议的立场, 君主不得服从的命令.
即使它没有直接说出来, 我们可以将此原则解释为避免反模式的警告.
尽管使用反模式可能解决短期问题, 你应该记住，从长远来看，这将适得其反. So, 不管你省了多少时间, 你修复了多少bug，或者对你来说有多方便, 避免这些问题.
仍然, 有时，您可能会尝试使用反模式来解决紧急任务, 向自己保证，当你有更多的时间时，你会实施一个适当的修复, 但记住墨菲定律之一: 所有的权宜之计都会成为永久的改变.
虽然开发软件不同于在战争中指挥士兵或领导一个国家, 他们必须解决需要团队合作的问题, 良好的领导, 效率和长期解决方案.
然而, 兵法 这不是唯一一本包含可以应用于软件开发的原则的书吗. 尼科洛•马基雅维里的 王子，就是一个例子。.
事实上，这里有一份马基雅维利的名言列表，仍然是相关的. 试着猜测哪些是软件开发世界中相应的原则.
布宜诺斯艾利斯，阿根廷
2015年9月29日成为会员
世界级的文章，每周发一次.
世界级的文章，每周发一次.
