项目初期的工程构建过程只需要按照SpringBoot官方文档启动 hello world 程序就完成了吗？ 我的理解是： NO!
举个例子: 客户希望我们建一栋大楼 如果说之前的POC(Prove Of Concept)和Demo得到确认的话，那么紧接着的初期工程构建就是一个打地基的工程了。 打地基是一个很考究的过程。 大房子的地基如何打的好，这个得问思聪，不过SpringBoot项目的地基怎么打咱们就可以聊一聊了。
项目刚开始，我会建议团队讨论，达成第一个契约，即如何管理代码，这里面包括两个话题
-
代码仓库（Git / SVN）
这个问题现在可以逐渐淡化了，Git就跟智能手机一样风靡，选择gitlab, github还是其他的，就像选择安卓还是苹果，看团队的实际情况而定了。
-
代码分支策略
关于这个问题，我认为初期团队花时间讨论达成一致是很有必要的，甚至可以把之前别人的讨论结果提前整理出来，大家各抒己见，最后投票达成一致便是。 我听得看到最多的两个Trunk Based和Pull/Request, 这两种模式都能够应对团队合作开发的要求，网络和团队上都有关于这两个模式各自的使用场景和使用要求，大家讨论之前拿出来放到decision log里面就可以了。
有了仓库就可以checkout了，来啊，一起嗨，每个人先在本地把SpringBoot hello world给搭建起来，然后兴奋的跟团队说，跑起来了！咱们接下来是不是可以开始开发业务功能了呀。开发一半你突然发现，唉，怎么A同学用的Maven, B同学用了Gradle, 哈哈, 这真是一个难搞的问题，尤其对于某些强迫症的童鞋来讲。
慢慢你发现，我 X，怎么把代码跑起来越来越难，尤其是那些该死的配置文件！每次提交都包括了好多与业务代码无关的文件，后来发现那是IDE的代码风格在作祟！每次开发新功能，发现当前设计与自己期待的不太符合，内心一万头***！系统出了问题，QA找到你，日志去哪找，问题怎么重现，找Devops帮忙，你得到了一次善意的回复！系统上线之前，为了解决重构的风险，你噼里啪啦的添加了几百个单元测试！后期代码安全验收测试，你又得在报出来的几百个问题里挑挑哪些是自己作的孽，与此种种，让你从开始到结束都欲罢不能啊。
还能不能嗨皮的写代码了，与其欠的债最后一起还，不如分期啊！ 看看在工程初期构建过程还能做些什么来避免未来的深坑
-
确定代码编译工具，给Devops省点心
Maven， Gradle傻傻分不清楚，还是干一架统一项目编译语言吧。
-
统一团队代码规范，把问题暴露在你提交代码之前。
编译过程添加代码，以gradle举例，添加两个plugin，‘findbugs’和‘checkstyle’，具体细节稍微spike一下就能搞定，别让测试追着你屁股跑
-
让单元测试为你的代码质量和重构保航
编译过程添加单元覆盖率检查，以gradle举例，添加plugin jacoco，你可以一步到位，覆盖率不得低于90%，如果那样难受的话，可以用后一次提交的覆盖率不得低于前一次这样的policy来逐步改善。 我鼓励并建议采用TDD开发，它更像是一种开发新的思维，不会造成冗余的设计，以目标驱动，直接简单，如果你觉得它拖慢了开发速度，那至少针对核心模块应该这么做，剩下的应尽快补上。
-
针对系统的外部依赖，应该快速的构建相应的mock server, 保证开发的流畅度。
如果有条件，使用在线的mock server来帮助快速搭建服务吧，RAP2, mockapi都不错。 简单的话，可以自己用jsonserver搭建一个 如果还有SSL链接需求的话，可以使用wiremock。
-
针对外部依赖，添加集成测试用例，
使用 spring integration test 应该有对应的集成测试来保证mock或者真实系统的正确性，减少集成调试时间。
-
统一环境依赖，避免冲突
为了开发者使用同一套环境的mock和其他依赖，使用docker是明智的选择，写个docker-compose文件轻松搞定
话说，jian到这个地步是不是可以了啊，など，还剩两个问题要撕逼，说完咱就撸起袖子干
-
Dev 和 Dev之间的问题
自己嗨还不够，大家好才是真的好
是用微服务呢，还是单体应用，这得具体情况具体分析，比如一个业务很简单的订单服务，用单体+load balancer就能轻松解决，如果用一个进程查，一个进程创建岂不是用牛刀杀鸡。
应用设计是用DDD还是传统分层架构呢，将DDD在springboot项目的实践是一个挑战，不过它比传统分层更能直接的表达出领域知识，这两个都是团队可以讨论和尝试的地方。
接下来的领域模型定义，业务模块划分和功能实现就是顺水推舟的事情了。
-
Dev和devops之间的问题
开发不仅需要保证业务功能的正确性，也需要关注到Devops提出的部署和运维需求，满足流水线的流畅和稳定。
比如配置文件的拆分和部署，在Spring boot有多种configuration管理方式，具体可参看其官方文档，比较常见的有两种，基于环境的profile机制，拆解local、dev、qa、pp、p配置文件，基于spring active profile启动应用程序。基于springboot默认的配置加载规则，将部署变量单独抽出来成为配置文件，和项目的基础配置文件applicaion.yml做merge, 并启动应用。
比如日志的需求，是打印到console呢，还是打印到文件呢，需不需要rolling policy呢，是需要纯文本格式，还是json格式呢，每条日志的内容包含哪些字段呢，需不需要x-trace链呢等等，在springboot和日志相关的，NDC,MDC,Logstash,logback，slf4j了解一下。
如果你读到这儿，那一定是真爱了，相信上面的问题如果得到有效的讨论和实践的话，那么后续的开发过程一定很流畅，非要用一个外语单词表达的话，那就是 nice.
如果你没试过，为啥不动个嘴摸个屁股试试
如果你试过还不爽，也麻烦你分享一下经验，咱们相互学习吸收一下。