入职一年啦

从入职到如今已通过了一年，然而博客几乎没有更新。原本毕业时和过年先后是打算写点总结什么的，写着写着就没有继续。

但不写点回顾的话，内心总感受难受。之后要是想回忆一下当初都作了啥，结果没想起什么，感受都是在浪费时间，这就很差了。

这几天恰好是咱们这批新人入职满一年，脑中“写点什么回顾一下吧”的想法频繁浮现。索性就把周末时间拿来写这篇博客了。

公司、部门

在同班同窗的安利下，来到如今就任的这家公司面试。如今咱们在同一个小组。

当初是冲着说不用加班来的（然然后来却常常加班，虽然是自找的）。此外，待遇好也是很是吸引个人地方~

同事以前的氛围很好。你们人都挺好的。此外咱们老大（咱们都叫他大大~）常常会请咱们吃下午茶，有时候会组织部门聚餐，上周六还一块儿去看了《我不是药神》。小组的聚餐也组织过几回。前面说过，这几天咱们这批新人入职满一年，你们会买下午茶请部门的同事。因而咱们就这样吃了一周下午茶，哈哈哈。在这样的部门里面，感受很幸福~

也有很差的地方。我所在的小组就编程而言，个人水平是最高的了，其余技术方面的也差很少。这也就意味着在这个小组里面，没有大腿能够抱，只能经过自学来提升本身。自学的进步速度比不上有人带的速度。这也是我常常感到压力的缘由——进步速度太慢了。

所幸的是，从去年十二月开始，咱们部门有同事组织起了知识分享会，成立了学习小组。每周五下午会抽出两个小时的时间给知识分享会。期初是针对特定议题，你们各自学习，并在会上针对议题讲述所学内容或发表见解。后来则是由每一个人自定主题，而后上台演讲。主题的范围很广，非技术相关的例如：时间管理、如何作好演讲、团队合做等；技术相关的例如：代理服务、分布式、存储组件等；不知道怎么分类的例如：人工神经网络介绍（我讲的），三维地图重建，密码学入门等。

总的来讲，能学到东西，但仍是不够。一般只有讲师学到的东西最多，其余人能学到多少，仍是要看讲师讲得如何。像我讲的人工神经网络，虽然全程都是有画图讲解的（彻底没有PPT），可是到了后半部分往深讲的时候，仍是有一半同事懵圈了。

项目

一年间接触的项目总共有三个，姑且称做项目 A B C。用的语言都是 PHP。

• 主要参与的项目是 A ，是一个用 PHP 写的至少有十年历史的任务系统（是否是有点可怕？）。
• 项目 B 是参与了其中一个模块的重构，但重构得不完全。由于此次重构的目的主要是加个流程的流转引擎进去。
• 项目 C 是个聊天机器人，用到了人工神经网络。然而我并无负责核心部分（泪）。

项目 A 放后面讲，另外两个内容比较少。

项目 B

项目用的是 Zend Framework 框架，1.10.8 版本，2010 年 8 月发布的。如今最新版本是 3。

旧代码不多用到框架已经写好的东西，还有很多东西是框架已经写好，但仍是本身写的。应该只是为了用上 MVC 和部分功能吧。

和其余模块的重构是把原来的代码拷一份，而后在上面修修补补的方式不一样。我基本重写了全部代码。把业务相关的东西抽出来，简化复杂的逻辑，把大块的代码拆解成几个部分。然而这是有代价的，我为此加班了好多天。不过最后仍是定期交付了。若是不重写的话，我能够不加班也能完成一样的功能，可是过不了本身这一关。本身经手过的代码，让它们保持之前那种糟糕的状态，实在不能接受。

不过我也知道本身这样作的风险。从公司的角度讲，天然是项目越快完成越好。万一要是由于我想把代码写好一些，致使项目进度变慢，那问题就大了。虽然在很多地方我克制了冲动，但仍是常常忍不住去重构代码。幸运的是，项目的进度要求都没有紧张到没有时间来作优化。这也是受到公司氛围的影响吧~

项目 C

一开始冲着机器学习来的，兴冲冲地加入到项目里面，想着学点有深度的东西。但果真仍是太年轻了。自身并无相关的技术积累，想经过加入项目来提升技术的想法，是否是太幼稚了呢？

