为什么写代码是一件很爽的事情?

为什么写代码是一件很爽的事情?

我的看法是：

• 及时反馈 —— 超级无敌的及时反馈
• 确定性强 —— 与代码打交道，确定性强
• 有成就感 —— 解决问题，或克服困难的成就感
• 被需要感 —— 如果自己的创作，还能服务于他人，爽上加爽(被需要感)

因为这些感觉/感受，写代码成为了一件很爽，甚至会上瘾的事情。其实会上瘾的事情，通常也有这些特质。

软件交付的上下游

写代码是整个软件交付过程的一环，当然软件交付是整个产品的一环，产品又可能是公司战略的一环。我们就只把上下文限界在软件交付的过程中。稍作抽象，软件交付是在解决问题，用某些技术(代码)来解决某些人的某些问题。

从定义问题，到找出解决方案，再到实现，那大约会就出现了”上下游“的概念。

顺流而下

从问题，到解决方案，再到实现，如果我们从以下几个维度来观察：

• 不确定性
• 反馈周期
• 无形/有形
• 人的问题/程序的问题

就会发现趋势：

(1) 不确定性 - 从高到低：

不确定性是因为变化导致的，而且是不规律的变化(如果变化是规律的，那就是可预测的，不确定性也就大大降低了。)

我们经常说市场在变化，需求在变化，甚至是人在变化，这些变化导致了大量的不确定性。从找到/定义问题，到制定解决方案，再到实现，不确定性的趋势，是由高到低的。

(2) 反馈周期 - 从长到短：

在问题阶段，客户/用户提出一个问题/请求，到这个问题得到合理验证性的回答，这个中间是需要一段时间的;而且，很多这个阶段的问题，都只能给出假设性的回答，或者没有回答，只能等到产品上线之后才能知道其中一些。

等到了最后的实现阶段，不断拆解Release -> Feature -> Story -> AC -> Task -> TDD, TDD的反馈环就不言而喻了吧。

(3) 从无形到趋近于有形：

在物理世界里，当然软件也是无形的;不过在数字化的世界里，可以工作和运行的软件就是有形的了。

某个问题，某些想法和感受，通过文字或者图片表达出来，以此来找到解决方案，再通过计算机程序语言来实现变成可工作的软件，这个过程是无形到有形的转化。

(4) 从人的问题转为了程序的问题：

Ta有什么期望?现在的体验是什么样的?有什么其他的没有说出来的诉求?会不会受到什么影响而改变决策?这些都是典型的人的问题，不一定有确切的答案，有时候甚至是Ta自己也不知道。

程序的问题则不一样，这个地方出错了，一定是有原因的，某个地方的逻辑一定出了问题，我会找到原因的。

所以，从问题到实现，我们一开始偏重人的问题，到最后逐渐转化为解决程序的问题。

上游的蝴蝶

上游对下游的影响是显著，而又数量级递增的，就像“蝴蝶效应”一样。上游的蝴蝶扇动了翅膀，可能会对下游产生剧烈影响。不过，倒也不用太担心，因为软件交付的下游影响比蝴蝶效应要可控一些，预测性比较强。

(1) 上游的Problem：

• 通常涉及到的人数比较少;
• 通常是在各种会议或者一对一的对话中，来识别，分析和定义的。
• 需要一定程度地定义问题：问题是什么(期望是什么?现在的体验是什么)，是谁的问题?

(2) 中游的Solution：

• 通常涉及到的人也不多(会远低于下游的Implementation)
• 是在给定问题或上下文的基础之上;如果给定的问题或上下文有误，那Solution就出问题;Solution阶段也会做问题/上下文的确认。
• 通常是线下工作，但是需要在各种会议或者一对一的对话中，来反复修正(技术实现角度，安全角度，一致性约束等)
• 比较多”纸上谈兵“，经验主义

(3) 下游的Implementation：

• 交付团队都上了
• 多数团队成员直接面对的是各种Feature/Story卡
• 日常交付工作(Release/Sprint/Story,Tech,Bug)
• ”沙场秋点兵“ - 安排合适的人解决合适的问题
• 有些工作会追溯回上游的Solution, Problem阶段

(4) 上游的"蝴蝶"，很重要

通过上面的分析，可以看到，上游的”蝴蝶"很重要，扇动翅膀的威力很大。

我们自然是希望更有经验的人来做上游的”蝴蝶”：

• 可以和客户在各种会议上，"谈笑风生"
• 需要(扯皮)的时候，能为团队Fight客户
• 可以给下游的信息，简约而不简单

项目里谁适合呢?有经验的PM, BA, TL被选中了!

如果客户方有技术/架构师参与到项目交付中的时候，TL就跑不脱了。

为什么不写代码是件”不爽”的事

非彼无我，非我无所取。

那不写代码很会失去哪些写代码的能获得的快乐呢：

• 及时反馈 —— 超级无敌的及时反馈(删掉
• 确定性强 —— 与代码打交道，确定性强
• 有成就感 —— 解决问题，或克服困难的成就感
• 被需要感 —— 如果自己的创作，还能服务于他人，爽上加爽(被需要感)

及时反馈 &确定性强，这两个肯定是没有(或者大幅降低)了。

那成就感，和被需要感呢?

既然加了一个“感”字，那就说明这个东西，就是“主观的”，我说有就有~

如果感受不到成就感和被需要感，那就去寻找，创造，记得向外看(可以参看之前的博客: "拼命的工作有人教 快乐的工作没人教")

那我不写代码，得到的啥?

是会议、PPT与扯皮吗?就这?

【本文是专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】

新闻名称：为什么写代码是一件很爽的事情?
新闻来源：http://www.shufengxianlan.com/qtweb/news19/379219.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联