随着软件行业的不断发展,历史遗留的程序越来越多,代码的维护成本越来越大,甚至大于开发成本。而新功能的开发又常常依赖于旧代码,阅读旧代码所花费的时间几乎要大于写新功能的代码。
我前几天看了一本书,书中有这么一句话:
“复杂的代码往往都是新手所写,只有经验老道的高手才能写出简单,富有表现力的代码”
此话虽然说的有点夸张,可是也说明了经验的重要性。
我们所写的代码除了让机器执行外,还需要别人来阅读。所以我们要写:
其中2,3点更多强调的是面向对象的设计原则。而本文则更多关注于局部的代码问题,本文通过举例的方式,总结平时常犯的错误和优化方式。
本文的例子基于两个指导原则:
一.DRY(Don't repeat yourself)
此原则如此重要,简单来说是因为:
二.TED原则
三.举例说明
1.拒绝注释,用代码来阐述注释
反例:
/// <summary>
/// !@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*((
/// </summary>
/// <returns></returns>
public decimal GetCash()
{
//!@#$%^&^&*((!@#$%^&^&*((
var a = new List<decimal>() { 2m, 3m, 10m };
var b = 2;
var c = 0m;
//!@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*((
foreach (var p in a)
{
c += p*b;
}
return c;
}
重构后:
public decimal CalculateTotalCash()
{
var prices=new List<decimal>(){2m,3m,10m};
var itemCount = 2;
return prices.Sum(p => p*itemCount);
}
良好的代码命名完全可以替代注释的作用,如果你正在试图写一段注释,从某种角度来看,你正在试图写一段别人无法理解的代码。
当你无法为你的方法起一个准确的名称时,很可能你的方法不止做了一件事,违反了(Do one thing)。特别是你想在方法名中加入:And,Or,If等词时
2. 为布尔变量赋值
反例:
public bool IsAdult(int age)
{
bool isAdult;
if (age > 18)
{
isAdult = true;
}
else
{
isAdult = false;
}
return isAdult;
}
重构后:
public bool IsAdult(int age)
{
var isAdult = age > 18;
return isAdult;
}
3.双重否定的条件判断
反例:
if (!isNotRemeberMe)
{
}
重构后:
if (isRemeberMe)
{
}
不管你有没有见过这样的条件,反正我见过。见到这样的条件判断,我顿时就晕了。
4.拒绝HardCode,拒绝挖坑
反例:
if (carName == "Nissan")
{
}
重构后:
if (car == Car.Nissan)
{
}
既然咱们玩的是强类型语言,咱就用上编译器的功能,让错误发生在编译阶段
5.拒绝魔数,拒绝挖坑
反例:
if (age > 18)
{
}
重构后:
const int adultAge = 18;
if (age > adultAge)
{
}
所谓魔数(Magic number)就是一个魔法数字,读者完全弄不明白你这个数字是什么,这样的代码平时见的多了
6.复杂的条件判断
反例:
if (job.JobState == JobState.New
|| job.JobState == JobState.Submitted
|| job.JobState == JobState.Expired
|| job.JobTitle.IsNullOrWhiteSpace())
{
//....
}
重构后:
if (CanBeDeleted(job))
{
//
}
private bool CanBeDeleted(Job job)
{
var invalidJobState = job.JobState == JobState.New
|| job.JobState == JobState.Submitted
|| job.JobState == JobState.Expired;
var invalidJob = string.IsNullOrEmpty(job.JobTitle);
return invalidJobState || invalidJob;
}
有没有豁然开朗的赶脚?
7.嵌套判断
反例:
var isValid = false;
if (!string.IsNullOrEmpty(user.UserName))
{
if (!string.IsNullOrEmpty(user.Password))
{
if (!string.IsNullOrEmpty(user.Email))
{
isValid = true;
}
}
}
return isValid;
重构后:
if (string.IsNullOrEmpty(user.UserName)) return false;
if (string.IsNullOrEmpty(user.Password)) return false;
if (string.IsNullOrEmpty(user.Email)) return false;
return true;
第一种代码是受到早期的某些思想:使用一个变量来存储返回结果。事实证明,你一旦知道了结果就应该尽早返回。
8.使用前置条件
反例:
if (!string.IsNullOrEmpty(userName))
{
if (!string.IsNullOrEmpty(password))
{
//register
}
else
{
throw new ArgumentException("user password can not be empty");
}
}
else
{
throw new ArgumentException("user name can not be empty");
}
重构后:
if (string.IsNullOrEmpty(userName)) throw new ArgumentException("user name can not be empty");
if (string.IsNullOrEmpty(password)) throw new ArgumentException("user password can not be empty");
//register
重构后的风格更接近契约编程,首先要满足前置条件,否则免谈。
9.参数过多,超过3个
反例:
public void RegisterUser(string userName, string password, string email, string phone)
{
}
重构后:
public void RegisterUser(User user)
{
}
过多的参数让读者难以抓住代码的意图,同时过多的参数将会影响方法的稳定性。另外也预示着参数应该聚合为一个Model
10.方法签名中含有布尔参数
反例:
public void RegisterUser(User user, bool sendEmail)
{
}
重构后:
public void RegisterUser(User user)
{
}
public void SendEmail(User user)
{
}
布尔参数在告诉方法不止做一件事,违反了Do one thing
10.写具有表达力的代码
反例:
private string CombineTechnicalBookNameOfAuthor(List<Book> books, string author)
{
var filterBooks = new List<Book>();
foreach (var book in books)
{
if (book.Category == BookCategory.Technical && book.Author == author)
{
filterBooks.Add(book);
}
}
var name = "";
foreach (var book in filterBooks)
{
name += book.Name + "|";
}
return name;
}
重构后:
private string CombineTechnicalBookNameOfAuthor(List<Book> books, string author)
{
var combinedName = books.Where(b => b.Category == BookCategory.Technical)
.Where(b => b.Author == author)
.Select(b => b.Name)
.Aggregate((a, b) => a + "|" + b);
return combinedName;
}
相对于命令式代码,声明性代码更加具有表达力,也更简洁。这也是函数式编程为什么越来越火的原因之一。
四.关于DRY
平时大家重构代码,一个重要的思想就是DRY。我要分享一个DRY的反例:
项目在架构过程中会有各种各样的MODEL层,例如:DomainModel,ViewModel,DTO。很多时候这几个Model里的字段大部分是相同的,于是有人就会想到DRY原则,干脆直接用一种类型,省得粘贴复制,来回转换。
这个反例失败的根本原因在于:这几种Model职责各不相同,虽然大部分情况下内容会有重复,但是他们担当着各种不同的角色。
考虑这种场景: DomainModel有一个字段DateTime Birthday{get;set;},ViewModel同样具有DateTime Birthday{get;set;}。需求升级:要求界面不再显示生日,只需要显示是否成年。我们只需要在ViewModel中添加一个Bool IsAdult{get{return ....}}即可,DomainModel完全不用变化。
五.利用先进的生产工具
以vs插件中的Reshaper为例,本文列举的大部分反例,Reshaprer均能给予不同程度的提示。经过一段时间的练习,当Reshaper对你的代码给予不了任何提示的时候,你的代码会有一个明显的提高。
截图说明Reshaper的提示功能:
光标移动在波浪线处,然后Alt+Enter,Resharper 会自动对代码进行优化
如果你能够避免本文总结的反例,你的代码就已经具备了优秀代码应有的基因。当然高质量的代码还需要良好的设计和遵循面向对象编程的原则。 如果想了解更多相关内容,请阅读《代码大全》,《代码整洁之道》,《重构 改善既有代码的设计》,《敏捷软件开发 原则、模式与实践》
你遇到过性能很差的网页吗?
这种网页响应非常缓慢,占用大量的CPU和内存,浏览起来常常有卡顿,页面的动画效果也不流畅。
你会有什么反应?我猜想,大多数用户会关闭这个页面,改为访问其他网站。作为一个开发者,肯定不愿意看到这种情况,那么怎样才能提高性能呢?
本文将详细介绍性能问题的出现原因,以及解决方法。
要理解网页性能为什么不好,就要了解网页是怎么生成的。
网页的生成过程,大致可以分成五步。
这五步里面,第一步到第三步都非常快,耗时的是第四步和第五步。
"生成布局"(flow)和"绘制"(paint)这两步,合称为"渲染"(render)。
网页生成的时候,至少会渲染一次。用户访问的过程中,还会不断重新渲染。
以下三种情况,会导致网页重新渲染。
重新渲染,就需要重新生成布局和重新绘制。前者叫做"重排"(reflow),后者叫做"重绘"(repaint)。
需要注意的是,"重绘"不一定需要"重排",比如改变某个网页元素的颜色,就只会触发"重绘",不会触发"重排",因为布局没有改变。但是,"重排"必然导致"重绘",比如改变一个网页元素的位置,就会同时触发"重排"和"重绘",因为布局改变了。
重排和重绘会不断触发,这是不可避免的。但是,它们非常耗费资源,是导致网页性能低下的根本原因。
提高网页性能,就是要降低"重排"和"重绘"的频率和成本,尽量少触发重新渲染。
前面提到,DOM变动和样式变动,都会触发重新渲染。但是,浏览器已经很智能了,会尽量把所有的变动集中在一起,排成一个队列,然后一次性执行,尽量避免多次重新渲染。
div.style.color = 'blue';div.style.marginTop = '30px';
上面代码中,div元素有两个样式变动,但是浏览器只会触发一次重排和重绘。
如果写得不好,就会触发两次重排和重绘。
div.style.color = 'blue';var margin = parseInt(div.style.marginTop);div.style.marginTop = (margin + 10) + 'px';
上面代码对div元素设置背景色以后,第二行要求浏览器给出该元素的位置,所以浏览器不得不立即重排。
一般来说,样式的写操作之后,如果有下面这些属性的读操作,都会引发浏览器立即重新渲染。
所以,从性能角度考虑,尽量不要把读操作和写操作,放在一个语句里面。
// baddiv.style.left = div.offsetLeft + 10 + "px";div.style.top = div.offsetTop + 10 + "px";// goodvar left = div.offsetLeft;var top = div.offsetTop;div.style.left = left + 10 + "px";div.style.top = top + 10 + "px";
一般的规则是:
有一些技巧,可以降低浏览器重新渲染的频率和成本。
第一条是上一节说到的,DOM 的多个读操作(或多个写操作),应该放在一起。不要两个读操作之间,加入一个写操作。
第二条,如果某个样式是通过重排得到的,那么最好缓存结果。避免下一次用到的时候,浏览器又要重排。
第三条,不要一条条地改变样式,而要通过改变class,或者csstext属性,一次性地改变样式。
// badvar left = 10;var top = 10;el.style.left = left + "px";el.style.top = top + "px";// good
el.className += " theclassname";// goodel.style.cssText += "; left: " + left + "px; top: " + top + "px;";
第四条,尽量使用离线DOM,而不是真实的网面DOM,来改变元素样式。比如,操作Document Fragment对象,完成后再把这个对象加入DOM。再比如,使用 cloneNode() 方法,在克隆的节点上进行操作,然后再用克隆的节点替换原始节点。
第五条,先将元素设为display: none
(需要1次重排和重绘),然后对这个节点进行100次操作,最后再恢复显示(需要1次重排和重绘)。这样一来,你就用两次重新渲染,取代了可能高达100次的重新渲染。
第六条,position属性为absolute
或fixed
的元素,重排的开销会比较小,因为不用考虑它对其他元素的影响。
第七条,只在必要的时候,才将元素的display属性为可见,因为不可见的元素不影响重排和重绘。另外,visibility : hidden
的元素只对重绘有影响,不影响重排。
第八条,使用虚拟DOM的脚本库,比如React等。
第九条,使用 window.requestAnimationFrame()、window.requestIdleCallback() 这两个方法调节重新渲染(详见后文)。
很多时候,密集的重新渲染是无法避免的,比如scroll事件的回调函数和网页动画。
网页动画的每一帧(frame)都是一次重新渲染。每秒低于24帧的动画,人眼就能感受到停顿。一般的网页动画,需要达到每秒30帧到60帧的频率,才能比较流畅。如果能达到每秒70帧甚至80帧,就会极其流畅。
大多数显示器的刷新频率是60Hz,为了与系统一致,以及节省电力,浏览器会自动按照这个频率,刷新动画(如果可以做到的话)。
所以,如果网页动画能够做到每秒60帧,就会跟显示器同步刷新,达到最佳的视觉效果。这意味着,一秒之内进行60次重新渲染,每次重新渲染的时间不能超过16.66毫秒。
一秒之间能够完成多少次重新渲染,这个指标就被称为"刷新率",英文为FPS(frame per second)。60次重新渲染,就是60FPS。
Chrome浏览器开发者工具的Timeline面板,是查看"刷新率"的最佳工具。这一节介绍如何使用这个工具。
首先,按下 F12 打开"开发者工具",切换到Timeline面板。
左上角有一个灰色的圆点,这是录制按钮,按下它会变成红色。然后,在网页上进行一些操作,再按一次按钮完成录制。
Timeline面板提供两种查看方式:横条的是"事件模式"(Event Mode),显示重新渲染的各种事件所耗费的时间;竖条的是"帧模式"(Frame Mode),显示每一帧的时间耗费在哪里。
先看"事件模式",你可以从中判断,性能问题发生在哪个环节,是JavaScript的执行,还是渲染?
不同的颜色表示不同的事件。
哪种色块比较多,就说明性能耗费在那里。色块越长,问题越大。
帧模式(Frames mode)用来查看单个帧的耗时情况。每帧的色柱高度越低越好,表示耗时少。
你可以看到,帧模式有两条水平的参考线。
下面的一条是60FPS,低于这条线,可以达到每秒60帧;上面的一条是30FPS,低于这条线,可以达到每秒30次渲染。如果色柱都超过30FPS,这个网页就有性能问题了。
此外,还可以查看某个区间的耗时情况。
或者点击每一帧,查看该帧的时间构成。
有一些JavaScript方法可以调节重新渲染,大幅提高网页性能。
其中最重要的,就是 window.requestAnimationFrame() 方法。它可以将某些代码放到下一次重新渲染时执行。
function doubleHeight(element) {
var currentHeight = element.clientHeight;
element.style.height = (currentHeight * 2) + 'px';}elements.forEach(doubleHeight);
上面的代码使用循环操作,将每个元素的高度都增加一倍。可是,每次循环都是,读操作后面跟着一个写操作。这会在短时间内触发大量的重新渲染,显然对于网页性能很不利。
我们可以使用window.requestAnimationFrame()
,让读操作和写操作分离,把所有的写操作放到下一次重新渲染。
function doubleHeight(element) {
var currentHeight = element.clientHeight;
window.requestAnimationFrame(function () {
element.style.height = (currentHeight * 2) + 'px';
});}elements.forEach(doubleHeight);
页面滚动事件(scroll)的监听函数,就很适合用 window.requestAnimationFrame() ,推迟到下一次重新渲染。
$(window).on('scroll', function() {
window.requestAnimationFrame(scrollHandler);});
当然,最适用的场合还是网页动画。下面是一个旋转动画的例子,元素每一帧旋转1度。
var rAF = window.requestAnimationFrame;var degrees = 0;function update() {
div.style.transform = "rotate(" + degrees + "deg)";
console.log('updated to degrees ' + degrees);
degrees = degrees + 1;
rAF(update);}rAF(update);
还有一个函数window.requestIdleCallback(),也可以用来调节重新渲染。
它指定只有当一帧的末尾有空闲时间,才会执行回调函数。
requestIdleCallback(fn);
上面代码中,只有当前帧的运行时间小于16.66ms时,函数fn才会执行。否则,就推迟到下一帧,如果下一帧也没有空闲时间,就推迟到下下一帧,以此类推。
它还可以接受第二个参数,表示指定的毫秒数。如果在指定 的这段时间之内,每一帧都没有空闲时间,那么函数fn将会强制执行。
requestIdleCallback(fn, 5000);
上面的代码表示,函数fn最迟会在5000毫秒之后执行。
函数 fn 可以接受一个 deadline 对象作为参数。
requestIdleCallback(function someHeavyComputation(deadline) {
while(deadline.timeRemaining() > 0) {
doWorkIfNeeded();
}
if(thereIsMoreWorkToDo) {
requestIdleCallback(someHeavyComputation);
}});
上面代码中,回调函数 someHeavyComputation 的参数是一个 deadline 对象。
deadline对象有一个方法和一个属性:timeRemaining() 和 didTimeout。
(1)timeRemaining() 方法
timeRemaining() 方法返回当前帧还剩余的毫秒。这个方法只能读,不能写,而且会动态更新。因此可以不断检查这个属性,如果还有剩余时间的话,就不断执行某些任务。一旦这个属性等于0,就把任务分配到下一轮requestIdleCallback
。
前面的示例代码之中,只要当前帧还有空闲时间,就不断调用doWorkIfNeeded方法。一旦没有空闲时间,但是任务还没有全执行,就分配到下一轮requestIdleCallback
。
(2)didTimeout属性
deadline对象的 didTimeout
属性会返回一个布尔值,表示指定的时间是否过期。这意味着,如果回调函数由于指定时间过期而触发,那么你会得到两个结果。
因此,如果回调函数执行了,无非是两种原因:当前帧有空闲时间,或者指定时间到了。
function myNonEssentialWork (deadline) {
while ((deadline.timeRemaining() > 0 || deadline.didTimeout) && tasks.length > 0)
doWorkIfNeeded();
if (tasks.length > 0)
requestIdleCallback(myNonEssentialWork);}requestIdleCallback(myNonEssentialWork, 5000);
上面代码确保了,doWorkIfNeeded 函数一定会在将来某个比较空闲的时间(或者在指定时间过期后)得到反复执行。
requestIdleCallback 是一个很新的函数,刚刚引入标准,目前只有Chrome支持。
(完)