如何帮助团队更好地写代码

我们发现很多开发者似乎认为烂代码最终并没有带来太多伤害。

如果你数一下有记录在案的因代码问题而失败的项目个数，那么，我们认同这个数字并不会很大。但是，你不必创造真正的灾难导致软件项目损失大量金钱。

作为一名架构师，你可以做什么来帮助团队更好地写代码呢？

1．烂代码真的比好代码更昂贵

我们不清楚你的情况，但我们肯定认为写烂代码真的比写好代码更加昂贵。至少，我们认为在生命周期比较长，业务影响比较大的项目里是更加昂贵的。

听起来可能很简单，当使用烂代码（即创建、测试和维护它）的成本超过业务模型可以忍受的代价时，项目才会因它而败。同样地，如果公司设法使代码的成本保持在极低水平，没有项目会因为代码问题而失败。

这就是痛点。

你如何定义最终影响代码成本的因素？哪些动作组成了“写代码”：编码、构建、调试？你应该把测试当作一个附加的按需的特性吗？文档呢？缺陷修复呢？

有时候，管理者只是投机取巧，通过雇佣廉价开发者或砍掉测试和文档等缩减开发成本的手段来解决问题。

不幸的是，这些管理者没有意识到他们只是缩减了产生可能（但不一定）工作的代码的成本。产生刚好可以工作的代码只是问题的一面。现在，需求经常改变，复杂性不断增长，更糟糕的是，复杂性通常仅在行进的过程中才能完全了解。在这种情况下，产生代码只是影响总体成本的一个因素。代码维护和进化才是最大因素。

好的架构师都很清楚，只有写得好的代码，对软件原则和语言特性有很好的了解，恰当使用模式和实践，以及注重可测试性才能解决代码维护的问题。这使得编码比产生刚好可以工作的代码更加昂贵，但比维护和进化刚好可以工作的代码就廉价得多了。

2．使用工具辅助编码

我们认为成功的项目基于两个因素：懂得领导艺术的管理层，以及懂得代码质量的开发团队。

就编码而言，不一定有时间让开发者现在写代码，然后在往后的某个时间修复和整理它。每个开发者都会发誓，第二遍处理永远都不会发生，即使发生，也不会造成很大影响。

如果想在第一次就写出更好的代码，最好使用代码辅助工具。这些工具通常集成在IDE里，可以简化常见开发任务，使开发者的工作进展得更快，可以写出更好的代码。在最坏的情况下，代码可以写得更快，留有一些时间做第二遍处理。

自动完成、惯用设计提示（即根据语言或框架建议的惯用方式写代码）、代码检查、支持键盘输入的预定义代码片段，以及支持预定义和自定义模板等服务都是加快开发以及确保一致性和更好、更干净代码的实践。

代码辅助工具使开发得以持续发展，只需两次点击就能极大地改善你所写的代码的质量。代码辅助工具可以发现重复和没用的代码，使重构体验变得愉快，简化导航和检查，以及强制使用某些模式。

比如说，所有开发者原则上都同意适当的命名规范对于代码的可读性和质量来说是很关键的。但是，当你意识到你应该重命名一个命名空间或者一个方法时，你就会面临至少要在你自己的整个代码库里这样做的问题。这么疯狂的工作原本需要你自己在极短的时间内完成，现在可以由代码辅助工具代劳了。

ReSharper是最受欢迎的代码辅助工具。若想了解更多，可以访问http://www.jetbrains.com/resharper。其他类似工具有来自DevExpress的CodeRush，以及来自Telerik的JustCode。

但是，你要记住，代码辅助工具不是魔法，它们所做的只是让你付出更低的代价和更少的努力就可以写出更好和更干净的代码。除此以外，一切仍然取决于你。你在重构过程里以及在代码编辑阶段操作工具。

3．如何告诉别人他们的代码很烂

假设你发现你团队里有人在写烂代码。你会如何跟他们说？

