编程的97件事——8、童子军军规

童子军军规

童子军有一条规则:“总是保证营地在离开时比发现时整洁。”如果你发现地上是乱的,不论是谁弄乱的,你都要收拾干净。你要有意的为一下批露营者改善营地环境。实际上这条规则,是童子军之父,Robert Stephenson Smyth Baden-Powell写的:“努力留下一个比你发现时更好的世界。”

如果我们在编码时也新遵循一条类似的规则:“总是保证模块签入时比签出时整洁”。无论模块的原作者是谁,如果我们总是作出一些努力,无论多么微小,去改进模块,结果会怎样?

我认为如果我们都能遵守这条简单的规则,我们就能看到我们的软件系统不再无情地恶化下去。取而代之的是,我们的系统会发展地越来越好。我们会看到团队将系统看作一个整体来关注,而不是每个成员只关心自己负责的那一小部分。

我认为这样的要求并不过分。你不必保证每个你要签入的模块是完美的。你只要让这个模块签入时比签出时好一点点。当然,这意味着你为这个模块添加的代码必须是干净的。这也意味着你签入模块前至少整理了一个模块中其他的部分。你也许只是改进了一个变量的命名,或是将一个长方法分割成了两个更小的方法。你可能中断了一个循环依赖,或增加了一个接口以解耦规则对细节的耦合。

坦白来说,这就像平常的得体做法一样——就像你上了厕所要洗手,或者要将垃圾扔进垃圾筒而不是地上。实际上留下混乱的代码就像乱扔垃圾一样,是不被社会所接受的。它本就不该发生。

不仅如此,关注我们自己的代码是一回事,关注团队的代码完全是另外一回事。团队成员互相帮助,互相整理代码。他们遵守童子军军规是因为这对每一个人都好,而不只是对自己有好处。

by Uncle Bob


The Boy Scout Rule

The Boy Scouts have a rule: "Always leave the campground cleaner than you found it." If you find a mess on the ground, you clean it up regardless of who might have made the mess. You intentionally improve the environment for the next group of campers. Actually the original form of that rule, written by Robert Stephenson Smyth Baden-Powell, the father of scouting, was "Try and leave this world a little better than you found it."

What if we followed a similar rule in our code: "Always check a module in cleaner than when you checked it out." No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result?

I think if we all followed that simple rule, we‘d see the end of the relentless deterioration of our software systems. Instead, our systems would gradually get better and better as they evolved. We‘d also see teams caring for the system as a whole, rather than just individuals caring for their own small little part.

I don‘t think this rule is too much to ask. You don‘t have to make every module perfect before you check it in. You simply have to make it a little bit better than when you checked it out. Of course, this means that any code you add to a module must be clean. It also means that you clean up at least one other thing before you check the module back in. You might simply improve the name of one variable, or split one long function into two smaller functions. You might break a circular dependency, or add an interface to decouple policy from detail.

Frankly, this just sounds like common decency to me — like washing your hands after you use the restroom, or putting your trash in the bin instead of dropping it on the floor. Indeed the act of leaving a mess in the code should be as socially unacceptable as littering. It should be something that just isn‘t done.

But it‘s more than that. Caring for our own code is one thing. Caring for the team‘s code is quite another. Teams help each other, and clean up after each other. They follow the Boy Scout rule because it‘s good for everyone, not just good for themselves.

by Uncle Bob

时间: 2024-10-20 04:30:05

编程的97件事——8、童子军军规的相关文章

编程的97件事——6、在重构之前

在重构之前 每个程序员都会在某些时候需要重构已存在的代码.但在这样做之前请想想下面的问题,这会省去你和其他人很多时间(和痛苦): 开始重构的最佳时机是审查代码库和代码库的测试代码的时候.这时你明白当前代码的优点和不足,这可以确保你重构时保持代码的优秀特性并避免上个版本犯下的错误.我们都以为自己会比现存系统做得更好,结果并没有更好,还可能更糟-这是因为我们没有从前人的错误中吸取教训. 避开推到重来的诱惑.复用的代码越多越好.无论这些代码多么丑陋,这些代码毕竟是被测试和复查过的.丢弃旧代码,尤其是产

编程的97件事——2、应用函数式编程原则

