要多健壮的代码才能支撑起千变万化的需求？

[waiaan]

最后不会成为屎山

[typing]

容易改的代码

[FanChen]

if else 足够多的话

[flyingghost]

千变万化的开发团队。

[MrBearin]

人容易看懂的代码

[XiLingHost]

可维护性高，可扩展性强的代码

[wangritian]

看架构怎么拆分层级依赖

[qping]

怎么都不可能吧,
尽可能的解耦. 不断迭代 , 把一段时间内堆的小屎山铲掉

[xieqiqiang00]

“开闭原则（ OCP ）: 如果系统想要容易被改变，那么其设计就必须允许只靠增加代码来改变系统行为，而非只能修改原有代码”

“不将未来的需求抽象化，「 You aren’t going to need it 」，一项中的需求往往是不存在的
需要发现在某个位置确实需要边界，如果不设置，再添加的时候需要的成本和风险往往是比较高的
架构师需要在上边两点做 trade-off，需要一点点未卜先知的能力”

[h82258652]

不可能的，例如一个一对一的逻辑，贯穿了整个业务流程，然后某天产品说要改成一对多的。

[HENQIGUAI]

你好，有的 。https://github.com/kelseyhightower/nocode

[waiaan]

@h82258652
不错，就是这种业务逻辑都变了。

[BeautifulSoap]

这是做梦呢，对于处理千变万化业务的代码，最好办法就是引入测试（单元测试、集成测试）然后根据需求持续重构代码，而不是不停在之前的代码上修修改改

代码即模型，你业务变了意味着模型也变了，想用一套代码处理所有业务意味着想用一套模型去处理所有业务，不存在这种神奇的银弹的

[zhangchongjie]

代码这玩意儿，感觉就和做生活中产品一样，单一的产品功能简单反而达到更好地效果，想必这也是以后发展的趋势吧。而不是像现在 bat 一样，恨不得一个软件所有功能都集成了

[Granado]

个人认为，这从来都不是代码的问题，根本在于没有一套合理的模型去处理业务；
每次开发的时候，leader 都说要抽象，要扩展，可是最开始的设计根本考虑不到以后的各种业务细分 case，只能不停修修补补。

[pengtdyd]

典型的程序员思维。如果出现千变万化的需求说明你们公司应该换一个带脑子的产品经理

[yunyuyuan]

@HENQIGUAI #10 少了个'亲'，差评。

应该是'亲，你好，有的'

[way2explore2]

无码

[CodeCodeStudy]

需求千变万化说明老板都不知道要做什么，赶紧跑路

[FranzKafka95]

个人认为不是代码问题，是架构问题

[maichael]

“没有银弹”

[charlie21]

垃圾需求直接挡掉，
若你什么需求都接（且免费做），那么，嗯，哈哈，哈哈，连外包公司都知道 每一次和客户商定额外变化需求 都得额外加钱

[boywang004]

easier to change 也许更值得追求……

[yidinghe]

我这边有一个服务就是帮助学校统计考试成绩。为了支撑各种学校的不同需求，我只能将统计过程划分成非常细微的步骤，根据需要进行组合。如下图所示：


[Hack3rHan]

正经回答：屎山

[rationa1cuzz]

足够简单的易懂的，记得之前的老大哥说过一句话，写代码秀什么操作，怎么简单怎么易懂怎么写，秀技术过段时间自己都不看不懂，更别说别人（小公司）

[huangmingyou]

像魔兽一样，允许产品经理写 lua 脚步，有没有搞头？

[wangkun025]

道高一尺魔高一丈。
放下反抗，立地成佛。

[waiaan]

@yidinghe 赞

[liuxingdeyu]

没有银弹

[tabris17]

健壮性和“支撑起千变万化的需求”有什么关系？

printf("Hello world"); 最健壮了，能撑起个啥？

[dxpy]

无解

[guisheng]

写的时候先走一步。

[Building]

