码农嫌弃自己leader的系统设计理念怎么办？

因工作调动转到了缺人的新组，面对新的工作、设计风格感受到了严重的不适应。以下观点发表出来可能显得过于浮躁，请前辈轻喷

补充内容 (2020-10-5 04:17):
我只是一名后端小开发。新组的业务多类似于特定节日使用的线上小游戏，各种业务间有不少相似概念，但细节有许多不同。而新组设计风格明显倾向于流程模版的设计理念，将这些不同相似概念设计为一个个微服务模块，模块间往往是在一个隐含的业务流程中直接互相调用。这样已经造成了一个游戏的细节逻辑散落在了多个服务中，每次新业务上线都要发布所有服务，个人觉得并不高效。又因为需要包含各种游戏逻辑，导致许多服务的表中加入了“万能字段”，比如用json来放各种异构数据，以及使用xxid+xxtype来兼容不同的关联键（比如这里的id在两种游戏中可能有玩家id和任务id两种，就将值都写在xxid中，用两种xxtype区分，其实就是过于关注了其他领域中的identity）
自己这边，则认为基础能力服务+业务中心服务才更合适，基础能力服务间不直接关联，由中心服务维护实体间的关联、进行调用，并直接与玩家接触。因为原本游戏形式就太多样了，每一种新的玩法，设计一个新的中心服务也不会有太大历史负担，数据含义也明确得多
其实很想就这点与新组长好好讨论下不同的理念，近段时间却感觉被原组里的人轮流私下表达了，这个组长十分独断又善变的意思，而目前的感受就是：阿里味很浓。对新组其他成员的认知则是，水平参差不齐，风格理念也有不少细节上的不同，但共同的一点是，对leader言听计从
难受的是，未来几个月会有个无休的封闭开发安排，如果继续做下去，一想到许多时间都会被用来考虑一个耦合如此严重的系统以及与各种风格的代码打交道，就很抗拒

补充内容 (2020-10-5 04:18):
唉，不知不觉写了这么多，就当我是来发牢骚的吧

补充内容 (2020-10-5 12:44):
可惜这套东西并不是为某个项目建的，整个组也才成立大半年，其实是作为组内基础设施来做的
现在我觉得，小组目前业务特点是不停出新东西，新功能生命周期短而迭代次数少，这套方案的主要问题还停留在复用性低，拉长初次的开发周期（造成我们自己加班），即使它对监控、报表以及大修改来说是个噩梦，暂时也不明显
这就很尴尬了，站在leader的角度，我好像没办法提出十分有力的修改动机，而一线开发承受了最多的伤害

这是个常见的BQ题...

所以你也没跟tl讨论过为什么他用现有的设计，就是因为你听说他独断，
其实如果以讨论或者请教的办法，去了解一下现有设计，这个做法没啥问题，至少就算面对独裁的领导也不会一下子就让对方觉得你在挑战权威
说不定人家还会给你个解释，说不定解释里面有些东西你的确没想到
就算对方真的是独断的人，也有跟他work together的办法
你就听别人一说，就关门自己生闷气，这不是一个主动解决问题的办法，如果以后遇事都这样，那只有不断跳槽了

意见肯定是要提了，要是换了老美有这些想法，我估计早就在组里哔哔了。写个doc，在现有的项目里找几个具体的例子来证明你的观点是如何可以解决这些例子里的问题的。然后找个1:1的时间，和tech lead过一遍doc，深度讨论下。就算不采用，你也在tech lead心里证明了能独立思考的能力了，对以后也有帮助。说实话，我更相信自己能独立思考能力的队友的。

作为一个小TL, 经常和其他的TL/EM讨论组员的design和performance，我只能说大部分时候lead的high level design都要比下面的人要好，而且经常有意见的人其实大家都知道 …

chengguo201063 发表于 2020-10-04 12:57:40
作为一个小TL, 经常和其他的TL/EM讨论组员的design和performance，我只能说大部分时候lead的high level design都要比下面的人要好，而且经常有意见的人其实大家都知

其实自己感觉与上一个十多年经验的leader相处起来还是舒服很多，并不是对技术细节掌握得多好，而是他提出的一些方案，细想后都是总结得出的“傻瓜式”原则带来的，至少确实让需要关注的细节更少了

如果你的tl人还比较能听得进不同意见，并且你提的修改意见有明确的benefit（而不单纯是你喜欢某种style你tl是喜欢另一种style），可以在design过程中或 review之前提。对事不对人地把修改的cost和好处讲清楚就行。
如果项目已经做到一半了，除非碰到大的blocker原路走不下去不然不建议费时费力改design，即使原来的desigj可能不是特别好的。改design很可能会严重耽误进度。

如果tl是不听意见的那种，那没有什么办法，要么忍要么走...

跳槽走人

那你有什么办法，人家tl的话语权在那里，嫌弃归嫌弃，尽量参与吧

我一般会写一个doc主要描述现有的你认为的问题，不一定马上解决，但是表达出你对这些问题的担忧，（并可以表忠心的说，现有的design一开始没有问题，但是随着业务发展的壮大有些不适应；这个doc只是想总结和提出问题，并不是说我们一定要马上着手解决）

如果这个doc并没有得到什么反响，要么是这个问题其实不是问题，要么就是组里一言堂。但是anyway你把你的想法写下来别人才知道，说不定会有人和你合作推进这个事情（比如skip manager）

leaders are right a lot……

tq5124 发表于 2020-10-04 18:53:59
我一般会写一个doc主要描述现有的你认为的问题，不一定马上解决，但是表达出你对这些问题的担忧，（并可以表忠心的说，现有的design一开始没有问题，但是随着业务发展的壮大有些不适应；这个doc只是想总

我确实有写我的感想在周报中，但目前还没有得到反馈。并且说起来，这些问题毕竟不涉及正确性，如果leader自己对产品的想法预估十分自信，也是有可能毫无动摇的