这是一个创建于 1930 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前呆过某家互联网公司，需求总是拍脑门（没有经过思考和设计）+明天就要，日积月累，后台越来越乱。（ ps.不是产品设计人员的错。领导明天就要，产品能设计一周吗？）
导致后台动不动就炸，改点什么，异常困难。
最后公司不说死在这上面，但发展也深受拖累就是了。
后来渐渐发现，项目无法摆脱这种糟糕的情况。
基本上的死循环是：
1 、第一个项目往往是新团队。领导也没底，不放心给超长时间把第一版做好。都希望尽快先出点成果，好交代，也好考察员工能力，万一做不出来也好调整。（明明第一版是最重要的基础）
于是第一版总是混乱赶工。这种混乱不单是技术混乱，而是从需求，到开发，到测试的整体赶工混乱。
2 、混乱的第一版完成之后，基础已经歪了。但这时候，其实可能是获得表扬的。超出预期达到了 xx 目标。
这时候，需要大重构而不是修 bug 式的小重构。 这时，“第一版+大重构”的时间，远远大于“好好做第一版”的时间。
显然不可能。
3 、迭代开始了.....
4 、项目质量越来越差.....
这个死循环不知道怎么破。
对于领导来说，新员工新团队，怎么可能放心给半年以上的时间去做一个东西呢？万一做不出来怎么办？
很无奈。
 | 1 lairdnote 2020 年 12 月 10 日 最好做减法 |
 | 2 kop1989 2020 年 12 月 10 日  4 这就是代码腐败。 随着业务和需求的改变，你在之前做的“精妙设计”逐渐都会变成 ifelse 。 然后就是选择：继续往上堆还是重构。 人力资源不够富足的一般公司会选择让老员工继续往上堆。 直到整个系统变成一个黑盒。 然后推倒从来。（这时候恰巧会出现一些新的系统设计概念，比如 saas，比如云） |
 | 3 onikage 2020 年 12 月 10 日 根本问题就是领导瞎指挥, 明天就要是病根. |
| 4 kop1989 2020 年 12 月 10 日 所以减缓代码腐败的前提，就是足够的人力资源。 保证对于程序的每个修改和完善都是基于充分考虑和设计的。 但这明显对于多数公司不现实，性价比也太低。 所以你看即便是 google，淘宝这种体量的产品，也都是在不断的推倒重来。 只不过是通过一些软件工程上的流程优化来尽量让替代产品平稳推进。让普通使用者无法察觉罢了。 |
 | 6 hdbzsgm 2020 年 12 月 10 日 严格 code review 而且要人工做。 我自己的感觉是 如果想永远保持项目代码干净整洁 最好招两个大佬 专做 cr |
 | 7 coderluan 2020 年 12 月 10 日 2 |
 | 8 caixiaomao 2020 年 12 月 10 日 需求文档没有 规划设计没有 全凭领导一张嘴 没法子 越做越乱 越做越烂  |
 | 9 lyz1990 2020 年 12 月 10 日 无所谓啊，代码能跑就行。（手动狗头 |
 | 10 yule111222 2020 年 12 月 10 日 领域驱动设计可解，前提是大家都玩，领导认同。起步比较难而且慢，起来后会很爽的 |
 | 11 SuperMild 2020 年 12 月 10 日 1 很简单，加钱即可。项目越来越乱都是老板想省钱造成的后果，加人、给时间、请专家，没什么项目是搞不整齐的。 不加人、加班、赶工期…… 没什么项目是搞不乱的。 |
 | 12 zjsxwc 2020 年 12 月 10 日 9 以前有个人老是碰到领导乱提需求， 然后每次有需求时，他就引入购买三方服务，于是三方服务预算越来越大， 然后项目就被卡在财务哪里了， 逃 |
 | 13 hantsy 2020 年 12 月 10 日 2 对于开发，需要持续改进。 1 。正确的使用 Git 是第一步，必须使用 Branch 提交，一切项目的产出（包含文档，可以是 MD ,Asccidoc，最终输出 PDF，Doc 等）都要 Git 版本化。 2 。 代码写测试，做 CI 集成，借助云平台检测质量，等。 公司管理层面，就没话了，100 个公司有 200 个不同的做法。 |
 | 14 ruokw 2020 年 12 月 10 日 via Android deadline 就在那 做得好也在，做的不好也在 |
 | 16 xuanbg 2020 年 12 月 10 日 我只能说基础设施很重要。基础设施齐全，写点 crud 的业务代码费事吗？一点都不费事。 为什么我推荐大家搞微服务，不要怕难，也不要怕麻烦，有机会就要搞。因为你一套微服务搞完，基础设施就攒出来了。而这套基础设施，你随便到哪都能用。 |
