Re: [請益] 新手請問一小片段程式

看板PHP作者 (werewolf)時間14年前 (2010/02/11 18:12), 編輯推噓1(102)
留言3則, 2人參與, 最新討論串6/8 (看更多)
直接回一篇文盡量講通透好了 不然講半天有一點鬼打牆 其實一切的一切就在 : → 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

02/11 20:27, , 1F
我想邀請您年後來參加敏捷軟體座談會!有意願前來了解嗎?
02/11 20:27, 1F

02/11 20:28, , 2F
聽我說!不如聽專家說。
02/11 20:28, 2F

02/11 22:56, , 3F
對這系列我只有一個看法, test case 的撰寫也是有差的
02/11 22:56, 3F
文章代碼(AID): #1BSzVvvx (PHP)
討論串 (同標題文章)
文章代碼(AID): #1BSzVvvx (PHP)