建筑公司网站电工,广州注册公司最新流程,erp是什么意思,大型网站一般用什么语言做的前言
作为一个程序员#xff0c;再职业生涯中会写很多很多万行代码。感觉学习写代码的过程很像学习写作的过程#xff0c;写大型软件就是在写一本长篇小说#xff0c;那么如何定义好的代码#xff0c;感觉就像是问说怎么写出好的文章。 那么什么是好的代码呢#xff1f;对…前言
作为一个程序员再职业生涯中会写很多很多万行代码。感觉学习写代码的过程很像学习写作的过程写大型软件就是在写一本长篇小说那么如何定义好的代码感觉就像是问说怎么写出好的文章。 那么什么是好的代码呢对于产品人员来说好的代码是只要能运行不出现bug的就是好的代码也就是所谓的说文以载道诗以言志至于辞藻是否华丽不是最重要的。 但是别忘了写代码的时间可能发现在那一刻但是我们后面阅读自己代码的却经常进行如果结构混乱词不达意那么就往往会发生写到最后发现前面的情节都不慎了之了。 所以写出好的代码的一个目的在于如何减少代码维护的成本理解代码是其中之一。 另外我们要知道没有人能够在跨度周期在几个月甚至一年的时间内知道自己软件最后会具体怎么一个呈现。业务都是不尽相同的根据排列组合我们没有办法一开始就穷尽所有的变化所以我们总是会在原有代码的基础上不断修修改改正如很多小说一样一气呵成总是发生在极少数天才那里即使是如红楼梦一样的惊世之作也是批阅十载。 所以总的来说好的代码的原则也就是两点一个是容易阅读一个是容易修改。
相关内容
有意义的命名
程序代码里面除了一些约定熟成的关键字大部分的英文字符都是被变量、函数、参数、类等构成的而这些都是我们自己所赋予的。所以容易阅读是命名最关注的东西常见的一些tips如下
不要使用误导性的词语来进行命名例如list,;,o等。在对同类型数据进行区分的时候不要使用数字来进行。可搜索也是命名关注的点无论是变量名还是文件名包名等对于强类型语言来说当前的编译环境来说不用运行就能检测出类型错误类型编码已经淘汰。成员前缀也是不必要的因为都是看有意义的字段。类名和对象名应该是短语而不应该是动词。如Customer等方法名应该是动词或动词短语。如postPayment。对于程序中经常出现的概念取一个一以贯之的词例如xx控制器可以一直用controller或者一直用manager。
函数
函数是对于程序逻辑的第一层封装因此同样也遵循易读易修改原则常见的一些tips如下
函数长度不宜过长主要是容易阅读同时函数越短功能越集中名字也更好取更容易抽象长而有描述性的名字比短名称好函数只做一件事这是出于高内聚低耦合的考虑同时也让代码更易修改一处的改动不会影响到其他部分自顶向下阅读代码这是处于易读的考虑因此在对函数进行编写的时候可以从上到下依次编写对应的抽象再紧接着对应的实现。对于多态情况下的switch使用对于对象不同行为的实现方式根据对象种类的不同会有n种 switch语句和对应的分支同时违反了单一职责原则多个修改的理由以及开闭原则添加和修改没办法解耦。解决方法可以利用工厂模式也就是对不同对象的行为定义一个统一的接口或者抽象类将switch分支封装在工厂类下。函数参数一般是0-2最好一个是处于理解成本的考虑还有一个最重要的原因是多参数对于测试代码组合带来的复杂度。 单参数一般单参数有几种情况一个是判断参数的问题一个是将参数进行转换为另一种类型还有就是事件。但是对于一种传入bool的标识参数来说这意味着在true和false的情况下都对应着不同的处理逻辑也就是函数不只是做一件事这是应该进行拆分为两个函数分开处理。双参数双参数主要是注意两个参数的相对顺序以及是否可以将两个参数转换为一个参数成员等参数列表当函数需要两个及以上的参数类型且这些组合经常出现的话就意味着这写参数可以被封装为类了这意味着对这组参数的封装。而对于可变参数类型如果超过三个那么和直接传递list类型的单个参数也没有分别所以一般是1-3命名对于单参数直接采用动名词形式就好对于双参数类型可以在命名时记录参数的相对顺序。输出参数在oop出现前存在着向函数中传递参数的时候也就是 方法名参数但是在oop后可以直接利用this来代替输出参数也就是利用 对象.防方法的形式。在异常处理的时候直接返回错误码会造成更深的嵌套结构直接 try-catch返回异常就好同时为了避免异常处理与正常流程混在一起可以把try-catch的代码块主体抽离出来另外形成函数。
对象与数据结构
数据抽象 不愿意暴露具体操作数据实现的逻辑可以利用函数进行一次封装。过程式代码数据结构代码和面向对象代码的不同在于过程式代码可以在不修改原有代码的基础上新增方法而面向对象更适用于新类型的添加。数据传送对象DTO只有公告变量没有函数的类。通常用于与数据库通信的部门。
类
类的抽象也应该符合单一职责也就是只有一个修改的理由。理想的状态是多个短小的类互相协同而不是少数巨大的类。类的内聚一方面体现在内部方法对于内部变量操作的程度操作的变量越多说明变量越黏聚在类上这将得到许多短小的类。隔离依赖主要在于怎么对容易变更的部分进行抽象提供接口等等。
系统
将系统的构造与使用分开否则如果在程序中有许多种类似的情况根据全局设置策略就会缺乏模块组织性通常也会有很多重复代码。一个方法是将全部的构造过程搬迁在main函数中进行处理 mian函数创建系统需要的对象再传递给应用程序只管使用。对于大型软件的编写来说一开始就将所有的组件和系统构造得很好是很难的我们应该只去实现今天的用户故事在后续再不断地扩展系统实现新的用户故事这也是迭代和重构。
迭进
这一部分其实主要就是说一点在代码和模块越来越多的时候也不断重构。
代码的坏味道
注释 不恰当的信息无用的重复的废弃的注释过时的注释意味着代码的跌进后注释并没有怎么改变注释掉的代码 环境 多步实现的构建 单个命令进行系统的签出需要多步才能做到的测试应该能够使用单个指令就可以运行全部的单元测试 函数 过多的参数参数0-3差不多输出参数如果函数要修改什么变量的状态直接修改它所在的对象的状态就好了布尔值参数这使用函数不止做了一件事 一般性问题 不正确的边界行为在开发的时候不要只写出能工作的函数也要考虑或证明代码在所有的边界情形下都能真正工作。重复重复的代码可能会是一个子程序或者一个类出现在概念上重复的代码意味着抽象的遗漏。在错误的抽象层级上的代码在继承关系中注意将较低层级概念放在派生类中较高层级概念放在基类中。比如说只与细节实现有关的常量变量或者工具函数不应该在基类中出现。软件设计要求分离不同层级的概念放在不同的容器中这些容器有时是基类或派生类有时是源文件模块或组件不管如何底层级概念不能和高层级概念混在一起。基类依赖派生类主要在有限状态机的实现中会出现这样的问题。位置错误的权责例如很多变量应该放在哪里的问题根据最小惊异原则变量应该放在读者期望它在的地方或者看函数名称。不恰当的静态方法静态方法不应该在单个实体上操作而更多作为一个工具函数的作用不与特定对象绑定另外对于一些需要多态实现的方法也应该使用非静态函数。函数名称应该表达其行为用多态替代if/else或者switch/case在使用switch之前先考虑使用多态。或者在case语句中创建多态对象避免对于多个方法选择上使用多个switch的情况。封装条件将关于条件判断的表达式进行封装会更容易理解避免否定性条件使用肯定性条件会更好函数应该只做一件事函数不应该只做一件事应该转换为多个更小的函数掩盖时序耦合这种情况下使用有参返回也可以。在较高层级上放置可配置数据
总结
在编写大型软件的时候我们常常对于过高的复杂度以及过高的理解成本而望而却步这直接影响了我们代码跌进的速度和效率软件开发是一个增量跌进的过程因此降低每一个环节的理解成本和减少每一个模块之间的耦合就是我们的终极目的也是一个良好的编码习惯的养成。在这个基础上去看看其他更美丽的风景吧。
