软件工艺八荣八耻（2014版）

[Joseph Yao]

三年前，我闲来无事写了个软件工艺的八荣八耻 http://weibo.com/1887029092/yrflBedWF。经过这几年的学习，又有了很多新的体会和感想。借着去厦门飞机误点的机会，我弄了个新版本，算是一个总结吧。

软件工艺八荣八耻（2014版）
以测试驱动为荣，以不写单元测试，先写代码为耻
以积极重构为荣，以代码臭味为耻
以浮现设计为荣，以复杂建模，滥用模式为耻
以小步消灭遗留代码为荣，以重构项目为耻
以结对编程、代码共有为荣，以单兵作战为耻
以持续集成为荣，以只会用Jenkins为耻
以需求协作为荣，以只按照规格说明书办事为耻
以编程练习、交流分享为荣，以应付工作、闭关修炼为耻

欢迎大家的反馈

谢谢，

Joseph

[Joseph Yao]

--
--
您收到此信息是由于您订阅了 Google 论坛“Scrum Gathering”论坛。
要在此论坛发帖，请发电子邮件到 scrumga...@googlegroups.com
要退订此论坛，请发邮件至 scrumgatherin...@googlegroups.com
更多选项，请通过 http://groups.google.com/group/scrumgathering?hl=en 访
问该论坛
网站: http://scrumgathering.cn
微博: http://weibo.com/scrumgathering

---
You received this message because you are subscribed to the Google Groups "Scrum Gathering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumgatherin...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hippoom Chou]

以持续集成为荣，以只会用Jenkins为耻

这句是看到什么症状提出的？

--
您收到此邮件是因为您订阅了Google网上论坛中的“agileshanghai”论坛。
要取消订阅此论坛，并停止接收其发来的电子邮件，请发送电子邮件至agileshangha...@googlegroups.com。
如需了解更多选项，请访问https://groups.google.com/d/optout。

[Joseph Yao]

好问题，下面是我的想法，刚好准备微信上面分享出来。：）

关于持续集成和“只会Jenkins”，我再多说两句。不理解“持续集成”就去用Jenkins，我觉得就是“为了工具而用工具了”。更何况，“只会Jenkins”其实对团队做持续集成的伤害非常之大。

首先，只会Jenkins的团队，不明白持续集成需要一个快速的反馈和验证，通常的情况就是一个Job（构建和测试）运行超过10分钟，长的甚至有几个小时的。在这种情况下，团队如果不去思考如何加快反馈和测试运行的速度，时间长了大家都不愿意频繁提交代码了，更谈不上用代码来沟通了。另外，由于运行慢的测试通常都是一些集成测试或者端到端的测试，其运行环境搭建复杂。有不少团队图省事，索性就让那些测试只在Jenkins的服务器上面运行。结果，程序员无法在自己的开发机上运行这些测试，导致提交代码批量更大，提交次数进一步减少。这样还能叫“持续集成”吗？

另外运行时间长的Jenkins作业一旦失败，如果团队没有形成一个持续集成的工作守则，大家不会放下手上工作第一时间去修复的话，即便是有一些失败提醒机制（如邮件和CI灯），久而久之，大家也会对这些信息麻木，最后干脆忽略了。更有甚者，将Jenkins保持成功的时间作为一个考核指标，直接导致团队干脆不写测试和更不频繁的提交代码。其实，Jenkins一直保持失败或者成功中的某一个状态是没有意义的。重要的是，在持续集成的前提下，Jenkins失败了团队可以在最短的时间里面恢复，并且找到原因和可以改进的地方。

总之，团队完全可以在不用Jenkins（或者其他CI系统）的情况下面，做到持续集成。Jenkins只是团队在开展了持续集成的相关实践之后的一个辅助工具罢了。

[hippoom Chou]

明白了 ：）

之前看过一篇文章，http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html，很有意思。

P.S. 突然发现文章一开始图片中的那只塑料鸡很眼熟…… 

[Joseph Yao]

感谢你的文章分享，我收藏了回头看看。：）

那只鸡外表虽然想Odd-e办公室的那只，不过工作原理大概不同吧。。。

--
您收到此邮件是因为您订阅了Google网上论坛中的“agileshanghai”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到agileshangha...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[伍斌_Ben]

这篇文章真的很棒！道出了CI中最重要的事情。感谢分享！

Ben Wu

