为什么各项目负责人都喜欢搭个架子？

[honmaple]

真心想吐槽这个，你搭个架子可以，但你得考虑程序与业务功能的可扩展性啊，最后真是想改都不知道怎么改

最近遇到一个项目，我准备用以前用过的一个比较成熟的架构，已经写好了基本的功能，结果被全盘否定，理由是这个项目只是内部使用，能用就行，不需要设计得太完善，可大哥，这项目是要正式上线和客户接触的呀，另外一个理由，"我不喜欢你的命名"，嗯，这是原话

好吧，不用没问题，等了几天，该项目负责人搭的架子出来了，看了代码之后我才知道什么叫做能用就行，什么叫做流水线式代码，为什么刚开始讨论时我说某个模块可能需要几百行代码，你却说只需要不到一百行。。。一套流程从头走到尾，行云流水般没有“一丝”可扩展性，配置参数检查没有，错误及异常处理没有，几十 G 的数据全部保存在内存，每个模块都有几十行重复代码，明明是 Go 项目，一个目录里却混有 go 文件，python 文件，go 和 python 各自的依赖文件，docker 文件。。。没办法，只能硬着头皮把之前写好的功能重写适配，也提了一些建议，第二天告诉我要重构，好的，没意见，起码把配置检查和异常处理加上吧，第三天发现所谓的重构其实就是重构我提交的代码，改成他自己的风格。。。

上周，老大让排查某个问题，我愣是呆呆地看了一天，明明知道 bug 在哪，可我怎么改，一改 n 个模块都要改，架构也要变，改了之后其它不是我负责的部分不知道还能不能跑起来，唉，下周继续

[ericgui]

离职走人

[reus]

离职啊
离职前，往死里叼它。

[luckyrayyy]

因为省他的事……

[honmaple]

@ericgui @reus 已经滚过一次了，上家公司也是负责人搭了一个架子，到最后各种功能已经无法继续扩展时，我重写了部分设计，不过目前应该还待在“其它分支”；另一个项目也是又搭了一个架子，不过这次我没用这个架子，自己新设计了一套，结果直接被叫去骂了一顿，然后我就滚了，没想到新公司还是老样子。。。

[honmaple]

@luckyrayyy 可后期的功能实现和代码维护不是他来做的

[2643595423]

有时候不打一架解决不了事 打一架就行了 别太过分了

[luozic]

虚心求教么，不是牛得一笔，多吹捧吹捧，让他给大家介绍介绍混合面条式代码如何 debug

[fuxkcsdn]

如果已经连续 2 家公司（现在应该是第三家了？）都这样，难道不应该考虑下是不是你的问题了吗？

[JounQin]

要么自己主动去改，要么走。
成年人，少点抱怨，多点实际行动。

[hantsy]

现在很多 DevOps 工具配置是 Python 或 Ruby 来写，这个没问题。有 Dockerfile 也应该的，现在项目基本是标配的，在 CI 服务上创建 Docker Image，直接 Push 到 Docker Registry，部署到 Docker 容器（ K8s, Openshift 等）。

如果是 Python 代码是业务代码，和 GO 混在一起，这的确感觉不大好。不过一个项目同时用不同的语言数据库等技术混合现在太常见，一般分开在不同的模块，或服务（ Microservice ）中，Service A 用 Python 开发，Service B 用 Go 开发，没问题。

你把你自己以前的东西带过来，一直试图按自己的来，本来就是最大的问题。如果你不能在短时间内遵循业内的一些公认的 Convention （比如 Effective GO 等）来证明你的方法做得更好（比如，清晰的代码结构，合理的 Struct 设计，完整的测试代码，开发，测试，生产环境中使用的相应的 Build 脚本等），为什么不按他的来，想想公司每个人都按自己的来，项目不是乱了。

至于你说什么架构问题， 你负责的那一点东西谈什么架构？一个项目整体考量才讨论到架构，你的描述也看不出来有什么问题。

[metrxqin]

一句话总结 OP 根深蒂固的错误观念：Tech debt 并非完全不可接受的。

[honmaple]

@hantsy 一个目录，一会儿 go 文件，一会儿 python 文件，一会儿依赖文件，建个目录把这些分开不好吗。
还有，我并没有一直试图按自己的想法来，我说了，搭架子可以，但得考虑到后续的可扩展性和可维护性，不是简单的能用就好，你更不能搭个只是能用的架子，然后其他人都得按照这个来，改一个模块就要同时改其它所有模块，后续对于其他人的维护成本很高，你却可以什么都不管
另外，我认为一个项目刚起步，所有这个项目的人都要参与该项目的整体设计，不是等架构被设计出来才开始你干你的，我干我的，我做了什么你不知道你也不关心，你做了什么也与我无关。。。

