时间:2023-01-18
球王会近期在公司设计了一个技术方案,真正实施过程中发现不可用,促使反思一下技术方案的设计过程
在一个项目的初始阶段,大家只是对这个模块有一个模糊的认知,有纷繁的需求。对这些需求分出优先级,优先做重要需求。
2.性能需求:本系统需要承担多高的并发,能够承受多大的数据量、计算量。假如性能不够,如何扩容等等
3.运维需求:如何确保整个系统的稳定运行,需要加上相应的监控统计。为了方便运维,需要开发相应的展示界面,查看系统运行状况。
在设计的整个过程中,总会遇到一些不确定的因素。例如:不确定某个技术选型的耗费的时间、球王会承载的最高并发量等等。
本人在设计流式抓取技术方案的时候,就遇到这个问题。对数据从mysql中读取的时候,根据最快的速度,速度应该是30M/s,而线s。虽然网卡速度很快,但是python解析数据加载入内存却很慢。最坑的是在插入数据的时候,日常会在10分钟执行完的程序,因为目标mysql表有unique key,导致批量插入数据处于7个小时无法执行完成的状态。而只能分散插入。
设计并不是讨论和思考,还需要去尝试,我认为当你的设计完成的时候,你的骨干核心代码都基本完成了。(多些时间能少写些代码)
我遇到的过度设计大多数源自于对需求理解不清楚,球王会把非核心需求,或者很久之后的需求,当做高优先级的事情来满足。
之前我一直的节奏是,最多一个星期做方案设计,然后开始进入两到三星期的编码阶段。设计和研发的时间比例一般是1:3。
现在想起来,这个时间分配是不合适的,技术方案设计阶段应该占整体时间的50%。前期考虑的越周密,后期反复修改、调整方案的时间越少。整体来看是节省时间的。
切忌先入为主,看哪个方案高大上或者容易实现,就开始用哪个技术方案。对于每一个技术方案,首先要想到该模块的应用场景,球王会把每个应用场景分析清楚,在该应用场景下,应该选用哪个技术方案。
排期的时候,务必把事情考虑详细,具体执行步骤。同时还需要考虑到以下因素:
1.平时其他业务的干扰。平时我们不仅要做自己的项目,还有其他临时的业务需求,或者其他人来问问题等等,都有可能很耗时间。这部分时间导致,一个星期最多只有3天的时间专注到长期规划的工作中。
2.延期的风险。每个项目,球王会在原有计划的基础上,增加20%的时间,来应对方案实施过程中各种异常情况。好比,某个细节没有考虑清楚等等。
聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30% – 50%的时间是在忙碌着编码,调试和测试。聪明的老板也会让团队这样做。而的老板,球王会苦逼的程序员会拿出来100%-150%的时间来忙着赶进度,返工,重构,fix 大量的bug… 所以, 越差的团队一般会越忙,而且还忙不完。(引自多些时间能少写些代码)