? ? ? ? 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，而是放棄外包。上面提到的糟點都是技術上的問題，是可以解決的。而不能解決的核心問題是，外包的產品不是自己的。我找不到理由去優化代碼效率，對頁面微調，不能提出對需求的修改意見。如果我這樣做，會被認為是傻。因為這是甲方的產品，我只需要在規定時間內做過指定的界面、實現相應的功能，就可以了，交貨收錢后管他洪水滔天。
? ? ? ??這樣不可能做出優秀的產品。我可能不是一個安分的程序員，總對產品有想法。我想做一個“好的”產品，而不是很多個“能用的”產品。
? ? ? ??絮絮叨叨說了這么多，希望以后看的時候能不忘初心吧。不知道明年七月會不會再寫？

總結

以上是生活随笔為你收集整理的PHP从入门到接到外包合同，再到放弃的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。