PHP从入门到接到外包合同，再到放弃

        15年7月，我自学两个月PHP后进入鸟窝（公司），接受作为程序员的第一份工作。那时候真是一头纯纯的菜鸟，我甚至连ls命令都不知道。
        我的第一个项目是为一个正在运行的网站，写一套相应的接口， 供App前端调用。项目很小，代码量也小，现在看来是很简单的工作。而当时我在阅读源码时的感觉，就像做英语考试的阅读理解：一个个单词我都认得，但拼起来是几个意思？不过我学习得很快，这个项目也算顺利完成，可是App的体验并不好。这个项目让我对web开发有了初步的了解，源码也对我的代码风格产生了一定影响。  
        由于公司一直招聘，我见识到一些其他的PHPer。其中，echo(一个人)看过代码后，指出我没有真正的理解MVC。受第一个项目的影响，我当时基本上没有使用M层，即把数据库的操作放在C层，所以实际上是VC结构。我那时曾经思考过，数据库操作完全可以放在C层，M层有什么意义？后来我带的实习生阿曼，也有过类似的困惑。问题的答案是很明确的，就是为了提高代码复用率。
        菜鸟们总是喜欢把所有代码，写在一个文件里，一个类里，一个方法里。因为这样简单，符合一般的线性思维习惯：想到哪里，写到哪里。但这显然不是一个合格的程序员思维。模块化、面向对象，才是PHPer的真理。我对阿曼说：”引用代码，不要复制代码“。
        在相当长的时间里我的指导思想是，先把想到的写出来。这种想法让我吃尽苦头。如果只是研究一个新的功能，这样想没有问题。但如果放在一个项目中，后果可能是灾难性的。我曾经多次修改一个项目的结构，因为要扩容，添加新功能。这使我们的工作量直线飚升，因为底层结构一改，几乎所有人都要做出修改。这就是为什么架构师如此的重要，我无法想像一个大型项目频繁地修改底层架构会发生什么事。
        所以动手前一定要先想一想，哪怕只是简单的估计项目规模、划分模块。
        不久后，我开始全权负责招聘，这项工作让我有好多体会、感慨。一开始我的方法就是看简历，觉得还行，就叫来面试。但这样有点虚，因为看不到应聘者的代码。于是，增加一个环节，做测试题。题目是我自己出的，PHP的测试题考察数组操作和编写类，Js（前端）考察dom操作。
        这让我看到很多人写的代码，人和人真的很不同。PHP题一般都能做完（实现功能），但在代码规范，执行效率上千差万别。印象比较深刻的一个小伙子，刚毕业，有实习经历，他完成得很好，但在交谈过程中，显得很不自信。他认为是实习经历让他有成长，也留下了阴影。还有一位有四年工作经验的PHPer（我应该叫他前辈），他当然也完成了题目，但是我觉得他的答卷对不起四年经验。因为他用了最容易想到的，效率最低的实现方法，与一个实习生没什么差别， 甚至代码很不美观。
        Js题目的完成度很低，高质量的代码很少。我后来意识到题目的方向可能错了，逻辑考察过多，就像为了出题而把问题复杂化。前端工程师的日常工作很少会遇到比较复杂的逻辑。当然也有做得好的，他们让我见识了一堆东西，webpack,  Angular, Vue, Backbone, gulp等等。我想说，”贵圈发展得太快，我跟不上“。
        实现一个功能往往有很多种方法。你可以把一段代码封装成一个函数，也可以是一个类，甚至不封装。你可以把逻辑代码写在M层，也可以写在C层，甚至写在V层，用js来实现。不同的解决方案，就是水平的体验。写代码不能满足于只实现功能，我正在追求优雅的路上。
        与很多PHP初学者一样，我第一个学习的框架是ThinkPHP。TP很好，方便，简洁，易学，文档齐全，能找到一大堆教学资料，大多数PHPer也都接触过TP, 交流零成本。我甚至认为以后的项目都用TP就可以了，直到遇见Laravel。我们接到一个微信公众号开发外包单，对方坚持使用Laravel。于是我们只能边学边做，慢慢地我被它的强大和优雅所震撼。我不打算对比不同框架的优劣（这个问题永远都吵不完），只谈代码风格。
        Laravel5.2要求的最低PHP版本是5.5，它大量使用新的特性和标准，如闭包、Reflection、psr、spl、静态绑定等等，这让Laravel看起来很“高大上”。在阅读源码过程中，会遇到好多“新”的东西，这让我对PHP的理解更深刻和广阔。
        当然解决问题不一定需要“高大上”的代码， 但是程序员总是追求“高大上”，不是吗？
        由于大量的外包工作，我接触过很多cms或框架，如discuz, ecshop, shopnc, wordpress, dedecms, 小猪cms, WeiPHP， 方维p2p等等，有一些对PHP的要求还停留在5.2。
        在此忍不住吐糟一下外包，好一些甲方明确要求使用某个cms，在此基础上“二次开发”。他们认为这样可以压低成本，“套一下模版，改两行代码就可以了”。理论上是对的，但是甲方需求“一定会”修改的。比如dedecms的页面都是预先生成的静态html文件，现在要加入一个动态的页面，怎么办？当然也有套的很好的，我见过用wordpress做企业网站，就好像彻积木一样拼出来，真的很快。
        我还见过这样的需求，“使用原生PHP开发，不能使用框架”。对于是否使用框架的争论，早就有了。我的答案是，“无法理解拒绝使用主流框架的想法”。理由之一是担心框架有未发现的bug，其实所谓的不用框架的原生PHP，难道不封装数据库操作层？不用模板引擎？不实现路由功能？如果这些都做了，与一个开源框架何异？而且哪来的自信，觉得自主开发的框架，可以比主流框架封装得更好，执行效率更高？

        我是开源的忠实粉丝。由于多人协作必须使用版本控制，我选择用git。为什么不是SVN？因为git 看起来更“高大上”。由此关注到GitHub，但真正使用开源，还是从学习用Laravel开始。从各种开源项目中，我吸收到很多营养，同时git 和 composer 也解决了项目开发的很多问题。后来我也开始写几个项目放在GitHub，到现在还没一颗星....

       我还稍微学习了一下Python, 主要是为摆脱烦人的bash。还有node.js，这个只能说还处在"hello world"的阶段。

        文章的题目说的放弃不是指放弃PHP，而是放弃外包。上面提到的糟点都是技术上的问题，是可以解决的。而不能解决的核心问题是，外包的产品不是自己的。我找不到理由去优化代码效率，对页面微调，不能提出对需求的修改意见。如果我这样做，会被认为是傻。因为这是甲方的产品，我只需要在规定时间内做过指定的界面、实现相应的功能，就可以了，交货收钱后管他洪水滔天。
        这样不可能做出优秀的产品。我可能不是一个安分的程序员，总对产品有想法。我想做一个“好的”产品，而不是很多个“能用的”产品。
        絮絮叨叨说了这么多，希望以后看的时候能不忘初心吧。不知道明年七月会不会再写？