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

看板PHP作者flamerecca (werewolf)時間15年前 (2010/02/11 18:12)推噓1(1推 0噓 2→)

留言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