為什麼這篇軟體開發流程圖鄉民發文收入到精華區：因為在軟體開發流程圖這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者guest2008 (guest)看板Soft_Job標題Re: [心得] 為什麼軟體開發者需要...
軟體開發流程圖 在 腦洞大開｜商業時事X 議題分析 Instagram 的最佳貼文
2021-09-16 09:23:55
【9/6-9/12 腦洞一週商業大事】#腦洞商業時事 #9月⠀ ⠀ ❶ Apple Car 負責人轉換⠀ ⠀ 9/10，彭博社報導，蘋果將任命 Kevin Lynch 擔任開發 Apple Car 泰坦計畫的主要負責人。在前任負責人 Doug Field 跳槽到 Ford後，福斯於週二也宣布將由 D...
再提另一個現實問題，跟 CMMI 無關，請問版上所有的公司所有的工程師們，
請問你公司的專案都能如期結案甚至提前結案的的請舉手。
幾乎每件案子都逾期了，還想的那麼美好，還可以有時間寫什麼除錯程式來測試？
要品質誰沒這概念？ 從工讀生到老闆全部的人都早就有這個概念了，
重點還是同樣一句話「成本」問題。
一個案子遞延效應，業務請研發小組估時程，估需N個月，結果簽約完畢，花在
前前後後客戶跟業務的來往確認已經佔了 1/2 的時程，等到開發小組可以開發
只剩下 1/2 的時程可以開發，要怎樣照顧品質？？大家都是無眠無日的趕工，
要怎樣會有品質出現？我描述的絕對是現在大多數的公司現況。
要品質當然可以有好品質，你的資源粗厚當然可以有品質，可以去用一倍甚至
3倍的人來搞。
現在還有些公司更慘!! 工程師內部的平均素質不足，只有一兩位資深真正有戰力
的在扛案子，其餘的都是「來學習」的，來練功的，等待練功完畢再來跳槽的。
人員的素質也是一團糟，要怎樣有品質？
那些美好的未來，書上的理論大家早就懂了，重點就是你有沒有去「台灣軟體業」
上班過(也許有，但沒待過我待過的那些公司)？你是否知道台灣軟體業的毛病是啥？
理論跟現實真的差距很大的。為啥一堆資訊系畢業的，學了那麼多理論，到了公司
一點用處都沒有？甚至連程式都寫不出來？理論學那麼多，還學啥 UML，結果到了
現實去實戰，你寫 UML 客戶看的懂你的鬼畫符嗎？ 那些都是學術派的東西，真實
世界至少在台灣根本真的是垃圾，你跟客戶溝通這種東西客戶看不懂，要跟工程師
溝通，工程師也不需要你做這個東西了，他只要你的需求列表跟資料庫結構，就能
完成後面的所有的任務。
我講的都是真的現在台灣軟體界的現況，當然有制度一版一眼的公司真的有在搞
UML 還是不少，但請問一下，你們公司真的有搞這個的請舉手。大家都是只有三份
文件，資料字典檔、系統需求及規格表，了不起加一個流程圖跟 E-R圖就很猛了。
等到你分析完角色跟系統關係、每個介面的進出畫完所有的 UML圖，客戶已經在
跳腳了，工程師也在跳腳了。
了解我的意思吧?? 文件的用處其實在打發客戶，讓他們理解我們的系統「沒有這個
功能」，我們系統「你開的價格」，我們只有做到這樣子，不讓他們亂追加功能，
而不是給工程師看的，甚至根本寫錯了(注意這一句話，很重要，如果文件很重要，
不該有錯誤，有錯誤後面應該就要掛掉了，但很神奇，文件真的是錯的，但後面的
人還是做的出來，那這份文件重要嗎?)，工程師其實通通都懂，不懂也沒差，
付錢的是老大，主管說了算話，你的文件沒寫的，他還是會生出來功能給你，
內部完全不會有任何問題，再重複一次：「文件真正的用途是在打發客戶」好讓專案
能順利結案。
所以你寫UML根本沒用，客戶看不懂，劃UML 對結案說實話真的沒幫助。
你提的什麼DOS時代的進銷存，那些都一樣早期開發好品質也沒你現在用的好，
那些現在品質那麼好的原因是因為「時間因素」才是品質那麼好的主因，
而不是你想鼓吹的，「在開發階段造就品質」。系統上線，那麼多人在罵，
慢慢的調整修改，是時間因素才會有現在的品質，不是什麼那個進銷存品質那麼好。
連一堆超大型軟體、超知名的系統開發出來的都不是品質那麼好了，你還真的以為
那些軟體品質那麼好？ win7 已經多少補釘了？？品質好有需要補釘嗎？連大公司
超知名的一堆軟體都一樣，更何況是台灣軟體體系那麼糟糕，市場價格那麼糟糕，
你還要顧到什麼品質？
做個總結：要品質真的要高成本的，不是不想做，是江湖造成現狀，你要講的每個人
都知道。今天市場願意付出50倍的價格請我們開發，願意給我們5倍
的時間給我們好好把他寫完善，系統的品質絕對也會一級棒。
重點是人在江湖，身不由己。不是我們不想做到完善。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 1.170.40.61
推 Obama19:我倒很好奇你是去了哪些公司 UML不做 到後期只會很慘 05/26 15:19
→ semop:到後期就生得出UML了 剛開發新產品時就真的是這篇的狀況 05/26 15:23
→ semop:現在很多公司生得出UML來 是因為已經對同類型產品有經驗了 05/26 15:24
→ semop:在創業到早期業務拓展階段 軟體品質沒有意義 能交貨就好 05/26 15:28
→ semop:等同類東西做了三年後 就會有閒得蛋疼的人鼓吹軟體品質了 XD 05/26 15:30
推 thinkniht:我感受到了比我對我主管還深的怨念XD 05/26 15:35
→ TonyQ:基本上這篇比較接近是專案公司的狀況 05/26 17:08
→ TonyQ:對那些自己是打造產品的公司，又完全是另外一群問題。 05/26 17:08
→ TonyQ:還有，逾期問題不見得在開發身上，如果不會收斂的需求，你用 05/26 17:09
→ TonyQ:什麼仙丹妙藥都沒用，如果時間就是不夠多，那你怎麼開發都會 05/26 17:09
→ TonyQ:死。這不見得是正確歸因。 05/26 17:09
→ TonyQ:當你專案 functionility 多到成千上萬個，不寫 test case 你 05/26 17:10
→ TonyQ:光自己測就一個月不見了，有 test case 你至少還有一定比例 05/26 17:10
→ TonyQ:的品質。這時候不幹 test case 才是讓時程 delay 的問題。 05/26 17:10
→ TonyQ:當然如果是先上線再說，哪怕一點就爛，不管 user 死活的， 05/26 17:11
→ TonyQ:這的確不用管這個問題。 05/26 17:11
→ TonyQ:另外補釘跟品質是兩回事，照你這樣說的話全世界沒有品質好的 05/26 17:13
→ TonyQ:程式了，補釘大多還是因為需求變動。 05/26 17:14
→ TonyQ:另外高品質 不代表 沒有問題，完全就是不對的類比啊。 :P 05/26 17:14
推 ssnlee:第一、錢！ 第二、保佑使用者不會又突然想起來我要加什麼！ 05/26 17:29
→ ssnlee:光這兩點要一起成立，你這輩子能遇到幾次？ 05/26 17:30
推 b6byc:依照win7這種等級的,patch已經算是很少了.在台灣,品質重要? 05/26 17:33
→ ssnlee:還有這種情況不止台灣有，大陸就不說了，六年前和日本和最 05/26 17:34
→ ssnlee:近和一間泡菜國的，他們大概也是這德性，檯面上的東西看看 05/26 17:35
→ ssnlee:就好了。 05/26 17:36
推 f1234518456:品質...結的了案拿得到錢比較實在...XD 05/26 17:39
→ guest2008:關於test case,我的看法是你還能真被測有缺陷真的要檢討 05/26 18:08
→ guest2008:這些都是"明"的.有一定水平的還發生這樣低階錯誤,不是 05/26 18:11
→ guest2008:昨天一整天沒睡.要不然真的是都沒去跑過自己的程式. 05/26 18:12
→ guest2008:真正的bug都是存在沒想到還有這樣的狀況會發生. 05/26 18:13
→ guest2008:原本每位開發人員就該對他自己的code負責.本來就沒啥錯 05/26 18:16
→ guest2008:其實太依賴測試員給你結果..真的會降低你的生產品質. 05/26 18:20
→ guest2008:反而沒測試員這樣練出來的..最後的程式品質都會較佳 05/26 18:21
推 Ting1024:好像也是，測試其實自己寫自己測一下就好了 05/26 18:22
→ Ting1024:critical 的地方滿少的。基本上也不會有啥錯啦 :D 05/26 18:22
推 derekhsu:聽到CMMI就哈哈哈哈哈 05/26 18:30
→ TonyQ:@guest2008 通常 test case 真正的 power 是來自於後人改 05/26 20:18
→ TonyQ: 規格，那種時候你不靠 test case 自己測，可以啊 05/26 20:18
→ TonyQ:小改大概幾十個地方，大改幾千個地方。 05/26 20:18
→ TonyQ:要嘛你摸摸鼻子一個一個測，要嘛就是說這不敢改/改不動。 05/26 20:19
→ TonyQ:寫 test case 寫完當然當下都會過，寫一個不過的 test case 05/26 20:19
→ TonyQ:是沒意義的，你會這樣講表示你真的沒體會過 test case 帶來 05/26 20:19
→ TonyQ:的好處，有寫過並持續用一陣子的人應該不會這麼沒sense。:P 05/26 20:20
→ TonyQ:還有 QA 跟 unit test 不是同一件事，開發者也可以寫 unit 05/26 20:21
→ TonyQ:test ，誰跟你說寫 test -case 等於依賴測試員？ 05/26 20:21
→ TonyQ:開發者本來就該對他的 code 負責，所以寫能力所及跟容易測試 05/26 20:22
→ TonyQ:的 test case 、容易測試的 code ，也是對 code 負責的表現 05/26 20:22
→ TonyQ:我之前的工作我們有上千個 test case ，改 code 改規格之後 05/26 20:26
→ TonyQ:除了你自己手動測，跟老闆說「我測過了，"應該"沒問題」， 05/26 20:26
→ TonyQ:比不上一句話「一千個 test case 全過，沒 side-effect。」 05/26 20:26
→ TonyQ:當然只會開發一次的專案不需要作這麼深，但基本的測試作起來 05/26 20:27
→ TonyQ:幫助還是很大。 05/26 20:27
→ TonyQ:倒是直接把這些東西哈哈一笑拒於門外的態度，就算他真的有用 05/26 20:28
→ TonyQ:，你也永遠不會知道跟感受到。:P 05/26 20:28
→ TonyQ:讓我想起以前某份工作推版本控制，有人就喜歡用 ftp 直接改 05/26 20:28
→ TonyQ:說 commit 浪費時間跟效率。這種「理論」對某些人來講，是真 05/26 20:29
→ TonyQ:的有點遠跟感覺不到好處。 05/26 20:29
推 thinkniht:@TonyQ:為甚麼你都不愛回文XD 05/26 20:39
→ thinkniht:我是有看過有文章認為做單元測試可以縮短開發時間 05/26 20:39
→ thinkniht:越早發現問題可以花費較少成本...不過啊... 05/26 20:40
推 thinkniht:我是相信啦 但別人不相信的話...我也沒辦法XD 05/26 20:41
→ guest2008:我用最簡單的比喻說明:大家都認同細嚼慢嚥有益消化.. 05/26 21:11
→ guest2008:但休息時間不容許你細嚼慢嚥.且你沒細嚼慢嚥也從沒事過 05/26 21:13
→ guest2008:比喻聽的懂吧? 我認同細嚼慢嚥.我也認同測試..但現實? 05/26 21:15
→ TonyQ:我說得這些東西都是我現實有看到專案上在用的東西啊 05/26 21:27
→ TonyQ:你沒有興趣學一個有用的東西是你的事情，但是你把一個有用的 05/26 21:28
→ TonyQ:東西說成非現實，我覺得這是可以再多點討論。 05/26 21:28
→ TonyQ:工具是看人怎麼用的，當然一樣是工具有人用得像找自己麻煩， 05/26 21:29
→ TonyQ:這些工具確實也有可以用來是增進自己效益的地方。 05/26 21:29
→ TonyQ:這些東西需要五十倍的價格跟五倍的時間？ 05/26 21:31
→ TonyQ:在懂得用這些工具省時間的人看來，完全不作才浪費時間。 05/26 21:33
→ TonyQ:當然，不諱言的確有地方不作的確會比做好，但是不是所有專案 05/26 21:33
→ TonyQ:都這樣，而且那都是明白這些取捨經過評估的結果。而不是什麼 05/26 21:33
→ TonyQ:非現實。我待過專案公司，但我也可以利用工具縮短結案時間。 05/26 21:34
→ TonyQ:工具是用來做得快、穩、好，一樣是 excel 厲害的人拿他算一 05/26 21:36
→ TonyQ:堆東西還跑即時股票分析，不會用的會說 excel 好爛按計算機 05/26 21:36
→ TonyQ:比較快。:P 05/26 21:36
→ guest2008:建議你真的直接用新文章回覆比較快. 05/26 21:47
→ guest2008:你們家的金主你們家的老大有資源有時間給你們這樣子玩. 05/26 21:50
→ guest2008:我一直重複提"是環境因素"..結案收款遠比夢想更重要. 05/26 21:57
→ guest2008:系統比Excel好用太多了.但開發系統要一個月值得嗎? 05/26 21:58
→ guest2008:聽你的描述你的背景就是維護一套成熟的產品.只需做這件 05/26 22:00
→ guest2008:你有很多時間去做你想做的.更多公司都被逼到跟交期抗戰 05/26 22:02
→ TonyQ:我有三年的經驗在外面作案子，你以為我不知道你在說什麼嗎 05/26 22:04
→ TonyQ:就是因為有過這種經驗，我更知道工具怎麼去簡化時程跟追趕 05/26 22:04
→ TonyQ:時程。 05/26 22:04
→ TonyQ:還有回覆文章或推文與否，那是我的自由。 05/26 22:04
→ TonyQ:我會有很多時間正是因為知道怎麼作比較有效率，別倒因為果。 05/26 22:05
→ TonyQ:你也別忘了，拼結案收款，之後捅一堆樓子或是一堆 bug 讓你 05/26 22:06
→ TonyQ:驗收過不去而導致專案 fail 也是再常見也不過的。 05/26 22:06
→ TonyQ:並不是拼結案，案子就會結給你看。 05/26 22:06
→ TonyQ:在同樣的「環境因素」狀況下，不是只有你現在相信的那一套才 05/26 22:08
→ TonyQ:跑得動，只是你沒看過或不知道這樣跑更有效率而已。 05/26 22:09
→ guest2008:每個人工法不一樣.物件導向寫法根本不需重新1000case測 05/26 22:09
→ TonyQ:UML 的部份我沒什麼話說，那的確是用來溝通的，如果看得人 05/26 22:09
→ TonyQ:看不懂那自然就沒用。但是 test case 只要是開發者都可以用 05/26 22:10
→ TonyQ:來省時間。 05/26 22:10
→ guest2008:只需測你新增加的東西跟改過的.上層不會出問題 05/26 22:10
→ TonyQ:......你哪來的這種自信。 05/26 22:10
→ TonyQ:你 API 開得再好，底下調用那些 api method 的人不用測？ 05/26 22:11
→ TonyQ:你都在寫新 method ？ 不用改變既有函式？ 05/26 22:11
→ TonyQ:運氣這麼好都不會碰到核心函式？ 05/26 22:11
→ TonyQ:不說別的，改動一個 DAO 裡面的條件，後面"絕對" 不會爛？ 05/26 22:11
→ TonyQ:"你改過得東西" 如果有幾十個地方用到，你改一次測一次？ 05/26 22:12
→ TonyQ:再說，如果 bug 會在你想得到的地方出現，那就不算 bug 了。 05/26 22:13
→ TonyQ:問題不是「用什麼架構寫」的問題，問題是有人改過code就會有 05/26 22:13
→ TonyQ:錯，幾十年的資深工程師也可能會打錯字或丟錯變數類型。 05/26 22:14
→ guest2008:所以你的結論是花1/N的時間寫測試案例,反而會縮短開發? 05/26 22:23
→ guest2008:我沒數據沒有喊牌權.有比較閒的案子,實驗後再來看結果 05/26 22:26
→ guest2008:其實結案的關鍵點還是在源頭..需求.客戶/接案者/開發者 05/26 22:32
→ guest2008:三方面認知相同.才是結案關鍵..會寫錯都是有一方認知錯 05/26 22:33
→ guest2008:因bug fail是新組團隊或菜鳥才"容易"發生.資深很難發生 05/26 22:41
→ guest2008:發生九成是來自源頭需求不明確,傳達錯誤,搞錯需求. 05/26 22:44
→ TonyQ:「所以你的結論是花1/N的時間寫測試案例,反而會縮短開發?」 05/26 22:56
→ TonyQ:我的經驗是，省下來的時間來自於那些重複手動測試的時間。 05/26 22:56
→ TonyQ:這個時間是非常可觀的，當然，也因為這樣，測試要做在容易 05/26 22:56
→ TonyQ:被經過的地方。對 getter /setter method 寫 test case 05/26 22:56
→ TonyQ:就有點笨了。然後有些很難寫 test-case 的初期應該是先跳過 05/26 22:57
→ TonyQ:像是驗證碼這種東西就不要強求 test-case 去測試之類的。 05/26 22:57
→ TonyQ:test-case 適合那種單元內行為很複雜，驗算要花很多時間的。 05/26 22:57
→ enthos:朋友是geek居多,沒人在管UML、CMMI.但他們會做Test Case. 05/26 23:03
→ enthos:心得:需要準時做出產品,高時薪外包給最強者,不要找公司。 05/26 23:03
推 derekhsu:TonyQ，你說的QA所節省的產品Bug，並不一定可以帶來更高 05/26 23:21
→ derekhsu:效益，這是一個比較新的概念，與傳統QA流程不同 05/26 23:22
→ ohb:test case的設計與否在"第一次開發" "不需要維護"的專案比較沒 05/26 23:25
→ ohb:有意義 這可能也是接案公司比較常見的狀況 因為他們不需要持 05/26 23:26
→ derekhsu:產品上市之後再回來修Bug，產生的效益會高於完整測試 05/26 23:26
→ derekhsu:這在許多Start up裡面已經開始普遍接受 05/26 23:26
→ ohb:續的維護和擴充 但如果你今天想要自己做一個長期的產品 或是 05/26 23:26
→ ohb:把你的產品的生命週期延長 test case就非常非常重要了 05/26 23:26
→ derekhsu:如果Unit-Test能做好，QA的Case就可以減少 05/26 23:28
→ TonyQ:@derekhsu 這是比例問題，有些東西你必須要上市前準備好， 05/26 23:53
→ TonyQ: 有些東西是你可以等上市後再處理的。 05/26 23:54
→ TonyQ:上市前的目標仍然是在有限的時間內作最有效率的事情 05/26 23:55
→ TonyQ:而不是弄到沒有 bug ，這完全是兩回事。 05/26 23:55
推 derekhsu:你不瞭解我的意思，我是說完全不需要QA程序、Test Case 05/27 00:37
→ derekhsu:而是將焦點放在產品功能是不是對的，效能是不是可接受的 05/27 00:38
→ derekhsu:是「沒有傳統QA流程」，你提到的幾乎都是傳統QA流程 05/27 00:39
推 jlhc:我推一句 該回文啦... 05/27 00:58
推 atpx:兩位可各開一篇, 比較好閱讀 05/27 00:59
推 thinkniht:我建議回文 是覺得這樣編輯之類會比較方便 05/27 00:59
→ thinkniht:要不要做 就當事人的自由了(茶) 05/27 01:00
→ TonyQ:@derekhsu 這要看你怎麼定義QA流程，我看的公司十家有十種 05/27 02:14
→ TonyQ: 作法，我不確定你所謂傳統 QA 流程是講哪一套。 05/27 02:15
→ TonyQ: 另外 Test case 是為了確保程式有一定品質，產品功能再怎 05/27 02:15
→ TonyQ: 麼樣能容錯，總是有幾個核心功能必須確保完成， 05/27 02:15
→ TonyQ: 傳統 QA 流程可以包含這些流程，但不代表有這些流程就是 05/27 02:16
→ TonyQ: 某種特定的 QA pattern 。 05/27 02:16
→ TonyQ: 現也偶爾會看到將 test-case 列入 dev team 而非 QA team 05/27 02:17
→ TonyQ:我會選擇推文或回文都有我的理由，想看得就看，不想看得就不 05/27 02:19
→ TonyQ:要看，這種幾行推文回文也很難全數引到前因後果，反而容易 05/27 02:20
→ TonyQ:失焦，用推文的比較有一致性。 05/27 02:20
→ TonyQ:@derekhsu btw test-case 一樣可以拿來驗證功能跟效能。 05/27 02:23
→ TonyQ: 只是我不理解這跟你所謂傳統 QA 差在哪。:P 05/27 02:23
→ TonyQ: startup 搶快是用比較便宜行事的方式上線，用比較低的標準 05/27 02:24
→ TonyQ: 去上線，但是他還是會有一定程度的測試，test-case並沒有 05/27 02:24
→ TonyQ: 這麼狹隘。他就只是個工具，一個操作，把人工換成電腦。 05/27 02:25
→ TonyQ: 人能做的事情，在能有效率紀錄的前提下，換成手工去作。 05/27 02:25
→ TonyQ: *電腦 05/27 02:25
→ TonyQ:一般而言，會覺得 test-case 在增加開發時間的，是因為他們 05/27 02:29
→ TonyQ:在那些原本手工測試就不太會操作到，不太需要去測試的地方寫 05/27 02:29
→ TonyQ:test-case。但如果有知道哪些是熱點的經驗，這些 test-case 05/27 02:29
→ TonyQ:是可以相當有價值的。 05/27 02:29
→ TonyQ:至於對這些測試的看法，可以去翻「笑談軟體測試的幾個階段」 05/27 02:30
→ TonyQ:裡面寫得比較詳細，就不另外回文了。 05/27 02:31
→ TonyQ:"/笑談軟體測試的幾個階段" 05/27 02:31
推 leicheong:(小聲說)其實除了前一家公司外, 我一直沒用過UML... 05/27 07:43
→ leicheong:後期嗎? 只要一直是同一批人做就沒有問題. 會有問題都是 05/27 07:44
→ leicheong:在人手不停變換的環境吧. 這也就是小公司內的IT部門 05/27 07:45
→ leicheong:雖然不一定有標準流程也有可能準時結案的原因. 05/27 07:46
推 thinkniht:我目前專案會拿到的SA/SD文件格式堪稱多采多姿 05/27 07:47
→ thinkniht:偏偏就是不用UML(流程圖也跟一般格式不同) 05/27 07:50
→ thinkniht:不過看不懂會被當作是程式設計師自己的問題一.一... 05/27 07:52
→ tkdmaf:我只是知道，XP和AGILE DEVELOP很重試TEST！ 05/27 12:38
→ tkdmaf:打錯！重視！重點是重視他之後…… 05/27 12:39
→ tkdmaf:你就可以每天三天半去喝下午茶了。 05/27 12:39
→ tkdmaf:我曾經就發生過一個BUG解了4個小時搞不定。 05/27 12:39
→ tkdmaf:版本回歸後耐下心寫TEST，結果只花4分鐘搞定…… 05/27 12:40
→ tkdmaf:寫測試和不寫的結果是差了60倍的時間。你說要不要做？ 05/27 12:41
→ tkdmaf:真要我說那些說什麼事實上沒時間等等什麼理由。 05/27 12:41
→ tkdmaf:不如說是打從一開始就沒建立這種習慣吧。 05/27 12:42
推 leicheong:但是PM一開始的預算沒把test算進去的話, 寫test需要的 05/28 07:48
→ leicheong:時間就只能自己生出來了... (默) 05/28 07:48
→ tkdmaf:但如果花5%專案時間寫test，省去30~40%的debug時間的話。 05/28 07:50
→ tkdmaf:你寫不寫？ 05/28 07:50
→ guest2008:不寫.會出現30%debug時間..肯定是你還沒搞清楚需求就一 05/28 10:05
→ guest2008:頭栽進去造成的..請先退回起點.把條件完全搞懂在寫程式 05/28 10:06
→ guest2008:真的懂還會出現30%.表示身體警訊.請去睡覺睡飽一點. 05/28 10:08
→ guest2008:都不是.那表示你的工法有問題..才會種下陷阱災難 05/28 10:13
→ TonyQ:我讀樓上推文，很有樓上寫 code 都不需要 debug 的錯覺。XD 05/28 12:39
→ guest2008:又不是神.誰沒被bug玩過?現在搞網站都是被排版/CSS 玩假 05/28 13:33
→ guest2008:的.反而很少被bug玩了..要減少被bug玩一定都會有竅門的. 05/28 13:34
→ guest2008:我寫一個函數的習慣是"先寫完流程註解再開始寫code" 05/28 13:36
→ guest2008:跟大家一邊寫code一邊寫註解的習慣不同..而且 1.1 1.2.. 05/28 13:37
→ guest2008:都是列出一大堆輸入的檢核事項.,讓輸入源進來不會出問題 05/28 13:37
→ guest2008:重點是模組交出去,就不會有問題.而不是開發過程沒bug. 05/28 13:42
→ guest2008:有bug只會出現一次..怎麼可能重複出現?還要重複驗證? 05/28 13:42
→ guest2008:那表示你改錯位置了才會還再出現。 05/28 13:43
→ tkdmaf:樓上好厲害！寫程式從來不會有BUG的！(包括打錯字....) 05/28 14:54
→ tkdmaf:只要會出bug，管你是大bug或是小bug都應該要測。 05/28 14:54
→ tkdmaf:說真的！我只想看到每個函式是不是都有一個bug_list表示為 05/28 14:55
→ tkdmaf:正常。而不是你告訴我你的功能是正常的。 05/28 14:55
→ tkdmaf:我也不會想去看你的註解。最多是看那個函式幹嘛的！ 05/28 14:56
→ tkdmaf:上面寫錯！是test_list才對。 05/28 14:57
→ tkdmaf:然後我只會期望你把功能標在test_list，而不是函式前面。 05/28 14:57
→ tkdmaf:這樣我要看比較快。 05/28 14:57