这里涉及一些心理学方面的东西。你不想表现得尖锐，你也不想伤害任何人；与此同时，你不想其他人的工作在某一时刻伤害到你。沟通是关键，不是吗？所以你需要找到最佳方式在别人的代码很烂时告诉他们。

总体而言，我们认为让人注意到某些代码的最佳方式是不经意地问为什么用这种方式来写。你可能会找到更多背后的动机，不管是信息有误，态度不好，技能局限，或者你所不知的约束。

在没有确凿证据之前，不要断定你的编码方式更好。那么，你只需对问题代码背后的真正动机表现出好奇和兴趣，并且表达出想了解更多的意愿，因为如果换了你会用不同的方式来编码。

4．使每个人都变成更好的开发者

下面总结一下让团队写出好代码的金科玉律：

针对代码，而不是写代码的人。但通过写代码的人来尝试改善代码。

你可以通过某种方式修复任何一块烂代码。但是，当这种情况发生时，你不要责怪写代码的人；你可以帮助写代码的人改进他做事的方式。如果你可以这样做，你至少可以得到两方面的好处：你的团队得到一个更好的开发者，你的团队可能得到一个更快乐更有动力的开发者。你使这个开发者感觉更像英雄，因为他现在有了完成他的工作的最佳方式。

为了改进某些方面，每个人都需要培训和实践。最有效的方式是以敏捷的方式结合培训和实践。但是，我们经常看到一些公司购买了培训服务，让他们在短短几天内完成和交付，然后期望人们在接下来的星期一就能投入工作。事情并不是这样的，至少不会如此有效。

这让我们想起几年前非常流行的一个短语：在职培训。它指的是一边学习、一边做实际的工作。这起因于拥有不同技能的人在同一个团队里协同工作。

5．在签入代码之前检查一下

你的公司可能会有最好的编码标准，但你怎样实施它们？信任开发者是好的，但验证可能更加有效。结对编程和常规设计审核是检查代码库健康程度的具体方式。在一次典型的设计审核里，你可以和大家一起开放地讨论某些示例代码。这些代码可以是来自项目的真实代码片段，它是某些参与者写的，或者为了避免牵涉到情绪问题，也可以是为了阐明你想表达的观点而专门写的一段代码。

为了实施编码标准，你也可以考虑对你的代码控制系统采用签入策略，不管是Microsoft Team Foundation Server（TFS）、TeamCity或者其他系统。这个过程可以自动化吗？

今天，几乎任何源代码管理工具都提供针对签入文件实施控制的方式。比如说，TFS支持封闭签入（Gated Check-ins）。封闭签入本质上就是根据规则签入。换句话说，文件只有在符合既定规则的时候才会被系统接受。当你选择创建封闭签入时，TFS会要求你指定一个现有的构建脚本。只有在构建成功完成的时候，这个文件才会签入。

在TFS里，一个构建只是有一个MSBuild脚本，它可以使用各种任务来定制。TFS自带一些可以集成的预定义任务。比如说，你会找到代码分析（以前的FxCop）任务和一个运行选定测试列表的任务。因为MSBuild任务只是一个实现了约定接口的注册组件，所以你可以自己创建新的任务，添加自己的验证规则。

值得注意的是，JetBrains的ReSharper，前面提到的其中一个代码辅助工具，在它的最新版里提供了一组免费的命令行工具，可以在自定义的MSBuild任务里检测重复代码以及执行常见检查，包括根据你定义的自定义模板执行自定义检查。有趣的是，你甚至不需要ReSharper许可证就能使用这个命令行工具。若想了解更多关于ReSharper命令行工具，可以访问http://www.jetbrains.com/resharper/features/command-line.html。

6．值得欣喜的是，这个项目不需要英雄

开发者倾向于超越自我，至少在他们深藏的梦想里，希望他们每周可以工作超过80小时来拯救项目，让客户满意，并且成为管理者和开发者同伴眼里的真英雄。

我们想改编诗人和剧作家Berthold Brecht的一句名言：我们总想活在不需要英雄主义的世界里。对英雄的需要以及由此而来的高压力通常源自不足的期限。