我们公司开发了一个云软件，只要本地输入需求，AI 就会生成专用软件，使用特简单，就是编译时间比较长，可以随时登录查看编译进度，完成后直接下载就可以使用了。

实际: 后台收到需求立刻组织团队人工开发，项目经理定时更新进度，完成后上传。

[newtype0092]

代码不用多健壮，只要开发人员足够健壮，看起来一拳能打死🐂那种，就可以让提需求的人主动闭嘴，把千变万化的需求消灭在萌芽里。

[molvqingtai]

没有

[weiwenhao]

web 业务的话 直接把数据库数据原样丢给前端，让前端去处理，后端建表暴露增删改查，千万别做复杂处理和组合，不然需求一变你就要改代码。
需求方都是看着最前端界面改的需求，让前端跟着变就好了， 数据则是固定的，不会因为需求的改变而改变。

[cz5424]

先教产品经理写代码，或招个会写代码的产品经理

[littlewing]

不可能，很多情况就是，功能 A 不需要做，以后也不会有，不用考虑这个功能，不需要设计那么复杂，快上线，过一段时间，A 功能需要做，马上就要，这周就要上线

[pkoukk]

不需要健壮
改变程度超过阈值就重写
不然哪来的工作量，怎么造福新入行的同事
手动狗头

[iBaoger]

简单，易懂，功能闭环

[keepeye]

屎山是如何形成的。很多时候不是因为增加需求，而是因为需求不断变化，前后矛盾

[vone]

@HENQIGUAI nocode 现在的 issues：3,487 Open，514 Closed 。看起来也不是特别健壮了。/doge

[gps949]

取决于你的“千变万化”会发生在多长时间内。
[几天之内千变万化] 别写代码了，搞个脚本，最好还是靠人工吧。
[几个月之内千变万化] 要注意类函数变量的类型、命名、作用范围等，编码时尽可能的考虑全特殊值、边界问题等。
[几年之内千变万化] 写好注释、文档，系统模块化设计，标准化接口，数据格式精心设计更灵活，方法和模块复用尽可能小心。
[几十年之内千变万化] 系统架构设计灵活、可扩展，代码语言的选择仔细考量，第三方框架、库、插件等尽量少用，一切轮子尽可能自己实现，并除很小内核外，尽可能以松耦合的插件方式实现。
[几百年之内千变万化] 你 /你的程序 /业务活不了那么久，不如思考下人类发展历史走向吧。

[iBugOne]

乱改需求可以掀翻小菜鸟，但是掀不翻大佬

[YUCOAT]

我觉得方法只有一种，那就是“看到 shit 的时候及时把屎铲掉，别等堆起来”。

以前所在的团队，我们写代码遵循两条原则：
1 、以前的旧代码，能不动就不动。
2 、添加新代码的时候，尽可能少的对旧代码进行修改。

正是因为这两条原则，使得垃圾代码越堆越高。

纯靠设计来防止垃圾代码越堆越高根本不现实，项目早期的时候，我们会对未来需求的预测来设计代码结构。
刚开始可能设计良好，一两年以后，新的需求与早期的预测差别越来越大，这时老的设计已经无法通过扩展代码的方式来满足新的需求了，这时如果不对部分代码进行翻新，垃圾代码就会慢慢堆积起来。

[bloomy8]

@yidinghe 请教下这个图是手工画的还是自动生成的，用的什么软件

[thtznet]

能支撑业务的，从来就不是代码，而是资本。

[shyangs]

開閉原則（ OCP ）: 如果系統想要容易被改變，那麼其設計就必須允許只靠增加代碼來改變系統行為，而非只能修改原有代碼

----

以前所在的團隊，我們寫代碼遵循兩條原則：
1 、以前的舊代碼，能不動就不動。
2 、添加新代碼的時候，盡可能少的對舊代碼進行修改。

正是因為這兩條原則，使得垃圾代碼越堆越高。

[seakingii]

这不叫健壮,叫灵活吧

[opentrade]

解耦+单元测试

[swim2sun]

没有银弹

[Perry]

有各种测试真的是最重要的

