目前业界可以使用的web框架非常多，各有各的优势和缺陷。结合这几年的从业经验，我畅想了一款面向个人开发者、中小型企业可以快速开发上线的web框架的建设原则。可能有的同学会说，我用spring-boot就很快，我用Django也很好，用php直接无敌了。你为什么还要做这些东西？
为什么有那么多，我还要做
市面上的产品很多，但是真正能让我拿来直接开箱即用，可以直接快速上线的几乎没有。
很多沉淀了多年的大中型公司有自研的中间件、知识沉淀以及适合业务发展的中台系统，帮助他们快速上线业务。像阿里做盒马、闲鱼这些产品可以做到借鉴淘宝的中台能力，快速上线。
针对资深的个人开发者，有很多自己的脚手架，帮助自己专注于业务开发，快速上线。对于他们来说，一个月接3个项目的，就是比1个月接1个的挣得多。同时还能保证质量。
但是对初创公司、不是长期从事外包生意的个人开发者来说，即使是研发经验丰富，想要做到业务开发快速上线，日志检索简单，质量有保障，知识有沉淀，能进行简单的devops，还具有一定运维能力，至少需要几天到一两周时间，有的甚至更长。而且可能会因为需要业务快速上线的需求，引入一些技术债务，如：代码组织混乱，日志乱打，接口文档和实际代码对不上，做了很久没有知识沉淀。
市面上有很多框架，有性能好的、配置灵活的、自动生成代码的等等等等。但是对于一个初创公司或者一个想要开展自己第二职业的个人开发者来说，过剩的性能、过度灵活的配置，反倒会因为大家的选择困难症导致宝贵的时间被浪费掉了。
基于上述这些问题，我打算怎么做
基于上述问题，我觉得在做新的框架时，定下的几个原则。
原则1：首要原则，以快速上线为指导思想
这条原则不用来指导框架里面的实施细节的，但是一条基本纲领，一条核心的行动指南和最核心的指导思想。在做框架开发的方案选型、技术选型时，快速上线是最重要的。
我认为，对中小型企业来说，时间是最重要的。可以最快速上线的，相同的时间里实现更多功能的，可以最快转型的，都是有更大的几率活下来的
对于个人开发者来说，一个想法有多快速可以落地成产品。做个人外包时，每天2小时的业余时间赚点外快可以做多少功能，通常来说与能多快上线直接挂钩的。
所以，在做这个框架的时候，任何一个方案、技术等等一切都是为快速上线服务的。
原则2：约定大于配置
很多时候，我们浪费时间在纠结一些类似方案的选择，日志、文档格式的写作差异。
比如代码分层到底如何定，架构师A一个想法，程序员B是另一个想法，代码写一段时间之后各种混乱，需要治理。
日志有的地方打了，有的地方没打，错误日志和业务日志打在一起，格式乱七八糟，没法监控，错误排查困难。
api文档有的写了，有的没写，有的写过之后改了，swagger里头是一套，文档里是一套，各种迷惑，项目组成员在对接时沟通成本高。
所以适度的放弃一些灵活性，把部分约定在一开始开发之前由框架就提供好，如：
- 约定好的rest api，只关注入参、出参格式和业务逻辑编写。到底是使用get、put、post还是delete，只要遵循规范，框架会帮你生成。
- 自动基于约定好的rest api，解析注释，生成swagger和相应的文档，做到代码、文档、注释一处编写，多个场景复用，降低沟通成本。
- 统一的日志规范，方便问题排查以及接入监控系统。
- 本机、开发、测试、生产环境统一约定好，使用同一套代码库进行差异化部署。
原则3：开箱即用
开箱即用是个很大的词，怎么说都对，但基于我们以快速上线为核心的指导思想，提高开发调试、部署时候的效率。我认为的开箱即用应该包含以下几个点：
- 以配置代码化为核心，将所有相关的配置都在一个代码仓库中。做到任何一个人，在任何一个时间点加入这个项目组，把代码从仓库中拉下来，点击运行，一个可以用作调试的环境就已经搭建好了。这种方式极大的减少程序员每次调试时候的浪费的时间。
- 针对开发环境、测试环境、生产环境，只需要简单配置就可以支持各环境自动化部署。在过往的开发经验中，开发机器、开发环境、测试环境、生产环境上的差异，经常会导致意想不到的bug发生。由框架直接提供自动化部署能力，尽量消除差异，提高部署一套环境的复杂性。让“上环境调试”变成一个非常简单的事情，更容易提早发现问题，提高效率。
- 提供数据库代码化的能力，数据库模型与dao层模型保持一致。如果dao层模型发生代码变更，数据库也执行相应的变更。
结论
本文中主要结合了这年的开发经验，畅享了一套针对中小型企业和个人开发者的web框架建设理念。
提出了我认为的三个主要原则：
- 以快速上线为核心
- 约定大于配置
- 开箱即用
在后面的文章中，我会逐步产出该项目的roadmap、技术选型和实施方案，并一步步的实现该框架。希望可以帮助到更多的人快速实现自己的想法。
2020-10-27
东方赞