写作绅士,读作丧尸 X岛揭示板
顺猴者昌 逆猴者亡 首页版规 |用户系统 |移动客户端下载 | 丧尸路标 | | 常用图串及路标 | 请关注 官方公众号:【X岛揭示板】 官方微博: 【@X岛极速版】| 人,是会思考的芦苇
常用串:·豆知识·跑团板聊天室·公告汇总串·X岛路标

No.63248433 - 无标题 - 技术宅


回应模式
No.63248433
名 称
E-mail
标题
颜文字
正文
附加图片
•程序语言、压制投稿、视频制作以及各计算机领域的技术问题
•我觉得还是CSDN靠谱一点
•本版发文间隔为15秒。

收起 查看大图 向左旋转 向右旋转
无标题 无名氏 2024-07-28(日)22:57:54 ID:HJkfQMu [举报] [订阅] [只看PO] No.63248433 [回应] 管理
逐渐理解屎山是如何形成的了( ゚∀。)
我不清楚是否有人能够做到,但是大部分时候,我们很难在开发初期就决定某个类或方法可能承担的所有功能
这就导致随着开发的进行,必须不断地对原有类或方法进行修改
当修改超出原有类或方法的承载上限时,就不得不创造新的类以及新的方法
而新类或新方法在逻辑上甚至跟原先的非常相似,但是因为些许步骤的不同而导致不能通用
这时候如果选择把共有步骤抽提出来,那么恭喜,复杂度又上去了( ゚∀。)

这还是一个人开发,清楚自己都写过什么都干过什么的情况
如果是多人协同开发,我都不敢想回是什么盛景( ゚∀。)
Tips 无名氏 2099-01-01 00:00:01 ID:Tips超级公民 [举报] No.9999999 管理
(`ヮ´ )σ`∀´) ゚∀゚)σ
无标题 无名氏 2024-07-28(日)23:04:30 ID:RLbFeM0 [举报] No.63248534 管理
从开发初期就能预见到以后所有功能
神仙来了也难做到吧( ゚∀。)需求这玩意哪有那么好预知的
无标题 无名氏 2024-07-28(日)23:16:03 ID:HJkfQMu (PO主) [举报] No.63248694 管理
>>No.63248534
如果是个人开发
开发开始前先明确所有需求
根据所有需求模拟出所有功能
根据模拟出的功能提取出相同逻辑
然后再根据相同逻辑的广泛程度,补充上可能会用到的通用逻辑
也许能行( ゚∀。)7
无标题 无名氏 2024-07-28(日)23:28:46 ID:Zkhg0nA [举报] No.63248871 管理
>>No.63248433
记得一个前辈跟我说过,类似,永远没有完美的,总是在不断改进的过程中的,但是多看看一些源码会好一些,在不断思考的过程中弥补过去的不足
无标题 无名氏 2024-07-28(日)23:31:09 ID:8hxlYPV [举报] No.63248905 管理
>>No.63248694
耦合越低越好吧
这样组合起来也方便
无标题 无名氏 2024-07-28(日)23:34:16 ID:5YNdT6L [举报] No.63248949 管理
软件工程゚ ∀゚)ノ启动
无标题 无名氏 2024-07-28(日)23:34:36 ID:BRpdzA2 [举报] No.63248954 管理
>>No.63248694
这个在现实产品设计上基本不可行,原因很多,比如产品设计本身受到设计者宏观能力和需求的狭隘限制、测试过程中发现逻辑缺陷、客户修改需求。这些都会导致每次开发工作的不可控,最终成为屎山。这也是现代软件开发多采用敏捷迭代并进一步向devops转化
无标题 无名氏 2024-08-13(二)08:29:02 ID:Zfsa15E [举报] No.63435182 管理
函数式万岁゚ ∀゚)ノ
无标题 无名氏 2024-08-15(四)09:57:25 ID:Flni6rg [举报] No.63457169 管理
设计模式中的开闭原则本身和软件开发过程是矛盾的。一个类的设计本身就发生变化了,这个时候还要去限制修改而去用扩展去补充,层层加码,到后面一个简单的类被套了无层,用了好几个设计模式去扩展,最后可读性和维护性奇差,后来人不敢乱改,只能继续用扩展代替修改,屎山越来越高,直到有一个人不信邪去修改而不扩展,彻底引爆整座屎山
无标题 无名氏 2024-08-16(五)12:53:26 ID:rna0cTu [举报] No.63470131 管理
不敢改且懒得重写,很难知道项目中一段十几年的陈旧代码是不是某个地方还在用
无标题 无名氏 2024-08-16(五)14:16:02 ID:g5s61uT [举报] No.63470887 管理
解决屎山的唯一途径是花费巨额成本重构整个项目
无标题 无名氏 2024-08-16(五)14:51:32 ID:Gs2SdhS [举报] No.63471178 管理
最主要原因感觉是deadline,软件开发目的终究是为了快速实现能跑的代码,而不是比代码更优雅。重构的成本实际很难负担得起
其次是因为多人接手,不同的人水平不同,代码风格不同(比如python,js,java,很多同样的代码,实现的风格就不太一样)
无标题 无名氏 2024-08-21(三)10:55:56 ID:vfyMYqI [举报] No.63524399 管理
>>No.63471178
这个就是所谓的战术编程了吧
无标题 无名氏 2024-08-21(三)10:58:35 ID:vfyMYqI [举报] No.63524420 管理
>>No.63248694
问题在于业务需求是会产生变化的
甚至说用户客户对自己需求的认识和要求也不一定是真实符合实际情况的
所以在设计架构的时候也得考虑到万一需求变化了怎么修改扩张
无标题 无名氏 2024-08-21(三)11:27:30 ID:C5A03Bf [举报] No.63524676 管理
没错我就在维护老代码(屎山)( ;´д`)
无标题 无名氏 2024-08-22(四)06:28:29 ID:1LT9LKY [举报] No.63532777 管理
>>No.63524676
(´゚Д゚`)那每次工作岂不是都在品味屎山
无标题 无名氏 2024-08-22(四)13:41:29 ID:vfyMYqI [举报] No.63535712 管理
>>No.63532777
错了,往屎山接着拉屎也是我们工作的一环
无标题 无名氏 2024-08-25(日)18:14:39 ID:w8479uK [举报] No.63566795 管理
>>No.63532777
都是屎上雕花

UP主: