如何让写的代码达到开源的标准

发布时间:2022-12-04 09:00

不管工作几年能够写得一手优秀的代码那肯定是非常吃香的。怎样的代码才能够算的上优秀?业界还真没有一个评判标准,在开发人员每个阶段的代码的认知都是不一样的,跟工作经历和工作经验息息相关,每个人都有自己主观的评判标准,有可能昨天你觉得很优秀的代码今天依然看着很low;一个工作经验丰富的人看新人写的代码,心情也是各种复杂。

最近一段时间总结一些代码评判标准的一些看法,当然这也只是我自己的理解,能够更靠近标准。可以用一个公式表达:标准代码=场景+基础知识+设计原则+设计模式+注释+单元测试+工作经验;别看这只是一个简单的公式,消化起来也得花上几年的时间。

如何让写的代码达到开源的标准_第1张图片

场景化

所有的代码不可能凭空产生,首先我们要清楚前提是一个什么场景,这个场景有哪些需求,每个需求有哪些功能点;代码开始做设计的时候需要知道具体的场景,代码重构的时候也需要知道具体的场景;现实有很多这样的情况,项目的周期很长,维护项目的人一波又一波,到最后都不知道这些代码什么这么写,出现问题了也只关注局部,解决当前问题;很少考虑到源头什么去这么做,这个问题有可能引起哪些问题,如果需要重构的话有什么优化手段。

说到底就是怎么维护场景和代码的关系,通过场景知道代码实现,根据代码实现找到具体的场景;详细设计文档的作用就体现出来了;详细设计文档主要记录场景说明,前置步骤、触发条件,时序图、类图、接口输入输出;那这样又会带来一个问题,谁去维护详细设计文档维护文档是一个比较索而无味的事情,一些程序员宁愿写代码也不愿意写文档,所以还是需要有负责人去维护。

基础知识

代码基础知识是一个程序员的基石,不用多说,大家都懂;但是还是需要时常去回顾一下,以前学习的时候是学怎么用?而现在我们需要考虑的是为什么需要这样用!能给我们带来什么好处,用这些基础知识能解决那些问题。一般场景的就是封装、集成、抽象、多态、面向对象、面向接口的知识。

设计原则

设计原则可以说是比较实在的东西的,可以作为一种代码设计和评审的重要依据;一些叫有规模的项目在设计的时候都会去遵循这一套设计原则,那我们常说的设计原则有哪些呢?SOLID原则

  • SRP: Single Responsibility Principle,一个类或者模块只负责完成一个职责;

  • OCP:Open Closed Principle,软件实体(模块、类、方法等)应该“对扩展开发,对修改关闭”;

  • LSP:Liskov Substitution Principle,子对象能够替换程序中父类对象出现的任何地方,并且保证原来的程序逻辑行为不变及正确性不被破坏;

  • ISP: Interface Segregation Principle,客户端应该不强迫依赖它不需要的接口;

  • DIP:Dependency Inversion Principle,高层模块不要依赖底层模块,高层模块和底层模块之间应该通过抽象来相互依赖,除此之外,抽象不要依赖具体的实现细节,具体实现细节依赖抽象。

ItVuer - 免责声明 - 关于我们 - 联系我们

本网站信息来源于互联网,如有侵权请联系:561261067@qq.com

桂ICP备16001015号