在文章中，我们提到，把程序员逼成社畜的，常常是自己对工作量的评估不到位，对工作的安排不合理。有时候，明明需求没有那么多，却很难找到摸鱼的时间，还是发现忙成狗，下面这个场景，相信你也遇到过。
Q弟：这个方案已经实现得差不多了，就是有个功能点不好做，去找架构师请教请教？
（不靠谱的）架构师：你这个方案看起来有点问题，这个功能很难做，为什么不用方案B做呢？
Q弟：有道理，之前我也没想好，我回去加班改改。
代码改到一半，发现方案B在另外一个场景也有问题，最终继续讨论，得到了方案C，又风风火火加了两天班，最终才把整个项目完成。
在我们的工作中，经常遇到会遇到这个一个问题。一个需求下来了，然后就想着，这个需求跟之前的差不多，然后就火急火燎地开工，最后发现又有些点没法满足，然后继续修改方案。不停地翻工。
在战国策中讲过这样一个有意思的事情，魏王想要去攻打邯郸，季梁赶紧过来劝谏，跟魏王说，今天来的路上有个人说要去南方的楚国，却一直往北走，我跟他说，这不是去楚国的路，但是他不听，觉得自己的马是千里马，车夫也是老司机，身上的钱又多，怎么可能会到不了目的地呢？今天魏王如果要称霸天下，就应该要灵精图治，而不是贪图小利。
这就是著名的南辕北辙的故事，在错误的道路上，你越努力，可能离目的地却越远。在软件开发领域，想不清楚就做，让你付出了了大量无谓的劳动。
很多人会说，道理都懂，但是很多坑都是在写代码的时候才发现的。那么，有没有什么方法，可以让我们在软件开发前期，能否覆盖更多的场景。有一个有名的工作方法，叫做3C工作法。3C，即3Choice，在做事情之前，尝试最少3种不同的方案来解决这个问题，打开自己的思路，覆盖更多的场景。
发散思路对于刚刚起步的人，每一个需求都要想多个不同的方案，是非常困难的，那么有没有什么套路帮助自己打开思路呢？
首先是业内对比，业界有没有相似的业务？他们是如何做的。假如你要开发一个电商的后台，订单的数据库如何设计呢？那么可以去学习淘宝、京东、拼多多等成熟大公司的实现方案。最后，你会发现，大部分都是以用户维度进行分库分表，然后使用ES等实现复杂的订单搜索。假如你一开始使用商家进行分表，当你了解到他们这么做之后，是不是需要充分去思考自身的业务有没有什么特殊性，两种方案哪一个更加合理呢？
第二是与自身以往的业务进行对比，以前是怎么做的。那么，如果一个方案跟以往很相似，是不是可以直接复用，而且该踩的坑已经踩过了。例如原先客户端有一个好友列表，是使用增量更新协议，客户端跟后台都存一份数据。现在想新增一个黑名单列表，是否采用之前增量更新就行，还是要更改成分页查询协议，客户端本地不存了，需要的时候再来分页拉取？
第三是一些核心组建的选择，例如，现在需要新增一个缓存，是使用本地缓存，还是集中式的MemeryCache或者Redis等组件。要存储某个数据，是用Mysql等关系型数据库存储，还是使用MongoDB这些NoSql存储？
第四是一些核心流程与协议的选择。例如：一个数据的拉取，增量更新还是分页查询？一个写操作请求，同步做还是异步做？数据的预处理，文案的下发，是客户端处理，还是全部交给后台操作？
选择只要你简单发散发散，就会发现，要做一个功能，门还挺多的。那么，这么多方案，如何进行选择呢？
第一，是能不能满足我们自身的业务，某个需求，可能有多个核心功能，是不是每个功能都能够满足，不要做到一半，才发现某个功能无法实现。
第二，成本大不大，这里的成本，可能是人力成本，也有可能是运维成本。同样是交易系统，可能你现在每天的订单量就几百，不可能一上来就开始全球多数据中心，异地多活这么搞。本来团队都是PHP，现在为了实现某个功能，全部转成JAVA来搞。
第三，性能与后续的扩展性。这个技术方案，有没有存在严重的性能瓶颈，比方说你做一个OA系统，跟消息一样，每次增量把单据下发到管理员的手机上，客户端也存一份。不难想象，如果有一个大企业，管理员一天可能新增数万个单据，占据大量的手机内存。所以，这种企业级别的数据，应该让客户端需要的时候再上来查询即可。
收益知己知彼，方能百战百胜，在你了解对比各个方案的时候，肯定也对自己的业务有了进一步的认识。可以大大减少在开发过程中遇到的各种问题，从而进一步提升开发效率。
很多人都说，阿里的P7，腾讯的T10，字节的2-2就是大部分程序员的天花板。因为再往上，要成为这个领域的专家，不仅要做好自己的系统，还需要知道业内的其他方案，所以，这是一个非常好的机会，可以让你去开拓自己的眼界。
最后，不知道大家晋升的时候，有没有被问过这样的一个问题，你为什么选择这个方案？希望你下次被问到的时候，可以轻松怼回去。
总结程序员摸鱼指南，不是让你躺平。把时间花在刀刃上，才有时间进行摸鱼。把方案都做好，剩下的，都是代码翻译的工作而已。