我们需要软件工艺

前言

软件开发并不是一项简单机械的活动，将其看作一种工程学实践是不恰当的。因此，我们需要给软件开发一个更好的隐喻：软件工艺。 



上一篇我们提到，似乎一些对生命生死攸关的项目，人们要用一切资源来保证其不出错的项目我们应该使用软件工程的方式工作，那么一些出错代价较低的软件呢？似乎我们大量的软件项目都是这一类型的项目，我们应该用什么来对待呢? 答案是：软件工艺。那么接下来让我们来了解一下软件工艺到底给我们带来了什么不一样的工作和思维方式吧。





什么是工艺

提到工艺我们会想到传统手工艺，我们对匠人的尊敬。人们对工艺品的赞叹和喜爱，让好的艺术品真的可以经年累月，永放光彩并且价值连城。而这一切的核心是什么？我想那就是要有一颗匠心，要有匠心精神。软件行业一样需要这样的匠心和匠人。下面让我们看看软件行业的匠心精神都包括哪些。

• 要成为软件工匠

• 良好的声望 

工匠很在意声望，把每一个软件项目都当成影响自己声誉的作品来对待。为保持自己的声誉对软件作品精雕细琢。软件工匠同时也在意合作客户的声望，差劲的客户会成为软件项目的毒药。 另一个声望是在推荐其他工匠或者被其他工匠推荐给新的客户的时候，会以个人声誉为担保，所以这种推荐会更加真实可靠负有责任。

• 对自己的作品负责 

持续的改进自己的作品，而不是希望尽快脱手，从用户反馈中不断学习，持续精进，这不仅能让作品更优秀，也能够提升软件工匠的自身技艺。

• 拒绝丑陋 

不能接受自己写出丑陋的软件，甚至不能接受丑陋的中间状态。对作品苛刻的要求，持续不断的更新完善以达到这个极致。以维护软件为荣耀，例如开源社区，只有得到已有工匠的认可的人才可以获得维护软件的权力。一切都是从“为维护而设计”出发，不做一锤子买卖。



• 活到老学到老

• 拒绝丑陋 ，谦虚，向别人学习 

作为工匠，首先要保持一个谦虚的心态，你不可能擅长所有领域，但是和不同领域的工匠一同工作会让你有不一样的收获；

• 勇于承认错误 

软件工匠在和自己的客户一起工作的时候，会发现一些知识的缺失或者理解偏差，承认错误并及时调整，才能保证你的作品无限接近完美。

• 独立思考 

作为匠人的你需要忘记老师讲的“金科玉律”，不教条，在创作的过程中敢于尝试，好的作品往往是在灵感爆发的那个瞬间，而那是你的老师无法交给你的，是属于你的创新时刻。

• 博闻强记，善于遗忘 

记住本质，忘记细枝末节，因为匠人要不断更新知识，为作品注入新的活力。

• 给软件作品注入持续的生命力  

艺术品是要持续打磨的，<蒙娜丽莎的微笑>画了3年时间。<最后的晚餐>也画了3年。作为软件工匠的我们对自己的软件作品有多少耐心这样细细打磨呢？会不会早早的就像扔掉垃圾一样希望赶快脱手，感觉我们做过的软件项目并不是我们的呕心力作而是被逼无奈的临时小样。

软件工艺的管理方式  

和软件工程的科学管理方法不同，软件工艺讲的是小规模精英团队，工匠、技师、学徒三个不同级别的工匠彼此学习，互相激励，一同工作。学徒跟着工匠或者技师学习技艺，技师可以游走拜不同工匠为师继续工作，来获得新的知识，提升自己的技能。当技师积累了足够经验之后会在某个领域开创出属于自己的独特技艺，这时新的工艺就此诞生。

一般精英团队规避不大，因为要手把手的教授技艺保证质量，项目时间不超过1年。软件工艺的管理方式将工匠们当作知识工作者而不是体力劳动工人，这种环境会更激发创新。

关注与用户的关系  

好的工匠因为要保证自己的软件产品的成功，需要和客户保持良好的协作关系，因为好的客户和团队一起工作，项目中会遇到很多艰难的决策，彼此的信任、尊重、能够降低决策难度，因为用户与工匠团队的目标是一致的：用户要获得优秀的软件来提升业务价值；工匠们制造优秀的软件来建立自己的声望。  

另一个工匠们关注与客户关系的原因是因为，直接沟通能够减少中间人传话，减少需求失真，彼此获得最直接的反馈，这样开发者就不会认为客户都是忘恩负义、冥顽不灵的“庸户”，而客户也不会觉得开发者都是反应缓慢、自高自大的家伙。

“足够好”的谬误  

在软件工程的工作方式中，我们往往会有下面的想法：

• "我们能找的bug都找了，系统还有其他的bug，但是找不到了，我们尽力了。"

• "我们知道有bug，但是修复他们的时间和资金上都不划算。"

• "修复一个bug可能引发更多的bug，存在Risk。"  

上面这些在软件工匠那里是不会存在的，他们承担不起失败带来的声望损失，从内心也不能容忍这种将就的行为。为了让作品可以让更多的人满意，工匠们甚至愿意为10%的用户打磨需求使得他们达到120%的满意程度。因为工匠们知道，要让大量用户满意的最有效的方式是针对一个人单独设计让其满意。

软件工程 VS 软件工艺  

那么软件工艺能给我们软件项目带来什么不同呢？让我们来看看他与软件工程一些思想的对比:  

软件工程 VS 软件工艺 

1. 培训->遵循 VS 交流创新

2. 命令控制管理者 VS 善于处理多方关系的管理者

3. 确定过程 VS 经验过程

4. 大规模团队 VS 精英团队

5. 足够好 VS 匠心精神

6. 客户合作 VS 合同谈判

7. 老式的、几年必须更换的“遗留软件” VS 坚固的、长期使用的软件

8. 同时开始更多的项目 VS 更早的交付可用的软件

9. 一门糊口的工作 VS 传授技艺和自我实现

总结  

软件工艺更像是希望软件开发者把自己当成一个工匠来要求，对作品要注入生命而不是一个流水线上的装卸工人。软件工艺不是软件工程的代替者，因为我们无法将软件工程的方式规模缩减后应用到小型项目，也无法将软件工艺的方式简单扩大来应用到大型项目。从软件工艺的核心思想来看，他更关注的是软件开发这种技艺本身，知识工作者本身的价值，创造力是不能被自动化代替的，我很同意一句话：软件开发和画家、音乐家一样都是创造性的艺术工作。  

我还发现软件工艺的思维本身也和敏捷思想不谋而合：

• 敏捷中的特性团队也属于精英团队。

• 敏捷4个价值观和软件工艺追求竟然也是如此一致：

• 个体与互动高于流程和工具——工匠和技工、学徒之间的交流学习不正是这种个体之间交互。

• 可工作的软件高于详尽的文档——以简洁为美，设计“可维护的软件”来应对变化，持续更新软件，让软件获得持续的生命力。

• 客户的合作高于合同谈判——注重与用户的关系，因为客户的反馈是工匠持续学习并保持声誉重要因素。

• 响应变化高于遵循计划—— 工匠不会让软件寿终正寝，作为自己的艺术品，他会想办法赋予它更长的生命力，持续更新应对需求变化。



最后用一句书中的话作为结束：

软件开发理应有其乐趣。否则，开发过程就是错的。



原文引用

• [我们需要软件工艺]