回应模式 - No.63248433


No.63248433 - 技术宅


无标题无名氏No.63248433 只看PO

2024-07-28(日)22:57:54 ID:HJkfQMu 回应

逐渐理解屎山是如何形成的了( ゚∀。)
我不清楚是否有人能够做到,但是大部分时候,我们很难在开发初期就决定某个类或方法可能承担的所有功能
这就导致随着开发的进行,必须不断地对原有类或方法进行修改
当修改超出原有类或方法的承载上限时,就不得不创造新的类以及新的方法
而新类或新方法在逻辑上甚至跟原先的非常相似,但是因为些许步骤的不同而导致不能通用
这时候如果选择把共有步骤抽提出来,那么恭喜,复杂度又上去了( ゚∀。)

这还是一个人开发,清楚自己都写过什么都干过什么的情况
如果是多人协同开发,我都不敢想回是什么盛景( ゚∀。)

无标题无名氏No.63470887

2024-08-16(五)14:16:02 ID: g5s61uT

解决屎山的唯一途径是花费巨额成本重构整个项目

无标题无名氏No.63471178

2024-08-16(五)14:51:32 ID: Gs2SdhS

最主要原因感觉是deadline,软件开发目的终究是为了快速实现能跑的代码,而不是比代码更优雅。重构的成本实际很难负担得起
其次是因为多人接手,不同的人水平不同,代码风格不同(比如python,js,java,很多同样的代码,实现的风格就不太一样)

无标题无名氏No.63524399

2024-08-21(三)10:55:56 ID: vfyMYqI

>>No.63471178
这个就是所谓的战术编程了吧

无标题无名氏No.63524420

2024-08-21(三)10:58:35 ID: vfyMYqI

>>No.63248694
问题在于业务需求是会产生变化的
甚至说用户客户对自己需求的认识和要求也不一定是真实符合实际情况的
所以在设计架构的时候也得考虑到万一需求变化了怎么修改扩张

无标题无名氏No.63524676

2024-08-21(三)11:27:30 ID: C5A03Bf

没错我就在维护老代码(屎山)( ;´д`)

无标题无名氏No.63532777

2024-08-22(四)06:28:29 ID: 1LT9LKY

>>No.63524676
(´゚Д゚`)那每次工作岂不是都在品味屎山

无标题无名氏No.63535712

2024-08-22(四)13:41:29 ID: vfyMYqI

>>No.63532777
错了,往屎山接着拉屎也是我们工作的一环

无标题无名氏No.63566795

2024-08-25(日)18:14:39 ID: w8479uK

>>No.63532777
都是屎上雕花