专业做政法ppt的网站,信息系统推广方案,如何修改wordpress首页,郫县城乡规划建设管理局网站这些年写了很多的代码、也读过很多的人写的代码#xff0c;这几年#xff0c;写代码的机会越来越少#xff0c;但是每次写代码#xff0c;感觉需要思考的东西越来越多#xff0c;好的代码确实难能可贵#xff0c;在国内业界中#xff0c;好的软件不少#xff0c;但是好… 这些年写了很多的代码、也读过很多的人写的代码这几年写代码的机会越来越少但是每次写代码感觉需要思考的东西越来越多好的代码确实难能可贵在国内业界中好的软件不少但是好的代码确实有点凤毛麟角了写得出来的人不多有追求的也不多看到的好的代码越来越少。可能是因为每个人对于好的评判标准不一程序员中也不乏文人相轻的较劲总觉得比人写的代码都不够好我不想介入这些无谓的争论这篇文章中我将结合我的编码经验探讨一下如何写出设计优良的代码希望作为大家的参考。好的代码首先是逻辑正确的如何用编程语言表述正确的代码逻辑这个问题好像很少有人单独拎出来讲因为这个问题的答案很简单简单得你都懒得去思考它因为你肯定觉得用编程语言正确的表述代码逻辑无非就是if 、while 之类的东西有什么好探讨的其实我要分享的并不是这些关键词的本身在逻辑中表达的含义而是这些关键词的背后编写程序的过程中是否真的认真思考过背后的逻辑。我曾不止一次遇到有多年编程经验的程序员犯下类似的错误也见过很多年轻的同学反复强调纠正后逻辑上还是会漏洞百出这几年我会经常组织我组里面的同学对代码进行走读总结这些编码中的逻辑错误很大一部分也是因为编程逻辑背后的思考是不够的。所以我要讲的是很简单的知识但是往往是最容易忽略的思考点。我先给大家看一个例子这段代码为的目的是判断userInfo不为空串的时候couponing看起来这段代码非常简单判断上似乎还算比较严谨其实这段代码只是看到了眼前要做的事情但是并没有看到整体逻辑为什么这么说呢请看下面几行代码也许会引发最这个简单问题新的思考。这段代码虽说相比之前的代码长了一些但是反映出来的是逻辑思考的严谨性从这两个例子比较我们可以很明显的感觉到第一段代码的问题我们看到的只是为了保护是否能做couponing的条件但是并没有去思考条件不满足的时候如何去做是否有能力去恢复这个错误确实无法恢复的时候我们是否还要在错误的道路上越错越远呢这一点非常重要也很容易忽略需要在编码的过程中进行完整的思考才会意识到这个问题的如果让错误继续执行下去直到程序运行到下一个我们不期望的点如果下一个不期望的点,代码上也遵循这个风格简单的判断不为null就跳过执行这样下去就会有无穷的隐患代码整体上看上去就漏洞百出了。所以从这里要给大家一个建议【要有一颗勇敢的心程序不要害怕抛出错误越害怕错误越多】我们应该都知道错误越是早发现越好处理其实程序在执行过程中也是一样的越早发现错误执行中就越容易处理。我一般称这种代码为代码的盲目容错看上去这行代码很健壮不会报错但是不报错不能影响错误的客观存在性错会还是会存在的遇到错误的时候我们应该首先想到的是恢复这个错误对容错问题是需要进行非常深入很全局的思考才能做的决定盲目的容错只会让情况变得更加不可控制。【千万不要忘记else的思考】每当你要用到一个条件表达式的时候切记要思考这个条件不成立的情况。 尽可能的不要出现只有if 没有else的情况多组条件用 else if 连接使用最后再加一个else去做大兜底。 其他的条件表达式类似比如switch case 最后总有一个值得我们深思default。严谨的代码其实就提现在else上面的思考。容易造成思考不足的条件语句【条件有两面性思考要完整】有效降低逻辑的复杂度上一节的例子中肯定会有人觉得这样写代码是不是觉得太复杂了已经思考了这些问题一定要用这么复杂的方式表达出来吗这是另外一方面的问题我们要让代码逻辑变得简单这一节中我尝试分享一些我如何降低代码复杂度的方法和经验。还是用上面的例子我尝试将代码变得更加简单请看下面的代码是不是感觉舒服很多。这段代码中表达了上面所有的逻辑而且没有引入分支其实这里我想强调的是【减少分支就是降低复杂度】我一般的编码思想是尽可能的不要用分支处理异常也不要因为异常引入分支分支的使用场景最好是业务逻辑所需要的应该用分支尽可能的表达清楚业务逻辑而尽量不要用分支去适应异常的处理。这里进一步又引入了一个被忽略的尝试。【不要混淆分支和异常的概念】这一点看起来很难做到但是根据我的实际经验我们是有办法做到的通过优雅的定义和处理异常是可以比较容易的明确异常和业务分支的区别的。不过在本味中我还是希望能将减少分之的方法说清楚关于如何优雅的处理和定义异常本文先不做过多描述。我想说的是一个分支最好是能表达一层业务的含义用分支标示是分支的条件以及条件成立或不成立的时候要做的动作。所以还是基于上面的例子我们引入一个业务条件“当用户是VIP用户的时候我们才能给用户发放优惠券否则我们不发放优惠券”我们分支代码标示如下这段代码正常的表述的业务的含义注意其中的else这里else 进入之后是直接return的写上这一句就是上一节中说明的一样保证我们的代码逻辑是完整的这一句有很明确的语义就是表示条件不成立的时候我们不做如果不写的话其实这部分语义是丢失的或是不明确的。上面的代码能正常满足当前的业务需求但是业务是复杂的比如业务上我们有了新的需求需要对发放优惠券的规则进行调整调整会后的规则为增加白名单可以不是VIP也要发优惠券或者这个用户的用户UID是以00结尾所以这时候我们条件代码成了下面这个样子这段代码中我们逻辑一下就变得复杂了虽说我们只用了一个if else 表达式但是这里的分支复杂度其实是2的3次方但是我们处理的情况就是两种一种是成立一种是不成立所以我们更加关心的是成立或是不成立的情况而不是所有条件的组合形式通过观察我们发现所有的逻辑都是由“或”进行连接根据这个特性其实我们可以提炼出逻辑工具方法更好的表达我们更加关系的成立或不成立的条件。我们提取一个命名为any的逻辑方法来表述刚才的逻辑这个方法接收一个不定长的参数值要有一个为真则返回为真。其他场景我们也可以自己峰值其他的逻辑方法比如all、notAll notAny。则代码修改为这段代码有效的减少了代码的分支数量注意这里仅仅是从分支数量上进行了减少增加了一点点可读性这样做的好处是多数情况下我们关注的业务分支的动作本身而对于进入这个分组形成的的组合情况做所有讨论所以这样做可以有效的降低分支的数量减少用例的个数写过单元测试的同学都知道这样的逻辑要覆盖有多痛苦。这一节中用了一个看上去有些鸡肋的方法去封装逻辑组合其实在现在日常生产中想办法去封装逻辑表达式进行封装是非常有效果的这里只是举了一个逻辑封装的例子还有很多其它场景比如从一个Map中根据一组key逐个取值如果取到值不为null则放入到另外一个Map中这里其实可以写一个putNotNull的方法来封装逻辑这种做法非常有效。所以这一节我想给大家传递的一个思想就是尽你最大的可能对逻辑表达式进行封装【减少分支数量就是减少复杂度】代码和业务解耦上一节的例子中大家可以很容易看出来不管逻辑怎么封装代码是始终不稳定的其实这里就引出了我们要强调的一个常识就是能力要和业务解耦。如何将能力和业务解耦我对这个问题的理解是首先我得把这个能力定义出来这里我暂且定义为这个能力为发优惠券其实定义一个能力是最难做的事情深的思考会发现这个问题难到需要重新思考人生我这里不拉开篇幅讲了结合这个例子大家暂且先有一个模糊的理解后面在慢慢讨论能力定义这个大的课题有了这个能力定义之后我们根据这个能力定义做一个面向能力的条件判断代码示例如下从这几行代码中可以看出这里好像已经好了很多我们将发优惠券的能力和判断条件canCouponing进行耦合看上去这段代码已经稳定了但是仔细观察后发现canCouponing这个方法中依赖了userInfo这个依赖貌似还是会存在很多问题因为如果判断条件超出了userInfo的范畴则这个地方又会变得难以解决能力判断的要素看起来还是不可控的为了解决这个问题我们就要用到运行上下文或是领域模型的概念了用一个运行时的上下文作为数据信息载体承载我们业务执行过程中所需要的模型数据领域模型的发放则是我们对系统能力和业务有了足够深入理解之后抽象出来的能更加准确表述业务属性和行为的模型定义在没有很好的理解和抽象之前本节中我们还是先用运行上下文这样相对松散的概念来解决这个问题。根据这个思想我们将代码进行修改在上面代码中让runtimeContext中包含userInfo通过一个更松散的对象来传递对象交给canCouponing这个方法处理这里也许有人会问canCouponing这个方法内部还不是一堆逻辑整体上还是控制不住复杂度。其实这类问题我们将关键的业务点从硬代码中剥离出来并且将业务逻辑集中起来进行管理的话就可以使用规则引擎来处理了。通过规则引擎和专家系统将这些规则交给业务人员或是运营人员统一进行管理就可以了而我们的功能性代码可以做到非常的干净和稳定。也许有另外的人会问为什么couponing(userInfo,100);这行代码中没有用runtimeContext而是直接使用的userInfo在实际编程中你可能真的需要用到runtimeContext但是这里的目的是让大家理解如何让业务代码和能力解耦关于能力本身这块如何更好的设计这一方面的内容也有很多值得我们思考的本文暂不做过多探讨。【思考能力的定义用代码描述能力将业务从代码中抽出来交给规则引擎或是专家系统处理】来源动力节点Java学院文章版权归原作者所有转载仅供学习使用不用于任何商业用途如有侵权请留言联系删除感谢合作。
