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

[honmaple]

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

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

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

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

[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]

"我不喜欢你的命名"

"我不喜欢你"