最近跟朋友聊天，我们都是写韧体
聊到开案之后，要规划好架构，考虑所以因素后再开始动工还是先冲出一个雏形给老板看
我以前都是先冲出一版，出货后回报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真的很疲惫，不对工程师好一点就是整死工程师和自己但如果是一次性的买断的话，就看业务有没有要做口碑了

老板通常真的不懂什么架构 给出看得到的东西才是一切当然自己的信用是需要维护的在求表现跟绩效与信用的维护上要取得平衡

先冲一版，然后去跟老板谈要时间做完