周日早晨陪2岁的孩子玩，他想画画，于是找了一本英语单词的书。书上面有很多插图，找了一个waiter的插图准备要画。看着这个图片还真有点无从下手，虽然也没学过画画，但是了解过程序设计，想着画图其实也是一种设计，于是把画画的过程类比到程序设计上。
画画流程对比程序设计流程
下面是我画画的流程：
- 我要画的对象是什么，仔细看看，能大致描述这个物体。这次就是一个托着托盘的服务员
- 对象能大致分解成几部分。头、躯干、下肢、一些装饰性物体。
- 图片上这几部分之间是直接连接上的还是有特殊物品来装饰。头和躯干之间由脖子连接，脖子上有一个蝴蝶结。
- 在图纸上勾勒出整体的轮廓，进而勾勒出每一部分的大致轮廓。
- 针对每一部分进行设计，再适当勾勒轮廓。例如头部上的发型、五官，此时还只是勾勒轮廓的过程，还没具体画。
- 整体的再过一遍，看看已经勾好的轮廓是否比例合适，针对性的修改一下。
- 开始画，把每个轮廓都画上内容。
- 整体再润色一下。
- 给孩子看看，好在孩子小，看似效果还可以。
- 针对他指的地方再看一下是不是可以再改改。
针对画画的步骤，我做软件开发的时候也有对应的步骤：
- what？了解清楚要开发的程序是用来做什么的，它大致是由什么样的人使用。
- decomposition。在全面了解对象之后把系统进行细化，拆分。大系统拆成小系统，大模块拆成小模块，大class拆成子class组合的形式。然后用包图进行描述关系。
- relation and communication。每个小模块之间的关系和通信方式，为打通通信做好设计，可以是本地函数调用、http、tpc、rpc等，梳理一个简单的时序图。
- architecture。选一下合适的管理、通信框架，脚手架。可以考虑为每个模块可以创建好对应的包，写一个demo包，为后面的开发做模板。
- detail。详细设计，针对每个子模块甚至于类进行抽象、设计，画一下对应的类图。归置一下文档，比如，概要设计、详细设计之类的。
- implement。实现逻辑。这里虽然只是单纯开发，但是也有熟练和生疏，直接和啰嗦。
- polish。针对单个模块的代码走读。
- check & accept。测试并交付。
- maintain。维护。
经过对比，我发现一个共同点：先别着急做，先做好准备工作，准备好了再动手。
什么样的事情需要设计？
目前看来，那些复杂的事情，没有经验的尝试，不堪忍受多次失败的，都应该考虑先设计后动手。
程序设计的核心思想
- 有针对性的设计，在概要设计的时候不要掺杂详细设计的内容。
- 简单就是美，能简单实现的东西绝不啰嗦。
- 富有创造性，不拘一格，尽量不受固有思想束缚。
- 程序和人一样，它也需要查漏补缺，给它一定的延展性。
设计的弊端
上面说到，针对特定的情况才适合进行慢慢设计，经过设计的开发一般不会有重大的问题，质量相对有保证。但是设计也有它消极的一面：
- 过度设计。在刚刚接触设计之后，恨不得干什么事都要设计一番再动手，实际上根本不需要，比如让你写一个文件导出的类，用一次就作废了，你还要耗费几个小时进行设计，就得不偿失了。
- 时间成本。设计是非常消耗时间和精力的。
- 架构维度复杂。这针对于系统拆分子系统最为明显，现在微服务很热，有的公司恨不得把每个controller都拆成一个微服务。
- 维护难度增加。
经验原则
在做一些极为简单的任务时，往往靠经验就能完成，甚至一些比较复杂的事情，由老师傅去做也是一会儿就做好了，这就依赖他们丰富的经验，看似没有设计，实际上在他们心中已经设计上百次了。
彩蛋
来源：CSDN
作者：nickDaDa
链接：https://blog.csdn.net/nickDaDa/article/details/104605764