项目的前期架构是否要反复的揣摩一套体系？

没做过 我是感觉尽量去做 但也不要太麻烦

理想很美好，当你天天加班到十一的时候，什么文档，测试，需求做完就不错了。

前期需要有规范，但是这个规范的度要控制好，不要死，要留有足够的灵活空间，这样才可以在灵活的基础上摸索出来适合团队的架构和规范

@PiersSoCool 谢谢
@renmu123 是的，大家都挺忙会还在意规范，只要完成需求就行，有时我也是这么想的
@beryl 嗯，这需要一个很漫长的过程，而且必须有一定声望的人去做推行的工作

换个角度去考虑问题，如何节省成本
规范是为了节省成本的，什么时候技术债成本高到要用规范来减少成本，就什么时候把规范推广开。
减少开发人员调试的反馈周期，能大幅减少开发周期降低成本，那么这些规范里面有什么是可以降低开发反馈周期的，可以优先做，如果加上规范反而让本地调试成本更高，周期更高了，要重新评估是不是有简化方案，还是不适合在这个时候添加对应的规范。
重构也是为了节省成本，当技术债务过高，达到了 重构 + 新功能 > 在原有架构上写新功能的时候，就是一个很好的重构时间节点。

@lecher 很好思路和建议，谢谢

我觉得其他都不重要，最重要的是功能划分和团队的能力培养。

按业务能正确划分相对低耦合的服务，分给不同组。先找重点有潜力的几个人提高，然后各个组自己决定自己的风格，养成持续学习和改进的文化。

国内大部分团队的问题是过于强调标准，精力都放在对齐上，其实效率很低。lint 之类的东西只能解决一些皮毛，真正的设计质量取决于人，人的因素总是最重要的。

另外每级管理把部分工作逐渐下放也是提高人员能力和责任感的的方式。

项目规范主要看项目预算, 有钱就挖几个老手带新手就可以了. 没钱就随便了,反正以后都是要推倒重来的.

@namelosw 非常认同
@jones2000 是的，项目的 Boss 肯不肯花钱让我们搞非常的重要，毕竟打工的

需要考虑人员配比，硬件成本、开发时间这些问题。这些问题一次性都来了你就不会想这些。

gitlab commit 强制规范。规范检查谁去做，出现问题如何处理。
git commit before 强制跑 soner 。此处需要额外硬件成本，是否一个项目使用一个 soner，soner 的规则制定谁参与。
测试一个功能一个服务的实例和所有基础服务。不知道想要表达什么。
强制所有模块拆分成为一个，一个 git 远程仓库。拆分模块更多的会拆分服务，按照服务分配多个仓库。
通过 ELK 采集日志集中分析和查看。elk 的硬件资源。
对新表上线必须模拟日增数据。日增的模拟用意是什么？
对服务的监控和熔断，限流。服务监控是基础，熔断限流在项目伊始就应该直接具备，允许额外自定义。
git push master 必须通过所有回归测试。
所有服务必须有基本的 readme.md 介绍。readme 不如产品文档+版本文档+接口文档。
所有的服务必须有版本发布管理。不错
所有的部署必须通过 git 钩子自动化部署的。部署应该手动，避免出现 commit 一次部署一次，会导致硬盘控件暴增
模块的更新必须共同开发的同学一起 code view 。review 的成本很高至少会拖动 2 个人进行时间消耗，review 的时间节点是什么？，能跑就可以。
模块的调用必须通过 feign 或者 MQ 来完成代码的解耦。大可不必

springBoot + openfeign + springcloudAlibaba + nacos
技术栈不重要，不予置评。

gitlab commit 强制规范。很好，需要坚持。如果不能推行，可退而求其次，逐步推进。
git commit before 强制跑 soner 。能跑最好，不能跑就算了吧。
测试一个功能一个服务的实例和所有基础服务。不需要，基础服务本身应该是稳定的，没有必要每次都去测试。
强制所有模块拆分成为一个，一个 git 远程仓库。一个项目一个仓库就行了。
通过 ELK 采集日志集中分析和查看。必须的，但更重要的是日志的格式和内容。
对新表上线必须模拟日增数据。不需要。
对服务的监控和熔断，限流。不是必需的，等有需要再加上即可。
git push master 必须通过所有回归测试。不太现实。
所有服务必须有基本的 readme.md 介绍。需要，强制推行。
所有的服务必须有版本发布管理。必须的，通过工具来管理
所有的部署必须通过 git 钩子自动化部署的。不好，还是手动点一下发布比较现实。
模块的更新必须共同开发的同学一起 code view 。估计顾不上。
模块的调用必须通过 feign 或者 MQ 来完成代码的解耦。这是必然的，而且在服务内部，不应该存在模块间的调用。如果存在，那就应当抽离成一个公共的方法。

