3.6 举例说明出至少一个软件匠艺实践如何应用于你的工作
http://manifesto.softwarecraftsmanship.org/#/zh-cn
Manifesto for Software Craftsmanship 软件匠艺宣言
Raising the bar.
提高标准
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
作为有理想的软件工匠,我们一直身体力行,提升专业软件开发的标准,并帮助他人学习此工艺。通过这些工作,我们建立了如下价值观:
Not only working software, but also well-crafted software
不仅要让软件工作,更要 精益求精
Not only responding to change, but also steadily adding value
不仅要响应变化,更要 稳步增加价值
Not only individuals and interactions, but also a community of professionals
不仅要有个体与交互,更要 形成专业人员的社区
Not only customer collaboration, but also productive partnerships
不仅要与客户合作,更要 建立卓有成效的伙伴关系
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
也就是说,左项固然值得追求,右项同样不可或缺。
不仅要让软件工作,更要 精益求精
“你怎么知道代码能否正常运行呢?很简单,测试!一遍遍地测,翻来覆去、颠来倒去地测主,使出浑身解数来测!
要用这些自动化单元测试去测多少代三呢?还要说吗?全部!全部都要测!
我是在建议进行百分百测试覆盖吗?不,我不是在建议,我是在要求!你写的每一行代码都要测试。完毕!
这是不是不切实际?当然不是。你写代三是因为想执行它,如果你希望代码可以执行,那你就应该知道它是否可行。而要知道它是否可行,就一定要对它进行测试。
但是有些代码不是很难测试吗?是的,但之所以很难测试,是因为设计时就没考虑如何测试。唯一的解决办法就是要设计易于测试的代码,最好是先写测试,再写要测的代码。这一方法叫做测试驱动开发(TDD)。
专业开发人员对自己的代码和测试极有把握。”
我的经验:精益求精是一个永无止境的过程,在我的工作中,十几年才意识到软件工程是一个相当严谨细致的工作,而把自己做到“严谨细致”,需要把自己的心安静下来,慢下来,反复的练习,不断的保持和巩固这种做事情的方式,从而变得”专业“。而工作和生活中的每一件事情,大抵如此。
不仅要响应变化,更要 稳步增加价值
“(用户/业务)对功能的设想,其实经不起电脑前真刀真枪的考验。
东西画在纸上与真正做出来,是不一样的。业务方看到真正的运行情况时就会意识到,自己想要的根本不是这样的。一看到已经满足的需求,关于到底要什么,他们就会冒出更好的想法——通常不是他们当时看到的样子。
在工作中,有一种现象叫观察都效应,或者不确定原则。每次你向业务方展示一项功能,他们就获得了比之前更多的信息,这些新信息反过来又会影响他们对整个系统的看法。
专业开发人员(也包括业务方)必须确认,需求中没有任何不确定因素。
这件事唯一有效的办法就是编写自动化的验收测试。它们是无可挑剔的需求文档。”
我的经验:最近在跟进的一个项目,是需要总行的测试团队按照我们的需求来改造系统。我自以为每次的需求都交待的很清楚了,然而每次Release就完全给我放了一个大招——做出来一个我完全不想要的系统。所以这个完全不理解用户需求的团队,要重新带起来了(可能就是更细心、更耐心,手把手的去教——参见第一条),就是我最近的工作重点了。如果一个团队不能响应变化,持续的交付价值,简直就是噩梦。
不仅要有个体与交互,更要 形成专业人员的社区
我的经验:在企业中,我做的更多的是在不同的敏捷团队之间建立社区环境,例如,敏捷社区、测试人员的社区、TDD社区、前端技术社区等。
发起和收集一些话题让大家一起参与讨论和交流,引起共鸣,彼此支持。
社区活动容易受到日常工作的影响,比如工作特别紧张的一段时间,就较难组织起来。
另外,就是组织方要多考虑活动的形式、内容、深度等,让大家愿意付出这个时间来参与,并能有所收获。
不仅要与客户合作,更要 建立卓有成效的伙伴关系
我的经验:近几年,我负责一个兼职的开发团队,我们开发了一个维护测试数据的产品。因为这是来自于测试团队本来的痛点和问题而设计的产品,所以在开始的两年产品迅速的受到了大家的喜爱和欢迎,产品的客户就是我们自己,我们当然是自己的伙伴,非常熟悉和理解我们面临的问题、以及如何解决。满足了自己的需求之后,这个产品的发展就有些力不从心了。来自业务方的需求,通常我们接受到的就会隔着一层距离,不能真实的理解和满足用户的需要,产品就很难有生命力。“建立桌有成效的伙伴关系”,才能做出用户需要的产品。
参考书:
1. 《代码整洁之道——程序员的职业素养》Robert C. Martin