honmaple

提示打开 app 还算好的，起码我可以拒绝，最恶心的是进入网站后提醒下载 app，拒绝后想要返回原搜索界面结果返回不了，只能不停跳转某一个网页，跳转后又提示下载

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

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

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

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

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

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

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

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