写程式不知不觉也一年半了
看着公司庞大的老旧程式
前人写的实在杂乱
造成了维护上有一定难度
最近有心想要尝试从简单的地方开始试着重构
让后人可以更好的阅读程式
但想想，整理这个不知道有没有意义
以目前能力重构效能会不会变得更好都是未知数
而且还要花大量时间进行测试
最终效果可能就是变得 模组化 、好维护、易读
不知道各位前辈 对于程式要求是什么
维护能动就好？
偏好clean code的原则？
不管环境、工具、写法如何 只要能快速端出需求就行？

先谈钱薪水福利 再谈工作

改那个会让你钱变多吗

没新 feature 能开的时候，重构点小东西总是好的。不过，我觉得市场面或是长官总是新 feature >>> 重构，自己要好好把握这个权重

1. 专案能活多久 2. 公司能活多久 3. 你能活多久refactor出问题，以上三者可能就提前阵亡了要记得refactor永远是为了自己，为别人没意义甚至厉害的人是烂code丢给别人修，自己拿feature KPIClean code/arch的意义在，自己后续延伸能顺利不会卡到换言之一切都还是为了自己的feature = KPI或是像我这种小废物，已经接了无数别人丢来的烂专案来救把专案救活还改到很好，KPI全算别人的。只能说问心无愧

每月薪水准时到，奖金准时发，我可以一直没事

refactor有什摸performance吗想想现实面喇

当你会想这种事情的时候代表在这间的技术到顶了

理想很美满现实很骨感看过各种客制化 太靠北 想想这种还是继续乱下去

有分红 股票吗 没有的话 死薪水操什么心 公司赚一百兆跟一百块 都没差 搞好没人在乎 搞烂一定抓起来喷

不要浪费时间重构对长官而言重构一点贡献也没有曾经有一个长官对我说：重构只是把code改成自己看得懂的多年后回想，确实如此

最近也在苦恼一样的问题，code烂到老板觉得只是一点小改动，但需要花很多时间改，硬改出来也只是让code更烂...

楼上，我建议就继续烂，难改就尽量不要改只要撑到交接出去的那天就好

问题是老板觉得简单就会一直压时间，最后就只能靠加班，我怕撑不到交接...

专案只看结果啊，除非换你当主厨地位的去code review

一年半，先什么都别想

重构不是重写

一年半 你别添乱就好了

看情况，如果是就业寒冬的欧美，就得学会屎山雕花还有屎上堆屎，别问为啥这么干，全都是为了job security，你善于维护粪code，这算自己的credit，公司就裁员时比较不会动你。

重构就是模组化 避免构出一个垃圾还不好救

重构不都是面试才会提到的事情吗

想做点什么值得赞许啦，但老实说你想做这件事情只是自我实现，别人根本不在意，不如自己做side project ，说不定还能创业

看你觉得坑会不会害到未来的你啊~

你可以基于feature需求来改，不要没有gain就花时间

重构吃力不讨好，只会换到烂考绩，受不了的话离职比较快

可以想想自己的薪水有没有多到值得你重构屎山代码

直接跟你讲 没意义

你怎么说服人重构的结果比较好？

我经常在做重构 来给些建议首先重构只应该占用你总工时的30%以下 再来是分辨什么样的重构是有商业价值的 对于没有商业价值但却又必须做的部分 应该要让同事也来分担 如果这部分无法说服老板 那我建议放弃 同时要思考做重构能对你个人有什么价值? 譬如这些经验能把你训练成一个architect吗?总结要做重构要规划从最有价值的部分入手而不是最简单的且要说服老板跟同事这是一件有价值的事 并能把工作分担出去再举例什么是有商业价值的重构? 譬如memory usage会减少TAT会变快 UI更加user friendly

现在有AI帮忙通灵 要维护粪code应该容易很多了不要想不开去重构粪code

一堆系统10、15年才大修，到时要重构再说 除非找你进去就是为了系统翻新

没追求，只想早点退休

有没有一种可能 你重构完 下一个人看也觉得架构很差

先取得同事信任吧

