→ ghost3401:test-driven? 02/12 13:51
→ tkdmaf:YES!! 02/12 14:52
→ ghost3401:之前看eclipse的教學有這類的開發方式 利用junit..(不 02/12 16:06
→ ghost3401:熟) 跟版大提的這個超像! 02/12 16:06
再仔細看了一下，說真的我還是不太喜歡單純用文字表達意思。
因為可以被抓語病很多，有可能漏字，有可能表達意思不完全。
不過對於您的回覆我還是得用文字做些說明。
說真的我比較喜歡面對面的交流，因為言語的溝通往往不像文字毫無表情和情感可言。
※ 引述《flamerecca (werewolf)》之銘言：
: 這一句話。
: 有沒有道理？很有道理
: 但是並不是全部的場合都適合這個，甚至有可能還不是大多數的場合
: 怎樣說？設計模式的概念就不只有注重這一些
: 例如，你這一句話裡面沒有討論到"彈性","可靠性"
我想我有提到「高穩定性」、「低除錯」、「低維護成本」
你的可靠性就包含在這高穩定性。
如果程式無法提供高度穩定，又怎麼可能可靠？
低除錯，那是因為測試導向的功能，他在設計階段的測試函式就已經對於可能發生的錯誤
進行除錯功能。更何況，也許是我沒講清楚，說是測試code，其實本身就是一個測試的函
式。測試函式不是用來測出你的語法或是結構的錯誤，他純粹只是針對程式邏輯。
程式的bug最可怕的不是打錯字或塞錯語法，而是那種「明知道就是有錯，卻偏偏找不到
錯誤的邏輯」，甚至連我也鬼打牆的發生過：程式明明就沒錯，我卻偏偏認為他有錯。
還一直用「人工」的思考想半天，我同學直接寫一個測試函式一跑下去，才發現程式並沒
有錯誤，只是我程式的輸出跑錯順序讓我以為該出現的東西沒出現。
去想想，如果我繼續用「人工閱卷」式的繼續處理這個問題，恐怕再花個三天可能還是找
不到問題，但僅僅一個測試函式去測試我的結果卻為我省下大量的時間，重點是他保證了
程式在未更動前至少不再有錯誤。
而你提到的「彈性」就和低維護成本有關。
維護成本如何降低？當測試code能精準的為你的程式把關。
以及當你的程式碼是「任何『有經驗』的工程師」都能輕易解讀上手的話。
他的維護成本可以降低。這是一種。
另一種，就是開發的程式具有高度相容能力，當別的工程師要增加或修改功能時，並不需
要去動到主要程式本身的任何程式碼。
聽起來頗不可思議？那麼像xoops為什麼很多人開發了外掛模組？
facebook為什麼可以外掛很多的功能或是遊戲？
難道我們需要為了這些額外的新功能去變更我們主程式？
物件導向有提到的繼承和介面正好都提供這些問題的解決方式。
功能性的繼承與否，提供介面要求程式設計師依據原則來實作程式碼。
只要遵照我們定義的物件原則，工程師可以依他們的需求去開發他們的功能而不需要去
變動我們的主程式。
談到敏捷開發又提及物件導向，就不得不說說物件的原則：你不用知道我的程式碼寫些
什麼。你只要知道這個物件提供些什麼功能給你。如此一來你不用管我的物件放了多少
變數，也不用去管這些變數怎麼變。正如同你寫php使用的那些函式一樣！你會去用他們
。但你絕對不會去管這些函式在設計時內部的變數是如何運作。
原則不否認敏捷開發本身的基礎就是建立在物件導向上。
也因此，如果要說接手的工程師無法接任工作。或許我們該說，不是我們的程式寫得不
夠清楚易懂。而是工程師本身並不願意接受物件導向所帶來的好處。
但我們會相信在有測試code及透過各種良式的結構化程式設計。
具有一定經驗的物件導向能力的程式設計師會感覺到程式碼的易維護及可讀性。
畢竟敏捷開發的第一本書：重構。
原則上就是為了簡化讓程式碼可加清楚易讀而去使用的方法。
: 依據你的推文
: : → tkdmaf:那就是工程師本身的問題。不行處理就請客戶回來找我們。
: : → tkdmaf:反正我同學的公司對軟體是採「終身保固制」！
: 我大膽推測 你們是把程式的可靠性放一邊 以"反正有問題的話我們很可靠"取代
: code可閱讀性放一邊，以"有問題的話看測試code"取代
: 好不好？ 說實話我認為見仁見智
所以你這一段話當然還是以我那句「高穩定性」來詮譯這一點。
: 如果你們非常好找到 或許顧客每次客訴反而對你們優良的服務增加好感
: 反之我想他不僅下次會換工作室 而且會在外面給負評
: 對了 你們可以記起幾萬行程式裡面有哪幾種變數可以用這件事情嗎
: 還是你們的測試code會告訴你們這一件事情
這一段話在物件導向而言不是個問題。
就如同我說的：你會去管php的函式裡面有什麼變數在控制這個函式的功能嗎？
雖然我一直漏掉提及了一件事：
「把具有功能性的程式段封裝成一個函式，而這個函式最多5行就應該要結束他，如果
做不到，那可能你的要求不只一個功能，那就封裝成一個物件，一個物件或許就有很多
個函式，當然每個函式都僅可能不要超過5行，切開一個一個函式功能時，他們就只是
功能。而不再是一段程式碼。如此一來，就不需去在意這個物件寫了什麼變數，做了什
麼事。而是在於這個物件對其他的工程師而言：『它提供了什麼重要的功能給予使用』。
」
: ※ 引述《tkdmaf (皮皮快跑)》之銘言：
: : 很高興你提到了重點。
: : "無法快速維護及修改的程式"
: : 原因在那？
: : 我們寫程式往往都只著重在「預設計」、「設計」、「寫文件」、「除錯」。
: : 而往往佔最大的地方就是「寫文件」、「除錯」。
: : 尤其是除錯這件事。
: : 無法快速維護及修改，是因為前手的人未提供「測試code」做處理。
: : 你提到5000、10000行程式要靠註解才能去修改這非常非常的耗費時間。
: : 這或許不一定是程式架構不良。
: : 但絕對跟未提供良好的測試環境有關。
: : 正因為沒有一個測試環境提供或告知您需要修改那一段程式。
: : 或是bug出在什麼地方。
: : 我們才必須用人工閱覽的方法去審閱我們的程式碼。
: : 然而這種作法往往就是付出較高的人力以及消滅我們的腦細胞。
: : 工程師加班，或許就是因為在靠人力來解釋程式碼的功能。
: : 但如果我們在寫程式時，順手把測試code也寫好去對每一個功能及函式測試呢？
: : 那我們很快就可以獲取我們要找尋的問題。
: : 既使後來的工程師接手，也可以透過測試code所回應的各種結果知道他們所要修改的
: : 部份或是產生的bug是在什麼地方。
: : 這有一個「測試結果」表單您可以參考看看：
: : http://pipirun.gotdns.com/hrc/CsTestHrc.php
: 你這裡討論的是測試code的重要性，這是很正確的
: 不過跟一開始的註解討論以及變數作法已經無關了
: 測試code並不能完全取代註解，因為彈性有差異。
測試code當然能取代註解，因為測試code的說明就已經清楚指出「函式」的用途為何。
你不用管函式的內容寫些什麼，而是這個函式提供你什麼功能。
如果這個函式的功能不符合你的需求。你應該自己寫一個函式掛上去測試。
而不是想著要怎麼去改原來的函式。對工程師而言，改code是最麻煩也最累人的。
我拿我的水族箱要你改變他的造景，你要放水，要挖沙，要重新擺放水草。
那你可能反而希望我給你一個空的水族箱照你自己的意思去配置你要的造景。
但你絕對不會希望我要你換水族箱時還得順便把底下的櫃子也拆了。
原因只出在你拿來的水族箱比我的size大！
(物件提供介面時，工程師必須依照介面的原則去實作code，實作出來的功能絕對能相
容，因為是按照原本程式規範的架構，但至於是什麼功能，就不受到規範。)
: : 當我們有了比「註解」更棒的工具時。
: : 我們還需要去寫註解嗎？
: 並不是絕對會比註解更棒，我舉一個例子就好
: 請問你測試code要是出bug的話，跟註解寫錯哪一個會讓顧客比較火大？
測試code只是一個輔助工具，他是用來驗證主函式的正確性。
也就是主函式的輸出要符合我們的「期望」。
當最終輸出確切符合期望值時，測試code和主函式二方面都將100%無bug。
聽起來難以置信？但在我們的課程做練習開發時，我們的確見到這種不被相信的事實。
若要說有bug，那絕對是人為的對期望值判斷錯誤。這種情況就算不寫測試code也會
發生，甚至一發生之後，之所以難以修改是因為沒有測試函式給予立即性的告知。
另外確認測試環境在重構、專業php5程式設計、敏捷開發都不段的被提到。
這可不是什麼新的立論。因為敏捷開發已經是10年前的產物了。
國外很多的軟體團隊都相繼的使用這個被驗證高度有效率的方式。
國內則受制於很多公司採用CMMI這種標準而致使工程師們無效率的持續加班。
但根據業界工程師的了解，國內最少還是有4家公司仍採用敏捷開發來開發程式。
而這些公司或團隊，也因而創造出高效能及高品質保證。
: 如果你們不會拆夥也不會新增搭檔的話我很推薦你的作法
: 畢竟比起你們想辦法把code寫的可讀懂
: 可能快多了
搭檔編程除了透過二個工程師討論，實作之外。
也會不斷的對程式的架構進行修改並大量的提供程式的可閱讀性。
而並非你說的只為求快而犧牲掉可讀性。那不是一種正確的做法。
: : 但是程式的結構一但不佳，所帶來的毀滅性有時比安全性造成的問題更可怕。
: : 甚至就因為這結構不佳造成安全性的問題也說不一定。
: --
: 來個題外話 其實"註解"在refactory裡面是一個危險訊息XD
: 主要是 他認為真的好的code要好讀到不需要註解就看得懂XDDDDD
: 不過 要寫到那樣的code真的很難....再這之前好好地把code加一些註解
: 會實際一些XD
最近有一套程式(我忘了名稱)，他強到能分析像是C++、JAVA語言的程式碼結構特性。
包括連註解的數量都會清楚標示並認定大量的註解是影響程式碼效能的元兇之一。
最大的原因是太多人「濫用」註解。
註解只是用來說明你程式的功能，用途以及可能性的使用方法。
但他不是給你一行一行用來標示變數特性、用途以及方法。
//filename:CsSwap.php
//change number(2 number)
function swap($a,$b){
$temp = $a; //把$a先放到$temp
$a = $b; //再把$b替換掉$a的變數
$b = $temp; //最後把$temp放到$a就完成$a和$b的變數交換
}
上面的程式註解就一對一錯，對的是最上面說明這個函式的功能為何。
錯的是每個變數行後面都加這種根本沒必要加的註解。
因為函式只有三行。變數也限定函式使用。
這種情況加註解有加等於沒加而且註解的字還比程式碼長。
當你的變數只在於函式或物件(包含物件屬性)在運作時。
他跟程式的外部一點關係也沒有。
這種情況下，去為變數寫註解會變成極度沒效率的一件事情。
請記住：我沒說寫註解是錯誤的事！如果真的改不過習慣要寫也是無可厚非。
但有時過多的註解會反過來降低程式的易讀性。
因為你很難不去在意除了程式碼之外那些可能你並不想看的程式。
當然，我講的都是軟體開發的「方法」。
只是提供一些各位可能也沒思考過的議題去做一些說明。
大部份我講的東西在我學習開發的過程中都是被實作過才提出的。
當然我是感謝我有一個好的老師不斷的給我指導。
有些方法被質疑並不是方法本身有問題。
而是在於這些方法被人們花多少時間去實地驗證而去接受他。
重要的是：是否親身驗證並實作這個方法，才對這些方法提供意見。而非其實並未照實
作過，僅憑個人思考認為這不可行？
我很歡迎各位住台北有興趣的來參加2/21日的敏捷軟體座談會。
至少講師是我覺得很難得的資深(20年)實務派。
比較不像之前網路有個也是敏捷軟體座談會，講的全是理論的專案開發。
至少我們的座談會，會有很大量的程式碼供各位參考學習而不會流於紙上談兵。
為了避免有流於廣告，如果各位有興趣請直接來信給我。
我會告知參加的時間、地點、費用(費用我只能說很小額，非常的小額，小到其實那只是
場地清潔費加茶水費而已)
雖然那位講師的主要講述程式是C++(他偏愛C++)，不過可以依照實際條件全部改用PHP
做課程。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.104.130.253