Re: [轉錄] 抄捷徑的技術債，遲早要還的

[augustine (寒冬)]

※ 引述《thinkniht (不下棋=.=)》之銘言：
: ※ 引述《qrtt1 (lonely)》之銘言：
: :         http://www.ithome.com.tw/itadm/article.php?c=71807
: :         基於品質與時效，程式設計者在開發過程中，會因為一些
: :         做法而欠下所謂的「技術債」，雖然當時可以解決一些問
: :         題，但你要清楚知道，這麼做的代價終究是要償還的
: :         相信很多程式設計者都有類似的經驗，當我們在做軟體設
: :         計、或者是實際撰寫程式碼時，因為一些理由，我們沒有
: :         做出能得到最佳品質的設計、或是寫下有著最佳品質的程
: :         式碼。例如，當專案的時程過於緊迫，而在期限內完成工
: :         作又是十分重要時，我們就有可能放棄較為彈性、較具可
: :         擴充性的架構設計，或是寫出具有壞味道（bad smell）
: :         的程式碼。
: :         (全文請由網頁閱讀)
: 我認同這篇文章作者的看法
: 但軟體開發，很多事情都會受到一些不懂軟體開發的高階級管理者影響
: 要如何說服高階主管理解其此看法的重要性呢？
: 還是能用的只有一招：(重構的書上說的)
: 不告訴主管
: 反正任務交待下來，只要能做好就好，怎麼做是自己的事情
: 主管不用知道XDDD
說真的,我覺得有時候這問題是互相的~當然對工程師而言怎麼看都是只有問題有沒有解

我們公司就曾經軟體發生一重大問題,這問題是可以用不符原架構的方式去解決,

類似多個旗標去擋(總之就是快速偷懶但不是解根本).

好了~問題來了,開會時別team都說他們好早就採用這解了,而那位小主管堅持整隻要打

掉重練,他說這是架構上根本問題. 我們總經理是工程師出身的他能了解技術,但他非

常震怒,把他臭罵了一頓,這真的是換個位子換個腦袋嗎?

打掉重練依據經驗直到產品穩定要一年,而現在發生問題可能造成所有客戶退貨

也許這問題說穿了就是要還債,但工程師存在不是為了讓公司生存跟賺錢嗎?

也許這是極端例子,但有時重構會讓人不想去面對往往都是資源消耗差太多了XD

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 211.73.161.39
推 oaz:打掉重練就不是重構了。
推 yauhh:那個臭罵一頓應該是講話用詞上稍微敏感,重做跟重構不一樣.
→ andymai:不管是重構或重練~本來就要自己評估一下花費的時間了吧~一
→ andymai:意孤行不顧現實面也太... 另外重構雖然是應該是一個一個循
→ andymai:序漸進的進行~但還是要看原來的設計和預期設計的落差~有時
→ andymai:候就是沒有辦法只改幾個地方...
推 bobju:就像下棋,不能只算兩三步,也不能只看局面利益.
→ bobju:不過組織當中,本來不同位階的人利益考量點就不一樣,會發生矛
→ bobju:盾也是正常,這才需要溝通啊~
推 meltice:用flag很正常啊 尤其是#ifdef這類的 根本沒辦法不用
→ remmurds:打掉重練並不是重構...
→ darthv:overdesign
推 piss:有些工程師or主管，不知道是政治考量還是怎樣，一直專小問題
→ piss:碰到這種人真的很累很難溝通
→ LINGZ:很多小問題累積到一個程度就會變成大問題.