[honmaple]

@fuxkcsdn 所以我的疑问就是各项目负责人是不是都喜欢搭个架子，然后再交给实际维护的人

[liangkang1436]

老哥，说句实在话哈，工作代码，出于责任心，想写好，这是非常棒的想法，这点我很佩服，至于老板采不采纳，那是老板的问题了，你做不了主的，你干你分内的那一份活儿就好了，这其实是一个心态问题，没必要老是因为这离职，实在是不爽，就攒好实力，去大厂，我相信，大厂的架构不会有这些明显的槽点，你老是在小厂之间来回跳，逃不出这个圈子的

[willxiang]

看你这么说，我觉得你可以换一家你来当负责人的公司，
这样你就可以按你的想法按最合理的思路去写代码了

[learnshare]

答案：是
有“经验”的开发者往往拒绝接受别人的“垃圾”代码和风格

[mcfog]

你知道负责人的责是什么责吗？ 他负责他就有权利对你提要求，你只能提意见，觉得无法接受就走人，并且像楼上说的一下反思一下自己为什么连续两家公司碰到类似的问题

[hantsy]

@honmaple
1. 敏捷实践讲究 Brainstorming，要求各个 Stakeholders 参与，听取各方面的意义，一点没有错。国内的敏捷很多是形式主义，开会的场景样子十足，一些敏捷开发实践过程空白（比如，TDD，DevOps，Pair Programming 等），这个我深有体会。
2. 由某些更高级的技术人员去实现一个 MVP 或更小的 POC 也没问题，前提是这个 POC 能够说明某些技术架构的优劣，能够走完 DevOps 流程，来证明它有足够的价值。

[jinsongzhao]

有本书叫重构，可以看看，第一个框架总要有人搭，后来人则慢慢重构和优化，甚至量变到质变，完全变成新的架构。负责人要承担责任，用自己懂的架构才能承担责任呀，小项目才会重搭架构，几百万行代码的，是不可能重搭架构，只能重构。够强的负责人也能适应更多的架构。

[hoyixi]

其实，正常来说，都是架构师先搭好架子，然后下面的程序员填代码，实现具体的类什么的

不过国内很多技术头头都是“官”，都是让下面的人撸起袖子就写

[farverfull]

1.你大佬是不想接触重新学习你的东西，所以才不采用，基本哪个公司都是这样，只是水平高低问题。2.重构你代码，你之前写就没想过根据他的风格去写你提交你的模块吗？感觉长的像猪也总比四不像好看。3.bug 该怎么改就怎么改，能解耦就解耦，接受不了就走人，但很可能下家再遇到一样的。

[hantsy]

@mcfog 这个观点，我倒是不怎么认同。
平庸的人都是一样的平庸，都会排斥接收新东西，优秀的人却有不同的优秀，往往显得不合群。

[maddot]

每个人都想按自己的那套来，并且相信自己的是最合理的

[winterbells]

我这也是，自己 shi 样代码还天天管我规不规范

让我提优化点，看完了说没有实际意义，自己又提了一堆乱七八糟的东西，最后让我来改

搭的那个框架真 tm 废，每个生命周期都用 try catch 包起来。有鸟用。初始化的代码都不执行了，下面不一堆空指针

这种人要么真的有实力，要么就是为了满足自己控制欲

[hantsy]

@jinsongzhao 在国仙几乎没 refactoring 这种说法，一直是 revolution 的。架构 evolution 应该是经常 Refactoring 的结果。

重构的工作在项目要经常实施才有效，一些敏捷实践中每个 Sprint 留出一两天来做这些工作，将所有的 Code Small 在萌发状态清理。项目到一定程序，不定时清理代码，Tech Delbt 会越来越多，项目后期几乎不可能再重构了。

在以前上班的日子，我经常听到一些负责人的计划（谎言）就是“先实现功能，不要太关心质量，等以后有时间再重构”，而我从来没见兑现过。

[activemq]

负责人要对这个项目能有可控性，也许你用到了一些不可控的第三方类库，或者是新人上手起来不好接手

[mcfog]

@hantsy ？这和平庸还是优秀有什么关系，我的观点是责任和权力对等啊

