※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1464373625.A.CE0.html
推 wesley234: 觀念正確,腦袋清楚05/28 08:07
→ wesley234: 除非人家想要改Code,否則對於一個呼叫者來說05/28 08:09
→ wesley234: 根本懶得看細節05/28 08:09
→ wesley234: 人與人之間是合作整合的關係,各自負責不同的部分05/28 08:11
→ wesley234: 不是都做一樣的事,然後相互比較看誰強,這跟學校不同05/28 08:12
→ wesley234: Code太髒,苦的是接手的人,或者是未來的自己05/28 08:13
推 comesuck: 不是每個人的心態都這麼健康的...05/28 10:48
推 comesuck: 聽不懂抽象化是什麼的比想像中的多...05/28 10:57
→ GoalBased: 聽不懂又整天掛在嘴上講的可怕05/28 11:29
推 abc0922001: 看別人的Code,起手勢不是「寫這麼爛都看不懂」05/28 13:25
推 sunsamy: 請問policy based design的overloading的Template泛型05/28 20:44
→ sunsamy: 最終runtime實現方式也是一堆case或if else在那比對?05/28 20:44
→ sunsamy: 這樣效率會好嗎?不曉得我認知有沒有錯?05/28 20:45
推 kiwatami: 可是瑞凡 在接維護的人難免都會需要改程式05/28 21:41
→ kiwatami: 這個時候就需要看程式碼05/28 21:41
→ kiwatami: 你這篇的角度比較像是 api 使用者05/28 21:41
推 kiwatami: 其實有時候只是老闆希望產生的結果從 a 改成 b 05/29 09:04
→ kiwatami: 而這個演算法剛好是產生結果的核心部分05/29 09:04
→ kiwatami: 這樣不管怎麼抽離都會需要改程式碼05/29 09:04
→ kiwatami: 所以程式的可讀性與文件才會這麼重要05/29 09:04
→ kiwatami: 這也是為什麼我覺得你的說法比較接近 api 使用者05/29 09:04
推 comesuck: kiwatami 你指的應該是BO(or DAL)使用者吧05/29 10:29
推 comesuck: 只要當初寫code的人體質很差,很容易就會維護到這種三四05/29 10:32
→ comesuck: 個功能都擠到一個function裡做 05/29 10:32
推 comesuck: 但這些問題會一直累積到要改「機制」or「規則」的那個人 05/29 10:39
→ comesuck: 身上05/29 10:39
推 comesuck: 不用在意業界生態如何,用對的方式寫code就好05/29 10:50
推 comesuck: 不要被「實務上」魔人牽著走;因為我認為「因為我不懂,05/29 10:57
→ comesuck: 所以不這樣做」不等於「實務上」05/29 10:57
推 comesuck: 情境大致上是這樣:「為什麼不畫Uml?」、「為什麼不用de 05/29 11:02
→ comesuck: legate?」、「為什麼function一次做五件事?」答案開頭05/29 11:02
→ comesuck: 都會是「實務上沒人這樣做...」05/29 11:02
推 comesuck: 最後一個問題改成「為什麼function做五件事不拆出來?」05/29 11:04
推 kiwatami: 我指的 api 使用者其實就是一般開發者05/29 11:10
→ kiwatami: 通常不需要管原始碼 只要負責呼叫 method 就好 05/29 11:10
→ kiwatami: 這樣才符合原 po 提到的 1234點05/29 11:10
→ kiwatami: 接維護的人不太可能不需要讀原始碼05/29 11:10
→ kiwatami: 差別在於讀的範圍多寡而已05/29 11:10
→ kiwatami: 其實就算只有一個功能 複雜的演算法閱讀起來也很花時間 05/29 11:10
→ kiwatami: 如果改動幅度很大或是牽扯到資料來源內容的變更05/29 11:10
→ kiwatami: 這樣想不讀都不行 因為要評估重寫的可行性05/29 11:10
→ kiwatami: 以及是不是有把握重寫後的效能可以接近或是超過原本的05/29 11:10
→ kiwatami: 在這種情況下不論原本的架構有多好 都需要去讀原始碼05/29 11:10
推 comesuck: 原po針對的是演算法的部分;架構切割不完全(沒有各自負05/29 12:19
→ comesuck: 責功能的class or method)05/29 12:19
推 comesuck: 只要開發者開始負責某功能,而資料存取不是透過外部(ex 05/29 12:32
→ comesuck: :http api)取得,那所有這個功能相關的演算法、資料存 05/29 12:33
→ comesuck: 取 source code他都必須trace 一遍05/29 12:33
推 comesuck: 至於演算法複不複雜,算其次;這個演算法符不符合需求do05/29 12:37
→ comesuck: main的情境,才是維護的人該注意的05/29 12:37
推 comesuck: 跟需求落差很大的source code,對使用者來講毫無用處05/29 12:43
推 comesuck: 甚至會誤導方向 05/29 12:45
推 kiwatami: 接維護通常是驗收後的程式了05/29 22:22
→ kiwatami: 怎麼會有跟需求落差很大這種東西...?05/29 22:22
→ kiwatami: 原po第一段提到為什麼要閱讀 但接維護沒有為什麼05/29 22:22
→ kiwatami: 要改功能就是要讀 要修 bug 就是要讀05/29 22:22
→ kiwatami: 所以才說原 po 是從一般使用者的角度 才有所謂要不要讀 05/29 22:22
→ kiwatami: 第二段其實有點偏離主題 因為通通寫在一起不會跑比較快05/29 22:22
→ kiwatami: 同理功能分離效能也差不了幾微秒05/29 22:22
→ kiwatami: 所以效能問題不太會牽扯到這個東西05/29 22:22
→ kiwatami: 這反而是開發速度與維護速度的問題 05/29 22:22
→ kiwatami: 而 原原 po 要探討的就是高效能複雜的演算法05/29 22:22
→ kiwatami: 以及普通效能但可讀性高的演算法該如何選擇05/29 22:22
→ kiwatami: 也就是未來的可維護性 怎麼複雜度反而變成其次考量呢?05/29 22:22
→ kiwatami: 是瓶頸的不管多複雜都要用 但解法不一定只有一種05/29 22:22
→ kiwatami: 這反而是寫程式最花時間的時候 選擇使用哪一種方法解05/29 22:22
→ kiwatami: 以及評估各方法間的效能差異05/29 22:22
→ kiwatami: 為了解決問題 就算接手的人要花一個月才看得懂 05/29 22:22
→ kiwatami: 也得硬著頭皮寫下去 註解超多行 文件超厚也得寫 05/29 22:22
→ kiwatami: 反之就盡量維持高可讀性 因為不是重點05/29 22:22
→ kiwatami: 其實 原 po 說的並沒有甚麼不對的地方05/29 22:22
→ kiwatami: 只是出發點跟原原 po 要探討的有點不同而已05/29 22:22
推 comesuck: 可能最後有點扯遠了XD,但「驗收過」不等於「功能符合05/29 23:17
→ comesuck: 需求」(起碼要有9成才算);但經驗遇過的很多都是功能 05/29 23:17
→ comesuck: 「部分符合」(5成),驗收先過,之後再補。05/29 23:17
推 comesuck: 至於功能通通寫在一起,影響最大的不會是效能;影響最大05/29 23:21
→ comesuck: 的會是可讀性與可擴充性;class功能職責區分不明確,新05/29 23:21
→ comesuck: 功能程式碼找不到地方擺,就必須先重構05/29 23:21
推 comesuck: 對,原po一開始確實針對原原po的問題回應(開發);只是 05/29 23:32
→ comesuck: 後來的推文、編輯回文,情境轉成維護;是兩個討論主題05/29 23:32
→ ripple0129: 差不多是這樣,一開始就看原始碼我也覺得不如ㄧ開始05/30 08:36
→ ripple0129: 先寫測試程式,結果都如預期事實上原始碼可以跳過。一05/30 08:36
→ ripple0129: 些pattern的用意也是讓你可以不用管底層實作05/30 08:36
推 kiwatami: 驗收過待補不會交維護 而且那也是整體功能有缺05/30 10:26
→ kiwatami: 怎麼可能有演算法跟需求落差很大這種事?05/30 10:26
→ kiwatami: 那寫這個演算法出來是練打字嗎?05/30 10:26
→ kiwatami: 演算法他就是一個完整的功能05/30 10:26
→ kiwatami: 他不會只有一個 method 也不會有什麼架構問題05/30 10:26
→ kiwatami: 也不需要考慮介面什麼的05/30 10:26
→ kiwatami: 執行緒可能也不只一條05/30 10:26
→ kiwatami: 純粹就是為了解決問題所以邏輯上比較複雜05/30 10:26
→ kiwatami: 這種演算法怎麼可能說重寫就重寫05/30 10:26
→ kiwatami: 要修改的部分也可能是其中的好幾個地方05/30 10:26
→ kiwatami: 而在這樣的過程中完全不用讀程式碼?05/30 10:26
→ kiwatami: 還是說只有讀到int a = b; 才算"讀"程式碼?05/30 10:26
→ kiwatami: 你說的比較像是各功能間配合的"開發模式"05/30 10:26
→ kiwatami: 說到後來反而像是在教人寫程式該怎麼寫才漂亮05/30 10:26
→ kiwatami: 不太像是原原 po 主要探討的議題05/30 10:26
→ kiwatami: 就像我們在討論烤雞翅要這樣調烤肉醬才好吃05/30 10:26
→ kiwatami: 你卻在說烤肉架最好用精工牌的 a5 型號烤起來最好吃05/30 10:26
→ kiwatami: 雖然最後都會影響到好吃程度 05/30 10:26
→ kiwatami: 可是醬料該怎麼調 跟烤肉架用哪牌是兩個不同的層級05/30 10:26
→ kiwatami: 不是說你推薦的烤肉架不好用 而是醬料才是靈魂啊!05/30 10:26
推 comesuck: 認為演算法跟需求落差很大是罕事,我沒意見;只是在一05/30 12:56
→ comesuck: 個常態使用合約裡空泛的幾句話去定義一個功能scope的大05/30 12:56
→ comesuck: 環境底下,出現演算法與需求的落差,機率應該頗大吧?05/30 12:56
推 comesuck: 對,假設原原po的情境是:a要調出好吃的烤肉醬把烤肉烤05/30 13:05
→ comesuck: 好;那原po的情境比較像是:烤肉的任務a進行到一半,烤05/30 13:05
→ comesuck: 肉醬的材料切好了,現在換成b來接手,b憑經驗把材料組好05/30 13:05
→ comesuck: 變成烤肉醬,再完成烤肉任務。期間,只要換口味了,那就05/30 13:05
→ comesuck: 會發生醬料不符合口味的情境。05/30 13:05
推 comesuck: 至於不同廠牌的烤肉架,比較像是決定實作的framework或05/30 13:08
→ comesuck: 語言05/30 13:08
→ comesuck: 掌廚的人跟醬料會是勝負的關鍵05/30 13:09
→ comesuck: 我在講什麼...05/30 13:10
推 comesuck: 咦?XD05/30 14:42
推 GoalBased: 假設情境是,bubble sort比quick sort容易讀,但quick05/30 18:56
→ GoalBased: sort比bubble sort還快,那要選哪個呢?05/30 18:57
→ GoalBased: 原PO的問題比較像是這樣吧...05/30 18:57
推 ripple0129: 會用quick sort然後做成api出來是要的結果就好了,裡05/31 02:01
→ ripple0129: 面的東西不用讀了,知道怎麼用即可XD。我是覺得樓主 05/31 02:01
→ ripple0129: 說的很清楚了,大概就類似這樣的做法。除非是演算法出 05/31 02:01
→ ripple0129: 問題不得不進來讀原始碼吧。 05/31 02:01
推 kiwatami: 演算法跟需求落差很大驗收還會過 05/31 10:21
→ kiwatami: 那我乾脆寫個假結果給他驗收就好啦... 05/31 10:21
→ kiwatami: 何必寫什麼複雜的運算結果還是錯的 05/31 10:21
→ kiwatami: 不是效能瓶頸的地方當然不需要用複雜演算法 05/31 10:21
→ kiwatami: 因為提升的效能很有限05/31 10:21
→ kiwatami: 再來不管你分割的多清楚 你就是得讀原始碼05/31 10:21
→ kiwatami: 難道原本只需要改迴圈的數量就好也要重寫嗎?05/31 10:21
→ kiwatami: 沒有讀過怎麼會知道要改迴圈的數量呢? 05/31 10:21
→ kiwatami: 難道名稱是 loop3times 嗎?不然只看名稱怎麼知道?05/31 10:21
→ kiwatami: 知道怎麼用不需要讀裡面的就是一般使用者的情境05/31 10:21
→ kiwatami: 維護人員一定需要讀裡面的東西05/31 10:21
→ kiwatami: 難道你讀程式碼的定義是我沒有讀完全部就不算讀嗎?05/31 10:21
→ kiwatami: 我只讀了三分之一 只讀了其中的幾個 method 就不算讀?05/31 10:21
→ kiwatami: 再提一個更簡單的例子05/31 10:21
→ kiwatami: 假設今天某個變數在運算過程中要多加一個常數05/31 10:21
→ kiwatami: 難道你事先知道這邊要這樣改嗎?05/31 10:21
→ kiwatami: 還是說每個計算不管多簡單 就算只是指定變數值05/31 10:21
→ kiwatami: 也要切出來?為了所謂的預防萬一以後要改?05/31 10:21
→ kiwatami: 難道不可能會有以上這種情況發生?05/31 10:21
→ kiwatami: 維護要改的東西什麼都有可能什麼都不奇怪 05/31 10:21
→ kiwatami: 更何況有些時候算法是要一直調整的 05/31 10:21
→ kiwatami: 還是說在你的理論裡不會有開發到一半離職的情形?05/31 10:21
→ kiwatami: 還是說接手的不管如何就是重寫尚未完成的部分?05/31 10:21
→ kiwatami: 如果不是的話你要怎麼知道他寫到什麼程度?05/31 10:21
→ kiwatami: 靠名稱?靠慣例?靠心電感應?(喵喵)05/31 10:21
→ kiwatami: 用一個開發模式就號稱以後完全不需要動原始碼05/31 10:21
→ kiwatami: 這不太可能 不管你切的多細多完美05/31 10:21
→ kiwatami: 影響到的只有讀的範圍多寡而已 而不是"不用讀"05/31 10:21
→ kiwatami: 原 po 假設的情況太過於完美 而現實的瑕疵太多了05/31 10:21
→ kiwatami: 是瓶頸的部分不管你演算法多複雜都要寫05/31 10:21
→ kiwatami: 這我應該提到幾次了 簡單的算法也不是只有初學者的語法05/31 10:21
→ kiwatami: 而是不用過於特殊的方法去解決問題05/31 10:21
→ kiwatami: 可讀性的意義跟簡單完全是兩回事 風馬牛不相及05/31 10:22
推 comesuck: 會有這種結果,就不懂軟工啊;使用者只看ui;與修改中的05/31 12:10
→ comesuck: 功能相關的class,只要用到的method都要讀(只用到兩個05/31 12:10
→ comesuck: ,你沒必要把20個全看完,但看懂是其次,意不意會的到05/31 12:10
→ comesuck: 它有沒有符合情境才是關鍵);今天不會莫名其妙加常數,05/31 12:10
→ comesuck: 決定加一定是因為有需求、有情境、經過討論後才決定修05/31 12:10
→ comesuck: 改抽象化與實作;ok,程式碼開發到一半人員離職怎麼辦?05/31 12:10
→ comesuck: 看你如何降低程式碼與開發者的耦合,對我來講,就是畫UM05/31 12:10
→ comesuck: L把抽象化概念拉出來討論(畫到sequence diagram 就可以05/31 12:10
→ comesuck: 收斂大部份的方向了);開發者按圖施工,就算你寫到一半05/31 12:10
→ comesuck: 閃了,也不會出現不知道抽象化怎麼做下去的窘境;05/31 12:10
推 comesuck: 切function愛怎麼切看開發者,好或壞由維護的人定奪;05/31 12:17
→ comesuck: 但記得稟持童子軍的精神05/31 12:17
推 comesuck: 做認為是對的事就對了~ 05/31 16:46
→ viper9709: 推這篇~觀念正確 05/31 23:57
推 kiwatami: 我從來不認為你說的是屁 一直都很讚同你說的 06/01 10:10
→ kiwatami: 也沒有說不要用你的方法去實作 06/01 10:10
→ kiwatami: 只是你的角度與原原 po 要討論的不同啊... 06/01 10:10
→ kiwatami: 你說這樣的寫法不需要讀 所以我回應你說不可能不用讀 06/01 10:10
→ kiwatami: 你說這樣的寫法不需要改 只要重寫06/01 10:10
→ kiwatami: 但很多時候不可能重寫就好06/01 10:10
→ kiwatami: 所以舉例了一堆情況 06/01 10:10
→ kiwatami: 為什麼有算法需要調整?因為這個算法可能是顧問提供的06/01 10:10
→ kiwatami: 算出結果後發現有偏差於是需要調整 06/01 10:10
→ kiwatami: 因為這一大堆情況都需要"讀" "改" 程式碼06/01 10:10
→ kiwatami: 而你一再強調不需要讀 也只需要重寫06/01 10:10
→ kiwatami: 我反駁的從頭到尾都是這點 但你最後的回應06/01 10:10
→ kiwatami: 搞得好像我反駁的是你提倡的開發模式06/01 10:10
→ kiwatami: 也似乎忘了你一開始一直堅持的不用改不用讀06/01 10:10
→ kiwatami: 甚至連註解跟文件都不用寫不是嗎?06/01 10:10
→ kiwatami: 從頭到尾你觀念錯誤的地方從來就不是開發模式06/01 10:10
→ kiwatami: 而是你把接手人員的情況想得過於簡單06/01 10:10
→ kiwatami: 把這個開發模式想得過於強大06/01 10:10
→ kiwatami: 好像用了這個開發模式一切都不會有問題06/01 10:10
→ kiwatami: 我反駁的是這個過於天真的想法06/01 10:10
→ kiwatami: 把我打成一個異教徒並沒辦法掩蓋這個事實06/01 10:10
→ kiwatami: 為什麼討論到後來總是變成在酸人 亂扣帽子06/01 10:10
→ kiwatami: 最後連自己當初堅持的想法都忘記了?06/01 10:10
→ kiwatami: 要不要回頭看看你說的東西 再看看你最後的回覆?06/01 10:10
→ kiwatami: 完全像是兩個不同立場的人在說話06/01 10:10
→ kiwatami: 最後那段酸文對討論又有什麼幫助?06/01 10:10
→ comesuck: 他提倡較好讀較好改...沒有到不用讀不用改吧06/01 12:47
推 kiwatami: 原 po 第一段提到"程式為什麼讓人想看裡面的實作" 06/02 09:34
→ kiwatami: 沒有為什麼 要改就是要看 這4點只符合一般使用者 06/02 09:34
→ kiwatami: 並不符合一般接手程式的情況 06/02 09:34
→ kiwatami: 但之後原 po 又說其實要讀 只是範圍小了點 06/02 09:35
→ kiwatami: 這不是完全跟你前面幾次回覆要說的完全不同了嗎? 06/02 09:35
→ kiwatami: 之後原 po 又提到"要是演算法不合需求了 重寫就好" 06/02 09:35
→ kiwatami: "也不需要看程式內的實作" 06/02 09:35
→ kiwatami: "要表達程式資訊最棒的方法是使用慣例" 06/02 09:35
→ kiwatami: "因為註解文件又累又醜" 06/02 09:35
→ kiwatami: 並不是炮你表達 而是以上這些觀念都是不對的 06/02 09:35
→ kiwatami: 原原 po 的問題不成立是因為該寫的地方不用考慮複雜度 06/02 09:35
→ kiwatami: 而不是你說的"只要架構夠好根本不需要讀" 06/02 09:35
→ kiwatami: 這不是表達的問題 這是你真的這樣認為才會這樣說 06/02 09:35
→ kiwatami: 因為你覺得這個開發模式太美妙 想推廣給大家 06/02 09:35
→ kiwatami: 但不得不承認的是很多情況並不是開發模式可以解決的 06/02 09:35
→ kiwatami: 但你又堅持可以 只是對方貫徹的不夠徹底 06/02 09:35
→ kiwatami: 你最後也說很多結論有適用與不適用的地方 06/02 09:35
→ kiwatami: 但我提出了不適用的地方 你卻一直反駁這其實適用 06/02 09:35
→ kiwatami: 無法接受這個事實的不就是你自己嗎? 06/02 09:35
→ kiwatami: 不是體質不夠好 就算體質再好你還是要讀 06/02 09:35
→ kiwatami: 這這是我一直想告訴你的 但你一直不接受 06/02 09:35
→ kiwatami: 最後你的回覆不就是我前面一直想說的嗎? 06/02 09:35
→ kiwatami: 但你又把我打成了你的方法無用論者 06/02 09:35
→ kiwatami: 明眼人都看得出來很聰明那段是在酸人寫 code 架構差 06/02 09:35
→ kiwatami: 又死腦筋不願改進 06/02 09:35
→ kiwatami: 我只是覺得這對討論一點幫助也沒有 06/02 09:35
→ kiwatami: 這不是誇張了點 這是誇大成效 你要做的不是描述各種眉 06/02 09:35
→ kiwatami: 角 06/02 09:35
→ kiwatami: 而是忠實傳述這個開發模式的優點與目的就好 06/02 09:35
→ kiwatami: 不用讀 不用改 不用註解與文件云云根本是多餘又錯誤的 06/02 09:35
→ kiwatami: 可以的話請你回頭看看我在14樓回你什麼 06/02 09:35
→ kiwatami: 是不是就是你說的某些不適用的情況? 06/02 09:35
→ kiwatami: 但結果呢?你不接受 才有了這一大篇最後都歪樓的討論 06/02 09:35
→ kiwatami: 但最後你又接受了... 卻又說我在鑽牛角尖 06/02 09:35
→ kiwatami: 但我要表達的就是你最後結論提到的 06/02 09:35
→ kiwatami: 有適用與不適用的情況 這點而已 06/02 09:35
→ kiwatami: 也是你一開始堅持絕對沒有的東西 06/02 09:35
→ CoNsTaR: 嗯…很好啊 戰鬥力滿分 繼續保持…… 06/02 22:12