修正php代码的软件技巧_修改代码的艺术若何高效开拓掩护和重构复杂的现有系统

在我看来，软件开拓并不难，而且我一贯都乐在个中，由于通过软件开拓，我们能创造出新的产品、软件、系统来做事和帮助更多人的事情或生活，这是一件很有代价和造诣感的事情。

如果你也认同这个不雅观点或代价不雅观，刚好现在又以为自己或团队正在处于“开拓很难”的窘境，又特殊想提升研发的效率，那么我们不妨连续进一步，一起来总结下成功的履历、模式、方法和工具。

最近我们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;

展开设计便是，数据库设计及变更：

末了，是干系代码片段的实现。
如，后端PHP的任务业务领域类，在里面通过常量来描述任务状态，通过API接口及释意接口描述获取任务状态名称、任务是否延期等方法。
请留神细节，常日情形下不建议利用静态static方法，除非真的是和实体状态无关的，是属于做事类的工具方法才建议许可用static，不然代码随意马虎僵化。

./src/base/Domain/Tasks.php <?phpnamespace 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 -l306

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接口和几百份接口文档、几百个上千个测试用例、还有产品需求文档、设计稿、数据库数据等。

而在用户的眼里，在需求方的眼里，它便是一个界面、一份数据、乃至一个按钮而已。

系统越智能、代码越繁芜。
人想偷

程序员，从小工到专家，是职场晋升的表现。
系统，从混沌到稳态到智能，是需求方的感知。
产品，从创新到好用到办理痛点，是用户对它的代价感知。

末了，分享一个小故事。

有这样一个故事:三个工人在砌一堵墙,有一个人过来问:“你们在干什么?”第一个人没好气地说:“没瞥见,在砌墙。
”第二个人笑了笑说:“我们在盖高楼。
"第三个人边干边唱着歌,说:“我们在培植一个新城市."十年后,第一个人仍旧在砌墙,第二个人成了工程师,第三个人成了前两人的老板。

乐意或有心把代码培植成一个新产品的程序员/开拓工程师，我相信，他未来的路和未来的发展空间，都充满更多可能和展望。

加油，少年！

标签：status开拓