※ 引述《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

推推

这才是台湾软件业的现实面，花时间重构程式大多数都是在浪费时间而已，自己看着自己爽，其实都在白费功夫

一次到位就很了不起了，这样也不需要敏捷方法了

我9支棋类APP，跨C++,java,Obj-C,Swift。都不去重肥的反正AI的强度及CPU usage在同类APP找不到对手。我另外的opensource project, FPC开发的container, 就看一下各任重肥大神去肥一下吧。

好奇可以透露一下棋类 AI 诀窍吗

negascout+pattern evaluation, 没了。人类下棋也是这两个方式而已。

那你有机会可以分享一下面对需求扩充与变更如何一次到位吗我觉得比起吵要不要重构，这种技能更能带给大家利益

你会下棋，不就应该明白，棋要下得好，要如何看的吗？概念是一样的，在架系统架构时，多留点接口，但不要想一个接口做到底，也不要想什么动态参数的。一个功能call 三层都还做不出来，就有问题了。跟其它datasource 要三轮都要不到全部，就有鬼了。看需求，最好能通盘看，跟下棋一样只看一角会死很惨架构师对业务有了解，是很有帮助的。

我觉得你讲到一些很多人都忽略的重点1.布局优秀创造的效益远超过事后补救2.了解脉络对规划架构与实作路线非常重要比较可惜的是并非所有环境都能让这种布局的效益发挥到极致同时也不是所有人都有办法或有意愿养成这种视野

下棋你也无法做到全局最优啊。没这种情况吧。下棋也就是看一个大概的pattern的结果而已。

是，所以我也不会全盘否定所有的重构毕竟再好的规划也难免会有小更改，偶尔小型重构很合理退一万步，有些产品体质差到先还债就已是新功能的最速解了那这时候讨论要不要重构也没意义了

重构，讲的是产品，不是专案！！重构，要钱的。延申出要多久？要多“好”？谁付你钱？说白了，提出重构的两位老兄，看不到有开发什么大不了的系统。但宗教式的给出了refactor, agile,extreme programming, DSL 等。让大家宗教式跟着走。