我对 coding 最大的期待，就是简单（最近的吐槽和笔记）

喜欢go和php的原因都是因为简单明了，就算是复杂的系统，我们也应该化繁为简，用最简单的方式实现复杂的系统，同时保持严谨，逻辑闭环。

对开发的吐槽

1. 不是说设计模式不好，我觉得设计模式特别好，设计模式本身也是为了各种业务模型抽象出来的，用好设计模式，可以让我们用更简单的方式完成复杂的业务，写更少的代码完成更多的功能。
   但是就很容易走偏，初学者有一本好书或一个好老师带还好，一点即通，但很多时候是有一部分经验但经验又欠缺的人，很容易乱套设计模式，这导致代码越来越四不像。
2. 也不是说封装不好，封装是锻炼抽象能力的第一步，封装是每一个开发的基础能力。
   可是，封装应该是为了抽象而封装，而不是为了封装而封装。
   而且，好的代码是给人看的，你写那么复杂，封装那么多层，你不累吗，炫技吗，有什么意义呢？
3. 团队规范很重要，是每个团队在项目初始阶段就必须确定好的事，讨论确定下来后就要少数服从多数。
   但是规范统一更重要！请大家根据当前项目既有规范的基础上制定规范。
   我在做现在项目有个很迷惑的事，项目之前的组长推崇单行为控制器（就是一个控制器只负责一个接口，只有一个public index方法，其他都是私有方法，为index方法服务，这种代码结构会有AddController、ListController、DetailController、UpdateController、DeleteController），现在的组长推崇Services层必须有，controller中不允许调用model。其实这两种结构都挺好，但是有些矛盾啊，单行为控制器其实是为了解决Services层肥大的问题，现在的项目结构又是多个单行为控制器去调Services，有什么意义呢？我其实还是有些懊恼的
   （如果是我自己的话，我喜欢单行为控制器，因为Services层中大量的方法是没有被复用的。我觉得Services层很必要，复用的情况再用Services）
4. try catch很好、很严谨、很必须，但是我有时候就很困扰 我不知道为什么很多人的代码里充斥着try catch，每层都定义一个新的err code，排错很想哭好吗，尤其是微服务的情况下，一层层调用，排查错误的时候，怎么定位错误呢，有错误链吗…..
   我总觉得try catch 应该用在调用外部接口无法预知外部情况、避免次要业务影响主要业务的情况下，如果用laravel的话，可以在Exceptions/Handler.php中处理下常见的异常（球球了别再包了），生产环境的env中的APP_DEBUG肯定是false吧？数据库redis之类的连接异常，用户名密码没问题的话是不是应该找运维了…. sql之类的错误，fix bug啊
5. 循环里避免操作库/调接口操作。这条是自己的笔记。其实一直有注意这点，但是有时侯还是思维定势。上个月写一个功能，3张表ABC，两层1对多关系，思维定势想着C表要用B表的id，得再循环里先create B表数据，再insert C表数据。然后组里的小哥说可以优化，id是分布式id，可以提前生成，循环里只组装数据，循环外分别 insert B表 和C表。 学习了学习了，感谢小哥。
   如果没有用分布式id的话，可以定义一个唯一code去关联B表和C表，也可以循环里组装数据，循环外写表。

对微服务的吐槽

微服务很好，并且它也是现下的趋势，要搞分布式高并发，最后怎么都会发展到微服务。

此处推荐一篇文 一文详解微服务
小明小皮小红这篇看完会有豁然开朗的感觉，谢谢作者和分享者，比心～

1. 多个产品的情况下，请产品先对对产品，至少产品层面逻辑走通
2. 请在团队都准备好了的情况下，再拆分成微服务（领导、产品、开发、时间、硬件、日志、监控、思维转换），否则很容易大家一头雾水，“啥也不敢说，啥也不敢问，大佬怎么说，咱们怎么干”，但是干了啥开发大都还是一脸懵逼….
3. 合理架构设计和模块划分，我们组长说，要锻炼大家的抽象能力，架构设计和模块划分。可是这并不是一朝一夕就能get的能力啊
4. 人员分工和颗粒度分多细呢？肥肠极其容易扯皮。微服务的模块划分稍微设计不好，耦合度就太高，然后新一轮扯皮…..
5. 需要有大佬过产品，产品天马行空设计一堆功能，如果没有靠谱的大佬把关的话，开发懵逼着写，后面太容易出问题了……
6. 找到主体，分清主次，这条是自己的笔记，希望自己做到。就不容易做错主流程。

本作品采用《CC 协议》，转载必须注明作者和本文链接