负责人平庸，那是老板的问题，最后输出不佳也是老板拿钱兜着，楼主觉得自己优秀所以受气，那还是自己面试入职考虑不周

负责人优秀，楼主无法理解和沟通导致误解，那还是楼主的问题，尤其是连续两次说明不是偶然，所以我很赞成让楼主自己反思问题在哪里

我只说楼主是因为这里只有一方的观点，在这里评价负责人或者公司既做不到客观又产生不了价值和意义，评论楼主则有可能让他变得更好，不是吗？

[Junn]

角度不同，高度不同，看待问题和做事方法就不同。
往往公司新人都觉得哪哪都是问题，哪哪都应该改。

[Acoffice]

因为他是领导,你是兵...
领导的意思,就是你还不是领导,就不要站在领导位置思考领导的问题,你只需要解决你的问题就可以了,至于由你而产生的问题,自然会有人解决.
---
在其位,谋其职.
---
如果你认同不了,建议你继续换.直到遇到一个开明的领导.

[Acoffice]

这个算是接力擦屁股的游戏吧

[yun77op]

没有评审的过程吗，理想情况下需要开个架构评审会的吧，负责人可以自己搞个架子，但要有明确列出比现有的成熟架构的优势所在才好，同时要考虑到项目现有的人员配置

[honmaple]

@mcfog 非常感谢您的建议，我也在反思，可还是有些想不通如果一个可扩展性不怎么好的的架构，前期没有考虑到的方面，如何能在不修改基本设计的情况下不断地对程序功能进行扩展与维护，我目前只能想到多层封装，可这也是另一种方式的重构了

[iConnect]

@fuxkcsdn 很早前和楼主有过交流，楼主技术不错，人很 nice。换几次工作不是很正常吗？

[laike9m]

去更好的公司，问题解决

[honmaple]

@yun77op 这个还真没有，搭架子前后说的都是能用就好，不需要太完善。。。

[wangxiaoaer]

搭架子有问题吗？如果是多人合作，不搭架子怎么让别人往里填业务？

你反对的应该是瞎捷豹搭架子。

[mcfog]

@honmaple 不一定是技术上的问题，也可能是你在面试 offer 入职的过程要对下家的技术水平没有做好一个基本的把握，也可能是你其他方面的一些缺陷导致你无法拿到更适合你的技术水平的公司的 offer

关于技术上的问题，你可以和负责人沟通，提意见，如果他的回复中有东西让你学到你就好好学，如果你认为这方面难以沟通无法理解，那就默默按他的套路来做事，出了问题他是负责人，让他来组织怎么解决就行（说不定他就能比你更轻松的搞定呢，谦虚点跟着学咯）。当然，同时可以在外面看新的机会，但前提是你得想明白，真的就是公司不行负责人不行，你的问题真的是不会挑公司，否则问题大概率循环出现

说架构的话题的话，架构的大多数问题都是权衡和资源分配，没有免费的午餐，扩展性是要用初期开发速度，团队人员能力，上手难度等等来换的。如果给我一堆低水平的开发让我带又禁止我换人，那我就会考虑教会他们怎么在一个良好（而不简单）的架构下写扩展性好容易长期维护的代码合算，还是快糙猛简单直接的结构，就靠人工测试，不断重新堆积面条代码来实现需求，也许反而更合算。这种时候我设计架构的目标就是不看扩展性，只追求低耦合，确保任何一坨面条坏了都尽量少影响其他面条，能更便宜地堆人力上去重写

[honmaple]

@mcfog 非常感谢，看了你的这些话确实有些豁然开朗，可能还是我社会及工作经验不够，心态也没能很好的转变，谢谢！

[maomaomao001]

搭架子是为了团队协作的时候，更好的控制问题，搭好架子 ， 别人一般按部就班的开发就行了，引入问题了，也比较好处理，
还有一个比较核心的目的是，类似你这样不确定性人太多（不是针对你 ，是说刚进来后，容易打退堂鼓的），就算你走了，项目架子在那，自己接起来容易 。

你这种架子都有比较明显的缺陷的情况，应该找负责人问问你遇到的问题怎么解决，正常情况下，搭架子的人应该很愿意完善他的架子的。

总而言之。 我觉得还是稳定的问题， 如果你来上班，确定要干个 2，3，4 年，会走过项目的整个周期 ， 我估计负责人肯定会让你自己搭架子的....

[xiangyuecn]

"我不喜欢你的命名"

