【编者按】软件设计构造师Karan Goel在看到“joe”疯狂的成功之后,为我们总结了7个可以使软件寿命更长的规则,这其中包括:模块化、测试、持续集成、自动化等等。他表示遵循的规则越多,你软件的寿命就越长。下面一起来看看这些规则背后的细节。 以下为译文: 在“joe”疯狂的成功之后,我列出了一个我认为评判好坏软件的清单。尽管这使我对事物看得很清楚,然而对于任何给定的项目,很少有可以遵循这些规则的,包括我自己在内。但是你遵循的规则越多,你软件的寿命就越长。 什么让你远离编写好的代码?“快速打破事物”不是一件好事吗? 不!学习创建软件是一种技巧,任何人都能做到。而学习创建好的软件则是一种艺术,它需要时间、努力和奉献精神。 你希望世界上有更多的SEGFAULTs(段错误)吗?你希望系统管理员因为你的糟糕代码而不断的被电话骚扰吗?你希望你的PM是因为你的软件惹毛了用户而记住你吗?…… 我并不反对任何形式的快速发展,因为我相信MVP和第一时间推出的力量。但是在某些时候,当时间充裕的时,你必须要意识到低质量代码是走不远的。 当你走进医生办公室时,医生会询问你一系列问题来确定你的病因,他们不会在没诊断的情况下给你开药。 同样,知道在什么时间“写坏了”软件对你很重要。这里有些问题可以很好的帮助诊断我们是否正在编写糟糕的软件:
因此,让我们来看看本文所说的规则有哪些? 1. 模块化
虽然相比较有史以来最复杂的CPU来说,人类要更加的复杂,但是你不得不承认人类有时也会有无法解决的复杂问题,简单的来说,如果不使用任何计算器,你能告诉我13x35等于多少吗?我打赌你做不到,至少在一个合理的时间内你做不到。 但是我们擅长将复杂的问题逐步的分解为较小的我们能够解决的问题。 13x10是多少?130,13x5呢?即为130/2=65。那么130x3是多少?是390,390+65呢?455。搞定!(PS:或许你会有更简单的方法。当问题越复杂的时候,分解的优势就越显而易见。) 将同样的逻辑运用到软件当中,通过多个文件、文件夹甚至是项目来划分你的软件,将所有相关性的事物遵循MVC或其他变化规律置于一个位置。 这不仅会提高代码的可阅读性,也会让你的调试变得更加容易。在大多数情况下,堆栈跟踪会领你前往非常小的代码集,而不是成千上万行的代码文件。当更新个别模块时,你就不需要考虑整个系统。 2. 测试
我们习惯性的去把测试当作是一种不同于做软件的活动,即便是在学校,你被传授的是C++模块如何工作的,却没人教你它们是如何被测试的。在线教程会教你如何使用Brainfuck制作一个Web服务,然而它们不会告诉你如何去测试它,这就是问题所在。 有些人会告诉你,在开始写实际的应用逻辑之前,首先要做的是编写测试。 何时编写测试各有喜好,只要写了就OK。当你第一次开始的时候,不要试图成为一个测试高手,从简单粗暴开始,如print(add(1, 1) == 2),然后在逐步到测试整个框架。 当你开始测试你的代码时,你将会明白你软件的复杂性。你将开始学习如何将你的软件模块化,以便可能独立测试。所以当你遵循了这一规则的时候,你同时也在遵循第一个规则——模块化。 3. 持续集成
当你编写测试之后,你需要确保它们是合格的,同时也要确保它们在多种环境下是合格的(例如多版本的Python)。在代码作出任何改变时,你也需要测试。 当你能够手动的做这些时,你可以选择更方便、更快以及更便宜的持续集成平台。 Thoughtworks在CI上有显著的贡献,关于CI,你需要知道:
4. 自动化 有多个脚步需要运行测试和部署?将它们添加在单一的bash脚步中,减少步骤,节约时间 大的项目通常会有一些像引导代码或以不同的方式测试代码等任务,又或者部署到不同的服务器,备份部分的代码等等。 有些人会使用txt文本来存储这些命令,并在需要的时候复制粘贴。如果你是这样的,或许你应该抽个时间来学习一下bash脚本(或Python)。这里有些常见的任务,你应该用到简单的bash脚本来自动化处理它们:
5. 信息冗余
当你访问git-scm.com时你会看到这么一段话:
在这段话里,分布式是关键。 如果你把代码仅仅托管于Github的话,或许你应该需要反思了。试想一下,但凡Github有一点故障,你的工作流程将会停止。你无法预料到意外何时会出现,所以保持代码的离线备份永远都不会是一个坏注意。这种情况下信息冗余对你而言是一件好的事情。 这里提供一些代码存储的参考:
6. 提交
看看你提交的历史,你会发现类似这样的信息:
“fixed”指什么?“issue”又是什么问题?模块化有时哪个? 很多程序员多会把版本控制系统当作是一种备份,而不是维护历史的一种手段,充满这种信息的历史版本是没有用处的,除非你想去做检索文件。 如果你觉得很难去写好一个提交信息,或许可以参考以下几点:
7. 计划 制定一个计划为最坏的情况做准备,一旦真的出现问题,你该怎么做?所以在文档中详细的写下步骤。 即便遵循以上六个规则,也并不是意味着你的软件是不可战胜的。说不定由于什么或者是谁的过失,灾难就会降临。所以有一个计划是明智的,一个计划会让你看上去“很聪明”,事实也是如此。 最后 如果您并不相信这几个规则,回答以下两个问题:
如果你的回答是“No”,或许你应该再重新看一遍本文,与你的团队分享一下。 最后Happy programming!!! 本文为CSDN原创文章,点击“阅读原文”可查看全文并参与讨论。 如果您喜欢这篇文章,请点击右上角“…”将本文分享给你的朋友。 |
|