最近跟朋友聊天，我們都是寫韌體
聊到開案之後，要規劃好架構，考慮所以因素後再開始動工還是先衝出一個雛形給老闆看
我以前都是先衝出一版，出貨後回報bug接著maintain 花的時間有夠多，1 2次後覺得這樣
不行，有夠沒效率
需要更改功能的話，由於一開始沒有考量到，都要大改程式
之後我都是先規劃好架構，列出可能有bug的點，預想客戶可能會加減什麼需求
盡量讓程式彈性一點
雖然韌體軟體架構其實也不大喇
可是朋友跟我說，這樣不行
老闆只會希望趕快看到東西，愈快做好印象愈好，速度=能力
仔細想想好像有道理...反正maintain也是等客戶bug後再來改，或是下一個接手的人改
或者是要評估可行性，不管3721,先衝一版雛形，有達到部分需求讓老闆開心一下，後面
問題後面再說
是不是讓老闆看得見比較重要

我前公司常常隨便兜一些功能老闆看了很高興 然後很快就能簽約賣掉 到了真正上線都是馬上掛給你看XD

業務方面是這樣沒錯，越快交件越好但工程師方面也可以採取其他手段因應像是XP提倡寫測試然後把程式寫得簡單讓之後重構有個依據，不知道韌體可否

然後我就是接手善後的人

要先看你老闆是什麼人

接了一個整合系統維運，發現內部的邏輯就是if else六個系統就寫六個else，嘻嘻

然後上線後，連著半個月天天加班到凌晨，再回來靠北老闆

你老闆不是軟韌體rd升上去的話，所謂可擴充,易修改,好讀的程式只是你的自我滿足 只要UI漂漂亮亮，出功能快，他才不管裡面是不是一坨屎

寫不好也有可能被看見

拼快速出貨的東西，後面要維護會多很多時間和風險，只要程式碼夠垃圾，維護時就會很不穩定或是修改要多花很多時間。但另一方面，沒人講的話老闆也不一定維護的毛病跟專案前期有關就是* 漏字，不一定知道

FW就很難代CI/CD那套 硬體出問題就飽了 還要擦屁股

現在的我覺得：什麼都是假的，只有薪水是真的只有老闆的需求才是需求，只有老闆的問題才是問題自我滿足就到有餘力而且要有做白工的覺悟再說

其實你的想法是正確的

如果是用完就丟或是不用維護的專案這樣搞Ok，但是如果是要長期維運而且又是B2B甚至被政府監管的系統，這樣必死將來銀行就是一堆先求有再求好的搞死的

很吃寫的人的技術 強的可以寫的快但將來又好改

如果之後自己都不會再維護是沒差啦，但如果之後還是會回到自己手上，對自己好一點吧。

還有一點，習慣很可怕，如果長期都習慣趕工或是能動就好，久了之後就算讓你遇到重視可維護性的缺，可能你也達不到對方的要求了所以得先有能力顧好品質，再來看實務上要怎麼取捨

寫那麼快哪有什麼好的 除非語言好寫不囉唆 也怕被用完即丟

你朋友的說法 在普通的台廠 的確效果比較卓越

我自己是業務，覺得26樓說的有道理業務一定是希望越快出貨越好，但如果還需要負責後續的維運和接客訴的話，你系統出得爛當然也會怕像我就是系統有問題的時候被cue到就要馬上online回報，就算剛開始是會催工程師趕快寫出來出貨，到後來就變成盡量爭取更多的開發時間給工程師假日on call真的很疲憊，不對工程師好一點就是整死工程師和自己但如果是一次性的買斷的話，就看業務有沒有要做口碑了

老闆通常真的不懂什麼架構 給出看得到的東西才是一切當然自己的信用是需要維護的在求表現跟績效與信用的維護上要取得平衡

先衝一版，然後去跟老闆談要時間做完