其实吧，一个项目能不能迅速地开展，取决于你有没有一个成熟的体系。项目能不能顺利推进，取决于你有没有足够的现成可用的、稳定可靠的基础功能模块或服务。也就是说，只要你有一个成熟的技术体系，而且这个体系已经具备了常用的，可开箱即用的基础功能模块，你做什么项目都不会有太多问题。

@huifer
上面条件我只是描述的大概
#Q1 测试一个功能一个服务的实例和所有基础服务
就好比一个登录功能，要配一个登录实例和全新的 MySQL+redis 实例(当然还有其他基础服务的中间件)，我觉得这样做的好处是: 测试同学一旦发现问题，能让开发同学轻松的复现 bug，相当于一个快照的功能，我知道这样做成本来说会非常高。但是不这样做，怎么能保证一个功能的完整和回归测试呢。
#Q2 对新表上线必须模拟日增数据
日增数据模拟是想检验开发同学或者 DBA 同学的索引是否符合在未来一段时间的要求，以及是否会影响数据库的性能等提前做好预演。

## 和你有不同意见以及解释
#Q1 所有的部署必须通过 git 钩子自动化部署的
这个钩子一般是 push after. 我觉得这样自动化是合理需求, master 可以手动触发发布操作
#Q2 模块的调用必须通过 feign 或者 MQ 来完成代码的解耦
这里模块我应该改成服务，更专业的说应该是微服务，我明白社区有更好的解决方案，但是个人想到这些

至于每个部分的规范我觉得应该让所有的开发同学一起参与讨论，这样可以做到大家都明白为什么这么做，会解决什么问题。

其他观点我非常的赞同

@xuanbg 非常赞同，一个完善且稳定并高效的流程管理和规范对于一个专注于科技的公司非常重要。但是这些流程想象中很美好，现在总是被各种约束变的可有可无

gitlab commit 强制规范
A: 我们订了一套规范包括其中包括这一项，大家都应该按着这个来，至于强制主要靠大家自觉和定期检查下

git commit before 强制跑 soner
A: 前提要定义好一套合理相对宽松的规则集，太严成本好，太松又没有意义

测试一个功能一个服务的实例和所有基础服务
A: 基础服务可以做哈单元测试或接口自动化测试，后期收益很大

强制所有模块拆分成为一个，一个 git 远程仓库
A: 前期没必要管理麻烦，后期团队成员增多可考虑

通过 ELK 采集日志集中分析和查看
A: 集中日志这个很有必要，当然不一定是 ELK, 特别是公司多个业务线系统，或者一个系统部署了超过 2 个实例

对新表上线必须模拟日增数据
A: 没做过，感觉中小系统必要性不大

对服务的监控和熔断，限流
A: 发展到感觉需要做的时候再做，线上系统服务监控很有必要

git push master 必须通过所有回归测试
A: 还是看该的什么，小改动没必要吧，另外为什么要直接 push master 了？

所有服务必须有基本的 readme.md 介绍
A: 成本低很有必要，最近将一个单体应用按技术分层，改为业务模块划分，在 readme 中维护业务模块划分说明，这样后续不熟悉新的开发者新代码也知道放哪个模块

所有的服务必须有版本发布管理
A: 版本发布管理是？


所有的部署必须通过 git 钩子自动化部署的
A: 公司运维是 gitlab 上手动点 pipline 部署的，当然自动部署也可以

模块的更新必须共同开发的同学一起 code view
A: 如果整个团队不十分忙，code review 很有必要，对新加入成员前期 code review 也很有必要


模块的调用必须通过 feign 或者 MQ 来完成代码的解耦
A: 既然服务独立了肯定应该这样

fix bug 流程 new features 流程 发布流程是怎么样？
A: github 工作流，新分支开发修复测试，合并主分支 tag 上线，两个邮件: 提测, 上线, 运维使用 docker 和 ci

对于前期的架构和人员不足或者能力不足该怎么做平衡？
A: 如果让一个应届毕业生去搭建新项目，通常不会好哪儿去？但是如果有标准的项目模板、固定的代码生成器、编码规范(数据库设计、接口设计)、一些公司使用技术的最佳实践文档、一些基础设施和服务(city, sonar, 短信服务, sso 登录等)、适当有经验的员工指点

Q: 现实当中为了需求是否要牺牲一些基础架设？
A: 业务第一，架构第二

@MarioLuo 非常感谢你的回答