[ericls]

不需要 把该满足的目的满足就行了

平面几何解决不了曲面几何的问题
牛顿力学也解决不了微观的需求
你的代码要那么厉害干什么？

[shot]

@yidinghe #23

只是类图就错综复杂绕来绕去的……
就算代码写的再优雅，要是移交给别人（或者半年后自己再来看）会很难看懂吧……

针对这种计算规则多样，并且可能频繁修改的需求，一个比较推荐的办法是做个简单的「计算规则引擎」。

比如说：把「计算公式」和「参数」按照标准的格式记录在 Excel 文件里，「计算规则引擎」解读该 Excel 文件生成计算规则，然后应用程序读取数据并调用计算引擎作计算。
当需要更新计算规则时，业务人员只需修订 Excel，然后重新上传到系统。

除了 Excel，Python/Lua/Javascript 之类的脚本语言也能用来定义计算规则，我甚至用过 xml 。
之所以首选 Excel，是因为运营人员（产品经理、系统运维）和用户（学校老师）都熟悉 Excel 操作，而且能直接在 Excel 文件里输入一些样例数据对公式做人工验证。

[namelosw]

个人人为如果你用的语言支持 ad-hoc polymorphism，才比较建议追求灵活。

如果语言只有继承的话，追求灵活一般都是作死。

下面这篇文章说的是著名的表达式问题，很简单，就是加法乘法这些数据结构作为表达式，分别有打印和计算这些操作，然后希望符合 OCP 原则的情况下可以增加新的表达式和新的操作：

https://koerbitz.me/posts/Solving-the-Expression-Problem-in-Haskell-and-Java.html

如果你对比一下里面 Haskell 和 Java 的解决方案，就会发现 Haskell 在这个问题下实现 OCP 原则，使用了 Type Class 基本不牺牲可读性；而 Java 没有 ad-hoc polymorphism，要实现 OCP 只能用 Object Algebra 的方式来模拟，代码基本看不懂。

[3dwelcome]

@yidinghe 那么多英文，不写中文注释，完全不懂每个子模块的意思啊。

[libook]

《没有银弹》

[Sequencer]

AOP

[g0thic]

写好文档和注释 就好了

[sakasaka]

DDD 可以缓解这种问题，不过随着版本的演进，搞不好最终还是一坨屎

[starcraft]

如果项目本身就是业务型的，那就不可能存在你所说的。
前期考虑的再细致完美，几次需求一变，都成屎山。

[xwayway]

遗憾的是管理者、乃至技术架构师都不能真正地接受演进式设计（ Evolutionary Design ），尤其不能接受一个具有良好设计的系统，应该是能够被报废的，潜意识中总会希望系统建设能够一步到位，至少是“少走几步能到位”。
摘自 [凤凰架构]

[Samuelcc]

个人认为是分层设计搭配合理的抽象，并及时地应对需求进行架构演进，不要堆技术债务。
在写代码的时候发现有 bad smell，及时着手修改。

[Mark24]

不如解决产品。

[godgc]

个人认为，在重大代码更新后能够有一定时间可以对代码进行升级，不断的 patch 增加代码的鲁棒性，当然注释肯定必不可少

[NonClockworkChen]

产品逻辑一塌糊涂的话，没救。

[chanchan]

设计一个 DSL 丢给别人,然后进入下一个循环

[hungrybirder]

放心，再牛逼的架构，也跟不上产品逻辑的变化。

[wsfmzq]

https://www.v2ex.com/t/795055#reply52 只有放弃英文代码，写全中文代码，才能支撑起千变万化的需求

[jones2000]

钱到位, 别说千变万化, 就算亿万变化也没问题.

[justrand]

我觉得，公司能保证每次代码改动都有详细的开发文档（改在哪里，为什么改，涉及那些业务）留底才行！

[ljzxloaf]

ddd，如果業務模型發生顛覆性變化的話不能算是程序設計的問題。另外，這不叫健壯，這叫可擴展性。有個原則叫做 ETL （ easy to change ）

