作者jej (賊一賊)
看板Soft_Job
標題Re: [請益] 比物件導向更先進的程式設計思想？
時間Fri Oct 9 13:03:16 2020
依照目前看CodeReview
大部分人寫程式的方式
其實都披著OOP的皮
寫不是OOP的程式
甚至還看過很愛嘴別人的主管
寫著奇門遁甲的if else
只能說搖頭阿
多數的程式沒有要使用多型的跡象
版上的人一定會說
那是你公司爛阿
但本肥認真說還真的恭喜你
本肥在軟體業駐點到各種行業
再到目前歇腳的金融業
真的用OOP的
認真說不多
會運用GoF JavaEE的Pattern
還用錯的還不在少數
先不要討論有沒有新思維
真正落實OOP
才是目前台灣各產業資訊體系 軟體業
先跨出去的第一步
當然軟工當中的手段
也還是要落實啦
總歸一句
基本功才是神功
不要小瞧他了
-----
Sent from JPTT on my OPPO CPH1721.
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 103.246.208.241 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1602219798.A.AB5.html
1F：推 CoNsTaR: OOP 還是算了吧，落實這個要幹嘛 = = 10/09 13:54
2F：→ x246libra: 為什麼不落實？ 看來樓上是標準的能動就好工程師 10/09 13:56
3F：推 tonytonyjan: 事實上是一堆人連 SOLID 都沒聽過 10/09 13:57
4F：→ x246libra: 我想問問 職場真的完全沒人看重 介面抽象嘛？ 10/09 13:58
5F：→ x246libra: 我以為是我非本科轉職 去的公司爛 才有一堆爛CODE 10/09 13:58
6F：→ x246libra: 自己實力不足 去不到好公司 好奇知名公司也不管抽象化? 10/09 14:00
7F：→ Nitricacid: 管抽象幹嘛 被爛 code 炸死的再換一個進來就好了阿10/09 14:02
嗯 悲慘的就是對台灣的老闆來說
再洗一批便宜的牛肉就好了
再說抽象與多型
就我看到現在只有少數的公司
對於資料庫的設計
能夠曉得 ER Model和Class Diagram的差別
多數並沒有資料封裝 繼承 多型的概念
更遑論前端的Controller
明明做的都一樣
可以更抽象一點
大部分也還是一個Base Class
每個Controller繼承到底
然後理論上一個物件應該各司其職
但混著用的還是大多數
※ 編輯: jej (103.246.208.241 臺灣), 10/09/2020 14:16:23
8F：推 x246libra: 樓主這樣一說 讓我猶豫是否要繼續花時間研究 DDD10/09 14:20
9F：→ x246libra: 似乎花時間在刷題 比較可以去好公司10/09 14:21
10F：推 dream1124: ER Model 和 Class Diagram 分不清也太扯了吧…？10/09 14:25
真的不扯
可以請人把公司的資料庫設計
分別畫出他的ER Model
和Class Diagram
然後請他解釋這兩張圖
是不是幾乎一樣？
甚至還會有人反饋回來
幹嘛畫Class Diagram
而且多的是套過架構
沒有深入架構讓他可以封裝繼承多型
11F：→ dream1124: 另外最近意識到軟體業和資訊業是不同的，你是在資訊業10/09 14:25
12F：→ dream1124: 資訊業大多在開發內部營運用系統，鮮少程度好的人愛去10/09 14:26
13F：→ x246libra: 可以理解為 多數公司以資料庫驅動來專寫程式？10/09 14:27
14F：→ dream1124: 除非那是開發內部營運用系統產品的公司10/09 14:27
※ 編輯: jej (103.246.208.241 臺灣), 10/09/2020 14:31:05
15F：→ dream1124: 既然程度好的不愛去，想去純軟賺更多那程式碼自然難好10/09 14:28
16F：→ x246libra: 而不是根據領域驅動開發程式10/09 14:28
17F：→ dream1124: 我認為若是去純軟駐點的話狀況應該會好一點吧10/09 14:28
18F：→ dream1124: 至少我最近接觸的純軟駐點不論設計或技術都滿新的10/09 14:30
19F：→ dream1124: @x246libra 我猜他的意思是正規化做得不足？10/09 14:30
20F：→ dream1124: 或著那間公司能是用「單據」的思維在開發系統10/09 14:34
21F：→ dream1124: 而不是用工作流程的資訊流觀點在發展系統10/09 14:35
22F：→ dream1124: 以前公文或單據時代的資料欄位直接對應table欄位10/09 14:36
23F：→ dream1124: 然後你可能會看到一些正規化做得很奇怪的肥肥table10/09 14:37
24F：→ dream1124: 對應到系統 Entity 的時候就變成一個一個value object10/09 14:38
25F：→ dream1124: 於是才會得出「為何要畫類別圖？」的想法10/09 14:40
26F：→ dream1124: 想到這就覺得原PO看得清問題卻沒崩潰實在很強 XD10/09 14:41
27F：→ dream1124: 我一開始看到那種系統的時候覺得人生有夠灰暗 哈哈10/09 14:42
28F：→ dream1124: 回頭看發現自己講錯了 用工作流程的資訊流這說法不對10/09 14:44
29F：→ dream1124: 應該說那些公司可能只是作業電腦化，但沒重新設計流程10/09 14:44
30F：→ dream1124: 雖用電腦但流程沒變，只是資訊寫進電腦而非寫在單據上10/09 14:46
31F：→ dream1124: 如此一來物件導向做得差自然不令人意外10/09 14:53
32F：推 tsao1211: OOP是萬靈丹嗎？別人在檢討不要硬用OOP然後你在那邊要落10/09 14:59
33F：→ tsao1211: 實10/09 14:59
我知道反OO派
這讓我想到以前有個主管對我說過
與其誤用OO不如不用
甚至有些為了研究Pattern
走火入魔的也不在少數
反而增加維運上的困難
※ 編輯: jej (111.71.89.144 臺灣), 10/09/2020 15:05:05
34F：推 balaking: 語言只是工具，C、perl、Java、Lua都有其各自擅長的特性 10/09 18:31
35F：→ balaking: 邏輯不好寫出一堆vulnerabilities的最會互相鄙視 10/09 18:32
36F：→ drajan: 「鄙視」是源自於對自身能力的不安全感 只好寄生在"語言" 10/09 18:35
37F：→ drajan: "框架" "domain"等想像的共同體上來強化自尊 本質上是自卑 10/09 18:36
38F：推 alihue: 應該說...你見過的就只是會需要駐點的行業.自然不重視軟工 10/09 18:47
39F：推 balaking: 所有的選擇都是trade-off，沒什麼好比的 10/09 19:10
40F：推 drajan: 正確，看似很爛的科技在不同時空背景可能反而是首選 10/09 19:41
41F：推 clamperni: 你在哪工作? 10/09 23:23
42F：噓 CoNsTaR: 回某 x 如果所有你想要的就只是那種不需驗證的直覺的“ 10/10 01:34
43F：→ CoNsTaR: 抽象化”，那你就繼續落實你的 Oh-Oh 吧 10/10 01:34
44F：→ CoNsTaR: 記得不需要看看外面的世界，然後要繼續把自己無法理解的 10/10 01:34
45F：→ CoNsTaR: 人都冠上一個讓你自己可以自嗨的標籤哦 10/10 01:34
46F：→ superpandal: 然而這都只是理想 抽象用的好不好誰來定？ 我自己都 10/10 07:41
47F：→ superpandal: 覺得如果底層都我自己寫的一定很精美摟 可惜現實上就 10/10 07:41
48F：→ superpandal: 是一堆歷史共業摟 10/10 07:41