Re: [請益] 從php5.6跳到php7.1值得嗎

[tkdmaf (皮皮快跑)]

※ 引述《miniear (Littlear)》之銘言：
: 他說我們是作為一個開發者，而不是使用者...(這邊我就霧煞煞了
: 又舉例好幾年前接案的客戶自己請人來協助開發，結果那個人只會用framework跟mysqli
: ，沒多久就走了...(我師父因此蠻得意的~
: 而且許多客戶伺服器也不能直接改用php7，
: 再者他深信php5是不會被淘汰的...
: 但也沒有制止我繼續去搞這些，
我還是用回文的講一些事好了，當中會帶出我寫ios的經驗。
你提到你師父對於使用框架跟mysqli的經驗談。
我想知道的是，他對mysqli有意見的話。
敢情他是使用pdo？
如果不是pdo而是mysql指令集的話。
那就表示關於sql injection的過濾他都要自己土砲了。
還是說……其實他並沒有關注到sql injection的問題？
換個角度來看，php官方為什麼要在php7時拔掉mysql指令集。
又為什麼在php 5.6時就已經建議別在使用mysql指令集？
所以到底你覺得這邊是該聽你師父的？還是聽官方的？

再來就談框架好了。
我先說明，在ios的開發中，第三方元件庫也是稱之為framework。
其立意相當明白：聽工程師直接解決繁鎖而複雜的事。
如果沒有這樣的東西，就像我前陣子在刻的ios版的日曆。
如果沒有第三方元件庫，我連底層都得自己來。
但因為有第三方元件庫，引用之後我只要改好上層ui就好了。

就php來說，使用框架是有一些目的的。
1.以MVC架構來分離程式碼和視圖的分界，讓程式設計師專注於開發，而網頁設計師能
  專注在畫面的設計上。
2.提供良好的功能性類別及輔助函式來快速解決問題。
3.一致性的設計規範。
4.清析明確的統一架構內容。
5.官方統一制定的開發文件。
6.快速的設定。
7.方便的Active Record或ORM
8.第三方元件庫的載入支援(composer)
9.較統一性質的命名原則。
10.良好的資料庫遷移系統。
(後面就請大家繼續補充吧！)

基本上，所謂土砲，也只是讓你了解這些較核心功能的設計方法。
但前提是，你要有足夠的時間來去研究，那都是在工作以外來再花時間的。
但如果你當下就要解決或滿足客戶的需求時。
你有那麼多的時間來研究？還是善於利用資源來立刻解決你手上的問題？

講白的，我其實也算是土砲組的。
因為我很喜歡「浪費時間」去研究那些東西到底在核心是怎麼做出來的。
我也會想說要不要來「自幹」一個一樣的東西。

但問題是，真的在做客戶的東西時。我還是會去找資源。
看什麼東西能最快把問題處理掉。

什麼東西都要自幹出來其實是相當吃力不討好的事情。
更重要的是：常常自幹說得一口好方法的人………卻常常到了新的專案還在自幹。
徒然浪費更多的時間了。

我相信，等你跟著你師父越久……你就會發現越來越多問題。
但畢竟是前輩，你也不好直接反駁他。
只能說：那麼你就當現在是學習，然後把自己的能力提到一個程度就閃人吧。


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 175.181.255.20
※ 文章網址: https://www.ptt.cc/bbs/PHP/M.1511681561.A.9AB.html
推 miniear: 謝謝大大提點，今天才看你的pdo教學，這東西我是第一次
→ miniear: 聽到...對你來說應該很扯吧，哈哈
→ shadowjohn: pdo都出好幾年了...還沒用過就打屁股了
推 miniear: 呵呵，我學得都是$result=mysql_query($sql); 不過用這
→ miniear: 個有比較差嗎
→ mimikillua: 比較不安全
推 miniear: 看完t大的sql injection影片就明白了，謝謝~
→ shadowjohn: 標題都5.6->7.0，還在mysql_query…卡稱天try
→ shadowjohn:            7.1
→ miniear: 我目前都是用5.6啊 7.1是想自己去學的
→ crossdunk: ok 你師父連pdo都沒教你 塊陶啊
→ newversion: 7.1用mysql_query ,不是殺雞用牛刀,是殺螞蟻用核彈@@
→ xdraculax: 客戶環境很常連5.6都沒有，我是都定在5.3
→ tkdmaf: 不是吧？7.1用mysql_query就好比給你核彈……只有殼！
推 bakedgrass: 你跟著你師父結果PDO跟Injection都不知道，他就讓你用
→ bakedgrass: mysql_query...這師父如果不是不專業就是不盡責
→ bakedgrass: 7.1用mysql_query就是你身邊有一堆好用的工具給你殺雞
→ bakedgrass: 結果你用一把隨時會彈回來傷到你的小刀在殺
→ tkdmaf: 重點是這把小刀還完全不利……
→ newversion: mysql_query injection 隨便Google就一堆了~~
推 st1009: htmlentities($v,ENT_QUOTES,'utf-8');
推 st1009: 如果所有輸入都用上面函式處理過，會不會安全點阿...
→ st1009: 因為我把相關函數弄成包了，不知道怎改成PDO...沒時間研讀
推 st1009: 其實最大的問題是$row = mysqli_fetch_assoc($result)
→ st1009: 我其他地方都是用這樣子的函式去叫，改成PDO，要改很多檔
→ st1009: 案的code... 不知道有沒有可能PDO回傳$result，可以這樣叫
推 shadowjohn: 有，快去看php manual，然後快去改
→ MOONRAKER: 對，快改，反正想辦法用prepared statement
推 tsao1211: 現在學php，一定是要學pdo
推 st1009: 所以一樣可以用$row = mysqli_fetch_assoc($result)喔？！
→ st1009: php manual有寫怎用嘛...我研究研究...
→ st1009: 我忽然覺得不該問有沒有可能，應該問怎做 :P
→ st1009: 是說htmlentities有任何破綻嘛？我自我測試感覺其實超安全
→ jonlee: htmlentities 跟 sql injection 不相干~ :)
推 st1009: 有關吧(?htmlentities($v,ENT_QUOTES,'utf-8');
→ st1009: 這樣處理過之後，我這測試injection和XSS都pass
→ tkdmaf: 其實對於輸入有filter_input()這個函式可以用。
→ tkdmaf: 所以在土砲狀態時我都不使用$_POST來處理
→ tkdmaf: 但不管怎麼說，對於任意來源還是用pdo或mysqli來prepare
→ tkdmaf: 一定必須要這樣處理，因為這已經是最後一道防線了