年初从一家TO C的公司跳槽到一家TO B的公司，差不多半年了。在后端领域工作也有接近5年，看过一些专业书，看过一些大佬讲技术。逐渐从技术角度，偏向业务角度。
刚开始入行对技术有很高的追求，而不是能跑就行。看spring源码，从完全看不懂，到有一套方法论去读懂大佬写的代码。很期待在刚搞明白的时候，想要从项目中应用学到的设计模式。大致就是，接口定义、抽象类实现接口封装公共逻辑、自定义实现类完成具体实现。再一次实现业务的时候，不满足简简单单的CRUD，强行对代码进行抽象，写完的那一瞬间觉得这就是最棒的代码。其他同事一看，也觉得很不错，但就是不实用。过了一段时间，本身当初的设想是使用设计模式增加可扩展性，实际反而变得复杂起来，加个字段或者改个字段什么的，本身非常简单的一件事，搞得糊里糊涂。简直就是一坨shit。这个时候才明白，什么叫过度设计。
大部分的业务系统都不需要复杂的设计，直接MVC+CRUD，基本就可以满足业务。实际上，更应该考虑业务需要什么，而不是为了技术而技术。所谓的技术不在于代码多么高大上，而通常在于数据库设计，数据处理方向上。业务上通常需要保证数据的一致性，如何合理的使用锁等工具，让数据正确，才是后端应该要专注的事情。在往大的方向上想，所谓技术不仅仅局限于代码，文档、分支管理、私有仓库基础依赖、日志分析与问题定位、平滑发布等都是体现技术的地方。
技术也就仅仅是技术，不能赚钱再好的技术也是没用的技术。就国内而言，这句话确实是如此。大部分公司都是业务驱动的，而不是技术驱动的。业务跟不上，不需要这么多人，技术再好也会被裁掉。多年经验的开发，竞争力究竟体现在哪里？我认为在对于业务的理解，单纯会技术的人很多，很多培训机构出来的都可以满足需要。但又懂技术，又懂业务的人不多。
外行人起始不懂代码，无论写的多么天花乱坠，只要出问题，就会认为你的技术不行。只要业务用起来不出问题，即使交互难用，也能接受。但也不是说技术完全不重要，技术是基石，更好的满足业务。换句话说，主角是业务，配角是技术。无论多优秀的技术都好，最终目的都是满足业务，让技术变现才能证明技术的价值。
总的来说，讲究的就是技术能力强能快速应对业务过来的需求，前期磨炼技术，后期专注业务。
