一、约定大于配置

泰思勒定律也被称为复杂度守恒定律。该定律指出每一个过程都有其固有的复杂性，存在一个临界点，超过了这个点过程就不能再简化了，你只能将固有的复杂性从一个地方移动到另外一个地方。

根据这个定律，在做系统设计时，默认会给用户一个“套餐”，这个套餐会满足多数人的需求。实在不满足需求再特殊配置。比如：springboot、JVM的默认值。

二、随时保存

在如火如荼的编辑文档时，电脑突然死机只能重启，重启后发现自己丢失了两个小时的辛苦工作。这种痛苦不是一杯暖心奶茶可以消解的。所以目前市面比较新的一些编辑器比如intelij都有默认自动保存的功能。但一些经典软件，比如office还是需要手动保存，建议喘口气的时间随手就按下保存快捷键。

三、任务分解，持续交付

错误越早发现越容易解决。不知道大家有没有这样的经历：好容易写出一个完整的功能模块，好多代码。提交之后找同事评审，同事评审出一堆代码风格问题。你找他评论未果，同事坚决的说你不改不给合入。硬着头皮改了，因为思路不连贯，改出一些bug。气不气。

但是如果做好任务分解，任务分解的足够小。做好一点就提交进行评审，事情就变得很简单。对于review你代码的同事来说。需要评审的代码越少，他能更容易的帮你发现问题，review效果越好。

四、免过早优化

只有在问题和解决方案都出现在你面前时才进行重构—过早重构是时间上的巨大浪费。不要投入半年后可能被扔掉的任何东西的完善上。过早优化是罪恶之源。

当然上面这种说话可能触动不了大家的心弦，这么说吧：如果没有很明确的需求，优化了也没有业绩，大家也不知道你做了，那为什么要费这个力气呢。

五、可读性大于没有需求的性能优化

你的代码只写一次，可别人会读它千万遍。你的代码会有未来的观众。代码也是一种书写形式的沟通。所以如果一个性能优化效果不是很明显或者对性能没有很强的需求。为了性能牺牲可读性是不可取的。

六、打印必要的日志

日志用做数据统计、系统监控和问题排查手段，虽然重要性不言而喻。但是因为通常在需求里没有明确提出，所以很多人可能在真正开发的时候会忽略一些重要日志的打印。那系统的哪些运行信息，需要进行日志记录？

1、功能模块的启动和结束（完整的系统由多个功能模块组成，每个模块负责不同的功能，因此需要对模块的启动和结束进行监控。是否在需要的时机正常加载该模块？又是否在退出结束的时候正常完成结束操作，正常退出？）

2、用户的登录和退出（哪位用户在什么时间通过什么IP登录或退出了系统）

3、系统的关键性操作（数据库链接信息、网络通信的成功与失败等）

4、系统运行期间的异常信息（NPE、OOM以及其他的超时、转换异常等）

5、关键性方法的进入和退出（一些重要业务处理的方法，在进入和结束的时候需要有日志信息进行输出）

因为公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。

想知道自己错过了哪些更新，可参考我不定期更新的《系列文章分类汇总》。