北京大学直属职业院校-南京北大青鸟协同学院

青鸟新闻

当前位置: 北大青鸟协同软件学院 > 新闻资讯 >
北大青鸟_五个简单的原则,带你写出整洁代码!
时间:2019-02-15 14:08来源:南京北大青鸟 作者:北大青鸟协同 点击:
避免预先设计的代码 架构往往得预先设计的,而代码容易被过度设计。而事先设计的架构,往往在落地的时候,会遇到一系列的挑战。等到软件交付时,则会变成新的架构,或者该架构的变体。代码,则也是类似的。 日常工作中,我们经常遇到的情况,到底有没有必要提前编写一些代码这些功能往往是,我们根据以往经验,猜测未来会有的功能?不事先编写,那么后期修改就比

 避免预先设计的代码

架构往往得预先设计的,而代码容易被过度设计。而事先设计的架构,往往在落地的时候,会遇到一系列的挑战。等到软件交付时,则会变成新的架构,或者该架构的变体。代码,则也是类似的。
 
日常工作中,我们经常遇到的情况,到底有没有必要提前编写一些代码——这些功能往往是,我们根据以往经验,猜测未来会有的功能?不事先编写,那么后期修改就比较麻烦。事先编写的代码,不符合需求,那么后期还是得重写。只有运气刚刚好,我们才能编写出符合需要的代码。然而,多数时候,我们写的这些代码往往是用不上的。
 
一旦代码中有大量多余的代码,代码看上去就没那么整洁了。若非要在两者做一个平衡,便是多做一点点,如先把接口准备好,但是不实现相应的功能。
 
IDE 重构 vs 手工重构
整洁的代码,意味着不重复,而每个人对于重复的定义是不一样的。对于我来说,则是:事不过三,过三则重构。耦合和参数,会带来新的复杂度。重构,不是一件容易的事,也不是一件太困难的事。
 
手工重构代码,意味着风险。如果没有测试,直接对代码进行重构,那么就会生不如死。
 
IDE 重构代码,则是依赖于 IDE 自带的功能,以通过机器的方式来重构代码。与手工方式相比,它更加的可靠,并且风险相当的低。前提是,该语言有对应的 IDE 可以提供这个功能,如 WebStrom、Intellij IDEA 等。
 
短、平的函数
编写函数的时候,要注意长度要短~、一个函数完成一件事,并且避免多级嵌套。
 
长的函数,阅读体验不好。多层嵌套的函数,复杂度过高。
 
采用各种 Lint 来限制函数的长度、层嵌套的数量,是一种颇为有效的降低复杂度的方式。
 
适当的设计模式与原则
设计模式和各种原则是好东西,它们可以方便我们与其他/她开发人员进行交流。当你遇到一个一对多的问题,别人一说,”你这个东西用观察者模式来实现”,那么问题就这么解决了。
 
设计模式,是一系列对于相关问题的解决方案。缺少编程经验的时候,学习设计模式,是一个不错的提升方式。而问题的关键,在于如何在适当的时候使用它们。在这个过程中,我们经历这么一些情况:
 
不知道设计模式
 
拿着设计模式的锤子(定律),到处使用
 
对设计模式反感,会避免使用
 
自然而然的使用设计模式
 
编程语言在解决问题上是相通的,哪怕是不同范式的设计语言,要解决的问题是一样的,采用的设计模式也就类似。
 
命名而非注释
命名,对于程序员来说,是一个难题。
 
一个好的变量名、函数名,远远比一行行注释,更重要——代码是写给人看的。
 
阅读遗留系统代码的时候,最怕的不是又长又深的代码,而是代码中有个 42 这种魔法数字(magic number),又没有对应的注释。那怕得打出几个电话、发几十条信息,才能知道这该死的 42 到底是什么。
 
哪怕是使用错误的单词,将 42 赋予这个变量,如 var ratio=42,也远比 42 + 对应的注释拥有更好的可读性。特别是,如果到处是这个 42 的变量,只会使得到处都是相关的注释。同样的,这个问题,也出现在对于函数的命名上。好在我们对于函数的命名,会略微重视一些。
 

Copyright © 2002-2017 南京北大青鸟协同校区 版权所有
校区地址:①洪武北路121号,苏苑大厦12楼-南京北大青鸟 ②建宁路65号,金川科技园(原铁道职业技术学院)4号楼-南京北大青鸟苏ICP备09004837号