在这个项目组里面，到目前为止我都是负责后台的简单工做。例如提供知识库的录入界面等各类界面及其配套的后台逻辑代码，大部分工做都是前端相关。后端框架用的 EasySwoole ，由于涉及到通讯，须要用 swoole 扩展。不过我这一部分的工做跟这个框架其实没什么关系。先后端接口用的 Restful API 标准，可是 GET 查询的支持不完善。

其余同事有的负责模型训练，有的是负责通信模块。虽然原理我懂很多，但没有实践。后面咱们会交换工做内容，我到时争取换到模型训练去。

说到我在这个项目所作的事情，能够引出一个话题：

前端 VS 后端

其实我指向好好地作一个后端开发人员。嗯！前端是要了解一点，可是也没必要要这么早吧。等此次作完，之后再有其余前端的事情，我都推掉。此次没有早点推掉，把本身给坑了。

待我成为后端大佬，须要拓展技术面的时候再去多了解和实践前端。

项目 A

因为是主要参与的项目，因此能够说的东西就比较多了。下面我就叫它流水系统吧。事先说明，这是个内部系统，用户量不会大到哪去，但使用频率很高，并且跟绝大部分提供给用户的线上的机器有关。

前面说过，这个项目的历史有十年以上。想象一下十年前的开发吧，如今流行的几个框架中，最先的是在 2007 年左右发布第一个版本。没错，也就是说这个项目没有用到任何框架。最多见的 MVC 也是不存在的，基本全部东西都写在一块儿，面向过程。听说这个项目的开发人员基本都是从运维转到开发，包括目前组内的几个成员都是从运维转到开发的。

不过神奇的是，我参与的这部分（也是整个系统最有业务价值的部分），能够说是隔离的还不错。前辈们已经把前端相关的东西封装好了，只须要到配置界面配置一下，就能组合成一个简单的表单界面。剩下的就是写后端部分，你能够把它当作是一个接近纯 API 形式的系统，最终只要 return 一个 json 字符串就好了。这点实在是使人佩服。这也为我接下来的改造提供了便利，由于在整个请求中，会有一个地方成为主入口，只要在这个地方作个拦截，把部分请求重定向到另外一个位置，最后返回的时候是一个符合规定的 json 字符串就行。

流水系统的开发面临几个问题：

• 代码管理方式落后
• 本地环境搭建复杂
• 单个代码文件过大
• 难以测试
• 维护成本高
• 没有文档

听说在我来以前的一年，已经有说要重构项目了，但一直没有行动。由于维护自己就要花去不少时间，再加上需求一直作不完。这周才又开始提起这件事，由于组内目前有几个同事，他们负责的部分没有需求了。并且我在最近的半年间也作了很多事情，对他们也会有帮助。

接下来讲说我怎么逐个解决上面那几个问题吧。

1. 代码管理方式落后

本来能够说是没有什么管理方式。事实上咱们改代码基本都是直接到线上用 vim 改（致使我如今 vim 几个快捷键用得 66 的）。一旦保存，就会自动生成一份备份文件到指定的备份目录。而后咱们会有代码审核，要调用 linux 的 diff 比较两个文件的不一样，而后截图发到讨论组让其余人审核。有时候改的地方多，要截图好几屏幕。

连 svn 都没有，更不用说 git 了。

今年三月，我开始推进代码管理方式的变化，改为用 git 管理代码。固然，老大是支持滴。我作了几件事：

