For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
软件代码维护是程序员需要长期关注的一个问题,而本文我们就通过案例分析来简单了解一下,代码维护常用方法都有哪些。
复杂的软件也可以有很优秀的设计。各种大型项目本身也是有先例的。但是为了支撑起复杂的业务,必然的需要使用各种设计模式以及架构原则对系统进行抽象提取。但反过来说对一个add()方法中的a+b直接进行抽取,把符号运算与加数和被加数都进行抽象(实际上正交设计正是如此),不是说这种设计方式不可以,但是如果对于当前可预知的内容外做太多额外的逻辑设计的话,不免有过度设计之嫌。
过度设计的问题在于:通过经验或者参考过往方案进行的提前设计,如果预期未能兑现,则会造成额外的成本损失。
所以,在一小节中一次的支付需求设计的流程并无问题。简单的问题应该简单设计,复杂的问题再进行复杂抽象。设计本身没有问题,那么问题来自后续的迭代。
先说一个显而易见的结论:我们应该随着程序业务逻辑变得复杂时逐步地调整程序结构,让其从简单程序结果变成复杂程序结构。
但实际上这个并不这么容易实现,就如同一开始的支付逻辑一样。因为在实际业务中没有一个明确的边界告诉你:你的软件已经足够复杂了,需要调整程序结构了。那么在各种工期时间的安排下,人们自然而然地就更倾向于在原有简单结构的代码基础上进行业务逻辑调整。而这样后的后果就是:当发现程序已经足够复杂的时候却发现为时已晚。
这个时候我们就可以发现,软件退化的根源并不是开头说的:需求变更。需求变更只是表象的诱因,而根据上文我们也可以发现,软件退化的根源是:
在业务逻辑变得复杂的同时,没有根据业务重新调整程序结构。
所以,解决软件退化也就呼之欲出:
要保持软件设计质量不退化,必须要在每次需求变更的时候,根据变更点调整原有程序的设计结构。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。