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

[honmaple]

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

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

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

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

[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，努力自己做领导，然后重复同样的轮回。