PHP從入門到接到外包合同，再到放棄
阿新 • • 發佈：2019-01-23
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，難道不封裝資料庫操作層？不用模板引擎？不實現路由功能？如果這些都做了，與一個開源框架何異？而且哪來的自信，覺得自主開發的框架，可以比主流框架封裝得更好，執行效率更高？
我的第一個專案是為一個正在執行的網站，寫一套相應的介面， 供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，難道不封裝資料庫操作層？不用模板引擎？不實現路由功能？如果這些都做了，與一個開源框架何異？而且哪來的自信，覺得自主開發的框架，可以比主流框架封裝得更好，執行效率更高？