程序员修炼之道 12：项目启动前

研究是为了理解

已于 2024-09-23 10:02:06 修改

阅读量808

点赞数 10

CC 4.0 BY-SA版权

分类专栏：读书笔记 # 程序员修炼之道文章标签：编程思维

于 2024-09-22 15:06:36 首次发布

本文链接：https://blog.csdn.net/zhzht19861011/article/details/142345695

读书笔记同时被 2 个专栏收录

61 篇文章

订阅专栏

程序员修炼之道

13 篇文章

订阅专栏

不记录，等于没读。

这里是我阅读《程序员修炼之道》这本书的记录和思考。

在项目的最早期，你和团队需要了解 需求 。

需求之坑

需求 很少停留在表面。通常情况下，它们被埋在层层假设、误解和政治之下。更糟糕的是，无人确切知道自己想要什么。在现实世界中，得到任何事物的精确规范，即使不是完全不可能，也是非常罕见的。

而程序员的最有价值所在，就是帮助人们理解他们想要什么。

典型的客户会带着需求来找我们。需求有时用业务术语表达，有时用技术术语表达。新手经常犯的错误是，把这种需求照单全收，然后实现对应方案。根据我们的经验，最初的需求声明，往往并非绝对要求，客户可能没有意识到这一点。

我见到的技术人员很少说“不”：只要有人提出需求，他们就开始尝试解决。这可能是产品越做越差的主要原因。

一个例子。
你收到一个新的需求：为登录界面增加 短信登录 功能。

在这里插入图片描述
停一秒，你有大把机会发现问题：

验证码应该有一个 有效时间 ，比如 5 分钟。不然一个短信码可以重复验证。
验证码应该有 发送频率限制 ，比如两次发送间隔不小于 1 分钟。限制用户频繁点击。
应该有每日 发送次数限制，设置每个手机号每天可以接收验证码的最大次数。防止有人恶意拿登录界面当短信轰炸机。（因为手机号是可以随意输入的）
应该检查是 否是真人操作，比如图形验证。防止有人恶意使用机器人刷短信，造成短信费用升高。
错误输入次数 限制，过多错误尝试后，应锁定账号一段时间。因为验证码一般是 4 位或者 6 位，在验证码有效时间内，会有暴力破解验证码的可能。
应能解决 短信延时 问题。比如客户点击 “发送验证码”后，半天收不到短信，然后 1 分钟限制时间到了之后，又点击 “发送验证码”，这个时候收到第一次的验证码，但是这个验证码已经作废了，所以出现验证码登录不上的问题。可以在上一条验证码有效期内，再次请求验证码，发送的验证码不变。
要有好的 用户界面，比如重发机制提醒做成倒计时，让用户知道何时可以再次请求发送验证码。
如果用户来自不同国家，要考虑不同国家手机号码规格，短信到达速度差异，支持不同的语言。

这就是我们所做的。当某些事情看起来很简单的时候，我们却会去寻找那些 边缘情况（正常情况下不太可能出现，但特殊条件下会出现的场景），并就其不胜其烦地问人。

需求是一个过程，可以先制造出产品原型，并让用户先用用看。在与客户讨论的过程中，迅速修改原型，然后问客户：是不是更像这样。

了解需求的另一个方法是和用户一起工作，以便从用户角度思考。

有时用户提出的需求并不准确，需要针对更普遍的情况做开发。比如用户说“只有员工的主管和人事部门可以查看该员工的记录”，实际上，你应该能明白，客户要的是“只有授权用户才能访问员工记录”。

需求文档不是为客户准备的：

客户并不确切知道自己想要什么。
客户从不阅读规范。

需求文档是为计划准备的：团队中的开发人员需要知道即将做什么。可以写在真实（或虚拟）索引卡上。

需求文档切忌过于具体。好的需求是抽象的，由准确反映业务需求的语句组成。需求不是架构；需求无关设计，也非用户界面；需求就是需要的东西（Requirements are need）。

许多项目失败，都可以归咎于不断扩大功能范围。让客户知道多增加一个功能带来的影响。

处理无法解决的难题

面对难题，需要确定 真正的约束条件，而不是想象的约束条件。

戈耳狄俄斯曾经打了一个无法解开的绳结，解开之人就可以当亚细亚之王。亚历山大见到这个绳结之后，拿出剑将其劈成两半。只要对要求做了一点不同的解释，一些明显的约束条件并非真的约束条件。

面对难题，需要认识到你所受到的 约束 和你所拥有的 自由度。笔不离纸，画三段直线，把下图的所有点连起来，且最后回到起点。
在这里插入图片描述
你必须挑战任何先入之见，并评估它们是否是真实的、硬性的约束。一个解法是：

我们太容易忽视潜在的解决方案。当面对一个棘手的问题时，把你面前所有可能的解决途径都列举出来。不要忽略任何东西，无论听起来多么无用或愚蠢。列举并逐条解释为什么不能选择这条路。你确定吗？你能证明吗？