写了那么多年程序，我也无法做到快速开发的同时也能保持程序设计合理优雅，你们能做到吗？

[JoeJoeJoe]

既要又要是要被杀头的

[chendy]

AI 恐怕都做不到，更别说人了
只能按照项目需求的不同，采取不同的开发策略

[miaotaizi]

这种都是经验决定的, 有没有统计过自己的代码量?

超过 30 万行了没?

[red13]

上来直接写代码，写多了成了屎山，头大。。。
先做设计的话实现时也不可能按照既定设计进行，肯定得做修改，头也大。。。

[SayHelloHi]

做不到

但是 只要屎山代码能挣钱 继续堆 也不是不可以

[vultr]

那是你花在设计的时间不够吧？

如果一开始的设计有问题，也可以在写的过程中不断改进的。

[jorneyr]

矛盾一直存在。

[eleganceoo]

赶进度还设计个鬼，面向过程一把梭

[zhaosong]

在潜意识里排斥要写出的垃圾代码就行了

[potatocoderx]

不能啊，需求又赶，能做到基本规范和保证 bug 数量已经很不错了，你说后续有空优化下吧新需求又来了又得做新需求。像国内这种压榨和推崇敏捷开发的环境下就别想这么多了。

[mengdodo]

做不到，时间充足的情况下也只是偶尔能做到优雅，大部分时间也是各种纠结。相反时间紧张的情况下各种冗余，还不纠结，也不内耗。哈哈.

[fy718]

要学会用 ai ，堆屎山+ai 一键优化，效果完美好吧

[lscho]

快速开发和程序设计合理优雅本来就是冲突的

[brazz]

需求不合理谈何设计合理

[spritecn]

不管怎么设计优雅,迭代两年都是屎山

[tensleyon3]

现在 AI 出来后，更难了....

[yc8332]

想优雅，要做的事情就很多，但是不可能每次都能给你足够的时间

[otakustay]

大架构上的所谓优雅和合理，与快速开发可能存在一定程度的冲突，因为架构也是需要不断迭代和优化的，但架构的变更又需要比较大的、独占式的研发成本
但局部的、模块级的优雅，这事情根本不需要时间充足，不需要额外思考，你代码写的够多删的够多，这就会成为自然而然的思维

[kapaseker]

我现在能了，但是老改需求的话，我就要开始写屎山代码了

[s2555]

屎山代码增加防御力

[freezebreze]

业务需求都是屎 ！代码他就得是屎山代码

[yunyi93]

快速撸出来，业务发展好了就重构，发展不好 GG

[salparadise]

设计个鬼，一把梭就是干，需求急的跟要去投胎一样，哪有时间设计

[sky3hao9]

我理解优雅就是为了简洁, 所以能做到!
然而, 这种方式前期要投入的时间要多一些, 尤其是架构设计, 后面就能实现既快速又优雅.
如果一上来就不管不顾堆屎山, 后面就会又慢又丑问题一大堆.
开发经验足的都知道其实后者的投入的时间成本更大, 但是没办法, 国内风气如此, 愚蠢的管理者不重视技术,导致基本都是后者的方式

[ixcode]

@red13 屎山的隐含意思就是这个代码所支持的业务是赚钱的，因此代码值得继续维护。或者可以更极端点，所有正在运行的服务的程序代码，都多多少少是屎山

[FireKey]

别想太多,前期想得再好的设计碰到产品脑洞一开都得作废,边拉新的边梳理老代码,碰到实在理不动的需求一般是大版本,直接重构好了

[lilu0826]

计划赶不上变化，项目和人总有一个能跑。

[kevan]

真实，哈哈哈。

[zerovoid]

所谓的优雅，也是为了实际利益，比如可读性拓展性复用性等。
为了优雅而优雅，没活硬整，那就舍本逐末了。

[y2xworm]

开发第一原则：又不是不能用！
测试第一原则：用户就是最好的测试！
项目经理：先上线在说！
需求：后面开发细化！

[muchan92]

我现在可以。
设计的误区是扩展性，即使有充足的时间，但需求的奇葩性总会击穿原以为良好的扩展性，因为代码设计就像刚性结构的建筑，每一行代码都是堆砌的砖块，后面的代码堆砌在前面的代码上，但没人能保证前面的代码永远不会移动。所以扩展性仅能支持很小的形变，但需求却可能会 180 度转弯。
所以与其谈论扩展性不如谈论稳定性。假设需求非常多变，找到一种能够始终保证稳定性的方案即是出路。

[red13]

@muchan92 你这个比喻很形象

[Gilfoyle26]

我比较能，尤其是现在 ai 的时代，思路要对，不然 ai 也救不了