推 tkdmaf:我想邀請您年後來參加敏捷軟體座談會！有意願前來了解嗎？ 02/11 20:27
→ tkdmaf:聽我說！不如聽專家說。 02/11 20:28
→ ogamenewbie:對這系列我只有一個看法, test case 的撰寫也是有差的 02/11 22:56
直接回一篇文盡量講通透好了 不然講半天有一點鬼打牆
其實一切的一切就在
: → tkdmaf:敏捷開發：高穩定、低除錯、低維護成本。這是宗旨及要求。
這一句話。
有沒有道理？很有道理
但是並不是全部的場合都適合這個，甚至有可能還不是大多數的場合
怎樣說？設計模式的概念就不只有注重這一些
例如，你這一句話裡面沒有討論到"彈性","可靠性"
依據你的推文
: → tkdmaf:那就是工程師本身的問題。不行處理就請客戶回來找我們。
: → tkdmaf:反正我同學的公司對軟體是採「終身保固制」！
我大膽推測 你們是把程式的可靠性放一邊 以"反正有問題的話我們很可靠"取代
code可閱讀性放一邊，以"有問題的話看測試code"取代
好不好？ 說實話我認為見仁見智
如果你們非常好找到 或許顧客每次客訴反而對你們優良的服務增加好感
反之我想他不僅下次會換工作室 而且會在外面給負評
對了 你們可以記起幾萬行程式裡面有哪幾種變數可以用這件事情嗎
還是你們的測試code會告訴你們這一件事情
※ 引述《tkdmaf (皮皮快跑)》之銘言：
: 很高興你提到了重點。
: "無法快速維護及修改的程式"
: 原因在那？
: 我們寫程式往往都只著重在「預設計」、「設計」、「寫文件」、「除錯」。
: 而往往佔最大的地方就是「寫文件」、「除錯」。
: 尤其是除錯這件事。
: 無法快速維護及修改，是因為前手的人未提供「測試code」做處理。
: 你提到5000、10000行程式要靠註解才能去修改這非常非常的耗費時間。
: 這或許不一定是程式架構不良。
: 但絕對跟未提供良好的測試環境有關。
: 正因為沒有一個測試環境提供或告知您需要修改那一段程式。
: 或是bug出在什麼地方。
: 我們才必須用人工閱覽的方法去審閱我們的程式碼。
: 然而這種作法往往就是付出較高的人力以及消滅我們的腦細胞。
: 工程師加班，或許就是因為在靠人力來解釋程式碼的功能。
: 但如果我們在寫程式時，順手把測試code也寫好去對每一個功能及函式測試呢？
: 那我們很快就可以獲取我們要找尋的問題。
: 既使後來的工程師接手，也可以透過測試code所回應的各種結果知道他們所要修改的
: 部份或是產生的bug是在什麼地方。
: 這有一個「測試結果」表單您可以參考看看：
: http://pipirun.gotdns.com/hrc/CsTestHrc.php
你這裡討論的是測試code的重要性，這是很正確的
不過跟一開始的註解討論以及變數作法已經無關了
測試code並不能完全取代註解，因為彈性有差異。
: 他針對我寫的物件或是函式的功能進行測試結果。
: 當他輸出都是ok，就表示我的函式功能符合我預設的功能需求。
: 這個方法就叫做「測試導向」。
:
: 很多人都不明白幹嘛要那麼麻煩寫測試？
: 但寫測試的好處很多。
: 最大的優點就是：在你還沒開始設計你的功能前，先對你要的功能做測試，一但測試
: 你要的功能符合你的想法，你的程式也不用寫了。因為已經寫完了。
: (測試的本身就等同於程式功能的實作，這種事太多程式設計師想都沒想過。)
: 測試code所輸出的表單就已經是一份很棒的「註解」了。
: 既然如此，那何必那麼麻煩還要去寫註解？
: 當工程師們在挑戰5000、10000行的程式時
: 假設每五行就是一個函式
: 我可能只要看1000到2000個函式表輸出。
: 而且還可以透過搜尋去尋找我所要找的關鍵字函式或功能。
: 很快的，我就可以找到我要修改的地方。
:
: 我相信還是有很多程式設計師不能明白或習慣甚至不認同測試導向。
: 像CMMI這種重視文件甚於程式碼的專案管理規範也不能同意測試導向。
:
: 但曾經就有一個資深工程師在被別人陷害取走所有檔案。
: 在沒有任何資源也不會DELPHI的情形下。
: 花一個星期學delphi、14天透過測試導向實作專案。
: 最後7天做最終總結的測試。
: 他在1個月的時間內做完了原本做了6個月的工作。
:
: 那個工程師就是我們敏捷開發的講師，也是我以前的同學。
:
: 當我們有了比「註解」更棒的工具時。
: 我們還需要去寫註解嗎？
並不是絕對會比註解更棒，我舉一個例子就好
請問你測試code要是出bug的話，跟註解寫錯哪一個會讓顧客比較火大？
: 很多人可能不相信專案真的每一件都能案時交付客戶。
: 甚至覺得常常就是在delay進度。
: 但是我這位同學，他開軟體公司七年來，還沒遲交過任何一份專案過。
:
: 其實我也不否認我除了推廣敏捷開發。
: 也在找人才，找一個能跟我搭擋編程的人才。
: 所以他必須會php，必須能夠配合作業。
: 要能習慣就是二個人共用一台電腦來開發專案。
:
: 很多人聽起來不可思議？寫程式不是應該各司其職？
: 怎麼會二個人共同寫一個程式？這不是浪費人力又浪費時間？
:
: 這些疑問，我期望各位去翻翻敏捷開發和極致編程。
: 裡頭就有提到搭擋編程的重要性。
:
: 就如同有人說我對安全性的概念可能還不夠強。
: 說真的我一點都不care！
: 因為搭檔編程正是將二個人互相擅長的地方結合而能做到互相學習。
: 而且我們只是會不斷的找資料、買書去補強所欠缺的能力。
以上相同 見仁見智
如果你們不會拆夥也不會新增搭檔的話我很推薦你的作法
畢竟比起你們想辦法把code寫的可讀懂
可能快多了
: 但是程式的結構一但不佳，所帶來的毀滅性有時比安全性造成的問題更可怕。
: 甚至就因為這結構不佳造成安全性的問題也說不一定。
--
來個題外話 其實"註解"在refactory裡面是一個危險訊息XD
主要是 他認為真的好的code要好讀到不需要註解就看得懂XDDDDD
不過 要寫到那樣的code真的很難....再這之前好好地把code加一些註解
會實際一些XD
--
There are three kinds of lies: lies, damned lies, and statistics.
－－Mark Twain
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 218.172.241.136