精华内容
下载资源
问答
  • 吐槽代码可维护性

    2017-12-20 02:02:12
    吐槽代码可维护性写代码的时候要给维护留条后路,你可能永远不会想到或许有一天一个维护你代码的暴力偏执狂提着斧头找上你家门。不是开玩笑的!我这会正在磨斧头。python语言因为弃掉了大括号,以缩进安排语句块,...

    吐槽代码可维护性

    写代码的时候要给维护留条后路,你可能永远不会想到或许有一天一个维护你代码的暴力偏执狂提着斧头找上你家门。不是开玩笑的!我这会正在磨斧头。

    python语言因为弃掉了大括号,以缩进安排语句块,所以写出来的代码看着整洁、清晰。故从理论上来说,python代码的可维护性应该很好。

    但是,事在人为。永远不要低估程序员的创造力以及离经叛道,事实上,他们任何事都能做出来。

    乱七八糟的python代码和乱七八糟的C++、Perl、Java等一样难以维护,不要因为用的是python就有优越感。好的代码风格都略同,同样,糟糕的编码风格都一样平庸。所以整洁代码之道任重道远,从来没有免费的午餐!

    因此,面对这样一团乱糟糟的东西,我们该怎么办?因为难以理解而辞职?还是在Twitter和日常日狗(Daily WTF)上当个键盘侠骂娘?到底该怎么办?有什么东西能拯救我这颗伤痕累累的心?

    唯一解决途径:从我做起,从现在做起,编写具有良好风格的代码。什么样的风格算是良好的,这个自古没有定论,各种语言之间也千差万别。

    因为代码风格而在Google和Stack Overflow上发起的各派混战自程序诞生之日起就没消停过,而且往往敌友难分,甚至恶语相向,论素质,不分中外,不论今古,各在伯仲。

    但无论哪种风格,代码的最终目的是既要能运行还要可维护即让维护者轻易看明白到底干了个啥事。

    为了能让维护者明白,我们可能给代码编写大量的注释文档,详尽的单元测试,并且每天保持review代码至少3遍,但是无论如何,要记住一句—代码为王

    虽然你以记叙文或议论文的方式编写了大量注释文档,但你的代码真的是按这个思路走的吗?你遵循了良好代码的设计理念了吗?

    对于良好风格的代码,即使有错误,也很容易找到bug点。好风格代码大大减轻了自己和读者的认知负担。

    一旦你get到了一门语言的编程风格,你将会把大部分时间花在理解代码能干什么上而不是纠结于“等等,为什么这家伙要在函数返回时用一个namedtuple而不是tuple

    如果你真正理解了该门语言的编程风格,那么,阅读道友的代码那就跟看小说一般,这就是所谓的志趣相投吧。

    第一重境界,逐行浏览,为作者所使用的一些奇技淫巧而赞不绝口。

    第二重境界,一目一个函数,视野在调用关系上,一眼看穿原作者写这些个小玩意的用意和目的,比如“嗯,对,打开一个文件,对文件内容做一个查重处理然后保存到一个sorted list里,最后以线程安全的方式生成一个giant report”。

    第三重境界,浏览一遍代码就知道bug藏在哪怎么fix,哪里需要优化以及N多种优化方案。

    当你达到第二重时,就可以下山维护一方和平了;如果达到了第三重,那就是华山之巅把剑论,武林道上话盟主之日了。

    最后,python之禅要铭记在心,时时揣摩,昼夜参悟,达到融会贯通,最终无招胜有招。(可通过python 彩蛋import this打印出禅意。)

    PEP 20 – The Zen of Python
    by python的先驱、python之父Guido van Rossum的忠诚追随者、将为人民服务(BDFL’s guiding principles)牢记在心的Tim Peters

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren’t special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one– and preferably only one –obvious way to do it.
    Although that way may not be obvious at first unless you’re Dutch.
    Now is better than never.
    Although never is often better than right now.
    If the implementation is hard to explain, it’s a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea – let’s do more of those!

    汉语翻译过来:

    优美胜于丑陋(Python以编写优美的代码为目标)
    明了胜于晦涩(优美的代码应当是明了的,命名规范,风格相似)
    简洁胜于复杂(优美的代码应当是简洁的,不要有复杂的内部实现)
    复杂胜于凌乱(如果复杂不可避免,那代码间也不能有难懂的关系,要保持接口简洁)
    扁平胜于嵌套(优美的代码应当是扁平的,不能有太多的嵌套)
    稀疏胜于拥挤(优美的代码有适当的间隔,不要奢望一行代码解决问题)
    可读性很重要(优美的代码是可读的)
    即便假借特例的实用性之名,也不可违背这些规则(这些规则至高无上)
    不要包容所有错误,除非你确定需要这样做(精准地捕获异常,不写except:pass风格的代码)
    当模棱两可时,不要尝试去猜测
    而是尽量找一种,最好是唯一一种明显的解决方案(如果不确定,就用穷举法)
    虽然这并不容易,因为你不是 Python 之父(这里的Dutch是指Guido)
    做也许好过不做,但不假思索就动手还不如不做(动手之前要细思量)
    如果你无法向人描述你的方案,那肯定不是一个好方案;反之亦然(方案测评标准)
    命名空间是一种绝妙的理念,我们应当多加利用(倡导与号召)

    最后奉上开山祖师Guido van Rossum的一字箴言:life is short , you need Python。(人生苦短,请用python—鲁迅翻译)。

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    (内容同步更新到微信公众号python数学物理,微信号python_math_physics

    这里写图片描述

    展开全文
  • 为什么需要提高代码的可维护性 ...如何提高代码可维护性 ​ 开发之前建模 ​ 写代码之前最好建模,把整个业务流程清晰在图形当中展示,以便自己加深对业务的理解同时对整个业务代码的掌控。 ​ 合理的归...

    为什么需要提高代码的可维护性

    ​ 因为在平时开发项目过程中,因为项目工期紧、需求变化频繁等等原因,然后导致代码混乱、service臃肿,最后导致维护成本高维护人员怨声载道,最坏结果可能需要重构。

    如何提高代码可维护性

    • 开发之前建模

      ​ 写代码之前最好建模,把整个业务流程清晰在图形当中展示,以便自己加深对业务的理解同时对整个业务代码的掌控。

    • 合理的归类

      ​ 为什么需要合理的归类,大多数我们都只开发entity,dao,service,controller等四层,那么这样会随着项目不断的迭代导致类太臃肿。

      ​ 那么我们就需要在这四层的基础上再丰富一些。

      ​ 例如:

      ​ 1.加入job任务包

      ​ 2.加入utils工具类包

      ​ 3.加入handler处理器

      ​ 以上归类只是给大家提供一点思路,具体业务场景还需分析。其实这些在一些优秀的开源项目当中都有体现。大家只需要看看学习理解,然后照搬过来即可。这也是为什么需要看源码的原因,个人觉得看源码不紧紧是熟悉整个执行过程有助于排查问题过程。更重要的是学习里面的设计思路。

    • 合理的引入一些设计模式

      ​ 设计模式是老生常谈的话题了,面试当中也会问。那么问题来了在什么时候引入设计模式呢?

      ​ 举个例子:

      ​ 假设我们在开发一个订单功能,此时需要创建一个订单,创建好订单后需要给用户发送短信啊一系列操作。

      ​ 常规开发可能就是在一个方法里面或者在一个service里面拆几个小方法搞定了。

      ​ 其实在这个场景我推荐大家使用事件机制也就是观察者模式去实现,为什么?本身客户端是发起创建订单的操作,发送短信的等操作其实在这个时候和订单没关系,是在产生订单后的操作。如果大家有用spring,那么可以借用spring已经实现的来实现。

      @Service
      public class PaymentOrderServiceImpl implements PaymentOrderService {
          
          @Autowired
          private ApplicationEventPublisher applicationEventPublisher;
       
          public PaymentOrder createOrder(PaymentOrder paymentOrder){
              //完成创建订单后发起事件
              applicationEventPublisher.publishEvent(new PaymentOrderEvent(paymentOrder));
              return paymentOrder;
          }
      }
      复制代码

      ​ 根据上面的代码,我们只需要自行实现监听器,然后就可以完成创建订单后的业务操作。这样就达到了一个解耦的效果。会不会更好?

    展开全文
  • 当软件项目进入“维护模式”时,原本的代码可读性与编码标准往往很难得到保证。(当然,这些标准在软件项目建立之初就不...保护项目未来可维护性的一种理想方式,在于利用外部库检查您的代码运行状况。以下是目前开...

    当软件项目进入“维护模式”时,原本的代码可读性与编码标准往往很难得到保证。(当然,这些标准在软件项目建立之初就不容易坚持实施。)但必须强调的是,在代码库中保持样式与测试标准的一致性,正是降低维护负担的重要前提。只有这样,我们才能确保未来的开发人员得以快速了解新的情况,并随着时间推移切实保证项目与应用程序的健康状况。

    保护项目未来可维护性的一种理想方式,在于利用外部库检查您的代码运行状况。以下是目前开发人员最喜爱的的代码梳理库,它们能够以强制方式执行一致性样式,并确保项目在成熟之后仍具备可接受的测试覆盖率。

    检查您的代码样式

    PEP 8是一套Python代码样式指南,其为行长度、缩进、多行表达式以及命名约定等内容提供重要的执行规则。当然,您的团队也许拥有自己的样式规则,且其与PEP 8略有不同。

    凭借代码样式指南都拥有同样的目标——在代码库中强制实施一致的标准,从而使其更具可读性并降低维护难度。在这方面,以下三套库能够帮助大家高效改善代码质量。

    1. Pylint

    Pylint 是一套用于检查PEP 8样式违规与常见错误的库。它能够与多种高人气编辑器及IDE良好集成,亦可通过命令行加以运行。

    您可以运行pip install pylint命令以进行安装。

    要通过命令行使用Pylint,您需要运行 pylint [options] path/to/dir or pylint [options] path/to/module.py。Pylint将向控制台输出关于样式违规以及其他错误警告。

    大家也可以利用 pylintrc配置文件自定义Pylint的错误检查。

    2. Flake8

    Flake8是一款“Python工具,可将PEP 8、Pyflakes(类似于Pylint)、McCabe(代码复杂性检查器)以及其他第三方插件加以结合,用以检查Python代码中的样式与质量。”

    要使用Flake8,您需要运行 pip install flake8。而后,运行flake8 [options] path/to/dir or flake8 [options] path/to/module.py 查看相关错误与警告信息。

    与Pylint类似,Flake8也允许用户对配置文件的检查内容进行自定义,其中包含非常清晰的文档,例如一些实用的commit hook,用以自动检查开发流程中的代码片段。

    Flake8能够集成各类流行编辑器与IDE,但文档当中通常并未提及相关指令。要将Flake8与您喜爱的编辑器或IDE进行集成,请在线搜索相关插件(例如 Flake8 plugin for Sublime Text)。

    3. Isort

    Isort是一套库,能够按字母顺序对您的导入内容进行排序并将其拆分为适当部分(例如标准库导入、第三方库导入、来自您自有项目的导入等)。这将提升代码可读性并在模块中包含大量导入内容时降低查找难度。

    要安装isort,您需要运行 pip install isort,而后使用 isort path/to/module.py命令加以运行。关于更多配置选项,请参阅 说明文档。例如,您可以通过isort.cfg文件配置isort如何处理来自某套库的多行导入代码。

    与Falke8及Pylint一样,isort同时提供多款插件以集成各类流行编辑器及IDE。

    代码样式外包

    需要强调的是,在命令行中手动为需要变更的各个文件进行代码梳理是一项痛苦的工作,大家也可能并不喜欢特定插件在IDE中的运行方式。

    此外,您的同事可能更倾向于利用不同的插件或者干脆不配合任何插件使用自己喜爱的编辑器; 或者您自己可能不想投入太多心力进行代码梳理并根据警告内容做出调整。随着时间的推移,这一切都可能令您的共享代码库变得混乱且难以阅读。

    在这方面,一大理想解决方案是利用库自动对代码进行重新格式化,从而直接为您传递PEP 8内容。这里我们推荐的三套库都拥有不同级别的自定义能力,亦会以不同的默认方式进行代码格式化。

    这些默认方式各有优劣,因此大家可能需要像使用Pylint以及Flake8那样对其进行测试,看看哪些能够提供最有效的自定义选项,又有哪些不可更改的默认值比较符合您的要求。

    4. Autopep8

    Autopep8 能够自动对您指定的模块内的代码进行格式化。它会进行重新缩进、修复缩进、删除不必要的空格,同时重构常见的比较错误(例如布尔值与None)。感兴趣的朋友可以点击此处查看其文档中的完整更正列表。

    要安装Autopep8,您需要运行pip install --upgrade autopep8。要对代码进行重新格式化,需要运行autopep8 --in-place --aggressive --aggressive 。其中的aggressive标记(及其数量)表示您希望在代码样式上为autopep8提供多少控制权空间。您可以点击此处了解关于aggressive选项的更多细节信息。

    5. Yapf

    Yapf 是另一种代码重新格式化选项,其提供自己的配置选项列表。与autopep8不同,yapf不仅能够解决PEP 8违规问题,同时亦会重新格式化那些并不违反特定PEP 8规则的代码——包括不符合样式一致性或者存在其他可读性问题的部分,从而进一步提升代码可维护性。

    要安装yapf,您需要运行 pip install yapf。要对代码进行重新格式化,需要运行 yapf [options] path/to/dir 或者yapf [options] path/to/module.py。您可以点击此处查看自定义选项的完整列表。

    6. Black

    Black在代码重新格式化领域可谓后起之秀。它与autopep8以及Yapf颇为相似,但又有着自己的特点。重点在于,Black提供的自定义选项非常有限。换言之,其基本思路是用户不应对代码样式做出决定,而应将决定权交给Black。当然,大家也可以查看有限的自定义选项,并将其存储在配置文件当中。

    Black要求配合Python 3.6+使用,但亦可对Python 2代码进行格式化。要使用Black,您需要运行 pip install black。要对代码进行格式化,您需要运行: black path/to/dir 或者 black path/to/module.py。

    检查测试覆盖率

    在编写测试的过程中,大家需要确保其能够对代码库中的新代码进行测试,同时不致降低您的测试覆盖率。尽管测试覆盖率百分比并非衡量测试有效性与充分性的惟一指标,但其无疑是确保项目遵循基本测试标准的重要方法之一。为了衡量测试覆盖率,我们向您推荐Coverage。

    7. Coverage

    Coverage拥有多个选项,可用于向您报告测试覆盖率,具体包括将结果输出至控制台或HTML页面,并指示哪些行号存在测试覆盖缺失。您可以设置配置文件以自定义Coverage的检查内容,并降低其运行难度。

    要安装Coverage,您需要运行pip install coverage。要运行程序并查看其输出结果,需要运行 coverage run [path/to/module.py] [args],而后查看程序的输出结果即可。要获取哪些代码行未被测试覆盖,需要运行 coverage report -m。

    持续集成工具

    持续集成(简称CI)是您可以运行的一系列流程,用于在代码合并与部署之前自动检查梳理错误并给出测试覆盖率的最小值。目前有多种免费或付费工具能够自动完成上述目标,这里我们就不一一赘述了。不过考虑到持续集成是实现代码可读性与可维护性的重要环节,这里向大家推荐两种一般性持续集成工具:Travis CI 与 Jenkins。

    原文标题:7 Python libraries for more maintainable code,作者:Jeff Triplett

    展开全文
  • 代码可维护性的神秘面纱 http://www.csdn.net/article/2013-10-17/2817206-myth-of-maintainability
    展开全文
  • 我们写的代码程序,是基于具体的环境运行的,每一个主机环境是不一样的,因此为了提高代码的灵活度和高维护性,需要将固定的代码(硬代码)写为灵活的代码。 比如javaweb中的虚拟目录不要写死,因为一旦更换环境,且...
  • 在最近的编程实践中由闭包的使用引起了我对javascript代码可维护性的思考。面向对象的其中一个特性封装性通过封装可以降低类与类之间或模块与模块之间耦合性从而使我们的设计更加高内聚低耦合,在大规模的程序开发中...
  • 一个哲人说过:世界上没有不存在bug的软件,唯一一个从来没被修改的软件的作者已经死了,...在编写代码的时候,你要经常想着,那个最终维护代码的人可能将是一个有严重暴力倾向的疯子,并且他还知道你住在哪里。 ...
  • 所谓软件的可维护性其实说简单了就是软件代码的可被修改的容易程度。为了适应新环境、满足新需求,只有对当初的设计初衷进行修改;在这个修改过程里,只有考虑到提高代码可维护性,才能更好适应软件演化。 每一次...
  • 代码存在复写,或无用代码(无用变量),造成代码越来越多,且为需求做项目,没有考虑可维护性,最后难以维护。不断添加补丁。及时代码走读,及时发现问题解决问题。 转载于:https://blog.51cto.com/...
  • 当软件项目进入“维护模式”时,原本的代码可读性与编码标准往往很难得到保证。(当然,这些标准在软件项目建立之初就不容易坚持...保护项目未来可维护性的一种理想方式,在于利用外部库检查您的代码运行状况。以...
  • 保护项目未来可维护性的一种理想方式,在于利用外部库检查您的代码运行状况。以下是目前开发人员最喜爱的的代码梳理库,它们能够以强制方式执行一致性样式,并确保项目在成熟之后仍具备可接受的测试覆盖率。当软件...
  • “提高代码设计能力和增强代码可维护性” 因为UML可以应用在软件开发的全过程当中,但是显然对于美团这样的敏捷开发类的项目开发过程不太适用,所以我希望能够控制学习范围,使他聚焦于代码,发挥图表语言易于...
  • 学习 | Python之简介&安装&第一个Python程序学习 | Python之数据结构和流程语句学习 | Python之函数——实现代码抽象的利器学习|Python之高级特性:如何写出少而有效的代码学习|Python之高抽象的编程范式(1)—高阶...
  • 它是用组合关系代替继承关系来实现,从而降低了抽象和实现这两个变维度的耦合度。 装饰(Decorator)模式:动态的给对象增加一些职责,即增加其额外的功能。 外观(Facade)模式:为多个复杂的子系统提供一个...
  • 为了赶进度,拼命写代码,忽视了代码的注释和打印代码,结果为后面维护照成了很大的困难。 痛定思痛,补上所有注释和打印信息。算是亡羊补牢,尤未晚也。 开始写代码的时候,想的是业务应该不会太复杂,规模不会太大...
  • 代码维护手段有很多种,有单步,消息跟踪,栈打印,下面重点讲讲日志打印。 网上看到Python的八荣八耻如下: 以动手实践为荣 , 以只看不练为耻;以打印日志为荣 , 以单步跟踪为耻;以空格缩进为荣 , 以制表缩进为耻;以...
  • 本文是关于提高前端代码可维护性的一些基础方案,里面掺杂着一些个人理解,有不对的地方欢迎大家指正,我会及时进行修改。 1. 统一风格(Eslint) Eslint 的好处: • 降低低级 bug(例如拼写问题)出现的概率; • ...
  • 代码可扩展性,可维护性 除非您的问题域包括对高度优化的代码的某些特定需求,否则请考虑最大的编码优先级。 我建议您使它具有可维护性 。 最近有一个在线模因建议您应该进行编码,就好像维护您代码的人是知道您的...
  • 代码可维护性

    2015-10-28 15:35:00
    代码可维护性 转载于:https://www.cnblogs.com/cooking/p/4917513.html
  • 什么是可维护性代码 今天我们不聊性能优化,只是从后期维护代码的角度谈谈如何优雅的书写代码 为什么需要些可维护性高的代码 ? 在开发的过程中,迭代和维护是再正常不过的操作了 那么就必然要阅读别人的代码 你...
  • 代码质量规范,编写可维护性可拓展性高性能代码
  • 可维护的设计模式主要分为三种,分别为:创造模式(前三个)、结构化模式和行为化模式。接下来我们将围绕这三种模式分别进行详细讲解:1.创造模式(Creational pattern):1. 工厂方法模式(Factory Method ...
  • 做好代码规范、提高代码质量,能显著增强代码的可读性、可维护性和可变更性。努力提高代码的读写可维护性,是做好代码规范的必要非充分条件。代码规范和架构设计是软件的灵魂所在,代码质量偏低,就像是人失去了三...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 16,101
精华内容 6,440
关键字:

代码可维护性