被 Manager 批评了，但是我觉得我做得对，怎么办

[Mikawa]

这周被老板喷了，有点难受，不知道是不是我做错了，发出来请老哥看一看

我是去年跳槽进的现在公司，进去不久 Manager 分了个活给我，让我做一块小东西（一个通用的技术需求），因为不算绩效，所以可以自己折腾。我在开工的时候拉了个会和组里其他人过了下设计，就开始做了。

那个活我当时打算拿 node 写个 CLI 就行，但是实际写完之后发现还有些可以做的，需要在 CLI 里加个命令，本地起个 UI ，类似 Prisma 那样，就开了个 nextjs 的应用，和 CLI 放在同一个仓库，把那个仓库改成了 monorepo ，后面因为循环引用，就把 cli 里的一块逻辑提出来了。

上面这些坑挖了不久，我就因为被其他原因 block ，暂停这个 CLI 的开发，最近打算继续做，就在周会上提了下。

我 Manger 刚好打算对另一个新成立的组输出些东西，就找我要了仓库，说看一下。实际是打算把我做的和他手下另一个做这块的人做的东西缝一下，提供给他们组。

分支是周四发的，周五晚上他在微信群里 @全体，说不要把代码写的过于复杂，过度包装，还用了个抽象的比喻，我也没多想，就没管，也没想是说谁。

结果第二天打开工作 im ，发现老板给我留言批评我，说我过度包装了，让我把 monorepo 合回去，并且说“他以为可以分分钟给出去，最后他自己写了，这些功能几个文件就搞定了 balabala”，最后说这也不是什么大事，让我不要担心之类的

我一直觉得我和老板脑回路对不上，平时他带了好几个组，所以不常会和他一起交流设计，但是一旦开始讨论，意见几乎必然相左。平时都是在设计的时候意见不一致，这次是实际发生的事情，一步一步有迹可循，所以我直接给他说了我为什么这么做

昨天晚上他看到我的消息，还是说我做的不对，s 说我是在乱叠包装、杀蚊子用大炮，他自己写就几个文件，别人还可以改 balabala

刚刚醒了看到他昨天晚上的消息，人有点麻，完全没办法沟通，去年跳槽就是希望去外企工作氛围能轻松一些，结果老板完全没办法沟通。

总之我把我为什么这么做再详细讲了下，并且给他抗议他不经过我，直接扒代码，扒不出来就说我过度包装的行为，让他后续有这种例子叫上我

[wunonglin]

不用太过自责。他只不过是遇到自己不会的领域了而已

[Procumbens]

个人意见：自己的项目想怎么来就怎么来，公司的项目往往是要跟别的组对接的，一般还是听 manager 的

[w2er]

楼主大早上的消消郁结，既然是老板，有没有对下属谩骂罚跪人格侮辱之类？有没有工资克扣之类？其他事不都是老板您都对嘛，这点事就跟老板硬刚，还来回刚，就你面子值钱，不需要给老板留点面子是吧。
另外建议尝试考虑下，
1,自己公司该不该，有没有权利复用自己公司的现有代码？
2,到底是简单明晰了后面使用和维护过程中有好处呢还是块块力求纷繁备全后面大家才更高效？
3,同一个要求，我们到底该花一天时间给出简单直接可接受版本，还是花十天时间给个尽可能多的展现了我更多能力的力求完美主义版本。不论是从公司角度还是个人角度，我该如何选。

[aulayli]

你跟老板计较什么？打工人要有觉悟，工作上老板做啥都是对的，不要反驳，不要顶撞，非要杠就只有六字真言了😂。

[kx5d62Jn1J9MjoXP]

抗议他不经过我，直接扒代码，扒不出来就说我过度包装的行为，让他后续有这种例子叫上我

如果你做的东西是很简单的但是你的代码会让人"扒不出来"，那问题可能在你

[ruidoBlanco]

第一，manager 做太多 micro management ，甚至插手代碼用哪個庫，是個不懂如何管人的 manager 。但是這是他的問題，不是你的問題。
第二，打工人不跟老闆計較，他說什麼都聽。拿吃屎的錢，幹吃屎的活。這鍋算你的。
第三，manager 是坨屎，得跑路。這鍋也算你的。但這跟第二條並不矛盾。

[cuebyte]

如果这是你一个人的项目，你想怎么做就怎么做了。可实际上这是要在公司内部用的，你就需要在每一步和相关责任人达成共识，不然这锅你就真甩不掉。

