|
找一个个人开发者，帮我们开发公司官网 |
被《代码整洁之道》所震撼
里面传出一个观点：专业的程序员应该经常重构自己的代码，那些不愿意重构自己所写代码的程序员要么是对自己代码没有信心，要么是没有掌握严苛的测试方法。
以上这段话跟大多数人的心理完全相反啊，众高知以为如何？
共收到29条回复
Linus, Jeff Dean不知道同不同意，不过以Linus的性格和跟他打交道的经验，他肯定会对这句话爆粗的
如果是做个示范工程项目，那肯定支持重构，如果是按照实际需求来说，为业务服务的就不要重构
重构是要经济成本和时间成本的...所以LD愿意花这个成本吗?
除非自己拥有生产资料，否则分分钟被裁
大部分狗屎业务代码没这个价值，核心代码倒是可以。
一般没人会关心代码，程序员生存智慧之面相防御编程
送一句话：尽信书，则不如无书
嗯 重构 重构完就说我啥都没改就是重构了一下
国内这个环境 ，还是面向工资和防御吧 写太好，分分钟被优化了
我没在大厂待过，我们是做通信设备的。以我的程序员经历，老板不在乎你的代码整洁不整洁，你只要把功能实现了，在一定的时间内不出大问题就可以了。你永远再做新产品，维护升级旧产品，能给你优化重构代码的时间没多少，如果有，那也是实在需要了。
赶工期赶项目，屎上雕花的时间都不够，哪有时间去重构。
我重构了之后出问题了，我 人没了
他的意思是减少技术栈避免项目变成屎山吧 但是实际上不太好重构 一个是没时间 在一个重构出问题咋整 除非测试配套的很全面
栈->债
只要有随手写单元测试的习惯，根本不怕重构。之所以不敢重构，就是因为单元测试覆盖率不够。
我之前在github上参与过一个开源项目，那边只要发现更好的实现，立马重构，之所以能这样，就是因为他们做到了100%的单元测试覆盖。
不过国内的软件开发现状，不支持100%的单元测试覆盖。因为写完整的单元测试会把项目时间拉长至少一倍，没有几个老板愿意投入这样的成本。
确实会经常重构啊。。。
好多年前第一次开始写项目时，为了突出自己的严谨性，搞了一堆else if，套了一层又一层。再过了一段时间，知道了卫语句。基本上每隔个半年，回顾自己的代码，好多方法都可以重写。
圣人的书是用来读的，用来办事百无一用
没看出这句话有什么问题啊。
经常重构确实对自己的技术成长是有益的，不过对项目本身而言就见仁见智了。
老板不同意啊
难得有个看技术的铁子
代码就是说话，你可以发明新词，也可以用谚语，只要解释器能精准解释，就可以了，重构不是做重复的事情，而是你本身就有点拖沓。
科学是没有国界，科学家是有国界的，和这句类似，总是有其他方向的限制
这句话很好啊，学习了。
怎么说呢，建议读这本的一定要去读《人月神话》
惊恐
还可以读一下，程序员修炼之道。
其实程序员只是为了一口饭的工作，也不容易，真正热爱程序员职业的人在所有程序员中我估计20%都不到。所以多份理解。
赞同二楼，这本书怕不是喷王必喷。顺带一提，我也多年前看过这本，但是看的时候就对他书里最后又跑回去重构开头的一些其实并没有可读性极差的代码，以及后来开发和工作中遇到的一些情况，我只能说代码整洁之道有的理论真的不可取，一定要看情况看项目，看人。这书得批判性的看。
