呃
讲这个其实蛮尴尬的
因为绿乖乖是最省钱的解（？）XD
一般来说要提升程式码品质
一些软件工程的东西要确实执行
有没有看过整个办公室三四十人
每个人头单月成本是百万日币起跳
花好几个月只是在写设计书？
每本写出来还要开会review要指摘要修正
我是知道台湾公司不会这么干啦
被认为是浪费时间人力
这也是为什么日本要一堆人搞个大半年
还要外包印度中国的东西
台湾天才开发只要几周
（后面bug一堆就只能说理所当然）
有设计书当初为啥这样写经纬是什么
至少有个纪录
不会结案人走了（被赶走？）后就是个谜
没设计书真的只能掷筊
然后就是执行过程的一些机制
像是toyota弄他们自己的车载、或者中国一些搞医疗器材的
Code在merge前一定是送过code scan的
前面讲的一些未定义行为
或者可能造成memory leak之类的code
通通都会被抓出来
一些太新、或者被认为风险很高的“奇技淫巧”也会被禁用
这个是从coding执行面最大限度减少出现怪事情的风险
当然也是挺花钱的
Code scan本身就不便宜了
修正也是很耗人力成本
这种工程师不能随便请
你给一些搞不清楚状况的工程师去改
可能改好几次还是扫不过
或者改出bug通不过测试
最后就是真的ship后出bug的对应
我就碰过某POS机公司出一个GUI bug
大体上是资安缺陷、透过某种操作可以打开管理者才可以执行的选项
公司的对应是土日聚集30+个工程师
把所有相关程式码扫一遍抓bug
这些人都很贵、加班费算起来不得了呀
我看台湾还是摆个乖乖算了
※ 引述《arrenwu (不是绵芽的错)》之铭言：
: ※ 引述《wei115 (社畜)》之铭言：
: : 毕竟严格来说 只有自然科学才是科学
: ？
: : 其他学科因为变量太多 很难严格的用科学方法来解决问题
: : 反而很多时候都是经验主义 甚至有些迷信
: : 以写程式来说 比起科学他反而更接近工程学
: : 工程学很讲究实用主义
: : 也就是说，虽然不知道为什会动，甚至他不该动，他却动了
: : 但他能用，那就用他
: : 总之，我想说的是
: : 放乖乖不是迷信，是一种工程学手段，不要再靠腰惹
: 这种 绿乖乖迷信 的争论还真是不知道在吵啥
: 虽然看过不少人说“绿色乖乖一拿走就OXOXXOXO”
: 但就我的认知，我从没听过机器出问题之后，
: 检修原因可以写“没有绿色乖乖”。
: 换句话说，实务上大家已经否定绿色乖乖作为出包原因的可能。
: 除此之外，也没看过什么学术调查结果显示机器故障率和乖乖的关系
: 放绿乖乖不就跟“讨个好彩头”类似吗？

台湾绿乖乖万能 有问题先摆个几包压压惊

推 专业的

每个人头都是钱

科学 成本 迷信的连集 绿乖乖交集 讲错

不是责任制喔？要加班费？

人月计算费用的结果就是能动但找不到人负责的code