| 17 hantsy 2020 年 12 月 10 日 @zjsxwc 有些老板贪图一些小便宜。 项目的基础设施，我是建议全部能用商业全部购买商业版本，Github 有付费的（ Team 等一些管理只有付费的才有），CircleCI 有付费的，Code Climate 等。国外的很多云服务模式做得很好，开源项目可以免费体验大部分功能（一些只有付费才开放）。 自己用开源的，一套自动化流程配置下来，累死人了，效果不可能达到商业服务。而且需要大量的时间和人力，这个成本下来远远超过购买商业服务 10 倍。 |
 | 18 fengpan567 2020 年 12 月 10 日 1 针对这种明天就要，下周就要的，估计需求也是一句话，你觉得开发能做成什么样？能用就行！ |
 | 19 sogwsc 2020 年 12 月 10 日 我们倒不是明天就要 一个项目几个月 会花很多时间去定计划 计划非常细 然后各项都在延期 截止时间又不变 等到测试阶段 已经来不及了 然后开始发补丁 |
 | 21 ericgui 2020 年 12 月 10 日 离职，找一个新工作，涨薪 50%+ |
 | 22 mapoor 2020 年 12 月 10 日 "设计系统的架构受制于产生这些设计的组织的沟通结构。" M. Conway 什么样的公司结构就会产生什么样的系统，根本原因就是没有任何规则能约束领导的嘴。 |
 | 23 ghostsf 2020 年 12 月 10 日 做更多减法 不断调整优化代码 |
 | 25 Jinxxxx 2020 年 12 月 10 日 依业务看除非是 2B 公司且公司有钱，有耐心有要求愿意慢慢打磨。不然以国内 2C 的环境，慢慢把第一版产品打磨出来可能市场早就没了，所以第一版往往都是赶工做完推向市场抢占用户。这是业务决定的，毕竟没有业务谁都没饭吃。 你要是真的想摆脱这类情况，可以看一些做 2B 做得比较好的公司，这种情况不说完全没有，但起码会好一些。 |
 | 26 hbolive 2020 年 12 月 10 日 楼主你说的这种情况是普遍存在的。 就拿京东来说，当年最开始就是 asp 做的，那时候的情况估计也是类似你描述的，一天一小改三天一大改。。但强哥能忽悠来投资啊，可以支撑后来的重构。。 |
 | 27 fwee 2020 年 12 月 10 日 第一步就有问题，需求多时间少必然越来越乱，应该直接砍需求只做 MVP 。不过根本原因还是领导不行，只能换公司了。 |
 | 28 2379920898 202 年 12 月 10 日 我见过。非要 1 个月就上线的。。说是怕失去市场。。但是往往这种老板都是无经验的，都做不起来。。我也见过好几个月出项目的老板。。人家对市场也不着急。。但是项目上线之后慢慢也运营起来了。。给你个角度去思考。你不如先考量领导的经验能力上来思考。。一般比较急上线的都是创业经验很少的领导。。。 |
 | 29 tikazyq 2020 年 12 月 10 日 删库走人 |
 | 30 kingzeus 2020 年 12 月 10 日 找个靠谱的团队很重要 |
 | 31 arthas2234 2020 年 12 月 10 日 定时重构，剔除掉一些冗余的功能，我现在就在做这个事 |
 | 32 manami 2020 年 12 月 10 日 不要用框架 |
 | 33 wanguorui123 2020 年 12 月 10 日 2 没有代码规范、代码审核，很难做到代码的可维护性，大多数公司要求能跑就行了，也没有什么规范和审核之内的。 很多细枝末节的东西还得靠精细化管理和团队自律，不然早晚都会乱写的。 |
 | 34 MonoBiao 2020 年 12 月 10 日 代码重构专员 |
 | 35 Otho 2020 年 12 月 10 日 靠管理和自律的事儿，又不算 KPI 啥的，那基本无可避免。 |
 | 36 |
 | 37 charlie21 2020 年 12 月 10 日 这有什么值得苦恼的？ |
 | 38 FinnBai 2020 年 12 月 10 日 《 Clean Architecture 》开篇就讲了这个问题 “研发团队必须从长远的利益出发与其他部门抗争，软件的可维护性需要由你来保护，这是你角色的一部分，也是你职责中不可缺少的一部分。如果忽视软件架构的价值，系统将变得越来越难以维护，成本也会越来越高。终会有一天，系统将变得再也无法修改。” |
 | 39 azcvcza 2020 年 12 月 10 日 想啥呢，代码质量又不算 KPI，能用多少 if else 就用多少 if else，没人会知道哪天来的新需求，就把之前重构过的给打乱了。还是去面向 B 端的企业好点，至少不像 C 端这样需求多变 |
 | 40 conanjun 2020 年 12 月 10 日 1 纯粹个人看法：这个问题其实不仅仅在代码领域出现，其他领域也有。例如：刚刚发布的新显卡爆出频繁黑屏事件，刚刚发售的新手机爆出屏幕问题事件、电池事件，刚刚发售的游戏因为 bug 多获得各种差评，等等。 如今即使是国际大厂也避免不了出现这种问题。 我觉得问题就在于当今社会真是一个快节奏社会。一个产品想存活就要尽量压缩成本，尤其是时间成本。比别人慢一步就会失去很多市场。 |
 | 42 OHyn 2020 年 12 月 10 日 做 C 端，就是抓用户需求。 第一版摊大饼粗糙点没事，第二版还抓不到方向，继续摊大饼，基本就废了，该砍的功能要砍。 之前我做的的一个项目，某个流程大改版了，领导还要求保留之前的流程，做到后台配置即可切换，并且“明天就要”，好吧。。。 |
 | 43 ytmsdy 2020 年 12 月 10 日 0：需求响应不能太及时，很多需求仔细想一想其实是伪需求。一个字，拖，拖个两三天估计领导都忘了这事情了。 1：做减法，砍功能，把常年不用的功能和代码下线。 |
 | 44 XiLemon 2020 年 12 月 10 日 感觉这个问题无解 |
 | 45 hhyyd 2020 年 12 月 10 日 通病了站在小公司的角度，快速迭代，赶着能用就行。等融到资了，有钱了，撤了整个团队，重新去重构，这个成本也是可以接受的。 |
 | 46 u6pM63mMZ34z32cE 2020 年 12 月 10 日 多人项目没办法, 反正我自己的项目看不顺眼就重构, 开发起来真爽 |
 | 47 tabris17 2020 年 12 月 10 日 @arthas2234 醒醒，重构不计入 KPI |
 | 49 deletemyself 2020 年 12 月 10 日 深有体会，想要的太多做的太赶注定是最终会有问题的 |
 | 50 StephenHe 2020 年 12 月 10 日 微服务吧，烂一个总比全烂的好 |
 | 51 MaxFang 2020 年 12 月 10 日 这种问题目前也遇到一些，也很困扰，暂时感觉无解。 暂时的做法是在自己可控的范围内，将相对稳定的模块单独维护或做系统，那些日常改动或临时急需求的模块，就写上去放在那吧。 实在是没有做详细设计和技术方案的精力了，因为第一版的需求，可能上线使用一段时间后，就会做大改版。可能和业务有关，目前是做供应链相关的，具体的一些操作模式无法直接复制，都是快速试错加迭代。 等一些大的模块相对固定了，再抽象模型来重构。 |
 | 52 stevenkang 2020 年 12 月 10 日 其实很简单，如 #12 说的那样，能购买第三方服务的，就提出需要购买第三方服务才能做这个功能，哪怕花费的钱很少都没关系。 时间久了，以后加功能就是：哦，这个功能基础版不支持，需要升级高级版啥的，加钱吧。。。 |
 | 53 taogen 2020 年 12 月 10 日 via Android 1 时间、成本和质量只能选择两个。 时间少、成本低 yes ！ |
 | 54 anthow 2020 年 12 月 10 日 最近深有体会，之前一个项目要得很急，然后第一版的设计和编码都很拉胯。最近想重构，真的无从下手。 |
 | 55 laminux29 2020 年 12 月 10 日 1 这个问题本质上是工程管理问题，你可以去翻翻几百年以来的城市规划、大楼建设、地铁新建、航母潜艇建造等书籍，都会有关于这个问题的描述。 结论很一致：无解。 大家的办法是： 1.没钱时，对现有的东西，忍受混乱，修修补补，甚至容忍因此造成的事故。 2.有钱后，报废或爆破旧东西，砸钱造新的东西。 |
 | 56 jones2000 2020 年 12 月 10 日 小作坊的开发都这样, 没事不关管, 打补丁的开发就可以, 哪个有问题就改哪里, 千万不要重构, 文档,测试用例都没有的,老代码过几个月就看不懂了, 重构很有可能改出 bug 出来的. 等项目成了, 有钱了, 挖一个技术团队重构. |
 | 57 SjwNo1 2020 年 12 月 10 日 我现在的做法是：保证我自己的代码符合规范，其他人我不 care （ code review 又不计入 kpi...） |
 | 58 liudengchn 2020 年 12 月 11 日 自扫门前雪，休管他人瓦上霜，把自己的代码尽最大可能的精雕细琢即可 |
 | 59 laike9m 2020 年 12 月 11 日 3 自下而上是推不动的，唯一解决方案：跳槽去一家重视项目架构和代码质量的公司。 |
 | 60 lishen226 2020 年 12 月 11 日 1 、顶住压力，延期交付。 2 、辞职。 |
 | 61 ychost 2020 年 12 月 11 日 把自己那份代码搞好，别人代码看不惯不要动，最多写个 adpater 包装一下 |
 | 62 wupher 2020 年 12 月 11 日 时时勤拂拭 勿使惹尘埃 |
 | 63 byte10 2020 年 12 月 11 日 @yule111222 领域驱动设计，一般人搞不了， 太难了，想的东西 比写的东西多 |
 | 64 forYou 2020 年 12 月 11 日 几乎所有的初创团队都有这个问题 |
 | 65 xingguang 2020 年 12 月 11 日 看看人月神话就懂了，所有这些都是无法避免的。除非找到外科手术团队模式的开发团队。 |
 | 66 dany813 2020 年 12 月 11 日 没事就小范围重构吧，小步快走 |
 | 67 jsnjfz 2020 年 12 月 11 日 趁早走人，公司迟早要完，只顾需求实现不管底层基础的并且说不通的都是垃圾。反正亏的不是你的钱，功能明天就要，钱明天就亏 |
 | 68 Terry05 2020 年 12 月 11 日 歪个楼，大家有没有好用的 code review 工具 |
 | 70 jsjgjbzhang 2020 年 12 月 11 日 基于时间和成本考虑，一切都不是问题 |
 | 71 1534853288 2020 年 12 月 11 日 @hhyyd 有道理 |
 | 72 micean 2020 年 12 月 11 日 一个卡车公司的销售做不出业绩，往往会从自己身上找原因 一个互联网公司的市场做不出业绩，往往会从产品上找原因 机器产出是固定，而人力产出却是弹性的，所以脑力密集行业就是一个天生压榨自己的行业 所以需要一个懂得做市场的人才和一个懂得管项目的人才，有长远的规划，才能破这个局 而不是一周做个玩意儿，挨个问“您要不要？” |
 | 73 th00000 2020 年 12 月 11 日 当然可以避免, 怎么做, 参考大型开源项目的做法 你见过 JDK 推倒重来的吗 你见过 Linux 推倒重来的吗 人家是怎么保证项目代码质量的, 无非就是严格的代码质量约束, 严格的 code review |
 | 74 Mithril 2020 年 12 月 11 日 |
 | 75 new123 2020 年 12 月 11 日 当有一天 bug 修改的进度和修复进度，远远超出领导的忍受阈值时，领导会问你如何改进，这时候重构才有它的意义。 |