有时候，期限从项目一开始就不公平了。在其他情况下，期限是在进展的过程中被证明为 错的。

当这种情况出现时，情感上容易默许，但对指出不公平的期限的害怕产生对英雄的需要。沟通以及把问题挑明是一种坦诚，也是恢复更多控制以及降低压力的有效途径。

在软件里，我们可以说，你感到压力是因为迫在眉睫的最后期限或者缺少所需技能。如果及时沟通，两种情况都能很好解决。

我们不想要英雄，虽然我们自己也做过几次英雄（我们猜你们中的大多数也做过），我们认为英雄主义是一种例外情况。在软件里，例外通常是要避免的。

7．鼓励实践

几乎任何运动的专业运动员每天都会花上好几个小时来实践，到底是为什么呢？开发者和专业选手之间是否存在某种相似之处？看情况而定。

一种看法是开发者每天在工作中实践，并且没有与其他开发者竞争。有鉴于此，有人可能会得出没有相似之处的结论，因此没有必要实践。

另一种看法是选手经常练习基本动作，以便他们可以自动地重复这些动作。定期回顾面向对象基础、设计模式、编码策略以及某些领域的API可以使这些知识记忆得更牢固，回忆得更 快速。

注意

写过多本ASP.NET的书，也实践过验证和成员系统，时隔多年，Dino最近在使用基于角色的ASP.NET系统时感到问题很大。“老兄”，他最近跟我说，“我上次处理角色是什么时候？”最终，创建基于角色的UI基础设施以及相关的成员系统耗费比预期更多的功夫。

8．持续改变是工作的一部分

持续改变是描述现代软件项目动态的有效方式。软件项目始于一个想法或者一个相对模糊的业务想法。架构师和领域专家需要收集一些正式的需求，使原来的想法或业务需要更加明显。

根据我们的经验，大多数软件项目就像活动目标，而需求就是把目标到处移动的东西。每次添加一个新的需求，这个环境以及系统的动态（在没有这个特性的情况下可以正常工作的设计）也会改变。需求的改变是因为问题领域有了更好的了解，问题领域变化很快，或者时间压力的问题。

需求波动（Requirements Churn）这个术语通常用来表示软件项目里的需求变化率（功能性需求、非功能性需求，或者两者都有）。高需求波动将会为BBM提供理想的藏身之所。

每当处理新的需求都重新审视整个系统的架构是切实避免BBM的唯一办法。重新审视整个系统的架构确实需要重构，也确实具有较大成本。这里的重点是找到保持低成本的方法。重构是其中一个很难察觉会为项目带来价值的东西。未能重构会导致这些价值流失，这很糟糕。

注意

Twitter在2010年上线，当时的Web前端充满了客户端功能。大量功能是通过在动态下载的JSON数据之上即时生成HTML来提供的。在2012年，Twitter重构了整个系统，选择了服务器端渲染。这是一个架构层面的重构，毫无疑问是昂贵的。但他们认为这是必要的，并且持续服务数亿用户，不管是对还是错，反正它能工作。

作为一名架构师，架构和设计重构都是关键工具。架构师无法控制历史以及业务场景和现实世界的发展。架构师需要一直做出调整，避免重新构建。这正是重构派上用场的地方。

本文节选自《Microsoft.NET企业级应用架构设计（第2版）》

内容简介

软件架构是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。本书就是一个关于软件架构的坚实、可重用且易于访问的知识库。

本书分 4 个部分来介绍软件架构相关的内容。其中，基础知识部分为软件架构打下基础；设计架构部分关注表现层和业务层；支撑架构部分涵盖 3 个可用于构建各种子领域的支撑架构；基础设计部分介绍了多样化持久化、NoSQL数据存储、SQL、Entity Framework和关系型数据库等内容。

本书着重介绍软件架构相关的内容，非常适合软件架构师和想成为软件架构师的人阅读，而且首席开发者和各种.NET应用程序的开发者也能从本书获益。

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF91EB0000013FF0B0F910731B66

软件开发 架构设计

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。