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

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

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

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