1. 准备工做
   • 找其余组了解到咱们这边内部有搭了一个 Gitlab，因而到上面建了个仓库。
   • 线上代码整份备份，拷贝一份到我本地。把线上代码目录下，一些没用的东西都移动到一个备份文件夹。例如文件名为：！或者`这一类奇奇怪怪的文件；还有一些开发者我的的备份文件、测试文件等等，通通移出去。这些在移动以前都会把列表发出来，让其余人确认过才移动。
   • 找到程序运行时产生的文件夹，这些是要放到 .gitignore 里面的。
   • 本来超过 100G 的项目文件夹，只有大约 80 MB 的有用文件。大部分都是 log。这 80 MB 的文件里面，还有能够排除掉的，但可能有危险，就算了。这样之后要搭建新环境的时候，只要下载 80 MB 的文件就好了。以后把这些文件提交到 Gitlab 仓库上。
2. 代码同步
   若是使用 Gitlab ，那么要怎么把代码同步到线上机器呢？最简单的就是在线上目录下直接用 git pull 了，只是要记得把 .git 目录屏蔽掉，否则别人直接把你 .git 下载过去，就能获得你整套代码了。固然，也能够在另一个目录 pull ，而后用 rsync 同步到线上目录。后一种方式会比较安全，不过没有采用，多是由于要支持线上修改代码？
   线上修改代码是为了在上线代码后出现问题时可以当即在线上修改代码，而后不能影响到后续代码上线。要补充一点，这个项目没有按期发布版本的概念，一旦完成需求，就当即上线。既然是这样，就不能直接 git pull 。因而我写了个脚本专门用来同步。当线上代码和要更新的代码有冲突时，自动处理冲突——其实就是自动用冲突部分的线上代码覆盖上线的代码。
3. 培训
   上面准备工做作完了，就得向组内其余人推广了。组内只有我那同窗有接触过git，但也是那种 push 和 pull 的程度。此次用的是 GitHub Flow 的方式，就是 Pull Request + 审核，没有人能够直接 push 代码上去。
   我总共组织了三次培训，每次半个小时到一个小时。把 git 的基本使用和 GitHub Flow 的方式都介绍了。而后还写了篇教程。以后你们就开始用起来。

先后大概一个月的时间，前期准备花去大概三周（毕竟还有需求要作）。培训先后跨度一周。培训完的下一周开始使用。算起来应该要从四月初开始算起，到目前为止合并了 760 个 Pull Request。

咱们组四月份的时候来了个新人。当后来谈起 git 的时候，我说了在三月底才逐渐开始使用 git 以及之前是怎样管理代码的时候，她都惊呆了。

2. 测试机

让咱们回到还没使用 git 的时候。

上面说了修改代码时一般要在线上修改，为何不在测试机上修改呢？

• 测试机代码跟线上代码有不少不一样的地方。数据库也有不少不一样。我那个同窗就曾经栽在数据库表字段不统一上。
• 咱们的系统依赖于其余系统提供的数据，在测试机上难以获取所需数据，虽然他们也有提供测试机，但很差找到合适的数据。

不过我也有一段时间是在测试机上修改，而后复制到线上。可是 vim 编辑虽然挺熟悉的，但仍是不舒服。后来就下载 PHPStorm ，在本地电脑上修改，而后经过它内置的 ftp 传到测试机上测试。

为啥不在本地搭建个环境呢？这其实也挺困难的。

• 代码有不少依赖，甚至于有些代码写的是用 linux 的路径。你在 windows 下根本无法跑。
• 把系统跑起来的数据库表要先建好，数据要先准备好，但很差找到须要哪些表。

第一点还好解决，毕竟有虚拟机呀。第二点就比较麻烦，所有数据都同步的话，要几十个G吧。

因而本地搭建环境这点就先搁置了。要等到接下来讲的这件事作完才有继续的可能。

3. 调试

先说以前的开发是如何调试代码的。首先确定是在线上调试，调试的手段是 echo var_dump print_r 这些，直接把数据打印到界面上。是的，你没看错。用户都能看到他们打印出来的信息。

大量的数据暴露给用户，并且我以前还看到把一个接口请求的 key 暴露出来。更惨的是，这是已经调试完，没有删掉的。也就是说存在至关长的一段时间。事实上代码里面有大量的这种输出信息没有删除。所幸直接用户都是公司内部员工，这要是外部人员使用，早炸了。

对于开发者而言，若是是本身写的代码，echo 看一下可能很快就找到问题。但若是是别人写的代码，可能要 echo 一大堆才知道问题在哪。更可怕的是，这若是是系统基础层面的问题，根本不知道在哪找 bug，那代码一坨坨（来自同事的描述）的。

有个比较好的地方是，这个系统有备机。我在备机上装了个 Xdebug，这才使得断点调试成为可能。固然，为了支持多人能同时调试，还去装了个 dbgp。这些在我以前的博客中有写了：php+xdebug+dbgp远程调试（多人）。当时发到博客园首页，还被管理员踢掉哈哈哈。

此后我都是使用 IDE 来断点调试，这才能知道系统究竟是怎么运行的。

4. 本地环境

可以断点调试意味着我可以知道它链接了哪些数据库，查了哪些表。这样就能够开始作配置了。

为了方便之后新搭建系统，我还写了个半自动初始化的脚本。把要修改的配置组织好，而后转化成原系统可用的数据。还提示了要把系统跑起来，须要同步哪几个表格。可是碰到路径依赖的代码时，仍然要再去手动修改代码，而后重试。

这种方式持续很长一段时间，直到我最近接触 Docker 才获得解决。我在 Windows 10 上面装了 Docker。而后对 PHP 镜像作了定制，其实就是额外装了 xdebug 、 composer（PHP 的包管理工具）、一些项目会用到的 php 插件。

通过一些配置的调整，总算是跑起来了。效果还不错~不过还有几个地方须要调整和添加的，后续再继续处理。

5. 单个文件太大

看如下几个数字：

19264 17622 13223 12160 6621 6067 4655

这些是几个主要文件的行数，最大一个将近两万行了。用 PHPStorm 打开后有点吃力，解析要好一下子。

里面实际上是不少个 if-elseif-else 组合成的，每一个分支完成一件事情。其实能够把它们看为一个个 function，事实上把它们抽取为 function 也能正常执行。最大的一个文件由大概 200 个分支组成，平均每一个分支 100 行代码。可是也有很多分支有 5~6 百行代码，3 百行的 foreach 循环了解一下？

后来我作了个改变。前面有提到，它在某一个地方会有一个统一的入口，而后也有一个统一的出口。我另外建了个文件夹，而后建了一个文件做为新的入口，把知足条件的请求转发到这个入口。就像是进入一个子系统。

这个子系统能够直接使用 PHP 的一些特性，例如命名空间。在里面写代码直接用面向对象的方式来，只要最后返回的结果是 json 就好了。这样能够为之后的重构（实际上是重写）作准备，提早写好一些工具类，积累一些须要注意的点。

在实现上面，没有直接使用开源框架。一个是编码问题，咱们项目是 GBK 编码（其实也不是很难解决）；另外一个是之后项目重写的成本问题。目前不用框架，把骨架搭建起来仍是蛮快的。在一些实现上面会去参考开源框架，像 Yii2 和 Laravel ，也会往 PSR 上面靠。

这样单个文件的大小就变小了，变成多个小文件。不少能够重用的代码也能够封装起来，放到类里面。前面那么多年，没有留下什么有价值的代码，实在是惋惜。若是之前有封装一些业务相关的代码，如今要了解业务也比较方便些。

新的代码会写在这里面。若是有旧代码须要维护，且感受能够重构的时候，也会把代码重构到子系统里面。

这个是在 git 以后。由于作这种大规模添加和变动的时候，有 git 会比较好处理。

6. 测试

这项目的测试基本都是在测试机上直接进入网页测试，没有什么单元测试的概念。有时候测试机没办法测试，只能到线上测。Emmm...是挺危险的。

嗯对，没有专门的测试人员。

如今 git 有了、IDE 有了、面向对象也有了，能够了解一下单元测试。正好公司有这方面的绩效要求。

之前那些代码很难测，我先处理的是面向对象这部分的单元测试，引入 PHPUnit。先把工具类的单元测试搞定了。

接着想着怎么测试之前的代码。仍是从单一入口那里入手，一些全局变量都事先声明好，还有一些文件都导入进来，而后调用。固然还要处理其余问题，例如原先的代码里面，会直接 echo 出东西，这些要用 ob_start() 这种拦截下来。不过 PHPUnit 也有对这方面的支持。

7. 文档

这项目没有什么文档，他们的理由是业务常常变化，文档要常常改，麻烦。不过连基础的业务无关的开发文档都没有，确实麻烦。新人来了还得找导师问，由于并无相关的培训课程。

后来我写了篇开发文档，填补了这个空白。（听说写得不错）

自从引入了子系统，也补充了篇开发文档。不过由于结构挺清晰了，不用文档也能开发。

至于业务上的文档尚未写。以前公司的机器在作集群架构调整，目前咱们这边还在作相应改变。调整完成后，我会逐渐把业务文档补充上去。

8. 重构

上面提到这个项目要重构（重写）。这个其实才是我最感兴趣的地方，由于能学到很多东西。到时要向大佬们多请教。若是到时有大腿来指导就行了。

结束

你可能会问，哪来时间作这些事情？不用作需求吗？我说一个数据。咱们加班是没有加班费的，可是有一个误餐补贴。天天加班到八点半后就有 20 块钱，而我上个季度的补贴是 1k+。

这一年间作的事情看起来不是不少，也不是不多，惟一能肯定的是学到的东西很少。这是最让我忧虑的地方。这一点以前咱们部门的一个大佬跟我聊的时候有说过，孤军奋战进步很慢。其实部门里面的高手也是有的，但我不善于使用已有资源这一点是硬伤，要想办法有所突破。

但愿接下去能有更多进步的机会~我也会去多争取这样的机会。