无标题无名氏No.63248433 只看PO
2024-07-28(日)22:57:54
ID:HJkfQMu 回应
逐渐理解屎山是如何形成的了( ﾟ∀。)
我不清楚是否有人能够做到，但是大部分时候，我们很难在开发初期就决定某个类或方法可能承担的所有功能
这就导致随着开发的进行，必须不断地对原有类或方法进行修改
当修改超出原有类或方法的承载上限时，就不得不创造新的类以及新的方法
而新类或新方法在逻辑上甚至跟原先的非常相似，但是因为些许步骤的不同而导致不能通用
这时候如果选择把共有步骤抽提出来，那么恭喜，复杂度又上去了( ﾟ∀。)
这还是一个人开发，清楚自己都写过什么都干过什么的情况
如果是多人协同开发，我都不敢想回是什么盛景( ﾟ∀。)
无标题无名氏No.63248694
2024-07-28(日)23:16:03 ID: HJkfQMu (PO主)
>>No.63248534
如果是个人开发
开发开始前先明确所有需求
根据所有需求模拟出所有功能
根据模拟出的功能提取出相同逻辑
然后再根据相同逻辑的广泛程度，补充上可能会用到的通用逻辑
也许能行( ﾟ∀。)7
无标题无名氏No.63248871
2024-07-28(日)23:28:46 ID: Zkhg0nA
>>No.63248433
记得一个前辈跟我说过，类似，永远没有完美的，总是在不断改进的过程中的，但是多看看一些源码会好一些，在不断思考的过程中弥补过去的不足
无标题无名氏No.63248954
2024-07-28(日)23:34:36 ID: BRpdzA2
>>No.63248694
这个在现实产品设计上基本不可行，原因很多，比如产品设计本身受到设计者宏观能力和需求的狭隘限制、测试过程中发现逻辑缺陷、客户修改需求。这些都会导致每次开发工作的不可控，最终成为屎山。这也是现代软件开发多采用敏捷迭代并进一步向devops转化
无标题无名氏No.63457169
2024-08-15(四)09:57:25 ID: Flni6rg
设计模式中的开闭原则本身和软件开发过程是矛盾的。一个类的设计本身就发生变化了，这个时候还要去限制修改而去用扩展去补充，层层加码，到后面一个简单的类被套了无层，用了好几个设计模式去扩展，最后可读性和维护性奇差，后来人不敢乱改，只能继续用扩展代替修改，屎山越来越高，直到有一个人不信邪去修改而不扩展，彻底引爆整座屎山