近期在公司设计了一个技术方案，真正实施过程中发现不可用，促使反思一下技术方案的设计过程

技术方案类似于路线图。而这个过程中，尽可能的消除所有的不确定因素。

广义的技术方案从整理需求，到方案设计，再到开发排期的一整套内容。

在一个项目的初始阶段，大家只是对这个模块有一个模糊的认知，有纷繁的需求。对这些需求分出优先级，优先做重要需求。

需求整体来看，分成三种：

1.业务需求：本系统设计的使命是来做什么。

2.性能需求：本系统需要承担多高的并发，能够承受多大的数据量、计算量。假如性能不够，如何扩容等等

3.运维需求：如何确保整个系统的稳定运行，需要加上相应的监控统计。为了方便运维，需要开发相应的展示界面，查看系统运行状况。

初级工程师容易重视业务需求，而不重视性能需求和运维需求。

方案设计阶段主要根据个人的工程经验。

主要的坑是：

在设计的整个过程中，总会遇到一些不确定的因素。例如：不确定某个技术选型的耗费的时间、承载的最高并发量等等。

这个时候，千万不能：

自己必须针对核心应用场景，简化场景，然后测试可用性。

本人在设计流式抓取技术方案的时候，就遇到这个问题。对数据从mysql中读取的时候，根据最快的速度，速度应该是30M/s，而真正实施的时候，发现30M最快也需要3s。虽然网卡速度很快，但是python解析数据加载入内存却很慢。最坑的是在插入数据的时候，日常会在10分钟执行完的程序，因为目标mysql表有unique key，导致批量插入数据处于7个小时无法执行完成的状态。而只能分散插入。

设计并不是讨论和思考，还需要去尝试，我认为当你的设计完成的时候，你的骨干核心代码都基本完成了。（多些时间能少写些代码）

我遇到的过度设计大多数源自于对需求理解不清楚，把非核心需求，或者很久之后的需求，当做高优先级的事情来满足。

这种，需要把整个项目简化简化再简化。整个项目的可维护性也会大幅提升。

之前我一直的节奏是，最多一个星期做方案设计，然后开始进入两到三星期的编码阶段。设计和研发的时间比例一般是1：3。

现在想起来，这个时间分配是不合适的，技术方案设计阶段应该占整体时间的50%。前期考虑的越周密，后期反复修改、调整方案的时间越少。整体来看是节省时间的。

切忌先入为主，看哪个方案高大上或者容易实现，就开始用哪个技术方案。对于每一个技术方案，首先要想到该模块的应用场景，把每个应用场景分析清楚，在该应用场景下，应该选用哪个技术方案。

个人在排期上总是过于乐观。总是想着尽快把工作完成。其实有很多干扰因素。

排期的时候，务必把事情考虑详细，具体执行步骤。同时还需要考虑到以下因素：

1.平时其他业务的干扰。平时我们不仅要做自己的项目，还有其他临时的业务需求，或者其他人来问问题等等，都有可能很耗时间。这部分时间导致，一个星期最多只有3天的时间专注到长期规划的工作中。

2.延期的风险。每个项目，在原有计划的基础上，增加20%的时间，来应对方案实施过程中各种异常情况。好比，某个细节没有考虑清楚等等。

聪明的程序员使用50%-70%的时间用来思考，尝试和权衡各种设计和实现，而用30% – 50%的时间是在忙碌着编码，调试和测试。聪明的老板也会让团队这样做。而傻逼的老板，苦逼的程序员会拿出来100%-150%的时间来忙着赶进度，返工，重构，fix 大量的bug… 所以， 越差的团队一般会越忙，而且还忙不完。（引自多些时间能少写些代码）