[lap510200]

@flyingghost 我觉得是稳定的开发团队才能支撑，频繁更换人的团队，坑只会越来越多，然后在原基础打补丁，而不敢轻易重构

[whileFalse]

需求也得健壮。
有的需求一看就不靠谱的喷死就是了。

[lulu7]

当然要代码集体所有，这样团队中的每个人都可以看到并修改代码的任意部分。看过一个相关小视频，楼主可以参考： https://www.zentao.net/redirect-index-19354.html

[jin7]

需要健壮的身体

[shuxhan]

一个计划做一把椅子最后产出一套房子的行业，忍着吧

[coolmenu]

不可能有对付千变万化需求的框架，能在某一个领域解决一部问题的框架就很好了，类似于 saleforce 这种体系，把销售的框架搭好，然后给一堆 api，还有定制的开发语言，公司定制自己的销售策略，管理等等，这已经很复杂了。

[php01]

世界上能言出法随的，都不是人，二郎神也才 36 变化，孙悟空也才 72 变化。
你上来就千万变化。。。

[janxin]

不可能

[TheBlade]

@bloomy8 可以试试看 Mermaid, 可以在 typora 里直接成图, java 项目有一个 X-Ray 的 eclipse 插件, 可以根据你的项目自动生成 https://xray.inf.usi.ch/xray.php, 个人比较喜欢 Mermaid

[henryhu]

配置化模块

[simo]

千变万化才能养活这么多人

[bloomy8]

@TheBlade 好的，我试试能不能在 OC 项目里用，谢谢

[wolfie]

团队所有人对要更改代码足够熟悉
足够的时间开发

[glfpes]

如果需求是千变万化的，那将需要重构。

所以微服务还是有它的优势的，每一个服务都尽可能保持小，坚守初心。这样解耦的系统重构的模块会隔离。

[akira]

不相关的事情 不要放一起 , 尽可能的拆分

[burby]

千变万化的需求，不适合用现在程序来实现吧…… 等真人工智能吧

[jiayong2793]

代码？
难道不是设计模式和架构吗？

[crclz]

1. 战略设计：充分理解业务领域、合理划分 BoundedContext，并在 BoundedContext 间的耦合点做足抽象，保证耦合点变化少（例如，最开始只有手机号注册，后面来了微信微博用户。如果合理划分了 BC，那么只需要改身份与访问上下文，其他模块不需要改一行代码、一行测试代码）
2. 遵循 DDD 的战术设计（ less important than (1) ）
3. 代码需要有测试。易于测试的代码大概率是好的代码（例外：test induced design damage ）
4. 少魔法、少炫技的代码，尽量减少他人的障碍

说开闭原则的，还只是停留在理论阶段的菜鸟。web 框架可以开闭，例如 asp.net 、spring，但是你的业务代码中的 application layer 你使用继承的方式扩展一个试试？根本原因在于 application layer 的职责是协调，是非常贴近核心需求的。新到来的需求用继承来扩展，如果你实践过，会发现非常痛苦。

开闭原则描述的是通过继承、重写方法来进行扩展。打个比方，你写一个字可以越描越好看，越描越有楷体的感觉；但是你写作文如果这里插入一句，那里插入一句，就会乱七八糟。

[Kylin30]

一个函数一个进程

[Rheinmetal]

做低代码平台
来键盘鼠标给你自己写
:doge

[zhanghua0]

这个老哥提出来的见解 /t/795055
（

[isnullstring]

支撑不了，要是能支撑，就是需求没到千变万化的程度。狗头.jpg

[taowen]

https://github.com/taowen/modularization-examples

[Felldeadbird]

屎山是不可避免的。只能尽量降低屎山的高度。

[raaaaaar]

有的问题不是代码问题

[wangyzj]

千变万化但都可以砍掉的无用需求

[bear2000]

没有。最后都会变成屎山，我现在就在看屎山

[tobepro]

所以才需要定期重构，推倒重来才能解决问题。还能制造点 OKR