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

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Allen_Tsang/article/details/51930769

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


展开阅读全文

没有更多推荐了,返回首页