敏捷的世界观

敏捷的世界观

有一种至关流行的软件方法学要求对一个项目分配35种不一样的角色，包括架构师、设计人员、编码人员、文档管理者等。敏捷方法却背道而驰，只需一个角色：软件开发者，也就是你。项目须要什么你就作什么，你的任务就是与客户紧密协做，一块儿开发软件。敏捷依赖人，而不是依赖于项目的甘特图和里程表。

这大概是全栈工程师吧，哈哈哈~

为作事而工做

恶魔：“出了问题，第一重要的是肯定元凶。找到那个白痴！一旦证明了是他的错误，就能够保证这样的问题永远不会再发生了。”

在敏捷的团队中，你们的重点是作事。你应该把重点放到解决问题上，而不是指责犯错者上面纠缠。

你能够从本身先作起。若是一个开发者带着抱怨或问题来找你，你要了解具体的问题，询问他你能提供什么样的帮助。这样简单的一个行为就清晰地代表你的目的是解决问题，而不是追究责任，这样就会消除他的顾虑。你是给他们帮忙的。这样，他们会知道每次走近你的时候，你会真心帮助他们解决。他们能够来找你把问题解决了，固然还能够继续去别处求助。

若是你找人帮忙，却没有人积极响应，那么你应该主动引导对话。解释清楚你想要什么,并清晰地代表你的目的是解决问题，而不是指责他人或者进行争辩。

天使：把矛头对准解决问题的办法，而不是人。这是真正由用处的正面效应。

切身感觉

• 敢于认可本身不知道答案，这会让人感受放心。
• 一个重大的错误应当被看成是一次学习而不是指责他人的机会。
• 团队成员们在一块儿工做，应互相帮助，而不是互相指责。

平衡的艺术

• “这不是个人错”这句话不对，“这都是你的错”这句话更不对
• 若是你没有犯过任何错误，就说明你可能没有努力去工做。
• 开发者和质量工程师争论某个问题是系统自己的缺陷仍是系统加强功能致使的，一般没有多大的意义。与其如此，不如赶忙去修复它。
• 若是一个团队成员误解了一个需求、一个API调用，或者最近一次会议作的决策，那么也许就意味着团队的其余成员也有相同的误解。要确保整个团队尽快消除误解。
• 若是一个团队成员的行为一再伤害了团队，则他表现得很不职业。那么，他就不是在帮助团队向解决问题的方向前进。在这种状况下，咱们必需要求他离开这个团队。
• 若是大部分团队成员（特别是开发领导者）的行为都不职业，而且他们对团队目标都不感兴趣，你就应该主动从这个团队中离开，寻找更适合本身发展的团队（这是一个有远见的想法，不必眼睁睁地看着本身陷入一个“死亡之旅”的项目中。

欲速则不达

恶魔：“你不须要真正地理解那块代码，它只要可以工做就能够了。哦，它须要一个小小的调整。只要再结果中再加上几行代码，它就能够工做了。开工吧！就把那几行代码加进去，它应该能够工做。”

咱们常常会遇到这种状况，出现一个Bug而且时间紧迫。快速修复确实能够解决它——只要新加一行代码或者忽略那个列表上的最后一个条目，它就能够工做了。拙劣的代码工人会不假思索地改完代码，而后快速转向下一个问题。优秀的程序员会挖掘更深一层，尽力去理解为何这里必需要加一，更重要的是，他会想明白会产生什么其余影响。

Beware of land mines

在工做压力之下，不去深刻了解真正的问题以及可能的后果，就快速修改代码，这样只是解决表面问题，最终会引起大问题。短时间看，它彷佛是有效的。但从长远来看，经过几年的积累，代码里有着成千上万的补丁修复，在这样脏乱的代码中添加新的功能或修复Bug，会让开发者难逃脱发的噩运。

Don't Code in isolation

孤立很是危险，不要让开发人员彻底孤立地编写代码。若是团队成员花些时间阅读其余同事写的代码，他们就能确保代码是可读和可理解的，而且不会随意打补丁的代码。实行代码评审，不只有助于代码更好理解，并且是发现bug最有效的方法之一。

Use unit tests

另外一种防止代码难懂的重要技术就是单元测试。单元测试帮助你很天然地把代码分层，分红不少可管理的小块，这样就会获得设计更好、更清晰的代码。更深刻项目的时候，你能够直接阅读单元测试——它们是一种可执行的文档。有了单元测试，你会看到更小、更易于理解的代码模块，运行和使用代码，可以帮助你完全理解这些代码。

