仔细维护的注释、有意义的方法和变量名、SOLID 六大原则、单测覆盖、控制抽象层次使得代码像文章那样结构严谨层次分明。

语言特定的话，最好 team 里大家都遵守同一份 best practice，例如阿里巴巴 Java 开发手册中那样的规约

Bob 大叔的《代码整洁之道》和 Martin Fowler 的《重构》是非常不错的参考

先准备春招，拿到靠谱的实习 offer。尽量去比较知名的互联网大厂吧，相比于租房耗费你的学习成长的价值更大，而且这些公司的实习薪资一般 cover 租房吃饭费用没什么问题。

在 PDD 百亿补贴上买过 bose 降噪耳机、iPhone 11 还没翻车过。

方法名和参数表都一样的情况下，而且不打算重构。那么可以方法名加个 V2 后缀，当然这绝对不是最优的解决办法，但是比添加时间后缀要好。

更加强烈的建议是，为你新的方法取一个更加有意义且自解释的名字。

不会写很多，理想的情况下你所写的代码应该是自解释的。

控制代码的抽象层次，通过重构将代码整理成像文章那样顺畅的形式。可以参考《代码整洁之道》一书中对注释的建议。

本来想举个例子的，但是你说 “95%” 和 “绝大多数” 感觉又无法说明问题。

就我这边观察到的话，开发们对自己的代码应该有认真的态度和好的品味，当然这也需要一些像 code review 这样的过程建立起来，通过提升代码可测性和增加单测用例来控制千行代码 bug 率。经常线上遇到的问题，光看所用到框架的文档和教程是不够的。真实线上的流量和复杂的服务间依赖关系，排查问题可能要依次去定位到某个实例的锁争用、缓存系统、DB、任务调度等，而这又需要向下展开逐步定位到更细的位置。

某个服务告警了，排查出是上游服务的抖动带来多个下游服务的告警，继续排查是因为某个实例 CPU 占用率不规则跳动，问题可能需要深入到虚拟机 GC 算法。。。so on and so on

尝试把自己所学到的知识，整理成有条理的层次结构，可以用像 Xmind 这样的思维导图软件。

对于 Java 服务端开发来说，除了基本的 JVM 和代码技巧、CS 基础知识外，重点看看一些业务上必须要用到的框架，以及他们的使用场景和实现原理。

“整个职业生涯不会有一次和算法、数学打交道的机会”

作为程序员照理应该去熟悉所使用的技术和框架，特别是当遇到问题和异常时，如果理解不足那问题就会很棘手。同时在解决一个问题或是实现一个功能的时候，有多个路径可以选择，那么这个时候怎么选择也是需要精细化的分析在里面的。那在这个过程中，我理解的熟练掌握经典算法应该是基础中的基础。

“至于设计整体架构什么的，更多的是直觉或经验，而非智商”

错把软件架构模式当成了一门手艺。

“数学和算法”和“细心”，“直觉或经验”和“智商”，这两者所相对照的概念，并不在一个层次上。所以讨论 要 A 而不是 B，或更多的 A，而非 B，并没有太多的意义。

经典的 C10K 问题。但是看你具体的使用场景，如果不行的话，就负载均衡做吧。

MIT 6.824 B 站搬运课程 https://www.bilibili.com/video/av87684880

比较大的工程除了项目本身实现上的困难外，也需要关注建模的难点。

首先，实现上需要注重代码质量，有没有 code review，项目是否接入单测，单测的质量，ci、cd 等基础设施。

项目的领域模型是否科学合理，这是架构师层面关注的。

互联网产品关注业务的数据，业务产生的数据如何高效接入内部的大数据平台，供数据分析和运营同学使用。是否接入了监控中心，服务是否有完善的告警及时通知到开发。

估计项目的流量，以及未来的增长，评估机器的开销。是否已经有在使用的缓存、消息队列、存储、LB 等资源，机房可供扩容的机器数量。这里可以对服务压测，监控整条链路上机器的水位，服务的平响。

然后你列举的代码注释、日志、异常处理看看其他公司的 best practice，比如阿里的那份。

使用一个启动类完全可以，你启动时把相应的 Java bean 都加载进来即可