于 2014年03月17日 17:38, hippoom Chou 写道:

明白了 ：）

之前看过一篇文章，http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html， 很有意思。

P.S. 突然发现文章一开始图片中的那只塑料鸡很眼熟…… 

2014-03-17 17:22 GMT+08:00 Joseph Yao <joseph.ya...@gmail.com>:

好问题，下面是我的想法，刚好准备微信上面分享出来。：）

关于持续集成和“只会Jenkins”，我再多说两句。不理解“持续集成”就去用Jenkins，我觉得就是“为 了工具而用工具了”。更何况，“只会Jenkins”其实对团队做持续集成的伤害非常之大。

首先，只会Jenkins的团队，不明白持续集成需要一个快速的反馈和验证，通常的情况就是一个Job（构建和测试）运 行超过10分钟，长的甚至有几个小时的。在这种情况下，团队如果不去思考如何加快反馈和测试运行的速度，时间长了大家都 不愿意频繁提交代码了，更谈不上用代码来沟通了。另外，由于运行慢的测试通常都是一些集成测试或者端到端的测试，其运行 环境搭建复杂。有不少团队图省事，索性就让那些测试只在Jenkins的服务器上面运行。结果，程序员无法在自己的开发 机上运行这些测试，导致提交代码批量更大，提交次数进一步减少。这样还能叫“持续集成”吗？

另外运行时间长的Jenkins作业一旦失败，如果团队没有形成一个持续集成的工作守则，大家不会放下手上工作第一时间 去修复的话，即便是有一些失败提醒机制（如邮件和CI灯），久而久之，大家也会对这些信息麻木，最后干脆忽略了。更有甚 者，将Jenkins保持成功的时间作为一个考核指标，直接导致团队干脆不写测试和更不频繁的提交代码。其 实，Jenkins一直保持失败或者成功中的某一个状态是没有意义的。重要的是，在持续集成的前提下，Jenkins失 败了团队可以在最短的时间里面恢复，并且找到原因和可以改进的地方。

总之，团队完全可以在不用Jenkins（或者其他CI系统）的情况下面，做到持续集成。Jenkins只是团队在开展 了持续集成的相关实践之后的一个辅助工具罢了。

On Mar 17, 2014, at 5:20 PM, hippoom Chou <hip...@gmail.com> wrote:

以持续集成为荣，以只会用Jenkins为 耻

这句是看到什么症状提出的？

2014-03-17 12:17 GMT+08:00 Joseph Yao <joseph.ya...@gmail.com>:

三年前，我闲来无事写了个软件工艺的八荣八耻 http://weibo.com/1887029092/yrflBedWF。 经过这几年的学习，又有了很多新的体会和感想。借着去厦门飞机误点的机会，我弄了个新 版本，算是一个总结吧。

--
您收到此邮件是因为您订阅了Google网上论坛中的“agileshanghai”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到agileshangha...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

-- 
Cheers
Bin WU (Ben) 伍斌
Software Craftsman, 独立匠艺程序员
wub...@gmail.com, (+86) 13911116027, wubinben.com, 微信wechat: bjdp_org

 

[于彩荣]

不如原来的郎朗上口了.
 

发件人： Joseph Yao [mailto:joseph.ya...@gmail.com]
发送时间： Monday, March 17, 2014 12:17 PM
收件人： agiles...@googlegroups.com <agiles...@googlegroups.com> :
抄送： scrumga...@googlegroups.com <scrumga...@googlegroups.com> :
主题： 软件工艺八荣八耻（2014版） :
 

--
您收到此邮件是因为您订阅了Google网上论坛中的“agileshanghai”论坛。
要取消订阅此论坛，并停止接收其发来的电子邮件，请发送电子邮件至agileshangha...@googlegroups.com。
如需了解更多选项，请访问https://groups.google.com/d/optout。

********************************************************************************************************************************
The information in this email is confidential and may be legally privileged. If you have received this email in error or are not the intended recipient, please immediately notify the sender and delete this message from your computer. Any use, distribution, or copying of this email other than by the intended recipient is strictly prohibited. All messages sent to and from us may be monitored to ensure compliance with internal policies and to protect our business.
Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is taken to accept these risks.

收发邮件者请注意：
本邮件含保密信息，若误收本邮件，请务必通知发送人并直接删去，不得使用、传播或复制本邮件。
进出邮件均受到本公司合规监控。邮件可能发生被截留、被修改、丢失、被破坏或包含计算机病毒等不安全情况。
********************************************************************************************************************************

