可以这样说：不造轮子的程序员不是一个好程序员。

这个工资，OP 你可以外包给我。我每天花 1-2 小时给你做，就能比你招到的人做的更快更好。

@heyleo 假设按需求本身，不加以深层次的分析就进行开发需要 3 天的时间的话，你深入分析一下撑死再加 1 周。怎么就 2 个月了？这不是罔顾事实纯纯的杠吗

架构师要善于以小见大，从小地方发现大需求，然后从结构上去做业务支撑。就这个点来说，你的领导水平相当高，OP 你应该多学学。

@DingJZ 确实，好的软件架构设计本身就能避免很多乱七八糟的问题。我也见过不少糟糕的设计导致一些最佳实践根本没法落地。

是的，但在我们一般不会多个人同时改同一个文件。

手势操作是人机交互的一大进步，但并不意味着手势操作要淘汰键盘和鼠标。

@xuanbg 其实避免代码冲突总结起来就一个原则：

禁止在临时分支上直接修改线上代码！

线上代码的变更要走修复 bug 的流程且先上线，然后通过从主分支合并到临时分支的方式去更新临时分支的线上代码。

分支太多不是好事，什么测试分支和预发分支完全可以不要。
除了主分支，我们只有两类分支，说类不说个，是因为同类型分支可能同时存在多个。
一类是功能分支，从主分支分出来专门用于新功能开发的。提测就打个版本 TAG ，自然就自动发布到测试环境了。有 bug 就继续修，修完再打 TAG ，自动发布后继续测，测完没问题，合并到主分支并且删除功能分支，主分支上打验证版本 TAG ，发布到预发环境验证。验证完打正式版本 TAG ，自动上线。
第二类是修线上 bug 的分支，专门从主分支上分出来修 bug 用的，流程和功能分支是一样的。上线后，主分支要往所有功能分支上合并一次，这样功能分支的代码就和主分支不冲突了。如果修 bug 过程中有新功能上线，那么主分支也需要合并到修 bug 分支一次，以免产生冲突。

正常情况下几乎没有冲突，只有一种情况，冲突无法避免。就是功能分支的某个文件在其他临时分支上也被改变了。这时，就只能把相关的人都叫上，大家一起人工解决了。但这种情况几乎没有，各新功能之间不会有什么文件冲突，如果要改动已有代码，都是先走修 bug 流程，在主线上把新功能当 bug 先修了，而不是在功能分支上直接改已有代码，就不会冲突了。

说什么前端不值得的，能手撸一个比 VUE 更强更好用的框架么？

黑暗森林法则是三体最大的败笔。纯粹就是大刘写着写着写 H 了，后面怎么圆都圆不过来。

仅用缩进区分代码块在写的时候没啥问题，运行自如也没什么问题。但及其不利于从非 IDE 中复制代码，鬼知道你复制的代码缩进还对不对。

我自己用什么语言都无所谓，但代码不是写给自己看的啊。。。

3 个 select 结果 uinon 起来就行

AOP 把请求数据输出到日志就好了吧？我是在网关上做的，docker 容器输出的日志到 fluentd ，再转发到 ES 存储起来。基本上开箱即用。百度一下 EFK 就行了。

画思维导图啊。画不下去就说明机缘未到。我自己的经历，大多是画不出什么来的。

OP 你想多了，过好自己的生活就是了，老想着别人怎么想别人怎么看做什么？你又不是什么市里一把手的秘书。

我没还阳……我的意思是我还没阳……好吧，不装了，我就是很帅。嗯