作者 | Joydip Kanjilal
编译 | 王瑞平
意大利面是一种很好吃的食物,但是,如果用它来形容代码意味着这种程序很糟糕。
“意大利面条式代码”是一个术语,用于描述组织不良、纠缠不清或嵌套复杂的代码。这些代码非常难以理解、更新、扩展和维护,缺乏适当组织,具有复杂或令人费解的控制流。这违反了软件设计原则。
无论你的代码如何天衣无缝,混乱代码都将或多或少地潜入你应用程序的源代码中。最终,你的代码将变得难以阅读、难以处理,从而难以添加新的功能、无法修复错误和维护代码库。
那么,你的C#程序中为什么会出现混乱代码呢?这通常由以下原因导致:
1.未能遵循正确的方法和原则编写代码
2.编写代码时没有组织代码的计划
3.使用借来的代码
4.使用没有经验的开发人员编写的代码
从项目迭代到后期,往往会变得很混乱,只有少数人能知道某段代码的作用和该如何去改,或者是干脆谁都不知道,只能靠通过注释去猜测这段代码可能的作用。
因为团队内部人员变动导致撰写代码的人不再管理这段代码了。我们称这类代码为“祖传代码”,没人懂也没人敢动。祖传代码一多,开发人员再想迭代就难上加难,形成可怕的恶性循环。
混乱和无组织代码会给C#程序员带来麻烦,现在列举出来,看看你是否曾经遇到过这些情况:
·首先,它会为开发人员带来难以修复的bug或导致无法向程序中添加新的功能,还会导致试图更改C#代码的团队成员困惑不解。
·其次,由于算法效率低下或缺乏优化,混乱代码可能会导致应用程序性能降低、响应时间变慢、内存消耗增加,影响用户体验。
·最后就是安全问题,混乱代码中可能暗藏被黑客利用的漏洞。
如果你的程序中出现了混乱代码,需要付出昂贵的成本修复。幸运的是,这些情况都是可以避免的。在文章的下半部分,我们将提供10个最佳方法,用来避免C#语言中出现混乱代码并保持程序整洁、组织良好和可维护。
你需要遵循以下10种方法确保你的C#语言中代码干净、精简和易于维护。
您应该在C#语言的类和对象中封装数据和行为,并遵循“面向对象编程(OOP)”原则,如,继承、组合和多态性来创建模块化、可管理和有组织的代码。
首先来介绍下什么是SOLID和DRY原则:
(1)SRP(Single Responsibility Principle)单一职责
一个类或模块只负责完成一个功能。
(2)OCP(Open Closed Principle)开闭原则
(模块、类、方法)对拓展开放,对修改关闭
(3)LSP(Liskov Substitution Principle)里氏替换
子类对象能够替换程序中父类对象出现的任何地方,并保证原来程序的逻辑行为不变及正确性不被破坏。
(4)ISO(Interface Segregation Principle)接口隔离
客户端(接口调用者)不应该被强迫依赖它不需要的接口。
(5)DIP(Dependency Inversion Principle)依赖倒置/依赖反转
高层模块不依赖低层模块,它们共同依赖同一个抽象,抽象不要依赖具体实现细节,具体实现细节依赖抽象。
不要开发重复代码,可以复用或提取公共代码,同时,也要注意遵守“单一职责”和“接口隔离”原则。
总之,构建遵循“SOLID和DRY”原则的软件可以将出现混乱代码的相关风险降至最低。
·这里特殊说明下,根据“单一职责原则”(五个SOLID原则之一),每类程序或方法只需要具备一个职责。例如,应用程序中的Logger类代码只需要负责记录数据,而不应该包含其它功能。
·当具有复杂功能的程序被分解成更小、更集中的组件时,就更容易理解和维护它们。“DRY原则”可以将公共函数抽象为可重复使用的方法、类和库,从而减少出现重复的代码。
将复杂的任务分解为可管理的步骤,可以使你的代码更易于阅读和理解。这也减少了代码的冗余并提高了代码的可维护性。
通过遵守编码标准和风格指南有利于让你的代码库保持整齐,确保变量、类、方法和其它元素都能匹配上有意义的描述性名称。这些名称使你的代码更容易理解,从而减少注释并使维护代码变得更容易。
“圈复杂度”用来确定源代码中线性独立路径数量,可以帮助你理解代码复杂性。过多的if-else语句和深度嵌套使代码难以理解并增加了圈复杂度。你可以通过重构代码减少嵌套级别并简化分支逻辑。
6代码中应该包含注释,用来解释类、接口、方法和属性出现的目的,使代码更容易管理、维护和调试。但是,文档需要更加清晰。清晰的名称和更简单的代码(即,圈复杂度更低的代码)使代码更容易理解,并不一定需要出现太多的注释。
删除代码冗余或重复,简化复杂的代码片段,并通过定期重构提高代码质量。通过改进代码的设计和结构,重构使代码库随着时间的推移更容易维护。
KISS原则是英语Keep It Simple的缩写,也有人称“懒人原则”,是指在设计当中应当注重简约。
你可以将KISS原则应用于编程,用来构建最简单的框架,满足用户需求并避免不必要的复杂性。当你的应用程序中包含不必要的特性和代码时,它不仅会使单元测试和代码维护变得困难,而且还会影响用户体验。
YAGNI原则的英文全称是:You AIn’t Gonna Need It。直译就是:你不会需要它。当用在软件开发中的时候,它的意思是:不要去设计当前用不到的功能,不要去编写当前用不到的代码。
类似的,你可以遵循YAGNI原则清除不重要的功能和代码。你应该只关注需要的功能,避免为追求完美而给代码“镀金”。
你应该在软件开发工作流程中充分利用单元测试工具,减少应用程序中的错误。单元测试有助于确保代码单元按照预期运行。如果你已经更改或重构了代码,应该再次运行单元测试功能,用来确保一切工作正常进行。
进行代码审查可以让你深入了解代码并获得反馈。同行评审代码使你和团队成员有机会识别混乱代码并收集改进建议。同行评审可以帮助你的团队避免编写混乱代码并付诸实践。
总之,混乱代码错综复杂,就像一盘纠缠在一起的面条。如果你要清理它,最好从小处开始并不断改进代码。通过遵循本文中概述的10个指导方针,你可以避免应用程序中出现混乱代码,并为团队成员节省大量时间、精力和避免麻烦。
https://www.infoworld.com/article/3699709/how-to-avoid-spaghetti-code-in-c-sharp.html