[Joseph Yao]

是的 :( 我一开始也纠结这个事情，不过权衡了一下，还是以达意和总结的方式来写了。

[Joseph Yao]

分享一下我在微信群中的回复

感谢大家的反馈，我来澄清一下写这个“八荣八耻”的想法吧。“八荣八耻”对我来说是一个目标，是我当下努力的方向。它与敏捷宣言和软件工艺宣言不同，后者是价值观，是对目标的支撑。大家可以共享价值观，但是各自的目标不尽相同。所以，这是我不想把“荣耻”之说改成“高于”的原因所在。另外，目标变化的机会高于价值观变化，将来目标变了，我会再更新的。

“八荣八耻”作为一个目标，并不打算让每个人都接受。如果它可以影响到“早期粉丝”（Early Adopter），让这些人有所行动；又如果它可以刺激到“早期大众”（Early Majority），让这些人提高这些方面的兴趣，我觉得这样足够了。

中国程序员无数，但又有多少人可以算得上是一个对自己代码负责的程序员呢？很多团队和经理整天嚷嚷敏捷不落地，却不知道那些“耻”，或是知道了还要以各种理由说那些“荣”做不到，这不是自欺欺人是什么？“八荣八耻”是一个目标，团队可以逐步精进和改善，就算无法在当下达到所有的“目标”也无妨。知耻且愿意改变，足矣。“八荣八耻”也不是团队唯一的目标，他们如果找到自己的目标，不断的去改善，那就更好了。

为什么以“重构项目”为耻？

“重构项目”是否有意义这个问题，我经常会在有关重构的培训中被问到。我的答案很肯定，“团队通常不应该这样做”。当然，有很多程序员说的“重构”其实是“重写”，只是因为“重构”这个词说起来比较好听，大家都喜欢用。真正的“重构”是保证代码现有行为不改变的情况下来改善代码的设计和结构。而“重写”则是不能保证代码现有行为不变的，因为过程中不写测试或者一次代码修改过于庞大。下面要讨论的“重构项目”是以“重构”为初衷的。
很多团队要做“重构项目”，主要原因是了解到自己代码中有很多“臭味”，有无法忍受的感觉，于是就想到要通过“重构项目”这个方法来偿还技术债务。这个初衷虽好，但是有违团队应该关注业务价值的核心理念。试问，“重构项目”的业务价值到底在哪里？因为重构是不改变现有代码行为的，所以这个项目无法带来任何新功能（新的业务价值）。甚至，重构时是不应该修Bug的（功能和非功能Bug），因为Bug是代码现有行为的一部分，如果你修了Bug，你又怎么知道其他人因为这个Bug所做的变通方案依然还工作呢？既然如此，如果团队告诉业务人员“我们要做一个三个月的重构项目，虽然它不会带来任何直接的业务价值，但是做完之后我们的代码会更容易维护。。。”，你觉得业务人员听到之后会同意吗？更何况，有些团队即使开始做这样的“重构项目”，他们也并非小步重构代码，而是根据自己的理解重新做一个所谓的“符合业务的架构设计”，然后再花三个月的时间把它实现出来。这样根本就是“重写”了。“重构”和“重写”有个很大的差别，就是前者给了程序员很多学习和提高的机会，后者则很少或者根本没有学习机会。
如果“重构项目”不靠谱，那我们该如何在遗留代码的基础上工作呢？很简单，通过TDD，重构等手段来“小步消灭遗留代码”。如果你有新需求要做，那么先找到要修改的代码在哪里（修改范围越小越好），然后设法隔离代码的依赖，为原有逻辑补上单元测试并重构原有代码，最后通过TDD把新的需求加上去。这种做法既保证了交付业务价值，又偿还了必要的技术债务，达到团队和业务人员的双赢。坚持这种方法工作下去，团队就会慢慢获得一些没有技术债务的代码（下图中的红色圈圈）。而剩下的代码则可以被分为两类，有技术债务（如没有对应测试）但是稳定的遗留代码，和没有或者很少用户会使用到的代码。这两种代码都是不需要重构和添加单元测试的（不需要 = 没必要 + 做了没价值）。如果说遗留代码是一个坑的话，只要团队坚持“小步消灭”的做法，其实不用填满这个坑，团队就能从里面跳出来。