Re: [討論] debug靠感覺?

看板Soft_Job作者 (Victor)時間15年前 (2009/06/27 23:49), 編輯推噓22(22推 0噓 70→)
留言92則, 13人參與, 最新討論串2/2 (看更多)
※ 引述《prag222 (prag)》之銘言： : 前陣子在寫字典檔的程式 : 到了晚餐時間，寫一寫想說趕快完成就沒吃飯了 : 結果肚子餓,感覺好像有半昏迷的狀態 : 解果程式有問題bug,就找阿找的 : 過了一會,沒想到我隨便改一改,就可以用了 : 今天寫程式遇到問題也很直覺的去修改 : 只能說最近修bug幾乎都靠感覺了！ : 其實我覺得這樣不太好，應該是了解整個的邏輯架構 : 了解為什麼會出錯,再去改bug 程式應該要有良好的模組劃分 好的模組分出來他們之間的藕合度很小 且每個模組都能獨立測試 可以的話 最好替每個模組寫單元測試(unit test) 這樣在合在一起測試前可以把每個模組出bug的機會降到最小 硬寫 隨便想到什麼改什麼 對於小程式而言其實沒什麼差 但是對於大一點的程式就會死很慘 我剛好寫了一篇嘴砲文裡面有提到一點經驗 http://blog.ez2learn.com/2009/06/27/how-to-write-useful-program/ 以前寫爛程式真的遇到漣漪效應 改這裡那裡會出bug 改那裡這裡出bug 不止bug 改動程式 需要改動的部份也會擴散出去 除非程式寫一次就丟 而且很小 那隨便寫寫就好 不然最好還是先規劃比較好 -- 哇咧咧 創意投票系統 http://walele.com 易記學 程式設計教學 http://ez2learn.com/ 易記學 程式設計討論區 http://forum.ez2learn.com VICTOR's 個人Blog http://blog.ez2learn.com/ 財報分析王 http://victorlin.serveftp.org/stock/ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.170.180.12
推
06/28 01:05, , 1F
越精良的設計...越頂不住隨心所欲的客戶亂改SPEC...
06/28 01:05, 1F
推
06/28 01:08, , 2F
規格改個幾次，所有的rule就會互相衝突，最後時間不夠
06/28 01:08, 2F
→
06/28 01:09, , 3F
整個從底層改起，就會隨便改，然後就....，祈禱不出錯就好
06/28 01:09, 3F
→
06/28 01:59, , 4F
我不懂為何精良的設計會頂不住修改
06/28 01:59, 4F
→
06/28 01:59, , 5F
我指的良好設計包括藕合度低等容易維護的特性
06/28 01:59, 5F
→
06/28 02:00, , 6F
藕合度如果低 改某個不份不會影響到其它地方
06/28 02:00, 6F
→
06/28 02:00, , 7F
當然 大規模的更動或許是例外 但是爛的設計情況
06/28 02:00, 7F
→
06/28 02:00, , 8F
只會更慘而已
06/28 02:00, 8F
→
06/28 02:02, , 9F
沒有什麼越精良的設計越不經改 設計越好 才越好改
06/28 02:02, 9F
→
06/28 02:03, , 10F
如果你指的精良設計是所有組件都剛剛好組合在一起
06/28 02:03, 10F
→
06/28 02:04, , 11F
那我只能說那是爛的設計 組件互相依賴才會剛好合起來
06/28 02:04, 11F
→
06/28 02:04, , 12F
不然真正良好的設計組件對其它部份都是無知的
06/28 02:04, 12F
→
06/28 02:04, , 13F
何來的頂不住改?
06/28 02:04, 13F
※ 編輯: StubbornLin 來自: 118.170.180.12 (06/28 02:04)
→
06/28 02:45, , 14F
與其說精良設計 過度設計似乎比較有那樣的問題
06/28 02:45, 14F
推
06/28 03:08, , 15F
通常是沒時間設計啦, 尤其是寫網頁程式的...
06/28 03:08, 15F
→
06/28 03:08, , 16F
另外客戶前後吐出來的constraint有可能是完全不一樣...XD
06/28 03:08, 16F
→
06/28 03:09, , 17F
這種狀況除非你搞overkill不然爛掉的機率很高...
06/28 03:09, 17F
推
06/28 03:33, , 18F
真的是沒時間還是不會設計?你忍受的了哪個?
06/28 03:33, 18F
推
06/28 05:10, , 19F
基本上.只要客戶一個堅持的需求.有時連架構都要翻了...
06/28 05:10, 19F
推
06/28 10:57, , 20F
部落格文章講的真貼切阿`我可以引用你的文章嗎?
06/28 10:57, 20F
推
06/28 11:35, , 21F
是良好的設計或是過度設計 , 並不是單純由設計面來看的 ,
06/28 11:35, 21F
→
06/28 11:36, , 22F
而是由 spec 來定義的 ,
06/28 11:36, 22F
→
06/28 11:36, , 23F
當你的spec 不停的變動 , 今天的良好設計變成明日的不足或
06/28 11:36, 23F
→
06/28 11:36, , 24F
過度設計 , 這就是現在的 pg 所常見在處理的日常工作 ,
06/28 11:36, 24F
→
06/28 11:37, , 25F
但是這其實也還算正常 , 但是最重要的地方在於 spec 的改動
06/28 11:37, 25F
→
06/28 11:37, , 26F
是因為實驗性質？又或是一時興起？還是長久規劃？
06/28 11:37, 26F
→
06/28 11:37, , 27F
規劃的人有沒有考慮過 spec 改動所帶來的漣漪效應 , 這才是
06/28 11:37, 27F
→
06/28 11:38, , 28F
被concern的重點 , 當然重要的是資源釋出的夠不夠.
06/28 11:38, 28F
→
06/28 11:38, , 29F
很少有東西是不能改的 , 但是很少有東西是有足夠時間改的.
06/28 11:38, 29F
推
06/28 11:46, , 30F
這是軟體工程的基本概念阿
06/28 11:46, 30F
→
06/28 13:39, , 31F
當然可以引用 只要有出處
06/28 13:39, 31F
→
06/28 13:40, , 32F
嗯 的確不停的改spec會有這樣的問題
06/28 13:40, 32F
→
06/28 13:41, , 33F
那就不是設計層面的問題 而是客戶或方法的問題
06/28 13:41, 33F
→
06/28 13:41, , 34F
但以我個人的經驗 依照xp的做法 有很多個週期
06/28 13:41, 34F
→
06/28 13:42, , 35F
每完成一小部份就給客戶確認一下是否是他們要的東西
06/28 13:42, 35F
→
06/28 13:42, , 36F
確實對於做出客戶想要的東西很有幫助
06/28 13:42, 36F
→
06/28 13:43, , 37F
但是如果就算這樣做 規格還是不停的大幅度更動
06/28 13:43, 37F
→
06/28 13:43, , 38F
我只能猜想客戶連自己要什麼都不清楚
06/28 13:43, 38F
→
06/28 13:43, , 39F
或許是我沒遇過這樣的客戶 不過我都會約定在前頭
06/28 13:43, 39F
→
06/28 13:44, , 40F
如果因為更動規格造成需要大幅的修改程式需要額外的
06/28 13:44, 40F
→
06/28 13:44, , 41F
收費 如果客戶錢燒不完的話 而我又有空做是沒差啦= =
06/28 13:44, 41F
推
06/28 15:43, , 42F
思考改 spec 前先結清前次費用的可能性 (誤)
06/28 15:43, 42F
推
06/28 18:01, , 43F
客戶:好啦!好啦!就改一下那邊而已啊!先改來看看再說嘛...
06/28 18:01, 43F
→
06/28 18:03, , 44F
如果軟體像鞋子一樣~那架構就像模具~有人在買鞋子的時候會
06/28 18:03, 44F
→
06/28 18:04, , 45F
說:反正就裁一下~車個邊嘛~你先改來看看再說嘛...
06/28 18:04, 45F
→
06/28 18:05, , 46F
為什麼軟體可以被客戶這樣凹呢???
06/28 18:05, 46F
推
06/28 18:15, , 47F
訂製服設計師也是會被凹的...
06/28 18:15, 47F
推
06/28 18:38, , 48F
給錢的是客戶,對PM來說,RD對於架構的心力能賺到錢嗎...
06/28 18:38, 48F
→
06/28 18:39, , 49F
不如架構很差,但可以對客戶交差就好...先賺到這一單再說...
06/28 18:39, 49F
→
06/28 18:39, , 50F
為了架構得罪客戶,可能連這單都沒了...幹嘛為了不一有的下單
06/28 18:39, 50F
→
06/28 18:40, , 51F
去搞個很好的架構?
06/28 18:40, 51F
→
06/28 18:41, , 52F
對這一單負責的RD來說,下一單又不見得是我負責...不如趕快
06/28 18:41, 52F
→
06/28 18:42, , 53F
弄個可以跑的版本,趕快出貨,弄個好看的考績,拿bonus走人...
06/28 18:42, 53F
推
06/28 18:52, , 54F
很不幸的...真的有下一單了,接手的RD那到一個架構超爛的code
06/28 18:52, 54F
→
06/28 18:53, , 55F
但是可以正常運作,要加新功能可能要繼續破壞最早架構的理念
06/28 18:53, 55F
→
06/28 18:53, , 56F
不然就得整個砍掉重練,而且練完不知道會不會正常的動,砍掉重
06/28 18:53, 56F
→
06/28 18:54, , 57F
練的好處是下一個RD會輕鬆點,壞處是有300個以上的function藥
06/28 18:54, 57F
→
06/28 18:55, , 58F
重寫,而且架構改了,一些undocument的裏技不能用了,又不確定
06/28 18:55, 58F
→
06/28 18:56, , 59F
客戶有沒有用類似的裏技,改了八成會要一兩個月重新請QA重測
06/28 18:56, 59F
→
06/28 18:57, , 60F
你會選擇為了RD的自尊進行重搆嗎?
06/28 18:57, 60F
推
06/28 18:57, , 61F
所以這時厲害的PM..就會開始勸客戶用新案重做..
06/28 18:57, 61F
推
06/28 19:20, , 62F
然後利害的客戶就會說既然要重做可以挑你的對手來,而且她們
06/28 19:20, 62F
→
06/28 19:21, , 63F
比你們便宜....
06/28 19:21, 63F
推
06/28 19:31, , 64F
PL曾說:多給一個月, 包裝盒上你要寫架構更好還是功能更多?
06/28 19:31, 64F
→
06/28 19:32, , 65F
除了RD...PM, PL, BOSS, 客戶都不會在意你的架構好壞...
06/28 19:32, 65F
推
06/28 19:46, , 66F
我比較常遇到的是對手用低價搶來做不到只好再賠錢轉包...
06/28 19:46, 66F
推
06/28 21:21, , 67F
會講那種話的PL有點不大負責任，除非非你打定project是免洗
06/28 21:21, 67F
→
06/28 21:22, , 68F
不然PL要擋PM的壓力，PM要擋客戶的壓力，這樣有機會做好...
06/28 21:22, 68F
→
06/28 21:22, , 69F
很多短時間看不出效果的東西做在位子上的人要有guts去做...
06/28 21:22, 69F
→
06/28 21:26, , 70F
是嗎?後來我倒是頗同意PL的說法...公司付錢給我要我寫可以賣
06/28 21:26, 70F
→
06/28 21:27, , 71F
可以賣的code,而不是架構良好的code...優先的是可以賣,硬要
06/28 21:27, 71F
→
06/28 21:27, , 72F
弄個架構良好的code出來,大多是RD對自己的制約...
06/28 21:27, 72F
→
06/28 21:28, , 73F
這點並未列在Project內的必需條件,時限內你可以寫出良好架構
06/28 21:28, 73F
→
06/28 21:29, , 74F
那是你的自由,但不是一個用來推拖要求的理由...
06/28 21:29, 74F
推
06/28 21:29, , 75F
如果是做一次性的商品是可以，如果是次性的這樣搞...zzzz
06/28 21:29, 75F
→
06/28 21:31, , 76F
PM和PL的工作除了把project跑完以外還要確保最大出力...
06/28 21:31, 76F
→
06/28 21:32, , 77F
如果code可能是多次使用，之後修改需要的時間也應該算進去
06/28 21:32, 77F
→
06/28 21:32, , 78F
所以我說，你賭定這code只用一次的話沒差，不然就算做完
06/28 21:32, 78F
→
06/28 21:33, , 79F
後來想想...PL本來就沒必要為了我的架構去跟客戶炒,維護架構
06/28 21:33, 79F
→
06/28 21:33, , 80F
還是應該回頭把架構整理一下，最理想的狀況是設計時就解決
06/28 21:33, 80F
→
06/28 21:34, , 81F
我幹PL的話會做這件事，因為我認為那是技術主管的份內事...
06/28 21:34, 81F
→
06/28 21:35, , 82F
並且完成功能是我的工作,做不到是我的責任...
06/28 21:35, 82F
推
06/28 22:14, , 83F
坦白說，客製化的東西，如果確定不會有第二代，有時候真的
06/28 22:14, 83F
→
06/28 22:14, , 84F
是功能做完就算了，架構、好維護....，通常都拋諸腦後....
06/28 22:14, 84F
推
06/28 22:16, , 85F
但如果是會一直有新版本的軟體，架構真的很重要，但是....
06/28 22:16, 85F
→
06/28 22:17, , 86F
那也要主管或高層在乎，不然，你為架構花的心血，也不見得
06/28 22:17, 86F
→
06/28 22:17, , 87F
你能夠得到回報啊...有時候會有只是白花時間的感概~
06/28 22:17, 87F
→
06/28 23:39, , 88F
花時間去設計良好的架構,結果客戶嫌配合度不夠,客製化困難
06/28 23:39, 88F
→
06/28 23:40, , 89F
別想有第二單,放棄原始架構,照客戶需求東改西改,下一單苦的
06/28 23:40, 89F
→
06/28 23:41, , 90F
是不是自己還不一定...
06/28 23:41, 90F
推
06/29 00:02, , 91F
與其信仰 XP 能解決一切, 不如期望你有個硬度夠的 PM ....
06/29 00:02, 91F
→
06/29 01:16, , 92F
軟工沒有銀彈 xp也只是方法之一 沒有信仰的問題
06/29 01:16, 92F
‣ 更多 StubbornLin 的文章
文章代碼(AID): #1AHZ-Sql (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 2 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共2篇)
‣ 更多 StubbornLin 的文章
文章代碼(AID): #1AHZ-Sql (Soft_Job)