其实追求更好的程式码也才有机会挑战更好的公司 如果总是写垃圾 分不清楚什么是对是错 你会机会进好公司吗?不过确实做feature 跟做出效能提升比较有价值就是了

有钱领最重要！程式只要能交付出去，照spec操作没问题就好花时间在那重构、clean code，都只是自己看爽而已，主管根本不希望你去动那些使用者需求导向什么的也不用，主管要你做一坨精美的大便，就照着做出来给他就好

没产值的事情都是做来放履历的 但这效果还不如做有产值的

你自己都不知道效能好不好了，怎么说服大家？

看你时间成本和个人意愿到哪

同意某panda

没在整个重构的啦 这件事要有产值一定是重开发一套新的

开发新的记得要取新的名字，别像我用一样名字让大家熟悉结果就是年终时被列为没任何专案在做，同名的二代不算数

重构看目的是什么 如果重构完效能变高很多 而且效能提升让这个产品在市场更有竞争力 那我觉得可以

人家叫你换个灯泡不要帮人家把天花板也重做

gn01705529讲的是正解 模组化只有模组的人自己看得懂

重构完后两个礼拜回头看 又觉得需要重构

不要改

一堆人只会over design

你以为的 clean 其实是别人眼中的 messy and dirty

能动就好，程式内容一律放给它烂

我都在修bug的时候偷把code变成自己的形状 潮爽der

因情况而异。根本就没有标准答案。菜鸟才认为有答案。

改这个老板只会觉的你一整天都没事干

只要能稳定给薪水 就没差 没能力出来当老板就认命拿劳力换钱

等等，写一年半的程式是有能力去规划重构的吗？

能呀 不然要请那些写15年程式的老狗去规划重构呢

推六楼~做久了觉得真是这样+1

以前会想重构，现在只敢tab换space

我以前改个变量名称就被老害呛了，说这样会害他看不懂...就只是把一些tempNum, cnName, uCount这种意义不明的名称改成有意义的，就被呛XDDDD

楼上改成什么?

忘了 差不多就是uCount改成userCount这样 写清楚而不是缩写还有一些temp开头的变量通通改掉而已

看过好几间公司都这样命名...是业界通例吗还是都出自同一个厂商写的

u 应该是型别还是其他有意义的字?

我有遇过不准在for loop 里面写int i的说变量一定要有可读性 int i没有意义

i不就index==

不准用i 印象中是某教科书等级的文章规定这种规定多如牛毛，本soft job版十年前也有人订了几百条说要全国一致遵守，还做了套件去检查。当然是没人鸟

temp就真的是tempㄚ ==

才1年半，先不要

才写一年半，你确定你的架构观念比前人好？

我都是觉得这段程式 "不应该跑这么慢"，才去重构

不需要鸡婆 做了钱不会比较多

我变量都用中文，爽

敝司会把重构当KPI就值得做下去 没人理你甚至反对的事别做不过重构的同时一定会顺便优化效能, 解决稳定性, 减少客制化增加公版扩充空间

别浪费时间重构了 $$比较重要

陈年老扣 重构通常带来只有风险 以前圈了一个资深工程师人力去做局部重构 结果弄出来的东西 比前人因时间压力硬干出来的稳定性还差

当然是能动就好 那不是你的公司 不要出包 其它管他去死喜欢要求？做自己玩具专案 要多优美就多优美随便你搞

之所以写得这么乱就是让公司知道这屎代码只有你能搞 公司就不会随便开除你 你弄的太浅显易懂 你的替代性就高了

不是钱吗？不是追求。钱吗？

clean code?认真？都加班到9点了你还要clean code?叫老板多请人吧，除非是你自营

写程式的追求就是能够好好帮助公司达成目标

什么物件、OO、XX导向设计一律用工资导向设计来想就好

当然是有一定的模组化好维护特性 但特性程度不会太高在公司要好做事但是又不能做太好 最好的工作就是在公司要做事但是loading并不高至于公司前景那是很考验高层的能量的 否则就是一将功成万骨枯 我相信没人想当那个枯骨

主管：吃饱太闲，多给一些工作

$才是最重要的$给得够多，大便都给你吃

钱钱

谁会无聊去改以前的code，没事做？没事做就好好发呆啊。