外观
01.高效软件开发之道、态度决定一切
约 4400 字大约 15 分钟
项目管理devops敏捷开发个人
2022-06-05
第1章：敏捷 - 高效软件开发之道
在软件开发领域里，在项目研发过程中出现的需求变化和挑战就是你在冲浪时要应对的海浪 - 它们从不停止并且永远变化，像波浪一样。在不同的业务领域和应用下，软件项目具有不同的形式,带来了不同的挑战。甚至还有鲨鱼以各种伪装出没。
软件项目的成败，依赖于整个项目团队中所有开发成员的技术水平，对他们的培训，以及他们各自的能力高低。就像成功的冲浪手一样，开发人员必须也是技术扎实、懂得掌握平衡和能够敏捷行事的人。不管是预料之外的波浪冲击，还是预想不到的设计失败,在这两种情况下敏捷都意味着可以快速地适应变化。
敏捷开发宣言：
- 个体和变互胜过过程和工具
- 可工作的软件胜过面面俱到的文档
- 客户协作胜过合同谈判
- 响应变化胜过遵循计划
虽然右项也有价值，但我们认为左项具有更大的价值。
敏捷开发宣言：一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。
开发需持续不断，切勿时续时断。这种持续前进的开发思想根植于敏捷方法中。它不但应用于软件开发的生命周期，还应用于技术技能的学习、需求采集、产品部署、用户培训等方面。它包括了软件开发各个方面的所有活动。
有些人对使用敏捷方法有顾忌，认为它只是另一种危机管理而已，事实并非如此。危机管理是指问题累积并且恶化，直到它们变得非常严重，以至于你不得不立即放下一切正在做的工作来解决危机。而这样又会带来其他的负面影响，你就会陷入危机和恐慌的恶性循环中。这些正是你要避免的问题。
敏捷的修炼之道
敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。
下面将扼要讲述它的具体含义，以及敏捷的团队应该采取什么样的工作和生活方式。
首先，它要整个团队一起努力。敏捷团队往往是一个小型团队，或者是大团队分成的若干小团队（10人左右)。团队的所有成员在一起工作，如果可能，最好有独立的工作空间，一起共享代码和必要的开发任务，而且大部分时间都能在一起工作。同时和客户或者软件的用户紧密工作在一起，并且尽可能早且频繁地给他们演示最新的系统。
要不断从自己写的代码中得到反馈，并且使用自动化工具不断地构建(持续集成)和测试系统。在前进过程中，你都会有意识地重构代码。
要以迭代的方式进行工作：确定一小块时间(一周左右）的计划，然后按时完成它们。给客户演示每个迭代的工作成果，及时得到他们的反馈(这样可以保证方向正确)，并且根据实际情况尽可能频繁地发布系统版本让用户使用。
第2章：态度决定一切。软件开发是一项智力劳动。在此章，我们会讲解如何用敏捷的心态开始工作，以及一些有效的个人习惯。这会为你使用敏捷方法打下扎实的基础。
第3章：学无止境。敏捷项目不可能坐享其成。除了开发之外，我们还要在幕后进行其他的训练，虽然它不属于开发工作本身但却对团队的发展极其重要。我们还将看到，如何通过培养习惯来帮助个人和团队成长并自我超越。
第4章：交付用户想要的软件。如果软件不符合用户的需求,无论代码写得多么优美，它都是毫无用处的。这里将会介绍一些客户协作的习惯和技巧，让客户一直加入到团队的开发中，学习他们的业务经验并且保证项目符合他们的真正需求。
第5章：敏捷反馈。敏捷团队之所以能够顺利开展工作，而不会陷入泥潭挣扎导致项目失败，就是因为一直使用反馈来纠正软件和开发过程。最好的反馈源自代码本身。本章将研究如何获得反馈，以及如何更好地控制团队进程和性能。
第6章：敏捷编码。为满足将来的需求而保持代码的灵活和可变性，这是敏捷方法成功的关键。本章给出了一些习惯，介绍如何让代码更加整洁，具有更好的扩展性,防止代码慢慢变坏,最后变得不可收拾
第7章：敏捷调试。调试错误会占用很多项目开发的时间——时间是经不起浪费的。这里将会学到一些提高调试效率的技巧，节省项目的开发时间。
第8章：敏捷协作。最后，一个敏捷开发者已经能够独挡一面，除此之外，你需要一个敏捷团队。这里有一些最有效的实践有助于黏合整个团队,以及其他一些实践有助于团队日常事务和成长。
敏捷工具箱
Wiki: Wiki是一个网站，用户通过浏览器，就可以编辑网页内容并创建链接到一个新的内容页面。Wiki是一种很好的支持协作的工具，因为团队中的每一个人都可以根据需要动态地新增和重新组织网页中的内容,实现知识共享。关于Wiki的更多详情,可查阅《Wiki之道》这篇文章[LCO1].
版本控制：项目开发中所有的产物 - 全部的源代码、文档、图标、构建脚本等，都需要放入版本控制系统中,由版本控制系统来统一管理。《版本控制之道使用Subversion》[Mas05].
单元测试：用代码来检查代码,这是开发者获得反馈的主要来源。在本书后面会更多地谈到它,但要真正知道框架可以处理大部分的繁琐工作,让你把精力放到业务代码的实现中。
自动构建：不管是在自己的本地机器上实现构建,还是为整个团队实现构建，都是全自动化并可重复的。因为这些构建一直运行,所以又称为持续集成。和单元测试一样,有大量的免费开源产品和商业产品为你提供支持《项目自动化之道》[Cla04]介绍了所有自动构建的技巧和诀窍(包括使用JavaLamps ).
最后，Ship It ! [RG05]一书很好地介绍了怎样将这些基本的开发环境实践方法结合到一起。
第2章：态度决定一切
态度非常重要，包括你的和团队的。专业的态度应该着眼于项目和团队的积极结果，关注个人和团队的成长，围绕最后的成功开展工作。集中精力，你是为做事而工作。
软件项目时常伴有时间压力 - 压力会迫使你走捷径，只看眼前利益。但是，任何一个有经验的开发者都会告诉你，欲速则不达。
对事不对人，会让工作更加有效。
反馈是敏捷的基础。需要勇气去排除万难，奋勇前进。
做事
过程符合标准并不意味结果是正确的。敏捷团队重结果胜于重过程。
指责不会修复bug。把矛头对准问题的解决办法，而不是人。这是真正有用处的正面效应。
切身感受
勇于承认自己不知道答案，这会让人感觉放心。一个重大的错误应该被当作是次学习而不是指责他人的机会团队成员们在一起工作，应互相帮助，而不是互相指责。
平衡的艺术
- 如果你没有犯过任何错误，就说明你可能没有努力去工作。
- 开发者和质量工程师（QA）争论某个问题是系统本身的缺陷还是系统增强功能导致的，通常没有多大的意义。与其如此,不如赶紧去修复它。
- 如果一个团队成员误解了一个需求、一个API调用，或者最近一次会议做的决策，那么,也许就意味着团队的其他成员也有相同的误解。要确保整个团队尽快消除误解。
欲速则不达
要理解开发过程，尽管我们在谈论理解代码，特别是在修改代码之前一定要很好地理解它，然而同样道理，你也需要了解团队的开发方法或者开发过程。
你必须要理解团队采用的开发方法。你必须理解如何恰如其分地使用这种方法，为何它们是这样的，以及如何成为这样的。
孤立非常危险，① 不要让开发人员完全孤立地编写代码。如果团队成员花些时间阅读其他同事写的代码，他们就能确保代码是可读和可理解的。阅读代码的频率越高越好。② 实行代码复审，不仅有助于代码更好理解，而且是发现bug最有效的方法之一。③ 防止代码难懂的重要技术就是单元测试。单元测试帮助你很自然地把代码分层，分成很多可管理的小块，这样就会得到设计更好、更清晰的代码。
不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。
平衡的艺术
- 你必须要理解一块代码是如何工作的，但是不一定需要成为一位专家。只要你能使用它进行有效的工作就足够了,不需要把它当作毕生事业。
- 不要急于修复一段没能真正理解的代码。这种+1/-1的病症始于无形，但是很快就会让代码一团糟。要解决真正的问题，不要治标不治本。
- 所有的大型系统都非常复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。
对事不对人
对一个明显的错误的正确的反应。询问你的队友，并提出你的顾虑。
好的软件开发作品和好的软件设计，都需要大量的创造力和洞察力。分享并融合各种不同的想法和观点，远远胜于单个想法为项目带来的价值。
必须把重点放在解决问题上，而不是去极力证明谁的主意更好。
团队中的每个人都需要自由地表达观点。即使你的建议不被全盘接受，也能对最终解决问题有所帮助。不要害怕受到批评。你不需要很出色才能起步，但是你必须起步才能变得很出色。
设定最终期限。没有最好的答案，只有更合适的方案。设定期限能够帮你在为难的时候果断做出决策,让工作可以继续进行。
逆向思维。团队中的每个成员都应该意识到权衡的必要性。先是积极地看到它的正面,然后再努力地从反面去认识它。目的是要找出优点最多缺点最少的那个方案。
设立仲裁人。仲裁人的责任就是确保每个人都有发言的机会，并维持会议的正常进行。
支持已经做出的决定。一旦方案被确定了(不管是什么样的方案)，每个团队成员都必须通力合作，努力实现这个方案。
平衡的艺术
- 尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气。不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。
- 脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不太可能发生或不太实际的情形去批驳它。这时，请先扪心自问：类似问题以前发生过吗？是否经常发生？
- 这样说是不够的：我们不能采用这个方案，因为数据库厂商可能会倒闭。或者：用户绝对不会接受那个方案。你必须要评判那些场景发生的可能性有多大。想要支持或者反驳一个观点，有时候你必须先做一个原型或者调查出它有多少的同意者或者反对者。
- 在开始寻找最好的解决方案之前，大家对“最好”的含义要先达成共识。在开发者眼中的最好，不一定就是用户认为最好的，反之亦然。
- 只有更好，没有最好。尽管“最佳实践”这个术语到处在用，但实际上不存在“最佳”，只有在某个特定条件下更好的实践。
- 不带个人情绪并不是要盲目地接受所有的观点。用合适的词和理由去解释为什么你不赞同这个观点或方案，并提出明确的问题。
排除万难，奋勇前进
你应该重写这些代码，并比较重写前后的优缺点。动手证明(不要只是嚷嚷）最有效的方式，是把糟糕的代码放到一边，立刻重写。列出重写的理由，会有助于你的老板（以及同事)认清当前形势，帮助他们得到正确的解决方案。
当然，你也会很担心向团队其他成员说明这个问题，以争取更多的时间和帮助。
你已经把所有对问题的负面情绪抛诸脑后，你的意图很清楚，就是寻找解决方案。这显示出了你的真诚和勇气，同时你也赢得了他们的信任。
要有勇气向其他的项目成员、老板或者客户解释你的不同观点。你要不顾一切，向着正确的方向奋力前进。
切身感受
勇气会让人觉得有点不自在，提前鼓足勇气更需要魄力。但有些时候，它是扫除障碍的唯一途径，否则问题就会进一步恶化下去。鼓起你的勇气，这能让你从恐惧中解脱出来。
平衡的艺术
- 如果你说天快要塌下来了，但其他团队成员都不赞同。反思一下，也许你是正确的，但你没有解释清楚自已的理由。
- 如果你说天快要塌下来了，但其他团队成员都不赞同。认真考虑一下，他们也许是对的。
- 如果设计或代码中出现了奇怪的问题，花时间去理解为什么代码会是这样的。如果你找到了解决办法，但代码仍然令人费解，唯一的解决办法是重构代码,让它可读性更强。如果你没有马上理解那段代码,不要轻易地否定和重写它们。那不是勇气，而是鲁莽。
- 如果你在压力下要对代码质量作出妥协，你可以指出，作为一名开发者，你没有职权毁坏公司的资产(所有的代码)。