在你编码之前

jopen 10年前

  很多开发者,将自己限定为程序员,觉得自己就是一个专业写代码的,和代码稍微远一点东西,就不感兴趣。

  在前一篇文章 《软件开发之未来》 中, 我已经阐述了技术的时效性以及快速更新。

  如果我们紧紧把目光局限在代码,而不是分析、解决问题的综合能力,我们将迟早陷入中年危机, 被奔腾的技术潮流淘汰。

  这篇文章我想讲讲分析问题、解决问题的基本套路,这是我多年总结下来的习惯,希望对大家有帮助。

  绝对不是立刻写代码

  有些同学钟情代码,收到一个任务,马上就想到代码实现。

  问题都还没弄清楚,工作原理还没分析透,就开始整出几个类,然后思考如何用这些类。

  找人讨论,直接看代码。

  这是准备死 1000 次的节奏。

  动笔头: 设计文档

  有些新人,很有责任心,碰到问题也会找我沟通讨论。 但是怎么也不能深入下去,执行效果千疮百孔,各种返工改进,考虑不周,不能产品化,弯路不少。

  问题在于,不善于动笔头。动笔头的目的:

  1. 沉淀思考结果:

    每次思考,每次讨论,达成一步认识,就固定下来。上一步台阶,步步为营才能达到目标。

    如果不记录,就会焦虑,就会低水平原地重复思考。

    大多数人的大脑内存有限,必须借助文档这种外存进行交换才能顺畅运行的。

  2. 文档是 alpha 版本的程序

    大脑就是运行文档的计算机。

    看一遍文档,让整个系统在运行之前,在大脑里面运行一遍。

    每次运行一遍,才能发现是否会抛出异常。对这些异常,在文档修正。然后再次运行,再次寻找处理异常。

    不仅仅在自己大脑运行,还要通过设计评审在别人大脑运行。如果有多种方案,需要大家进行评测那条最佳。

    不可能一次就做好设计,只有反复运行,多处运行,才能最终出错可能性最小。

    因此文档是否清晰明了是否简单,非常非常关键。

  设计文档我推荐采用幻灯片的形式,因为一个页面说明一个问题。大标题配小节,更简洁。

  下面的各个章节,也是这个幻灯片文档的主要内容。

  当然你如果问题不大,对自己的大脑内存以及表达能力有信心,也可以不写设计文档。 风险自己承担了,其实设计文档不费时的。

  陈述问题

  陈述问题,也是陈述需求。

  陈述问题,不应该太涉及技术层面的问题。更多是从前用户的角度来陈述。

  陈述问题,应该是普通用户都能够看明白是什么东西。

  需要将各种场景都说明白。不能漏掉场景,否则对我们之后的设计会存在偏差。

  最终设计完成,需要验证这些问题、需求都得到满足了。

  这些需求、问题,也需要做一个轻重缓急的判别。因为我们整个设计过程,最终需要做一个开发计划,要求能最快提交一个最小的可工作版本。 这样才能做到敏捷。

  陈述问题,有时候不仅需要明确做什么,还要说吗不做什么,这是需要明确系统范围。

  如果是多用户系统,需要罗列参与的用户角色,以及每个人的希望的获得功能。

  工作原理图

  一图抵万言。特别是对于用于沟通的设计文档,文字越少越好。图形能表达最多的内容。

  工作原理图是一个方案的陈述方式。可以有一张,或者多张。这个是整个设计的中心。

  工作原理图,通常包括系统和外部直接的交互关系图,以及系统内部的组成结构图。

  这 2 种图,由方框和连线组成,方框表示模块,连线表示接口。需要标注各个接口和模块的名称,以及接口调用的主要顺序。

  画原理图,不仅仅画画,而是真正的设计。里面蕴含大量思辨,需要我们拟清各种概念。

  模块和接口命名,是思辨的体现。名不正则言不顺。

  围绕这个原理图,需要对个模块和接口进行说明,这个组成了所谓的设计正文。

  用户 UI 设计

  如果需要用户参与,需要设计用户 UI。当然如果是后端应用,需要明确接口。

  用户 UI 往往要比较早明确,因为明确 UI,才能细化需求,这个和概要设计也是相互呼应和印证的。

  用户 UI 设计之所以重要,在于,这是更多从用户的角度思考问题,因此更能完整表达系统,明确正确的方向,方便引导思考进入深入。

  当然如何设计,也会考虑从前方便实现的角度权衡。二者之间如何拿捏,这个是艺术所在。

  开发计划

  也就是 todo。

  一次设计下来,是需求和想法不断膨胀的过程,往往把简单的事情,弄得很复杂。

  开发计划,则是如何干了。这时候主要的思考点,就是理想很伟大,但是我们如何做快速做一个可工作的最小版本。

  大胆假设,小心实践也是这个意思。其实我们设计的内容,可能很多都是错的。

  设计是永远的,不会终止于一次设计文档,也不会终止于评审,也不会终止于若干次改稿。 设计在开发的过程中,才是真正深入,这时候会不断发现之前设计的问题。

  做一个最小可工作版本,这时候再次评估一下设计,发现问题多多。

  所以,设计要尽早做,因为每一次回顾,我们基本上都会有新思路。 最早设计,最晚动手,这才是靠谱的方法。留给我们更多时间去消化完善设计。

  根据问题,补充内容

  初步的设计完成,就会发现各种问题,和疏漏。

  准确记录下问题,然后思考解决方法。

  其实我们如果能够准确的表达出问题,解决方法往往是呼之欲出的。

  更新 Reference 文档

  其实设计文档,长期保留的价值并不大,原因是:

  • 文档过于简单,而且之后各种产品文档应该会包含设计文档的内容。
  • 文档很容易过时,正式开始编码之后,设计仍然在变,这时候通常不会再去更新设计文档

  所以设计文档通常都是虎头蛇尾的。

  一旦确定设计,设计人员需要优先更新 Reference 文档,而且长期去维护这个 Renference 文档。

  Reference 文档是一些参考手册,包括 API 手册、系统维护手册,诸如此类。

  这些文档是提供给其他用户,需要永久保留的。

  很多人老是觉得没有时间维护这些文档。在设计阶段维护这份文档,其实很重要。

  这份文档,其实就是详细设计文档,在编码之前,从用户角度更深入的设计系统,再次发现设计的问题。

  如果觉得 APi 很奇怪,或者操作手册很难写,那么可能设计存在问题。

  小节一下

  分析问题、解决问题,我的套路,基本是这些,其实不麻烦。

  但是这些是可以用在生活工作的各个方面的,是属于“道”层面的东西,如果编码是“术”的话。

  我们都希望成为一个做事靠谱的人,即便在你不熟悉的领域,也能借助资源做好一件事情,上面的分析方法,可能值得借鉴。