天使：“不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。”

切身感觉

• 在项目中，代码应该是很亮堂的，不该该由黑暗死角。
• 你也许不知道每块代码的每一个细节，或者每一个算法的每一个步骤，可是你对总体的相关知识有很好的了解。
• 没有任何一块代码被警惕线或者“切勿入内”的标志隔离开。

平衡的艺术

• 你必需要理解一块代码是如何工做的，可是不必定须要成为一位专家。只要你能使用它进行有效的工做就足够了，不须要把它看成毕生事业。
• 若是有一位团队成员宣布，有一块代码其余人都很难看懂，这就意味着任何人（包括原做者）都很难维护它。请让它变得简单些。
• 不要急于修复一段没能真正理解的代码。这种补丁的病症始于无形，可是很快就会让代码一团糟。要解决真正的问题，不要治标不治本。
• 全部的大型系统都很是复杂，所以没有一我的能彻底明白全部的代码。除了深刻了解你正在开发的那部分代码以外，你还须要从更高的层面来了解大部分代码的功能，这样就能够理解系统各个功能块之间是如何交互的。
• 若是系统的代码已经恶化，能够参考排除万难，奋勇前进一章

对事不对人

恶魔：“你在这个设计上投入了不少精力，为它付出不少心血。你坚信它比其余任何人的设计都棒。别听他们的，他们只会把问题变得更糟糕。”

你极可能见过，对方案设计的讨论失控变成了情绪化的指责——作决定是基于谁提出了这个观点，而不是权衡观点自己的利弊。咱们来看看对一个明显的错误有哪些常见的反应。

• 否认我的能力。
• 指出明显的缺点，并否认其观点。
• 询问你的队友，并提出你的顾虑。

第一种方法是不可能成功的。你那样指出问题根本不会对他的水平有任何提升，反而会致使他之后不再会提出本身的任何想法了。第二种方法至少观点明确，但也不会给多少帮助，甚至遭来反驳致使被打脸。而第三种方法，没有谴责，没有评判，只是简单地表达本身的观点。

在一个须要紧密合做的开发团队中，若是能稍加注意礼貌对待他人，将会有益于整个团队关注真正有价值的问题，而不是勾心斗角，误入歧途。咱们每一个人都能有一些极好的创新想法，一样也会萌生一些很愚蠢的想法。

Negativity kills innovation

负面的评论和态度扼杀了创新。咱们每一个人都会有好的想法，也会有不对的想法，团队中的每一个人都须要自由地表达观点。即便你的建议不被全盘接受，也能对最终解决问题有所帮助。不要惧怕受到批评。记住，任何一个专家都是从这里开始的。

你不须要很出色才能起步，可是你必须起步才能变得很出色。

集体决策确实很是有效，但也有一些最好的创新源于颇有见地的我的的独立思考。若是你是一个有远见的人，就必定要特别尊重别人的意见。咱们并非建议你限制会议决策，只是你不该该成为独断独行的首席架构师的傀儡。

能欣赏本身并不接受的想法，代表你的头脑足够有学识。

下面是一些有效的特殊技术：

• 设定最终期限：若是你正在参加设计方案讨论会，或者是寻找解决方案时遇到问题，请设定一个明确的最终期限，这样的时间限制能够防止人们陷入无休止的理论争辩之中，保证团队工做的顺利进行。同时应该现实一点：没有最好的答案，只有更合适的方案。设按期限可以帮你在为难的时候果断作出决策，让工做能够继续进行。
• 逆向思惟：团队中的每一个成员都应该意识到权衡的必要性。一种客观对待问题的办法是：先是积极地看到它的正面。而后再努力地从反面去认识它。目的是要找出优势最多缺点最少的那个方案，而这个好办法能够尽量地发现其优缺点，这也有助于少带我的感情。
• 设立仲裁员：在会议的开始，选择一个仲裁员做为本次会议的决策者。每一个人都要有机会针对问题畅所欲言。仲裁员的责任就是确保每一个人都有发言的机会，并维持会议的正常进行。仲裁员能够防止明星员工操纵会议，并及时打断假大空式发言。若是你本身没有积极参与此次讨论活动，那么最好退一步作会议的监督者。仲裁员应该专一于调停，而不是发表本身的观点（理想状况下不该在整个项目中有既得利益）。固然这项任务不须要严格的技术技能，须要的是和他人打交道的能力。
• 支持已经作出的决定：一旦方案被肯定了，每一个团队成员都必须通力合做，努力实现这个方案。每一个人都要时刻记住，咱们的目标是让项目陈工知足用户需求。客户并不关心这是谁的主意——他们关心的是，这个软件是否能够工做，而且是否符合他们的指望。结果最重要。设计充满了妥协（生活自己也是如此），成功属于意识到这一点的团队。工做中不感情用事是须要克制力的。