"我不喜欢你"

[version]

凡事换个方式思考会好一些..每个人都是这样过来的.包括你领导
作为开发.总想程序完美的设计..但是大多数企业都是业务驱动.都是上头安排.到技术负责人只是分配任务.明知道坑.改动大.还是要写的.技术部工资预算.人员分配.积极性.其实很大部分都是被压缩的
能搭架子的负责人其实算靠谱了.有不懂的.真上线前.最终坑会是他自己填的.不然项目延期最终他会滚蛋走人.如果几个项目一起.他了解你的代码然后分析问题.可能花费了 1 整天的时间.每个人都出问题.负责人每天就是打杂的活了.
在扩张性问题上.大部分企业都是.需求变化太大.从代码上去扩展是比较难的..还不如初期少写代码量.后期丢给其它同事也愿意维护.上手就是一个类是 1000 行.几十个文件.业务新大逻辑上大改.我想项目到后期能有多烂的问题了.1 年后没人维护.这个项目烂尾或者招毕业生来跳坑.我想 java 技术语言项目这种特别多

[nicevar]

说难听点，楼主你这样的也可能是个坑，这样的情况我见多了，框架满天飞的年代，一群员工每个人都想用自己的框架，该听谁的？如果没有决策人每个人都在里面写自己喜欢的一套，结果就是群坑集合，项目最后变成烂尾工程。因此项目负责人需要选择最稳定最有效的框架，不是每个人觉得自己的框架很成熟就能用，要是你的项目确实成熟比如线上项目跑着上百万的用户，你大可以直接怼负责人，如果只是你个人觉得的“成熟”就算了，到头来一群人还要帮你修改 bug，浪费时间。

[honmaple]

@nicevar 怼的真不错，可在怼之前能否仔细看看内容，我有说非要用自己设计的架构吗，项目负责人需要选择最稳定最有效的架构是没问题，可那么多明显的坑不是需要一群人帮他修改，我说是比较成熟的方案，而且已经提交 demo，负责人看了之后不提有什么问题，只说能用就好，还有不喜欢我的命名？？？难道非得让我直接表明这是我在前公司使用打磨了很久，线上稳定跑着几百万用户加上我对现公司业务的理解演变而来的架构

[honmaple]

@maomaomao001 @version 确实是这样，搭架子还需要考虑对非项目本身的人的代码可维护性和易上手性，但这只是对于引用了公司或部门内其它项目已有架构的项目，对于这样的项目，我还非得自己去新设计一个肯定是我的问题，我认错，但如果是一个全新的项目，全新的架构，设计者在设计的时候却不考虑现有维护者的维护成本，而优先去考虑现有维护者不维护的情况，这本身就是一个问题

[sagaxu]

偶遇也许是项目负责人的问题，连续遇到，多半是你自身的问题。也许是你项目经验不够，看不到屎山的价值，也许是你太优秀，要找个薪资 double 的工作。

不要给自己加戏，大部分项目并没有后期维护的机会，上线就是终点，甚至还没上线就被砍掉。即便需要小修改，一个只有一个文件 2000 行代码的实现，要比有 100 个文件每个文件 100 行的实现要更容易。

作为项目技术负责人，必须选择自己能搞定的技术栈，最好还是团队大家都比较熟悉的。外来方案再好再牛逼，也不能轻易推广，除非是空降 CTO 强推，否则很难推的动。技术负责人个人喜好，比你的喜好更重要，你觉得恶心带来的损失，比他小。语言选择很多，每种语言又有很多框架可选，每个框架甚至有多种风格可选，团队内部可能人人都有自己的风格，自然只能对齐到一种，谁背锅就听谁的。

我的习惯是快速发布一个屎山，先用起来，再重构。整个项目至少 20%的时间留给重构。那些活下来的模块，在长期的一点一滴的重构中，比你一开始精心设计的更好，因为重构的架构是需求驱动的，不是项目初期凭空想象出来的。而那些活不长久的模块，重构中直接干掉了。

[walkfish]

等你变成项目负责人，下面的人也会过来发一样的贴
理念和习惯不一样很正常，命名也有很多个人风格，加入一个团队是要融入，当然团队本身有很多做的不好的

遇到问题要解决，而不是一直以一个打工的心态逃避

[walkfish]

@reus 唯恐天下不乱的毒瘤

[walkfish]

@mcfog 很赞

[honmaple]

