Re: [討論] hard code 速度會快嗎?
※ 引述《HZYSoft (PCMan)》之銘言：
: 如果有在好好追蹤技術債，定期償還，視情況舉債，有時是一件好事情。
: 重點 hard code 的當下要留下註解，說明前因後果，並且開 bug 追蹤，
: 這樣日後不會忘記，要 refactor 也比較好搜尋到這些位置
: 補充:
: 註解的使用不是我想回的重點，重點是平衡短期和長期效益
: 按照當下的狀況，調整開發的步調。
: 建議註解單純是加個 TODO: 的註記日後才不會忘了 cleanup
: 或是有些緊急的修改有當下的時空背景，怕一忙沒法馬上清
: 日後有空要 refactor 的時候，回想不起來當時狀況。
: 註解不是描述 code 做了什麼，而是描述為什麼會有這 hack
: 至於 code 做了什麼，自然是 code 寫好讀 code 就懂了
都說是做專案了，又不是做產品。
做專案當然是做完收錢，Meet Dealine，所以重點是，
照案主的需求，改成他要的，照資安需求，修掉有問題的地方。好好上線。
一案結束，就下一案來了，你還有空refactor? 誰billing你？
我是真的不明白ptt 上一堆天天refactor 掛嘴邊的。
用數字說話吧，台灣是出了幾個產品？ 幾個open source project ?
大家不就接案或做公司內部PROJECT。
你一個人爽refactor 讓其他人陪你一起更版，就真的是一個老闆的現象囉。
--
好奇接案生態
但你不是有寫過象棋 app 嗎，你的 app 總會重構一下吧
內部project真的東西有在跑就好
我的app 基本是一次到位，不管加減功能。
一堆人嘴重構,現實老闆會答應嗎?
更何況你不用物件導向跟設計模式的方式去重構,結果一樣渣
如果是一人專案，想怎麼改，只要老闆不被 call ，當然
不會有問題，但你想改的絕不是一個人的專案，這時候就
不是你一人的事了。
實際上有的功能也不可能完全重寫,個人經驗有的是改寫
包成物件化,後續好使用好維護罷了
一開始不做以後大概也不想做 反正要爛一起爛
呃
我認識這樣的人，他說自律重於他律因此不屑加入版控
你的薪水低於100萬~ 這篇沒有說服力
台灣也是有做產品的公司，我覺得風格的確差很多
稍微有點好奇labbat說的不加入版控是啥情況 XD
中肯。做過產品的人還真相對少。台灣大部分的工作，哪來那
麼多refactor
也不一定 如果是有持續擴充維護案 有資源還是能重構的
但比較多時候是出現問題再來重構改善XD
推推
21
首Po如題 hard code的速度會比較快嗎? 根據我經驗 hard code可以在極短時間內處理一些專案上的問題 但是專案上有高度相似的東西 藉由hard code去寫並不會比較快 反倒是多花一點時間重構 重構完畢之後 再來只要套function 修改參數 這速度會比hard code快很多25
關鍵其實要看你的專案現在在哪個階段 1. 專案在非常早期: 這時候 hard code 有可能其實是最佳解。 此時需求不太很確定，可能經常修改。你現在看起來有幾段 code 很相似， 可以重構成共用 function，但不幸的是，幾個月後商業需求改變，他們的行為2
你講這個就代表你們公司(或工作室?)甚至於你個人 完全沒有經營codebase的習慣 我敢這樣說有幾個簡單的推論: 1. 如果你們是接案公司，接的案子種類應該不會南轅北轍 2. 如果你們是接案公司真的一天到晚在接五花八門domain的專案，那代表你們的競爭![Re: [討論] hard code 速度會快嗎?](https://i.imgur.com/tr55WF9b.png "Re: [討論] hard code 速度會快嗎?")
15
再吐一下天天refactor 的，在台灣你可以看到一堆公司，都有自己的產品， 就是接案子後，用原案的CODE重包出來的：產品。 然後，根本賣不動，這樣要你老闆BILLING你的閒著沒事做去re-fat-tor? 號稱精進系統，使系統更好what? 這下問題大了，何謂"更好"？如何衡量？1
re code 就是一個個人意願的問題，跟 code 是誰的財產無關，你雇用一個 coder 就等 於授權他來改你的 code，跟你請一個清潔人員來家裡打掃，跟你的房子是不是他的財產 無關。 還有人回說要經過股東同意才能歐push code咧，看到真是讓人噴飯，是多麼迷你的公司 會有股東跑來管這個？![Re: [討論] hard code 速度會快嗎?](https://i.imgur.com/iwoZNLCb.jpeg "Re: [討論] hard code 速度會快嗎?")
前面很多人說得很好了，只做點補充 如果你是新手，前面說的那些絕大部份都跟你沒有關係， 因為你不具備相應的必要能力。 某些 case hard code 好， 但是你可能沒有辦法正確判斷倒底是不是那些 case，![Re: [討論] hard code 速度會快嗎?](https://cdn.sstatic.net/Sites/softwareengineering/Img/apple-touch-icon@2.png?v=1ef7363febba "Re: [討論] hard code 速度會快嗎?")
33
Re: [討論] Unit test 的撰寫請益先說結論，先都不要寫。 Legacy system 要先補大範圍的 integration test，確定整體的行為是對的。 如果 code 沒有要再改，不用補細部 unit tests。 原因是因為，原本 API 可能因為設計不良，導致無法寫 unit test 得先 refactor 才有辦法讓它變成 testable，這情況就要先 refactor 再補 UT![Re: [討論] Unit test 的撰寫請益](https://martinfowler.com/logo-sq.png "Re: [討論] Unit test 的撰寫請益")
18
[討論] 專案尾聲，沒解完的bug還要理會嗎？記得以前接過一個車用HUD的專案 C3 sample, 接近 PVT階段的案子 因客戶急用，服務廠的展示廳新車要直接裝機 結果，賞車的客人在試車的時候，儀表跳出不尋常的訊息 嚴重警告的訊息，cover住整個儀錶板畫面了27
Re: [討論] 怎麼跟自以為是的同事相處提供一點不一樣的看法 ※ 引述《leo5916267 (封膜獵人)》之銘言： : 也許在軟體也蠻容易遇到類似個性的同事 : 我們是新創公司，我進去前已就有一個前端工程師，他從0建構了整個產品A 代表他能力不算差22
[討論] RD還需要身兼專案管理嗎小弟在一家烘焙坊擔任RD 公司主力產品是 摩斯漢堡 與 七龍珠人的蛋糕 最近因為專案開了近百個 而且我司編制上Project manager 只有 一隻手數得出來的數量 為了不讓這些Project manager 倒掉21
Re: [討論] 重構跟kpi的考量如果 A, B 都沒有任何 tests，建議不要動他。 幫 C 實做這個功能的時候，把 unit test 寫好寫滿，確保 C 是對的 行有餘力，針對 A, B 的使用情境也加上 test case，確保未來在 A, B 確實能重用 (這點很重要，否則很容易程式長得很像你以為可以重用，實際上根本不能) 就先做到這樣就好，確保 C 的品質，同時你獲得了高品質的 reusable 模組5
[問題] 台灣實習經驗對申請、美國找工的幫助[問題] 台灣實習經驗對申請、美國找工的幫助 各位前輩好，小弟就讀 112 轉專業 cs，目前在美商擔任 SWE intern，會在今年年底申請美國 cs 相關的研究所。想聽聽板上大大對於在台灣時期的實習經驗對於申請美國就業型 program 和畢業找工作的幫助。原本的公司願意讓我延長實習時間，但不知道該在一間公司繼續待半年，或是去其他公司刷 title 跟工作經驗。 目前有這三種選擇 1. Extend 美商公司的 SDE intern 半年（2021 年末結束） 優點：4
[實況] 有毒有料的TD塔防《Refactor》當肉遊戲：重构 Refactor 受到廠商邀請來玩這款自由度很高的TD塔防 目前玩3小時的心得是，有料，好玩，夠毒 但不確定後面的關卡設計會是如何 那這作品挺便宜的102元，有興趣的可以看看![[實況] 有毒有料的TD塔防《Refactor》當肉](https://static-cdn.jtvnw.net/jtv_user_pictures/05486af8-a00d-4357-9634-a52a01dd11ba-profile_image-300x300.png "[實況] 有毒有料的TD塔防《Refactor》當肉")
3
Re: [討論] 用AI寫code產生的疑問幾個未來可能的 cases: 當工程師工作開始都提早完成了，會有以下幾種發展 1-0: 裝忙不要被老闆發現 or 更早下班 1-1: 老闆接更多工作 1-2: 砍人，更少工程師做更多工作