Apply Functional Programming Principles Functional programming has recently enjoyed renewed interest from the mainstream programming community. Part of the reason is because emergent properties of the functional paradigm are well positioned to addres

编程的97件事——3、多问“用户会怎么做”(你不是用户)

Ask "What Would the User Do?" (You Are not the User) We all tend to assume that other people think like us. But they don't. Psychologists call this the false consensus bias. When people think or act differently to us, we're quite likely to label

软件架构师应该知道的97件事

1.客户需求重于个人简历客户需求至上.为了自己的简历更炫而采用新技术是沽名钓誉,往往事与愿违. 2.  简化根本复杂性 ,消除偶发复杂性根本复杂性指的是问题与生俱来的.无法避免的困难.偶发复杂性是人们解决根本复杂性的过程中衍生的.分析问题好比拨云见月.水落石出.架构师的责任在于解决问题的根本复杂性,同时避免引入偶发复杂性. 3.  关键问题可能不是出在技术上大多数项目是由人完成的,人才是项目成败与否的基础.学会尊重他人,给予团队成员充分的信任,是聪明的架构师获得成功必须掌握的核心技能.团队同心,

软件架构师应该知道的97件事(一)

1 客户需求重于简历和个人兴趣 ,选用合适的技术,保证服务的稳定性,易用性. 2 明白业务的关键点,简化根本复杂性,避免为了解决问题引入偶发可用性. 3 技术只是项目的一部分.沟通,合理有效的沟通很重要. 4 沟通的简明清晰,开明的方式,与团队里面的人合作 . 5 架构决定了应用的性能 6 了解需求的意义,事件的意义,为目标努力,而不仅仅是需求.把最优价值的摆在首位 7 架构师最重要的是沟通,起立发言,考虑完善推动事情. 8 故障终究会发生.合理设计故障防范模型. 9 需求讨论或者其他的讨论,也

软件架构师应该知道的97件事(二)

11 架构师需要宏观上设计,微观上了解业务代码.宏观视野和微观视野 12 没有万能的解决方案,需要存在情景意识 13 提前考虑性能问题,考虑未来的变化 14 架构:系统建模,接口设计,模块划分,套用设计模式,优化性能.需要平衡:安全,易用,产品支持,发布管理,部署方式. 需要平和技术需求和各类业务需求 15 功能测试,避免草率的提交任务. 16 技术可能唯一.业务是不断演化的,没有一成不变的业务系统 17 业务为重.既要考虑架构,也要考虑业务. 18 先保证方案简单可以,再考虑通用型和复用性 1

JAVA编程“性能说”(java编程需要做的26件事)

转载于 http://www.csdn.net/article/2012-06-01/2806249 最近的机器内存又爆满了,除了新增机器内存外,还应该好好review一下我们的代码,有很多代码编写过于随意化,这些不好的习惯或对程序语言的不了解是应该好好打压打压了. 下面是参考网络资源总结的一些在Java编程中尽可能要做到的一些地方. 1.尽量在合适的场合使用单例 使用单例可以减轻加载的负担,缩短加载的时间,提高加载的效率,但并不是所有地方都适用于单例,简单来说,单例主要适用于以下三个方面: 控

关于多线程编程您不知道的 5 件事

虽然很少有 Java? 开发人员能够忽视多线程编程和支持它的 Java 平台库,更少有人有时间深入研究线程.相反地,我们临时学习线程,在需要时向我们的工具箱添加新的技巧和技术.以这种方式构建和运行适当的应用程序是可行的,但是您可以做的不止这些.理解 Java 编译器的线程处理特性和 JVM 将有助于您编写更高效.性能更好的 Java 代码. 在这期的 5 件事 系列 中,我将通过同步方法.volatile 变量和原子类介绍多线程编程的一些更隐晦的方面.我的讨论特别关注于这些构建如何与 JVM 和

在开发第一个Android应用之前需要知道的5件事:

你能否详细讲述一下,在开发Android应用过程中每一阶段要用到的技能和编程语言? 建立一个Android应用程序可以归结为两个主要技能/语言:Java和Android系统.Java是Android的通用编程语言,但是Android还包括学习用于app界面设计的XML语言,学习Android概念,以及从Java编程角度运用这些概念. 学了Java和XML之后,再用Android理念将两者连接起来. 我也有分享过一些学习Activities和 Fragments等的Android相关知识.我最喜欢