Re: [閒聊] 不用OOP的技巧

[qrtt1 (有些事，有時候。。。)]

        看了標題與內文讓我沉思了很久，「不用OOP的技巧」

        想著有些項目是否能稱為這是「技巧」或著說是「沉淪」!?



        引述自己之前回文寫的話：


        [請益] (寫程式的)熱忱?!
        https://www.ptt.cc/bbs/Soft_Job/M.1386172787.A.9A0.html


        理想上 coder 要有隨著年資越長捨棄更多的壞習慣，

        養成更多的好習慣。


※ 引述《F23ko (名無乚)》之銘言：
: 上面在戰OOP，有人把OOP批的一文不值
: 我覺得這算是時代的眼淚吧？
: OO的出現製造了一個「斷層」
: 把一些年資十年以上，而且沒跟著更新技術的程式設計師給區分開了

        帶來斷層的不是 OOP 本身。

        所欠缺的是在 OOP 盛行的年代，

        各家 OOP 語言的開發者對自身工作方式的「反思」



        OOP 剛開始的「世界觀」試著把所有東西都對應成 Class

        就像現今多數的入門書籍那般，

        弄了個「車」「形狀」「鳥類」什麼的，

        但後來發現每個人對於觀察事理的「粒度」差異蠻大的

        要如何將事物一般化或特別沒有太多的準則，

        弄得太「細緻」對於 caller 理解這個「小世界」的負荷加重了些

        弄得太「粗略」又難適應一些需要例外規則的情況。

        不過好在，大部分的程式開發人員只需寫出符合工作情況的 code 就行了

        頂多在程式內多個條件判斷，讓它能適應某種例外狀況。

        那麼當例外規則越來越多時該怎麼麼呢？



        諸如此類的針對實例的反思與提出解決策略，才是該補上的「斷層」！

        這些檢討與反思多數都被收納在 Design Pattern、Refactoring 的書籍裡

        趕時間也可以直接看 Clean Code 會小本一點。



        雖然書中的主要核心是繞著 OO 語言打轉的，

        但那可以被用在許多語言，即使有些語言沒有類別，

        多數的情況我們不是在處理「像 class 這種靜態的樣版」

        而是讓特定的程式片段更有意義的聚集在一起

        它可以是個 fucntion (或一組 function)，也可能是個 closure。

        不管你用的是什麼語言，有沒有 OO? 都是需要培養一些「觀點」

        像上述提到的「書」或「概念」都是其他人的「經驗」集合，

        有人替我們痛苦過，並且留下了紀錄，就別浪費太多青春重蹈覆轍。



        其實要完全沒有 OO 有可能嗎？

        至少我們大部分的人沒有經歷過完全 Procedurl Programming 的年代

        http://en.wikipedia.org/wiki/Procedural_programming

        寫出來的東西多少還是會有 OO 的影子存在


: 我任職過的其中兩間公司的程式專案有十年以上的歷史
: 一個是JSP一個PHP
: 都沒用物件導向
: (雖然JAVA是物件導向的程式，但是一開始寫的那個人把他當C在寫，沒用物件導向)
: 而且都不是小系統，一個是電子公文、表單系統，一個是博奕類系統
: 專案資料夾內的檔案數破萬
: 當時我的工作是維護系統
: 弄一兩個月之後就能弄得很順了
: 當然也學了一些，OO還沒出現時常用的一些技巧
: 1. 變數全部都放在檔案的最上面
:    變數名稱通常很長，這是為了避免撞名 (因為都全域變數)

        就算沒有 OO 也可以把「狀態」集中在「容器」內傳遞。

        就像在寫 C 的時候，把一些狀態收納在 struct 內一般

        然後將這個 struct 當作參數傳到為它而寫的 function

        即使在一個沒有 OO 的語言，也能有效的管理變數的 scope


        差別只是在於 behavior 是以物件為中心，

        或是以 procedure 為中心去操作資料



: 2. 剪下貼上也是有技巧的
:    如果變數的命名習慣跟程式風格統一的話
:    是可能做到，把這邊的功能copy到另外一個檔案中又能正常運作不用改的

        儘可能把 copy & paste 的內容，改用 function 集合成一個動作唄。

        至少你在 copy & paste 時，只要換 function 的參數名稱

: 3. 批次取代是好東西
:    有人說剪下貼上會造成「改個小地方就需要修改全部」
:    這用全域搜尋以及全域取代就可以解決掉
:    會正規表示式的話更輕鬆

        把重複的東西用 function 取代，

        如果是網頁部分 jsp 其實可以

        1. 使用 include
        2. 自訂 tablib
        3. 改用樣版引擎或是 sitemesh 這類的東西


: 4. 不要看程式碼
:    在找什麼功能，或是要修BUG時，不要一行行的去找
:    那很浪費時間
:    要學會找程式碼中的關鍵字，或是function、變數名稱
:    用全域搜尋去把可疑的地方撈出來看

        這個善用 logger 的訊息來找會再讓你更快一點，

        另一個適用於各語言的終極兵器應該是 debugger

        誠心建議寫寫 unit test :)

: 以上是一些，非OO的狀況下處理的方式
: 那些上個世代的程式設計師似乎挺習慣這樣做
: 我要推MVC或是其他新的方式給他們，還推不動.....

        我想與世代的關係不大，我知道一些比我早入行的前輩

        他們依然保持著讓我追不上的進化速度......Orz


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 59.115.98.31
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1425647748.A.4C0.html
推 et282523: 推~
→ qrtt1: 好尷尬，寫完了，發現原來的文章不見了.
→ dreamnook: 原文砍了 回文辛苦了 XD
推 zxc1020305: 推
推 F23ko: 推這篇
→ F23ko: 原本那篇連續被噓廢文，我就在想說那些現象對其他人說也不
→ F23ko: 是那麼有趣的歷史...
→ qrtt1: @F23ko 我有接手過那種 style 的 code，在能力所擇的範圍
→ qrtt1: 我加了 unit test 並把一些 duplicated code 抽成 utils
→ qrtt1: 在新加功能、修 Bug 時才加 test case & refactoring
→ qrtt1: 其他舊的部分，還不知道會不會用到就先放著了。
→ F23ko: 我在兩間公司都試著這樣幹，一間是告訴我「這樣很難維護」
→ F23ko: 就把我寫的class拆掉，改回原本那種寫法。另外一間還比較會
→ F23ko: 去吸收一下新的東西。真的還是要看人....
→ F23ko: 啊對了，跟我講「很難維護」那間公司還在用table排版
→ csfgsj: 給樓上，不要怕網路上的酸酸。像哥哥早就鍊成金剛不壞之身
→ csfgsj: 他們越罵你，收視率就越高。跟政論節目一樣
→ dreamnook: 並不是金剛不壞之身 只是很會跳針
推 iceonly: 把一切都當成酸酸，就跟把一切鄉民都當成網軍一樣
推 typepeter: 實用
推 JustinHere: 不想用 OOP 嗎？…XD http://goo.gl/w8caUk
推 roger00: 推