• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 382 days ago, the information mentioned may be changed or developed.
 |
1
既要又要是要被杀头的
|
7 |
chendyOct 17, 2025
2
AI 恐怕都做不到，更别说人了
只能按照项目需求的不同，采取不同的开发策略 |
 |
miaotaiziOct 17, 2025
3
这种都是经验决定的, 有没有统计过自己的代码量?
超过 30 万行了没? |
 |
4
上来直接写代码，写多了成了屎山，头大。。。
先做设计的话实现时也不可能按照既定设计进行，肯定得做修改，头也大。。。 |
 |
SayHelloHiOct 17, 2025
5
做不到
但是 只要屎山代码能挣钱 继续堆 也不是不可以 |
 |
vultrOct 17, 2025
6
那是你花在设计的时间不够吧？
如果一开始的设计有问题，也可以在写的过程中不断改进的。 |
 |
jorneyrOct 17, 2025
7
矛盾一直存在。
|
 |
8
赶进度还设计个鬼，面向过程一把梭
|
 |
zhaosongOct 17, 2025
9
在潜意识里排斥要写出的垃圾代码就行了
|
 |
potatoTomatoOct 17, 2025
10
不能啊，需求又赶，能做到基本规范和保证 bug 数量已经很不错了，你说后续有空优化下吧新需求又来了又得做新需求。像国内这种压榨和推崇敏捷开发的环境下就别想这么多了。
|
 |
mengdodoOct 17, 2025
11
做不到，时间充足的情况下也只是偶尔能做到优雅，大部分时间也是各种纠结。相反时间紧张的情况下各种冗余，还不纠结，也不内耗。哈哈.
|
 |
fy718Oct 17, 2025
12
要学会用 ai ，堆屎山+ai 一键优化，效果完美好吧
|
 |
lschoOct 17, 2025
13
快速开发和程序设计合理优雅本来就是冲突的
|
 |
brazzOct 17, 2025
14
需求不合理谈何设计合理
|
 |
spritecnOct 17, 2025
15
不管怎么设计优雅,迭代两年都是屎山
|
 |
tensleyon3Oct 17, 2025
16
现在 AI 出来后，更难了....
|
 |
yc8332Oct 17, 2025
17
想优雅，要做的事情就很多，但是不可能每次都能给你足够的时间
|
 |
otakustayOct 17, 2025
18
大架构上的所谓优雅和合理，与快速开发可能存在一定程度的冲突，因为架构也是需要不断迭代和优化的，但架构的变更又需要比较大的、独占式的研发成本
但局部的、模块级的优雅，这事情根本不需要时间充足，不需要额外思考，你代码写的够多删的够多，这就会成为自然而然的思维 |
 |
kapasekerOct 17, 2025
19
我现在能了，但是老改需求的话，我就要开始写屎山代码了
|
 |
s2555Oct 17, 2025
20
屎山代码增加防御力
|
 |
freezebrezeOct 17, 2025
21
业务需求都是屎 ！代码他就得是屎山代码
|
 |
yunyi93Oct 17, 2025
22
快速撸出来，业务发展好了就重构，发展不好 GG
|
 |
GabrielGarciaOct 17, 2025
23
设计个鬼，一把梭就是干，需求急的跟要去投胎一样，哪有时间设计
|
 |
24
我理解优雅就是为了简洁, 所以能做到!
然而, 这种方式前期要投入的时间要多一些, 尤其是架构设计, 后面就能实现既快速又优雅. 如果一上来就不管不顾堆屎山, 后面就会又慢又丑问题一大堆. 开发经验足的都知道其实后者的投入的时间成本更大, 但是没办法, 国内风气如此, 愚蠢的管理者不重视技术,导致基本都是后者的方式 |
 |
FireKeyOct 17, 2025
26
别想太多,前期想得再好的设计碰到产品脑洞一开都得作废,边拉新的边梳理老代码,碰到实在理不动的需求一般是大版本,直接重构好了
|
 |
lilu0826Oct 17, 2025
27
计划赶不上变化，项目和人总有一个能跑。
|
 |
kevanOct 17, 2025
28
真实，哈哈哈。
|
 |
zerovoidOct 17, 2025
29
所谓的优雅，也是为了实际利益，比如可读性拓展性复用性等。
为了优雅而优雅，没活硬整，那就舍本逐末了。 |
 |
y2xwormOct 17, 2025
30
开发第一原则：又不是不能用！
测试第一原则：用户就是最好的测试！ 项目经理：先上线在说！ 需求：后面开发细化！ |
 |
31
我现在可以。
设计的误区是扩展性，即使有充足的时间，但需求的奇葩性总会击穿原以为良好的扩展性，因为代码设计就像刚性结构的建筑，每一行代码都是堆砌的砖块，后面的代码堆砌在前面的代码上，但没人能保证前面的代码永远不会移动。所以扩展性仅能支持很小的形变，但需求却可能会 180 度转弯。 所以与其谈论扩展性不如谈论稳定性。假设需求非常多变，找到一种能够始终保证稳定性的方案即是出路。 |
 |
Gilfoyle26Oct 17, 2025
33
我比较能，尤其是现在 ai 的时代，思路要对，不然 ai 也救不了
|
Select Language