| 76 yule111222 2020 年 12 月 11 日 @byte10 也没那么难，就算不用 DDD，需求一样要分析的，面向对象设计一样要做的，这只是提供了一套方法论教你怎么更好的做 |
| 77 charlie21 2020 年 12 月 11 日 @Mithril Surface Pro X 是 ARM 架构，微软的优先级是 先让 自家 SDK 支持 自家的 ARM 设备、再让 自家 SDK 支持别家的 ARM 设备。所以 喷吧 随便喷，有人理算微软输 |
| 78 byte10 2020 年 12 月 11 日 @yule111222 不难的话，全世界都用 DDD 了，面向对象编程 本来就难以理解，构建模型一般小朋友 不好理解。还是面向过程写的快，清晰。所以 DDD 才流行不起来。不过最近微服务把它 整热了一遍，未来还得凉。起不来的。 |
 | 79 zypy333 2020 年 12 月 11 日 我觉得看技术 leader,选择什么样的架构,怎么安排开发计划,如何砍掉不必要的需求,如何保证代码规范的执行 |
 | 80 taowen 2020 年 12 月 11 日 via Android |
 | 82 mazai 2020 年 12 月 11 日 深有感触，当一个项目太过复杂以后，且没有文档与项目规范，不管是定位问题，还是改 bug，或是添加新功能，都困难无比 |
 | 83 hzw94 2020 年 12 月 11 日 和我们团队的目前状况差不多 |
 | 84 tesguest123 2020 年 12 月 11 日 via iPhone 两种方式，一，跑路。二，开新坑。业务一多不可避免。加个 if 下班完事。 |
 | 85 shakaraka PRO 1 |
 | 86 leven87 2020 年 12 月 11 日 via iPhone 所以说码农连建筑工人都不如，建筑都是按照图纸作业，严格规范。代码想改哪都可以，天马行空 |
 | 87 pkupyx 2020 年 12 月 11 日 重构。太烂就重写 v2 。 |
 | 88 mamahaha 2020 年 12 月 11 日 既然是短时间内做完的项目，那整个推翻重做也没啥可惜的，做个参考就完了，何必做基础。 不花大力气重做证明公司通过实测不太看好这个项目，暂时不赔钱就留着养人，等赔钱了就放弃。 |
 | 89 nieboqiang 2020 年 12 月 12 日 你别把写代码当成一个神圣的事情，任何产品，系统都是有寿命的，过个几年就要准备重构了。 只要保证这几年内能用就行了，你修补的手艺再好，也不能解决业务性的问题，不能创造价值，有时候 ifelse 是最具有成本意义的写法。 任何事情都是有成本的，你做的又不是框架，只是提供服务而已，不需要考虑兼容性，大胆的写，然后大胆的重构就好了。 |
Select Language