天使：“对事不对人。让咱们骄傲的应该是解决了问题，而不是比较谁的主意更好。”

切身感觉

• 一个团队可以很公正地讨论一些方案的优势和缺点
• 你不会由于拒绝了有太多却显得方案而伤害别人
• 也不会由于采纳了某个不甚完美（可是更好的）解决的方案而被人忌恨

平衡的艺术

• 尽力贡献本身的好想法，若是你的想法没有被采纳也无需生气。不要由于只是想体现本身的想法而对拟定的好思路多此一举。
• 脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不太可能发生或不太实际的情形去批驳它。这时，请先扪心自问：相似问题之前发生过吗？是否常常发生？
• 也就是说，你必须评判那些场景发生的可能性有多大。想要支持或者反驳一个观点，有时候你必须先作一个原型或者调查出它有多少的赞成者或反对者。
• 在开始寻找最好的解决方案以前，你们对“最好”的含义要先达成共识。在开发者眼中的最好，不必定就是用户认为最好的，反之亦然。
• 只有更好，没有最好。尽管“最佳实践”这个术语处处在用，但实际上不存在“最佳”，只有在某个特定条件下更好的实践。
• 不带我的情绪并非要盲目地接受全部的观点。用合适的词和理由去解释为何你不赞同这个观点或方案，并提出明确的问题。

排除万难，奋勇前进

恶魔：“若是你发现其余人的代码有问题，只要你本身内心知道就能够了。毕竟，你不想伤害它们，或者惹来麻烦。若是他说你的老板，更要格外谨慎，只要按照他的命令执行就能够了。”

假如要你修复其余人编写的代码，而代码很难理解也很差使用。你说应该继续修复工做，保留这些脏乱的代码呢，仍是应该告诉你的老板，这些代码太烂了，应该通通扔掉呢？

也许你会跳起来告诉周围的人，那些代码说多么糟糕，但那只是抱怨和发泄，并不能解决问题。相反，你应该重写这些代码，并比较重写先后的优缺点。动手证实（不要只是嚷嚷）最有效的方式，是把糟糕的代码放到一边，马上重写。列出重写的理解，会有助于你的老板（以及同事）认清当前形势，帮助他们获得正确的解决方案。

当发现问题时，不要试图掩盖这些问题。而要有勇气站起来，说：“我如今知道了，我过去使用的方法不对。我想到了一些方法，能够解决这个问题——若是你有更好的想法，我也很乐意听一听——但可能会花多些时间。”你已经把全部对问题的负面情绪哦爱猪脑后，你的意图很清楚，就是寻找解决方案。既然你提出你们努力来解决问题，那就不会有任何争辩的余地。这样会促进你们去解决问题。也许，他们就会主动走近，提供帮助。更重要的是，这显示出了你的真诚和勇气，同事你也赢得了他们的信任。

天使：“作正确的事。要诚实，要有勇气去说出实情。有时，这样作很困难，因此咱们要求足够的勇气。”

切身感觉

• 勇气会让人以为有点不自在，提早鼓足勇气更须要魄力
• 但有些时候，它是扫除障碍的惟一途径，不然问题就会进一步恶化下去。

• 鼓起勇气，能让你从恐惧中解脱出来

  平衡的艺术

• 若是你说天快要塌下来了，但其余团队成员都不赞同。反思一下，也许你说正确的，但你没有解释清楚本身的理由。
• 若是你说天快要塌下来了，但其余团队成员都不赞同。考虑一下，他们也许是对的。
• 若是设计或代码中出现了奇怪的问题，花时间去理解为何代码会是这样的。若是你找到了解决方法，但代码仍然使人费解，惟一的解决办法是重构代码，让它可读性更强。若是你没有立刻理解那段代码，不要轻易地否认和重写它们。那不是勇气，而是鲁莽。
• 当你勇敢的站出来时，若是受到了缺少背景知识的抉择者的地址，你须要用他们可以听懂的话语表达。“更清晰的代码”是没法打动生意人的。节约资金、得到更好的投资回报，避免诉讼以及增长用户利益，会让论点更有说服力。

• 若是你在压力下要对代码质量做出妥协，你能够指出，做为一名开发者，你没有职权毁坏公司的资产（全部代码）。