公司分享会的思考：软件开发是什么事情

起因

程序员节前夕，公司内的研发中心邀请了 Thoughtworks 洞见的「八叉」老师进行分享。

这次分享的主题是 Learn long and learn popular，内容关于程序员职业成长。

八叉老师从三个方面讲解了程序员职业生涯的历程。

因为篇幅的原因，本文仅总结第一部分「软件开始是一件什么事情」的内容，并附带笔者的部分观点。

老师首先通过枚举知识传递的方式来诠释软件在知识传递的作用。

建筑在人类很长一段时间用来承载知识，即建筑就是知识的另外一种形态，关于这一点，笔者表示认可，我们通常看见某个建筑，自然会联想到建筑本身的人文历史，就像蜿蜒的长城、壮丽的故宫以及久经沧桑的圆明园。

软件也是知识载体的一种，人们通常只会使用软件，但往往忽略了与「使用」伴生的知识承载能力，软件承载的知识就是「企业如何赚钱」的答案，在软件内写得一清二楚。

知识是在消费中产生的价值，而不是在生产的那一刻产生的价值。

有趣的一点是，老师提到「文章如果没有被他人阅读，就不会产生价值」，这让笔者有所领悟——价值传播的重要性比产出的重要性高。

「机器运行以及同事阅读理解代码时，代码才会产生价值」，笔者是非常认可的，我们需要为「人」写代码，写出容易理解的代码，这才能让代码更容易被消费，而不是编写「魔法咒语」。

编写代码追求「正确性」是最基本的要求，更长远的要求是让代码在未来一段时间内保持能被消费的状态。

老师提出的关键点是——我们需要从消费者（调用方）来编写代码，这时候我们就会用各种技巧把代码写得完美。

构造软件的过程，对于个体是学习的过程，对于团队是知识管理的过程，因为软件只有在消费那一刻才能产生价值。

我们在软件开发的过程就是学习和理解别人产生的知识。

从管理者的角度上讲，软件开发的过程更像是找一堆人写一本书。

老师谈及高效工作的内容是借助需求以及解决需求的任务来说明的。

如果你（程序员）不能把给定的需求分解成任务，那么这个需求你不会干。

如果程序员无法将需求拆解成任务，要么是需求不理解，要么是架构不理解，就这两方面。

而高效工作就是将拆解出的任务进行时间评估，如果掌握所有技术细节，那么这个时间评估可以到分钟。

可以通过预估的时间和实际花费的时间来确定技术掌握的程度，预估时间越接近实际花费时间，可以认为对技术的掌握程度高。

一个程序员如果会这个需求，会明确告诉需求方多少个小时能做完，至于直言不讳地说需要三四天时间开发的，那大概率是不会做这个需求的。

其实笔者目前的状态也是这样，对于所有的需求，统一评估的是「三四天」，最主要的原因借口是笔者目前刚开始工作，无论是技术还是对业务的理解都没有达到以「小时」为标尺的工时评估能力。

至于开发过程中出现的 Bug，八叉老师认为产生 Bug 的主要原因离不开两点，第一是需求没理解，第二是技术不到位。

提高技术的途径并不是依赖写代码，而是学习，去拓宽知识面，就像跑步运动员并不是把全部精力放在跑步上，而是积极地锻炼肌肉。

笔者认为八叉老师说的道理其实就是尽可能去巩固基础，学习知识从而获得更优秀的写代码能力，好的代码是积极学习的副产物。

最后八叉老师提到程序员的职业发展依赖的是学习时间，并非工作时间，越早培养学习的习惯，到后面就越轻松。

笔者有幸找到一本有关开发的书《开发者体验：探索与重塑》。

该书与八叉老师所说的「消费代码知识」有所关联，内容是探讨提高开发者体验的方法，感兴趣可以阅读电子版。