作者StubbornLin (Victor)
看板Soft_Job
标题Re: [讨论] debug靠感觉?
时间Sat Jun 27 23:49:46 2009
※ 引述《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
1F：推 sofss:越精良的设计...越顶不住随心所欲的客户乱改SPEC... 06/28 01:05
2F：推 poqwer:规格改个几次，所有的rule就会互相冲突，最後时间不够 06/28 01:08
3F：→ poqwer:整个从底层改起，就会随便改，然後就....，祈祷不出错就好 06/28 01:09
4F：→ StubbornLin:我不懂为何精良的设计会顶不住修改 06/28 01:59
5F：→ StubbornLin:我指的良好设计包括藕合度低等容易维护的特性 06/28 01:59
6F：→ StubbornLin:藕合度如果低 改某个不份不会影响到其它地方 06/28 02:00
7F：→ StubbornLin:当然 大规模的更动或许是例外 但是烂的设计情况 06/28 02:00
8F：→ StubbornLin:只会更惨而已 06/28 02:00
9F：→ StubbornLin:没有什麽越精良的设计越不经改 设计越好 才越好改 06/28 02:02
10F：→ StubbornLin:如果你指的精良设计是所有组件都刚刚好组合在一起 06/28 02:03
11F：→ StubbornLin:那我只能说那是烂的设计 组件互相依赖才会刚好合起来 06/28 02:04
12F：→ StubbornLin:不然真正良好的设计组件对其它部份都是无知的 06/28 02:04
13F：→ StubbornLin:何来的顶不住改? 06/28 02:04
※ 编辑: StubbornLin 来自: 118.170.180.12 (06/28 02:04)
14F：→ StubbornLin:与其说精良设计 过度设计似乎比较有那样的问题 06/28 02:45
15F：推 iincho:通常是没时间设计啦, 尤其是写网页程式的... 06/28 03:08
16F：→ iincho:另外客户前後吐出来的constraint有可能是完全不一样...XD 06/28 03:08
17F：→ iincho:这种状况除非你搞overkill不然烂掉的机率很高... 06/28 03:09
18F：推 juriolegend:真的是没时间还是不会设计?你忍受的了哪个? 06/28 03:33
19F：推 summerme:基本上.只要客户一个坚持的需求.有时连架构都要翻了... 06/28 05:10
20F：推 prag222:部落格文章讲的真贴切阿`我可以引用你的文章吗? 06/28 10:57
21F：推 TonyQ:是良好的设计或是过度设计 , 并不是单纯由设计面来看的 , 06/28 11:35
22F：→ TonyQ:而是由 spec 来定义的 , 06/28 11:36
23F：→ TonyQ:当你的spec 不停的变动 , 今天的良好设计变成明日的不足或 06/28 11:36
24F：→ TonyQ:过度设计 , 这就是现在的 pg 所常见在处理的日常工作 , 06/28 11:36
25F：→ TonyQ:但是这其实也还算正常 , 但是最重要的地方在於 spec 的改动 06/28 11:37
26F：→ TonyQ:是因为实验性质？又或是一时兴起？还是长久规划？ 06/28 11:37
27F：→ TonyQ:规划的人有没有考虑过 spec 改动所带来的涟漪效应 , 这才是 06/28 11:37
28F：→ TonyQ:被concern的重点 , 当然重要的是资源释出的够不够. 06/28 11:38
29F：→ TonyQ:很少有东西是不能改的 , 但是很少有东西是有足够时间改的. 06/28 11:38
30F：推 wa120:这是软体工程的基本概念阿 06/28 11:46
31F：→ StubbornLin:当然可以引用 只要有出处 06/28 13:39
32F：→ StubbornLin:嗯 的确不停的改spec会有这样的问题 06/28 13:40
33F：→ StubbornLin:那就不是设计层面的问题 而是客户或方法的问题 06/28 13:41
34F：→ StubbornLin:但以我个人的经验 依照xp的做法 有很多个周期 06/28 13:41
35F：→ StubbornLin:每完成一小部份就给客户确认一下是否是他们要的东西 06/28 13:42
36F：→ StubbornLin:确实对於做出客户想要的东西很有帮助 06/28 13:42
37F：→ StubbornLin:但是如果就算这样做 规格还是不停的大幅度更动 06/28 13:43
38F：→ StubbornLin:我只能猜想客户连自己要什麽都不清楚 06/28 13:43
39F：→ StubbornLin:或许是我没遇过这样的客户 不过我都会约定在前头 06/28 13:43
40F：→ StubbornLin:如果因为更动规格造成需要大幅的修改程式需要额外的 06/28 13:44
41F：→ StubbornLin:收费 如果客户钱烧不完的话 而我又有空做是没差啦= = 06/28 13:44
42F：推 qrtt1:思考改 spec 前先结清前次费用的可能性 (误) 06/28 15:43
43F：推 andymai:客户:好啦!好啦!就改一下那边而已啊!先改来看看再说嘛... 06/28 18:01
44F：→ andymai:如果软体像鞋子一样~那架构就像模具~有人在买鞋子的时候会 06/28 18:03
45F：→ andymai:说:反正就裁一下~车个边嘛~你先改来看看再说嘛... 06/28 18:04
46F：→ andymai:为什麽软体可以被客户这样凹呢??? 06/28 18:05
47F：推 fotofolio:订制服设计师也是会被凹的... 06/28 18:15
48F：推 sofss:给钱的是客户,对PM来说,RD对於架构的心力能赚到钱吗... 06/28 18:38
49F：→ sofss:不如架构很差,但可以对客户交差就好...先赚到这一单再说... 06/28 18:39
50F：→ sofss:为了架构得罪客户,可能连这单都没了...干嘛为了不一有的下单 06/28 18:39
51F：→ sofss:去搞个很好的架构? 06/28 18:40
52F：→ sofss:对这一单负责的RD来说,下一单又不见得是我负责...不如赶快 06/28 18:41
53F：→ sofss:弄个可以跑的版本,赶快出货,弄个好看的考绩,拿bonus走人... 06/28 18:42
54F：推 sofss:很不幸的...真的有下一单了,接手的RD那到一个架构超烂的code 06/28 18:52
55F：→ sofss:但是可以正常运作,要加新功能可能要继续破坏最早架构的理念 06/28 18:53
56F：→ sofss:不然就得整个砍掉重练,而且练完不知道会不会正常的动,砍掉重 06/28 18:53
57F：→ sofss:练的好处是下一个RD会轻松点,坏处是有300个以上的function药 06/28 18:54
58F：→ sofss:重写,而且架构改了,一些undocument的里技不能用了,又不确定 06/28 18:55
59F：→ sofss:客户有没有用类似的里技,改了八成会要一两个月重新请QA重测 06/28 18:56
60F：→ sofss:你会选择为了RD的自尊进行重构吗? 06/28 18:57
61F：推 summerme:所以这时厉害的PM..就会开始劝客户用新案重做.. 06/28 18:57
62F：推 sofss:然後利害的客户就会说既然要重做可以挑你的对手来,而且她们 06/28 19:20
63F：→ sofss:比你们便宜.... 06/28 19:21
64F：推 sofss:PL曾说:多给一个月, 包装盒上你要写架构更好还是功能更多? 06/28 19:31
65F：→ sofss:除了RD...PM, PL, BOSS, 客户都不会在意你的架构好坏... 06/28 19:32
66F：推 summerme:我比较常遇到的是对手用低价抢来做不到只好再赔钱转包... 06/28 19:46
67F：推 iincho:会讲那种话的PL有点不大负责任，除非非你打定project是免洗 06/28 21:21
68F：→ iincho:不然PL要挡PM的压力，PM要挡客户的压力，这样有机会做好... 06/28 21:22
69F：→ iincho:很多短时间看不出效果的东西做在位子上的人要有guts去做... 06/28 21:22
70F：→ sofss:是吗?後来我倒是颇同意PL的说法...公司付钱给我要我写可以卖 06/28 21:26
71F：→ sofss:可以卖的code,而不是架构良好的code...优先的是可以卖,硬要 06/28 21:27
72F：→ sofss:弄个架构良好的code出来,大多是RD对自己的制约... 06/28 21:27
73F：→ sofss:这点并未列在Project内的必需条件,时限内你可以写出良好架构 06/28 21:28
74F：→ sofss:那是你的自由,但不是一个用来推拖要求的理由... 06/28 21:29
75F：推 iincho:如果是做一次性的商品是可以，如果是次性的这样搞...zzzz 06/28 21:29
76F：→ iincho:PM和PL的工作除了把project跑完以外还要确保最大出力... 06/28 21:31
77F：→ iincho:如果code可能是多次使用，之後修改需要的时间也应该算进去 06/28 21:32
78F：→ iincho:所以我说，你赌定这code只用一次的话没差，不然就算做完 06/28 21:32
79F：→ sofss:後来想想...PL本来就没必要为了我的架构去跟客户炒,维护架构 06/28 21:33
80F：→ iincho:还是应该回头把架构整理一下，最理想的状况是设计时就解决 06/28 21:33
81F：→ iincho:我干PL的话会做这件事，因为我认为那是技术主管的份内事... 06/28 21:34
82F：→ sofss:并且完成功能是我的工作,做不到是我的责任... 06/28 21:35
83F：推 poqwer:坦白说，客制化的东西，如果确定不会有第二代，有时候真的 06/28 22:14
84F：→ poqwer:是功能做完就算了，架构、好维护....，通常都抛诸脑後.... 06/28 22:14
85F：推 poqwer:但如果是会一直有新版本的软体，架构真的很重要，但是.... 06/28 22:16
86F：→ poqwer:那也要主管或高层在乎，不然，你为架构花的心血，也不见得 06/28 22:17
87F：→ poqwer:你能够得到回报啊...有时候会有只是白花时间的感概~ 06/28 22:17
88F：→ sofss:花时间去设计良好的架构,结果客户嫌配合度不够,客制化困难 06/28 23:39
89F：→ sofss:别想有第二单,放弃原始架构,照客户需求东改西改,下一单苦的 06/28 23:40
90F：→ sofss:是不是自己还不一定... 06/28 23:41
91F：推 ledia:与其信仰 XP 能解决一切, 不如期望你有个硬度够的 PM .... 06/29 00:02
92F：→ StubbornLin:软工没有银弹 xp也只是方法之一 没有信仰的问题 06/29 01:16