你开工的时候拉了人说是做 CLI ，但之后改成 monorepo 应该没有沟通好；你可能在早会上提了，但他们可能以为你就是加了点小功能，提升了一下 UI 。实际上一到手上发现居然成了大项目，自己还都不知道。原本以为把你和其他人做的东西整合一下就行了，结果发现小需求变成了大项目。类似于你女朋友出门买菜，结果刷了一辆车回来，惊不惊喜，意不意外？


你觉得沟通困难，是因为你没有沟通，而是事后给自己擦屁股。不信任感已经产生了且愈演愈烈，当然会越行越远。

[chuck1in]

楼主能说下详细需求吗？文案提审是啥意思？

[Mikawa]

@chuck1in 我们项目的文案在设计稿里是设计师和产品写的，但是上线前会给专门的组审核这些文案，他们会提出一些修改。因为迭代拉得比较长，所以人肉找出文案挺麻烦的

[chuck1in]

@Mikawa 相当于你要比对上一个版本的 prd 和这个版本的 prd ，然后把改动 diff 出来，整理以后给审核小组发过去。他们审核改动好以后，你再 merge 到现在的 prd 里面吗

[Mikawa]

@chuck1in 嗯嗯，差不多，我比较的是代码，因为实际开发的时候遇到的小改动一般不会体现在设计稿里

[chuck1in]

@Mikawa 如果要做一个成熟的工具出来感觉挺不好做的，能请教下怎么实现的吗？每次需求可能增加了很多新文案，这种你怎么统计？是专门标记某个 html 元素中的 text 来统计的吗？

[Mikawa]

@chuck1in 我让其他同事帮忙在文案上加上 i18next 的包裹，这样就能标记出文案了，标记的文案可以用 i18next-parser 这样现成的工具提取。

diff 那块我的思路是用 json patch 来描述项目里 i18n resource 从初始化开始每一个迭代的改动，把改动记录存在项目里，类似 git 那样，因为是改动，所以合分支的时候冲突也只会出现在记录 commit 列表的地方，解决的时候 CLI 提供个 gny 直接跑一下三路合并就好。如果要取巧的话，可以只在主干跑一次，这样就永远不会有冲突。

提出来的 diff patch 可以转换成一个 excel ，拖到在线文档里让审核组看一下，改完拉下来跑个 merge ，把改动记录下来，修改 resource ，这样就行了

[Helsing]

在一个团队里，写代码最好要和原项目架构和设计保持一致

你想把代码设计的更好可以理解，但是：

1. 你原来和大家对的方案是 CLI ，但是你做着做着就改方案了

2. 你改方案没有知会到你的 manager 和相关方，没有了解其他人的意见和对别人的影响

3. 感觉你的沟通有问题，你做的时候，遇到问题，就要找机会跟 manager 说出来，和大家讨论方案，而不是擅自改动实现方案

估计你的 manager 看到你的代码的时候也是有点无语，怎么写出来的东西跟之前说的有那么多差异

[dandycheung]

在公司里做的事情，可以交付都是一个重要衡量指标。如果你在给自己挖坑之前，把项目做到了一个可以让人拿来就用的状态，那么，你既可以后续不定期维护迭代，也可以在任意时刻让有需要的人有的用。如果在当时就把这个工作里程碑同步给你的 manager ，那么应该可以避免这次的尴尬和委屈。总之，对工作成果有自发性的高要求，这种工作态度值得肯定和保持，不过工作方式还可改进。其实是个小事，不用过多挂怀。

[mrz3333]

多磕头，少说话。虽然我做不到！

[devliu1]

站在他的角度也没有错，涉及组与组之间的合作，复杂度高可能对方组里没办法改，还是要多 sync up 一下

“外企”+“微信群”这个组合就很有意思

[lasuar]

实现之前先讨论方案是否受到领导认可，最好不要有的自己的绝对技术思维，因为这不是你的个人项目。

[yougg]

老板给你钱，你还要教老板做事？
你是什么顶级行业咨询师吗？

[urnoob]

op 目前不明白
任何项目首先是交付
其次代码简单比复杂更难，何况就是个工具。人人能改，不容易改错才是工具。
外企比较开放，不会和国内互联网企业相互斗的那么厉害。碰到调整和裁员，移交的就移交 不会因为你特意做的复杂而留在你自己手里。
反而在移交后还要支持人家，对方首先要找的就是你上司。