28 | 怎么尽量“不写”代码？
范学雷
该思维导图由 AI 生成，仅供参考
最有效率的编码就是少编写代码，甚至不编写代码。前面，我们讨论过避免需求膨胀和设计过度，就是减少编码的办法之一。这一次，我们讨论代码复用的问题。商业的规模依赖于可复制性，代码的质量依赖于可复用性。
比如，Java 提供了很多的类库和工具，就是为了让 Java 程序员不再编写类似的代码，直接拿来使用就可以了。
不要重新发明轮子
“不要重新发明轮子”，这是一个流传甚广的关于软件复用的话。如果已经有了一个轮子，可以拿来复用，就不用再重新发明一个新轮子了。复用，是这句话的精髓部分。
如果没有现成的轮子，我们需要造一个新的。如果造的轮子可以复用，那就再好不过了。造轮子的过程，就是我们设计和实现复用接口的过程。
我刚参加工作的时候，从事的是银行综合业务系统的研发工作。银行的业务，牵涉到大量的报表。每一个报表的生成和处理，都是一个费力的编码环节。需要大量的代码，反复调试，才能生成一张漂亮的报表。那时候，市面上也没有什么可以使用的解决方案。我有一个同事负责这方面的工作，刚开始的辛苦程度可想而知。
过了几年，我们再聊起报表业务的时候，发现他已经在报表处理方面建立了巨大的优势。这个优势，就是报表处理代码的复用。他把报表的生成和处理，提炼成了一个使用非常简单的产品。用户只要使用图形界面做些简单的配置，就能生成漂亮的报表。编写大量代码、反复调试的时代，已经一去不复返了。传统的方式需要几个月的工作量，使用这个工具几天时间就搞定了。而且，客户还可以自己定义生成什么样的报表。生成花样报表的需求依然存在，但是再也不需要大量的重复劳动了。这个产品的优势，帮助他赢得了很多重要的客户。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文强调了代码复用的重要性，以及如何避免重复造轮子，推动轮子改进，以及避免重复多个轮子的问题。作者首先分享了在银行业务系统开发中的经历，通过代码复用大大提高了报表处理的效率。其次，文章提到了推动轮子改进的重要性，强调了改进现有轮子的价值，而不是重新发明。同时，也指出了市场上存在多个轮子是合理的，但在单一软件产品中，一个功能只应有一个轮子。最后，通过JDK 11中的例子，强调了重复多个轮子会带来维护和使用上的困扰。总的来说，本文强调了代码复用的重要性，以及如何避免重复造轮子，推动轮子改进，以及避免重复多个轮子的问题。文章还提到了代码修改的时机和注意事项，以及介绍了OpenJDK的接口设计问题。文章内容涵盖了代码复用、轮子改进、代码修改的时机和注意事项，以及接口设计的演进，对于开发人员具有一定的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《代码精进之路》，新⼈⾸单¥59
《代码精进之路》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(8)
- 最新
- 精选
丁丁历险记感觉老师在复述google 整理术，代码大全，代码简洁之道2019-10-146
王子瑞Aliloke有事电联原来传的是List的子集，JDK 10 里传的是Collection的子集，并且明确要求非空。 扩展了适用范围，增加了非空要求。 基于向下兼容的功能，所以没有在原有方法上修改，而是增加接口。2019-03-083
ifelse
不直接改原来方法是开闭原则，没记错List也是继承collection，用collection更通用。2022-07-27- ifelse我们每个人都会写很多烂代码，过去写过，未来可能还会再写。这些烂代码，如果运行得很好，没有出现明显的问题，我们就放手吧。--记下来2022-07-27
进化菌
说白了，就是要尽可能的做到复用，并且避免继续使用烂代码~2021-12-08
KEEP我想说，如果烂代码影响了新功能开发时，就是不得不改的时候了，要果断改掉，长痛不如短痛，否则只会越来越烂，后期维护成本会很大。 没有问题的烂代码就不要轻易修改。2019-12-08
轻歌赋看接口的描述，似乎是形参传入子集的问题，不知道对不对2019-03-08
往事随风，顺其自然扩展功能更好，不改变原来方法有可能向下转型错误，为了更好兼容以前版本2019-03-08
收起评论