@sagaxu @walkfish 谢谢，这的确是心态与经验的问题，外加有些强迫症，哈哈。目前心态在转变，先做好自己的工作，后面遇到问题再一起重构

[wweir]

@jinsongzhao 这一切的实现存在两个前提：
1、架子的质量过硬。别搭出来的架子都搞得跟新人代码一样，那就没意思了
2、搭架子的人心态要好，有足够的耐心和包容性。架子中难免有取舍，每逢取舍应该有所说明，才能让别人从内心接受。同时别人提出更好的实现，需要能放下面子，正确对待

[wweir]

见过很多 leader 之类的老家伙，用 N 多年前的做法、风格搭个架子，最后最大的作用，除了恶心团队成员，也就只剩彰显他有 N 年经验了

[version]

@honmaple 其实目前的情况也在考验你呢.技术负责人也不清楚你的真实水平.放下傲气心态.按负责人的路子先走走咯.然后平时私下混熟些.等他发现你技术靠谱了.自然会放手给你做的了.包括脚手架.流程设计思路.然后你平时也认真负责.不是只为了打卡上下班.这样你混上靠谱的核心人员.对你以后也有帮助呢.至少以后简单的 crud 浪费时间的任务不会分配给你.无聊的业务任务也不用给你.你专心弄更有挑战的任务多好

[TheFLY]

@fuxkcsdn 朋友，读书不是为了让你成为**的

[angel001ma]

或许沟通下，其实领导也想下面的人有成绩

[zuokanyunqishi]

敏捷开发≈闭眼瞎开发😃

[xuanbg]

我们也不允许任何开发人员使用自己的一套，但鼓励每个开发人员共同维护公司的项目模板，无论是添砖加瓦还是修复 bug。

统一的架子的好处不仅仅是统一的代码结构和风格，还意味着比较一致的包引用。当然，该有的东西模板都集成好了，直接上手业务代码就好了，能省很多事，也能减少很多问题 。

[winiex]

再造个轮子，目的是好控制，对细节都掌控，然而基本上带来的麻烦可能比选择开源软件要多许多。

另外一个原因就是展示自己进行了架构设计，有不可替代的能力吧。

[qqxx520]

不想被人管，就没活干，现实就是这样。

[cedoo22]

多数负责人不具备架构设计能力，只是想换成自己熟悉的代码风格，开源软件大多经过 N 多项目多检验，哪是你随便一个项目就能替代的。

[jorneyr]

不要随意说出领导 SB 的行为，不要挑战人家的权威，即使对方很 SB，努力自己做领导，然后重复同样的轮回。

[ilotuo]

说的这么详细怕是要被定位了

[hyy1995]

这种 leader 很多，其实开源社区早就有成熟的框架，但是他还是自己弄个半吊子框架出来，让公司的开发们都用他的框架，你知道为什么吗？


为了维持他技术 leader 的地位，全部项目用的都是他写的框架，这样他跟公司的耦合就高，老板不敢轻易撤下他的位置或者开掉他。

[qiumaoyuan]

我觉得根源上是因为他不招比他强的人，所以默认招进来的都是比较弱的，为了管好这些弱者，让他们不出乱子，就定制了一套规范，大家都按他说的来。

[nicevar]

@honmaple 你不就是自己的框架被否定了出来发恼骚的，还不照样以自我为中心，好像觉得他们用了你的框架会体验很好一样，记住目前只是你对你自己的框架很满意，别人不一定，光负责人否定了你就发毛了，别说还有其他同事，他们照样也能挑出你的烂代码，其实大家都差不多，巴不得用自己熟悉的，如果你觉得公司其他人和你不在一个档次，很明显这个地方不适合你。

[dandd134]

都是利益问题，楼上的有些人话越说越假，绕来绕去，最后都不知道说了啥
就简单的一个意思，看起来气场很强，但有必要上来嘲讽骂人，绕来绕去最后还看不明白云里雾里的？
用领导写的框架，他的功劳最大，你一个新来的用你的就抢功了，就这么简单

[dandd134]

你也看到了很多，做小领导的技术水平不太行，画 ppt 吹牛可还行，不做事的尽是人事
觉得不行就找个真正的大公司，否则同级都是这种情况

[wujunze]

Diss 他啊

[freelancher]

领志是将，你是兵。其实前面满多人说的也很清楚了。只有你适应他，他不会来适应你的。

你要做的就是向上沟通。韬光养晦。学会技术后拍拍屁股走人。真觉得自己水平厉害了。去大厂里。大厂里破事没这么多。