[技術討論]關於低耦合開發的討論

[技術討論]關於低耦合開發的討論

丁丁  15:15:50

求知

誰體會過低耦合帶來的好處 我怎麼覺得現在接觸到的專案 都是遷一發 動全身呢

青潤  15:17:03

你是全新專案，還是歷史專案改造？

丁丁  15:17:19

新的

繼承抽象和介面的方式 完全體現不出多麼易於修改

丁丁  15:18:38

只要有變更 涉及到的source全都要動

青潤  15:19:23

如果是新專案，那你們需要考慮設計上是否有問題。

低耦合也不是所有場景都能用，但是，確實有很大的好處。

丁丁  15:19:45

怎麼讓我覺得 高內聚低耦合 像是歷史遺留概念了呢

青潤  15:19:56

這裡面需要衡量低耦合帶來的好處和付出的額外開發量之間的關係。

丁丁  15:20:19

如果一個專案完全自由散漫的寫 完全不考慮耦合呢

反正都是分工 個做個的

難道算是默默符合了弱耦合麼

一人一個模組 或者一套流程 完事

青潤  15:21:28

不。

那樣的結果，往往是過度耦合。

因為幾乎每一個人都只會考慮更快的結束開發，也就是為了節省開發時間。

丁丁  15:22:03

只能是重複功多了點吧

青潤  15:22:06

這樣的結果，系統耦合度會非常高。

丁丁  15:22:05

是的

高又如何呢

青潤  15:22:42

牽一髮而動全身，就是搞耦合的結果。系統僵硬到一定程度，就不可修改了。

丁丁  15:22:48

專案一樣順利完工 就算有監理也不會挑這個

青潤  15:22:59

或者說，哪怕一個小地方的修改都需要全部專案所有關聯模組的變動。

丁丁  15:23:20

就算我們公司自主研發的專案 都沒人在乎這些細節

說不定過陣子 人都不在了

這是不是隻能算是我們追求軟體精髓的一種完美主義精神呢

青潤  15:23:54

很多公司都沒有人在乎這個，所以，中國的大多數軟體專案，不僅僅是程式碼問題而不可重構，整個系統的開發過程造成的結果就是不能重構。

這恰恰是違反完美主義的。

丁丁  15:25:00

我在公司宣揚一些正確的思想 往往被反對牴觸

對於大多數人 都會直接告訴我 什麼思想 低不低耦合和我有什麼關係

只能用這些 不影響正確定的理論 耽誤專案進度

青潤  15:25:43

我在05年曾經給人寫了一套sms介面平臺程式碼。

交付的時候對方一直擔心新接手的人不熟悉，我對他說，放心，有問題隨時找我，不過我給的程式碼和註釋，基本上應該不會有問題來找我的。

白吃了那頓飯後。

那個新接手的技術人員就沒有聯絡過我。因為我的程式碼的可讀性和註釋都是非常完善的。

這些並不影響開發速度，那套程式碼，我大概一共也就寫了一個多星期。

而此前他們提供給我的程式碼，我看了2個月，最後確認那套程式碼根本不可用。

逼迫我全部重寫。

丁丁  15:26:48

是啊 但是當初寫這些程式碼的人 也得到了相應的報酬

而且解決了勞動力成本

前人栽樹後人乘涼

青潤  15:27:32

做好自己就行了。

這輩子，你不可能讓別人都聽你的，但是，做的事情對得起良心，對得起朋友。

丁丁  15:27:32

低耦合 = 職業道德 了

青潤  15:27:38

不。

我只是描述一個例子，這個例子和低耦合關係並不大。

是關於程式碼質量的例子。

低耦合是需要付出額外的勞動的。因此會耽誤時間，另外在設計的時候，需要一定的水平。

必須能夠看到系統如何降低耦合，將來可能需要什麼樣的改變。

丁丁  15:28:32

我現在越來越覺得 各種思想和設計模式 不適合我國國情了

青潤  15:28:48

呵呵，還是那句話，做好自己。

丁丁  15:29:02

我已經被排擠成另類了

85 90後 不喜歡模式

人家只在乎黑盒

人家從來不喜歡用抽象xx

青潤  15:30:06

做好自己就行了，如果你的職責包括對他們的培養，那也是做好自己，培養他們就是做好自己，如果不包括，那就另說了。

丁丁  15:30:08

不喜歡模式 不喜歡思想

關鍵是我被排擠了

青潤  15:30:30

好了。抱怨的話就留給自己吧。

日月同行(30069932)  15:30:51

感覺做專案可以像丁丁那樣，快餐程式碼。

做產品，以後需要維護的，肯定要考慮以後的可維護性

丁丁  15:30:53

我只是討論討論

青潤  15:30:59

那就是企業的管理問題和你的職業發展問題了。

要麼你勸說你的老闆聽你的，要麼你找人幫你做到這一點。別的，就都是自己的事情了。

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE