高三的一个小故事
在高中时代,我读书不算优异,但也算勤勉。记得有一次高三我突然挺进了班前几名,在班会上班主任让我上台分享下自己学习进步的成功经验。我当时说,“其实也没啥,方法就是,把全部的练习册、试卷、课外教材、包括课本上的作业题练习题全部都做完,就可以了。”。台下立即有同学问:“那你是怎么有那么多时间把全部题目都做完的?!根本做不到嘛……”。是啊,怎么会有时间呢?怎么能做得到呢?但就是有人做到了。一般这类人我们称他为:学霸,或牛人。
反思现在开发的难
直到如今,从毕业到现在,我已在软件开发领域从事浸淫了约十多年,负责过开源项目、外包项目、上市企业核心高并发系统研发、高速发展中公司的系统重构、以及创业公司的敏捷开发和快速迭代和救火。在我带领过以及共事过的软件开发工程师中,很多人,大部分的人,都会觉得开发很难,说的很多的可能也是:“没时间,根本没时间”。要么系统很烂改不动,要么这个需求太复杂要很长周期,要么能做也是觉得在痛苦中开发。
在我看来,软件开发并不难,而且我一直都乐在其中,因为通过软件开发,我们能创造出新的产品、软件、系统来服务和帮助更多人的工作或生活,这是一件很有价值和成就感的事情。
如果你也认同这个观点或价值观,刚好现在又觉得自己或团队正在处于“开发很难”的窘境,又特别想提升研发的效率,那么我们不妨继续进一步,一起来总结下成功的经验、模式、方法和工具。
最近又一次成功的开发经验
最近我们YesDev项目管理平台收到了一个客户的需求,希望能把YesDev原来任务只有固定的3个任务状态(待办、进行中、已完成),动态扩充到任意多个任务状态(例如:期望流程:待开发 -> 开发中 -> 开发完成 -> 待测试 -> 测试通过 -> 待上线 -> 已上线 -> 已关闭)。
这个需求,就一句话,看似简单,实质上开发起来是有一定难度的。为什么呢?原因在于:
1、“牵一发而动全身”。对于现在复杂的系统,但凡动到系统主流程以及核心交互单元的,势必都是全局性的改动,而此处的任务协作也正好是YesDev项目管理最小颗粒度、最核心的管理协作单元,和业务有着千丝万缕的关系。
2、“数据结构决定上层算法”。从数据库的角度,原来定义好的字段语义(任务字段 0待办、1进行中、2已完成),需要重新从数据结构底层设计,既要合理又不能过度设计,还要能向前兼容旧数据旧逻辑、也要能向后兼容未来的可扩展性,还别忘了要处理历史旧数据!
3、“一个都不能少”。为了这一句话需求(约几十个汉字的需求描述),我们改写和新增约上万行代码。你以为难度在于这上万行的代码改动吗?非也,难在改动的这些代码一行也不能、一行也不能多、一行也不能错,最后改完好,这些全部的代码都要能符合编程语法、要能通过机器计算机编译、还要能充分贴合最终业务逻辑。代码错一行一个Bug,或者说源代码错一个字母就是一个故障。
4、“多个产品线要一起调整”。公司越大,部门越多,系统越杂,特别在某个需求需要多个产品线一起调整时,尤其吃力耗时和大成本。更别说还要同步更新接口文档、产品使用手册、FAQ、销售物料、内部培训等。本次的任务状态调整需要同步调整PC端、企业管理后台、H5移动端等,可能还会涉及计划任务、MQ、底层服务这些“看不见”的程序。
简单来说,对于现在已经有用户客户在使用的业务系统,如果需要修改核心、底层、主流程的逻辑,是一件 高风险、高成本、复杂而又困难的事。雪上加霜的是:原来的系统就已经很脆弱、开发人员又严重不足、需求方给到的开发时间又是急了又急、挤了又挤、系统前期的很多情况和内部都不透明、更致命的是需求就一句话!这些都是让开发人员抓狂和接近崩溃边缘的原因。
但这一次,我们又一次即将完美交付此复杂核心的需求,并又成功经历了一次核心主流程业务需求开发迭代的经验,同时收获了又一次有成就感的产品研发、设计与交付。
资深开发告诉你:做需求,先分析、再设计、后研发
拿到需求,新手开发人员先别着急立即开始写代码开发,要先把技术开发思路捊清楚,把整个技术开发方案先描画出来,提前搞清楚难点在哪?卡点在哪?耗时点在哪?不可控点在哪?注意事项在哪?还有哪些需要补充的?
要养成做需求,边做边整理文档的好习惯。首先,我们可以在YesDev项目管理工具,创建一个主需求:“需求#634715 状态扩充预留:项目、需求、任务、问题、测试用例 等(第一站:任务)”。注意,做需求也要举一反三,虽然需求方需要的只是任务状态扩充,但我们在规划产品需求时可以把项目、需求、问题的状态也一并设计,但可以分批实施,先做第一站:任务状态扩充。谋定而动。随后,再根据主需求拆解子需求。
采用领域驱动设计DDD的理念
核心的设计,先看图,结合 领域驱动设计DDD的理念,描述关键的业务规划和领域语言。即先从概念视角出发,再到规约设计,最后到代码实现视图。
为了平衡任务协作本质的情况、企业客户研发团队目前的需求、以及软件系统开发的完美设计,YesDev的任务状态从原来只有3个离散状态的点分布,升级设计成了3个区间状态段的设计,其中应用了“前等后不等、开区间、闭区间”等通俗的数学用语,而且通过坐标轴方式也清楚描述了业务逻辑。
再看数据库设计
下一步是数据库的字段变更设计:
-- 任务状态
ALTER TABLE `pp_tasks` CHANGE COLUMN `task_status`
`task_status` smallint(4) NOT NULL DEFAULT 600
COMMENT '任务状态,600 TODO,1500 DOING,2000 DONE';
以及别忘了对旧数据、历史数据的处理,复杂的处理需要额外编写一次性处理脚本。
update `pp_tasks` set task_status = 600 where task_status = 0;
update `pp_tasks` set task_status = 1500 where task_status = 1;
update `pp_tasks` set task_status = 2000 where task_status = 2;
展开设计就是,数据库设计及变更:
-
统一使用smallint
-
1000超步初始值(方便以后扩展更前置的状态)
-
2000作为完成状态的分割值
-
3000封顶。
-
中间 100至3000再取逢百作为系统预设预留的状态值
-
采用【/】屏蔽掉不需要的状态。
-
共30个状态(先扩充24组)。
最后代码实现
最后,是相关代码片段的实现。如,后端PHP的任务业务领域类,在里面通过常量来描述任务状态,通过API接口及释意接口描述获取任务状态名称、任务是否延期等方法。请留意细节,通常情况下不建议使用静态static方法,除非真的是和实体状态无关的,是属于服务类的工具方法才建议允许用static,不然代码容易僵化。
./src/base/Domain/Tasks.php
<?php
namespace Base\Domain;
class Tasks extends Base {
// 任务状态,TODO,DOING,DONE
const TASK_STATUS_100 = 100;
const TASK_STATUS_200 = 200;
const TASK_STATUS_300 = 300;
const TASK_STATUS_400 = 400;
const TASK_STATUS_500 = 500;
const TASK_STATUS_TODO = 600; // 初始 待办
const TASK_STATUS_1000 = 1000;
const TASK_STATUS_1100 = 1100;
const TASK_STATUS_1200 = 1200;
const TASK_STATUS_1300 = 1300;
const TASK_STATUS_1400 = 1400;
const TASK_STATUS_DOING = 1500; // 进行中
const TASK_STATUS_1600 = 1600;
const TASK_STATUS_1700 = 1700;
const TASK_STATUS_1800 = 1800;
const TASK_STATUS_1900 = 1900;
const TASK_STATUS_DONE = 2000; // 已完成
const TASK_STATUS_2100 = 2100;
const TASK_STATUS_2200 = 2200;
const TASK_STATUS_2300 = 2300;
const TASK_STATUS_2400 = 2400;
public static function getTaskStatusMap($isHtml = false) {
}
public static function getTaskStatusName($status, $isHtml = false) {
}
// 释意接口,是否延期任务
public function isDelayTask($taskStatus, $taskFinishTime) {
}
}
以上,只是开发的冰山一角,但思路大体类似。
解决之道:高效开发、维护和重构复杂系统的经验分享
我时常和团队开会时说,也和不太懂技术的老板说,系统为什么开发了这么多年,现在做个新需求还这么难、这么吃力?原因是:本身做这个需求不难,但要把这个需求完美嫁接到现有的系统则很难。因为有很多历史包袱、技术债务、旧的问题要处理。
当然,办法总比困难多。把问题量化了,自然就会解决之道。
1、改一处,记录一处,验证一处
对于主要界面,从管理后台配置、到前台使用、到辅助功能和新页面,改一处就在需求文档上记录一次,把页面功能、网站链接和实现效果,在自我测试验证后进行记录。例如:
记录的好处,有利于查漏补缺,也方便后面的测试回归。最好是把git代码提交也和需求进行关联。YesDev支持各类Git代码仓库的自动关联。
2、学会代码全局搜索和分析,一行也不能放过
如果一个开发人员和你说,这个需求非常大、很难做,那么你可以要求让这位技术开发人员提供需要修改的代码范围。如果你自己是开发人员,如何才能知道有多少相关的代码需要修改呢?思路方法很简单也很有效。就是根据数据库字段名去全局搜索源代码。
例如这里的,PHP代码及API调整共有306行,
$ pwd
~/dogstar/yesinew_www
$ grep task_status ./src/* -R | wc -l
306
Vue前端调整 共156行,
~/projects/codeup/xiaozhi on dogstar! ⌚ 22:06:15
$ grep task_status ./src/* -R | wc -l
156
还可以把每个源文件的代码行号罗列出来,以便后续逐个调整修改。如:
$ grep task_status ./src/* -Rn > task_status_todo.txt
将能看到类似以下将要可能修改调整的代码位置。简单、直接、有效。
3、提前做好自动化单元测试,收益真不少
代码要改这么多?!怎么知道有没改出问题?!要一个个自己手动测试吗?要一个个API接口重新测试吗?!要每个页面、每个功能都手动人眼看一次操作一遍吗?!不行不行,是个人都做不到,而且每个人手上还有这么多需求、这么多事情、这么多工作要做。没时间没时间!
那么解决的办法是什么呢?那就是:自动化单元测试!有没问题,一键测试,就知道。
可能你还会问,那单元测试怎么来?谁来写?没有怎么办?
我的回答:现在写,你写。现在不补写单元测试,永远都不会有。
又问:现在也没时间怎么办?
我的回答:把本次要新增单元测试的时间也加上。“功在当代,利在未来”。单元测试也是开发工作的一部分,而且也很有价值。
4、不要害怕,该重构就重构
原来的代码,肯定会有这样那样的问题,例如:一个规则逻辑放在了多处、重复代码函数甚至类比比皆是、方法参数过长、一个类文件非常庞大甚至都有成千上万行代码、注释掉的代码或没有的代码都没删(也没人敢删)、到处写死的代码、更别说不规范的代码命名和风格了。
5、适当引入新的模式、方法和新设计(包括设计模式、混入、枚举、原型链接等)
应对新的需求场景,结合应有的设计,恰当引入新的模式、方法和新设计,例如:设计模式、minin混入、枚举、原型链接、特质等。
本次开发过程中,有趣的是,为了避免写数字魔数,在前端我封装 $enum 枚举值,达到和后端对齐的效果。参考了张瑞丰的博文《Vue项目常量的使用》,实现了以下的效果。
相关核心前端代码片段,
import store from './store'
// 引入全局枚举值(避免魔数)
import './enum'
// 在视图文件使用
<Tooltip :content="`请确保任务为【${getConstantItem('TASK_STATUS', $enum.TASK_STATUS_DONE, 'name')}】状态`"
placement="right" theme="light">
// 在js中使用
this.taskCheckDisabled = task_status == this.$enum.TASK_STATUS_DONE ? false : true
6、别忘了做好SQL变更记录及上线清单准备
除此之外,还要把有关的工作、变更、调整做好记录。先记录,再执行。不要遗漏、不要记事。因为错误的代价成本很大,不容犯错。
办法总比困难多,能力比努力更重要
有个对联是这么说的:
上联:说你行你就行不行也行;
下联:说你不行你就不行行也不行;
横批:不服不行。
有一次,我听到一位高管在给下属分配完工作后打气说:“再努努力力,加加油,你可以的!”。而还有一次,在一家企业中,我看到了这样的文化标识:“我们需要的是指点,不是指指点点”。
Anyway,任何工作、任何项目、任何系统开发都会有困难,毕竟方法总比困难多。在你觉得开发困难时,不妨反思一下是不是自己的能力还不够?为什么同样的时间,别的开发就能做出来而自己却不行?是功力不够,还是能力不够?有时,能力比努力更重要。你固然很努力,但能力达不到就会很痛苦。最好的状态是,你有能力驾驭本次开发,而且还提前拥有了下一阶段的知识储备,不断正向循环,勇往直前,向前一步、快人一步。
知识,千万别总等到要到用的时候,再来学(更别说不学也不补)。
来自《童年》的歌词:
“总是要等到睡觉前
才知道功课只做了一点点
总是要等到考试以后
才知道该念的书都没有念
……”。
掌握方法,回归代码修改的艺术
如果作为专业的技术开发人员,想要进一步掌握专业的方法,洞察代码修改的艺术、掌握系统遗留旧系统维护的密码,那么继续推荐我前面也有介绍过的几本好书,和编程开发语言无关,和做什么项目无关,都是普适性的经典著作。排名也分先后,谁看谁受益。
《领域驱动设计 软件核心复杂性》
《重构 改善既有代码的设计》
《修改代码的艺术 [美] 费瑟》
如果前面的书太抽象、过于高阶,可以先看下基础夯实的入门书,例如:《Vue.js设计与实现(图灵出品)》。
从小工到专家,领悟软件开发的本质
开发,从来都不是一件简单的事情。
一个产品、一套系统,做下来,会有十万行以上的代码、几百个API接口和几百份接口文档、几百个上千个测试用例、还有产品需求文档、设计稿、数据库数据等。
而在用户的眼里,在需求方的眼里,它就是一个界面、一份数据、甚至一个按钮而已。
系统越智能、代码越复杂。人想偷懒、高效,就需要计算机做多一点,而作为中间的媒介就需要我们程序员多用心、多写几行代码、多做好兼容和提升系统的友好度和代码的容错性。
程序员,从小工到专家,是职场晋升的表现。系统,从混沌到稳态到智能,是需求方的感知。产品,从创新到好用到解决痛点,是用户对它的价值感知。
最后,分享一个小故事。
有这样一个故事:三个工人在砌一堵墙,有一个人过来问:“你们在干什么?”第一个人没好气地说:“没看见,在砌墙。”第二个人笑了笑说:“我们在盖高楼。"第三个人边干边唱着歌,说:“我们在建设一个新城市."十年后,第一个人仍然在砌墙,第二个人成了工程师,第三个人成了前两人的老板。
愿意或有心把代码建设成一个新产品的程序员/开发工程师,我相信,他未来的路和未来的发展空间,都充满更多可能和展望。
加油,少年!