为什么需要提前撰写Spec文档

Joel on Software(中文名叫《Joel软件随想录》)算得上是一本旧书了,但里面的建议和讨论,真的是历久弥新。特别是,Joel是个有趣、牛逼的家伙:前微软Excel的职员、Stack Overflow的创始人、Trello的创始人,以及他和他的boyfriend走入了婚姻殿堂。这本书,是Joel自己blog文章的一个精选集。

Joel在这本书里谈到了很多技术性的观点,高屋建瓴地从思想方法上去讨论如何看待程序、看待公司、看待构建过程。著名的The Joel Test也出自于此。

这本书我很早就知道,但一直没有机会亲自阅读。最近读了几章,便爱不释手。按理说,我应该将这本书读完后再写点评论。可是,它已经如此优秀,让我在这个阶段就想要开始对它做一些介绍和吹捧。

很遗憾,自己读这本书还是晚了些。要是能够在最开始学习技术的时候就读到,想必能少走不少弯路。以我自己的观点来看,要掌握任何一个领域的技术,一个很重要的点就是一定要聆听大师的指导。如果你运气够好在自己身边遇到了一位大神,你可以直接向他请教。而如果没有这样的运气,那自己便需要多花费点功夫,去找大师写的文章和著作阅读,特别是那些关于review和观点的著作。因为,对于一个初学者来讲,刚进入一个领域,他有且只能看到繁复的细节,并不知道该以何种方式在脑海中把这些凌乱的碎片,系统、有条理地在脑海中组织起来。所以,阅读大师的这些综述性的著作,其目的,就是要在脑海中建立正确的看待这个领域的思维框架。

Joel关于Specification文档撰写的讨论,就是一个很好的例子。对大部分不合格的programmer来讲,写文档、写注释是一件无足轻重、讨厌至极的事情。在他们眼中,唯有代码是真正值得关心的东西,因为只有代码才可以让计算机工作啊,而一堆论述性的文档,写出来也无法被运行,那不就是浪费时间吗?!

而对另一群程序员来讲,代码恰恰是最后的、水到渠成的结果性的东西,不是你应该花费大量时间耕作的东西。对他们来讲,如果你能够写出清晰、细致的文档,代码自然就会优质卓越。如同揠苗助长这个故事的寓意,你无法通过把秧苗拔高,来加速秧苗的成长,你能做的,是更好地耕耘、施肥,尽力提供促进植物生长的环境。单纯地把精力花费在代码的细节上,就是在强制性地拔高秧苗,希望通过最直接的方式,来加速你项目的完成。而写文档,则是提前为后面复杂的代码提供良好的生长环境——清晰准确的逻辑。在这样的牢实的基础上,你的项目自然可以快速成长。

大部分做技术的人,会过分地注重勤于动手,而忘记了更重要的一步——先动脑。在他们看来,“开大会、打嘴炮、写文档”,都是一些business上的该死的流程,都是在务虚,不务实。由于已经在脑海中定下“无用”的论调,自然更是没有机会去理解其中的精髓。

“开大会、打嘴炮、写文档”,如果用讽刺的话来讲,就是“纸上谈兵”。可是,还有另一个褒义的描述——沙盘演练。对于任何一个项目来讲,前期的需求确认,是极其重要的。因为它是后续所有流程的根基。流程的更改、方向的变更,如果发生在技术开发的过程中,其损害的成本非常巨大,你不得不调整构架、重新组织甚至删除你已投入大量精力的工作。而如果这个事情发生在似乎不怎么有用的“开大会、打嘴炮、写文档”呢?那无非就是多耗费一点口水,重新写一行文字罢了。

撰写spec文档,就好比是画家最开始在画板上勾勒的辅助线。粗糙的一横、一竖,潦草的正方形框、椭圆形脑袋,不一而足。而如果你去观察刚学画的小朋友,大多有一个共同特征:几乎无法经受住描绘细节的诱惑,一开始就精细地刻画眼睛、嘴巴、肌肉的纹路。而最后的结果也是理所当然的四不像,错位、扭曲、畸形的五官与大小各异的四肢组合。通常,老师会花费大量的时间去纠正初学者这种从局部出发的坏习惯,让他们逐渐适应、掌握从整体的框架出发,再逐步深入细节的技巧。

写代码和写文档的关系,就是这样精致描绘细节和简单勾勒草图的关系。

当你所写的项目稍微多涉及几个现实的事务,其业务逻辑就不会如你现象中的那样简单。例如写一个用户登录的输入框,乍一看,似乎没什么精细复杂的地方,于是大摇大摆地动手写起代码来。行至途中,通常会发现各种小问题,前面忘记一个验证数据,后面忘记一个记录cookie,搞得自己狼狈不堪。可如果你肯多花费一点时间,将spec文档写好,把每一个流程图、状态图庙会清楚,就等于是为后面的代码撰写提前做了一次沙盘演练,能让你成竹在胸。

而另一方面,软件开发是协作性的事物,仅仅是团队工作中的一个环节。你对代码的理解,往往只是代表你自己的个人意见,难保与你合作的产品经理、老板、其他部门会有不同看法。难道要把整个项目都写完,才去征求他们的意见吗?!

这就是提前撰写spec文档的另一个好处:你可以在写代码之前,就把流程理解记录下来,让项目相关人士提前审阅,从而以最小的成本,提前修正方向性的争论和问题。

近期回顾

叫兽的逻辑 | #Metoo
不会谈
编程语言吐槽之Java与C

如果你喜欢我的文章或分享,请长按下面的二维码关注我的微信公众号,谢谢!

更多信息交流和观点分享,可加入知识星球:

VIP赞赏专区:

原文地址:https://www.cnblogs.com/kid551/p/9387494.html

时间: 2024-11-02 05:58:12

为什么需要提前撰写Spec文档的相关文章

产品需求文档(PRD)的写作方法

无论我们做什么事都讲究方式方法,写产品需求文档(以下称PRD文档)也是如此,之前我通过四篇文章分享了自己写PRD文档的一些方法,而这一篇文章主要是对之前四篇文章进行整体的摘要介绍,帮助大家快速了解写作流程. 产品需求文档(PRD)的写作 四篇章:1.写前准备(信息结构图)2.梳理需求(产品结构图和用户流程图)3.原型设计(手绘原型,灰模原型,交互原型)4.撰写文档(PRD文档)5.用例文档(UML用例图.流程图) 1.写前准备(信息结构图):http://tangjie.me/blog/52.h

产品需求文档的学习记录(三)

我们通过思维导图将想法进行了结构化梳理,接下来我们就需要进行方案的可行性推演,验证产品功能是否可行,预估项目要花多少人力物力,因此我们就要通过原型设计进行相关需求的论证.一开始就撰写PRD文档,我们很难对产品进行各方面的评估,也无法得知方案的可行性,并且无法直观细致的考虑产品. 原型设计是帮助我们更细致的思考,并做各项需求的评估,同时也是将自己脑海里的想法进行输出,通过原型设计后,我们就可以进行产品宣讲了.相对于之前抽象的文字描述,原型则更加清晰产品的需求,设计和技术人员或者老板也能够更加直观的

(015)XHTML文档之sup和sub标签

XHTML文档之sup和sub标签 <sup>和<sub>标签表示在文本中加入上标和下标字符,特别是所撰写的文档有关数学或化学或者其语言需要上标和下标(如法语)时.上标文本的位置比周围文本略高,而下标文本则比周围文本略低.下面的代码则表示勾股定理和化学公式. <p>a<sup>2</sup>+b<sup>2</sup>=c<sup>2</sup></p> <p>H<su

让你提前认识软件开发(40):既要写好代码,又要写好文档

第3部分 软件研发工作总结 既要写好代码,又要写好文档 对于软件相关行业,在学校或单位上,大家也许都已经注意到了,除了要编写的程序.绘制设计图之外,还有一个重要的工作便是写文档.为什么要写文档呢?因为我们要把自己做的东西展示出来,不光展示给同行看,可能还要展示给其他岗位上的工作人员看,甚至展示给用户看.如果我们只是会写程序,不会在文档中描述自己的想法,那么就真正的成为"码农"了. 工作也有一段时间了,我发现周围的同事,会写高质量文档的确实很少.李开复老师在<浪潮之巅>的序言

征python文档撰写技术员

最近频繁使用python,一些不懂的东西就要查一下,好几次到了官网,查了半天都放弃了,直接google了....哎...被Qt的文档宠坏了...如果有python爱好者和我有一样的想法,希望在有生之年再也不用饱受官网文档的折磨的,请联系我([email protected]),我们一起to make life better. 要求:至少要会英文吧,文笔简练,行文流畅,最好是落笔生花的. 声明:这个一个非盈利活动,具体开工日期等人数凑齐再说,另外提供pythoner职位两枚,工作地点武汉,待遇优厚

使用Spec Markdown 编写手册文档

Spec Markdown 是一个基于markdown 的文档编写工具,安装简单,可以让我们编写出专业的文档 参考项目 https://github.com/rongfengliang/spec-md-demo 安装 全局 npm install -g spec-md 本地项目依赖 npm install --save-dev spec-md 项目使用 因为个人原因,比较喜欢使用yarn,所以项目基于yarn 初始化 初始化 yarn init -y 配置构建&&依赖 yarn add s

6、市场需求文档(MRD)撰写方法与技巧(上)

1.MRD与BRD文档的不同 -BRD 这么做有什么好处,并说明好处在哪里-MRD 通过BRD明确了这个事情值得一做后,描述应该怎么做,并说明这么做的原因 2.MRD到底要干什么? 用绕口的方法来说:如果说BRD是你抛出的论题,那么MRD就是要你用论点来支撑你的BRD,同时通过论证来得出你采取什么方式获得BRD里面的商业目标(讲究逻辑性).用大白 话来说:MRD就是经过一系列的分析后,拿出一套你认为最合理的干某个事情的方法与指导实施的文档. 3.MRD的阅读对象 未来参与产品的各个层级的同事,都

撰写架构设计文档的心得体会

1.架构设计文档阅读对象: 是软件工程师,平台产品经理,不是乙方客户: 2.架构设计文档目的与意义: a.系统规划: b.有利于软件工程师的开展工作: c.便于分配工作,指导工作: 3.不在于篇幅,注重干货: 4.系统思维,全面思考,注重规划,关注设计,考虑细节,不局限细节,来解决实际问题: 如软件注册问题,涉及到用户安全.角色.权限.口令加密,验证码的问题. 5.平台总体架构不要照搬照抄的现有系统,分析现有系统的利弊,扬长避短,少走弯路,多走捷径,注重系统的可扩展,可伸缩,未来3-5年扩容与发

中文Appium API 文档

该文档是Testerhome官方翻译的源地址:https://github.com/appium/appium/tree/master/docs/cn官方网站上的:http://appium.io/slate/cn/master/?ruby#about-appium 中文Appium API 文档 第一章:关于appium1.1 appium客户端客户端类库列表及Appium服务端支持 这些类库封装了标准Selenium客户端类库,为用户提供所有常见的JSON 格式selenium命令以及额外的