- 我是一个线程(修订版)
- 我是一个 Java class
- Javascript:一个屌丝的逆袭
- Java : 一个帝国的诞生
- JSP 一个装配工的没落
- TCP/IP 之 大明王朝邮差
- TCP/IP 之大明内阁
- TCP/IP 之蓟辽督师
- CPU 阿甘
- CPU 阿甘之烦恼
- CPU 阿甘:函数调用的秘密
- 我是一个网卡
- 我是一个路由器
- 我是一个进程
- 我是一块硬盘(上)
- 我是一块硬盘(下)
- 我是一个键盘
- 张大胖的 socket
- 张大胖学递归
- 学习面向对象的令狐冲
- 张大胖学数据库
- 数据库村的旺财和小强
- 小李的数据库之旅(上)
- 小李的数据库之旅(下)
- 漫画:什么是机器学习?
- 那些烦人的同步和互斥问题
- IE 为什么把火狐和 Chrome 给打伤了?
- 对浏览器村的第二次采访
- 节约标兵 IE 的自述
- EMail 诞生记
- Email 诞生记(下)
- Http 历险记(上)
- Http 历险记(下)-- Struts 的秘密
- 动物王国的面向对象
- 冯·诺伊曼计算机的诞生
- Http Server : 一个差生的逆袭
- 张大胖的加法器
- 从 1 加到 100:一道简单的数学题挑战下你的大脑
- 编程语言
- Javascript:一个屌丝的逆袭
- 计算机语言之战
- 我和编程语言的爱恨情仇(上)
- 我和编程语言的爱恨情仇(下)
- Android 为什么选择了 Java
- iOS 为什么选择了 Object-C?
- Basic : 一个老兵的自述
- Node.js : 我只需要一个店小二
- 命令式编程 vs 声明式编程
- 编译还是解释?
- 程序人生
- “架构师"小赵
- 师兄说
- 师姐说
- 小王的架构师之路
- 小李的版本管理系统
- 小超穿越记
- 小李的 Build 之路(上)
- 小李的 Build 之路(下)
- 张大胖改 Bug
- 我的编程之路--大学趣事
- 码农小王的一天
- 小李在外企
- 张大胖的需求估算
- 从厨师到码农
- 聊一聊那些神一样的程序员们(上)
- 聊一聊那些神一样的程序员们(中)
- 聊一聊那些神一样的程序员们(下)
- 谁是互联网之父?
- 一个价值百万的创业教训
- 让自己与众不同 - 提升工作的价值
- 看看你的“易燃性”
- 从无聊的工作中寻找价值
- 什么样的学生适合报考计算机?
- 谈谈程序员的职业方向(上)
- 谈谈程序员的职业方向(中)
- 谈谈程序员的职业方向(下)
- 谈谈培训班的作用
- 码农需要知道的“潜规则”
- 学习编程的加速度
- 码农在工作中的必备能力
- 码农和英语
- 老司机经验
- 假如时光能够倒流, 我会这么学习 Java
- 假如我是计算机系老师
- 学会编程, 而不是学会 Java
- 从增删改查中突围
- 抽象:程序员必备的能力
- 懒就一个字
- 编程的自学方法
- 小王买房记
- 从一道面试题谈谈一线码农应该具备的基本素质
- 想写框架的看过来
- 苹果手机变砖头以后
- 如何快速的学习一门技术?
- 唯一不变的是变化: 谈谈微信应用号
- 什么是企业应用?
- 勿以浮沙筑高台
- 为什么敏捷开发难于成功?
- localhost vs 127.0.0.1
- GitHub/Stackoverflow 找工作时有什么用?
- 动词 or 名词 :这是一个问题
- 如何选择入行语言
- 有时候,沉默是金
- 零 Bug 的代码是怎么炼成的?
- 浮点数为什么不精确?
- 文章错误大全
- Open Source--不要为了开源而开源
- 一不留神,代码就腐化了
- 先做个“键盘侠”, 再来写程序
- 不加断点调试的程序员是好程序员
- 码农必备技能:烂代码的处理之道(上)
- 码农必备技能:烂代码的处理之道(下)
- 学习数据结构有用吗?
- 从现在开始,丰富你的简历
- 那些永不过时的书,你看过几本吗?
- 学好编程必备的一个品质你知道吗?
- 你最爱的 Java
- 搞懂了这几点,你就学会了 Web 编程
- Spring 的本质系列(1) -- 依赖注入
- Spring 本质系列(2)-AOP
- 三层架构和 MVC 那点事儿
- Java 帝国之拨云见日识回调
- 小张的 Duck Typing
- JDBC 的诞生
- JDBC 后传
- 一个不安分的 JDBC 驱动
- Java 帝国之 Java bean (上)
- Java 帝国之 Java bean(下)
- Java 帝国之函数式编程
- Java 帝国之函数式编程(下)
- 关于 Java 初学者需要知道的 10 件事
- JUnit 你不知道的那些事儿
- 圣诞礼物:Java EE 的历史
- Java EE 读书指南
- 给小白的 Java EE 指南
- 给小白的 Java EE 指南(2)
- 给小白的 Java EE 生存指南(3) : XML
- 给小白的 Java EE 生存指南(4) : 一只叫 Tom 的猫
- 给小白的 Java EE 指南(5) : AJAX
- 给小白的 Java EE 生存指南(6) :Java 反射
- 闲聊
- "饿了么"初体验
- 来自大脑的控诉
- 一个高中生是怎么玩自媒体的?
- 尝试 分答
- 到底应不应该上培训班?
- 自学编程中遇到问题怎么办?
- 据说 99%的初级程序员看完后都不迷茫了
- 一行代码引发的“血案”
- 对一个死锁问题的思考
- 通过外包进入名企
- 请开往十年前的今天
- 为什么自学中最好有个师傅指导一下?
- 这个网站值得你花时间投入
- 为什么你无法坚持自学编程?
码农必备技能:烂代码的处理之道(下)
接上一篇 烂代码的处理之道(上)
3. 封装成类
但是我们不会就此停步, 你再看看代码,发现这么多小函数的调用其实是很凌乱的, 尤其是一些参数在函数之间传来传去, 看起来很扎眼。
这是另外一种暗示: 你应该抽取出类了 !
作为码农的你肯定知道什么是封装,是时候派上用场了, 把你的小函数及其相关的状态封装成类 , 这将是一步巨大的跨越。
别忘了测试啊!
4. 屠龙刀:发现变化,并且封装变化
好,现在你看到曾经凌乱的领地, 秩序已经慢慢出现了, 各个类之间尽可能的隐藏自己的状态, 只通过方法来进行交互。
如果你的编程素养更高的话, 也许你能嗅到另外一种代码的坏味道: 类的职责划分不清--一个类搅进去了太多的职责, 读代码时脑子需要对很多职责进行不停转换,浪费脑细胞。
我一直认为 把不同的责任放到不同的类中去是非常重要的一件事情,更是程序员经常要修炼的基本素养, 但我观察发现, 很多程序员只会停留在把代码封装成类这一步, 而不会划分职责。
可能有人要问了,职责到底是啥? Robert Martin (就是《敏捷软件开发,原则,模式,实践》的作者)有个精辟的描述: 职责就是引起变化的原因。
如果有多于一个的原因都可能引起类的变化,就违反了单一职责原则, 最好把职责划分开。
例如一个上传图片的类,调用 httpclient 来上传图片, 但是上传过程和上传成功都会更新界面, 此时就有两个变化的原因了, 一个是通过网络上传图片, 另一个是界面, 任何一个的变化都会引起这个类的变化, 好的设计需要拆分开。
这时候你的脑子里时刻要牢记一个原则: 发现变化并且封装变化, 拿着这柄屠龙刀对你的类进行毫不留情的重构吧。
5. 倚天剑:对接口编程而不要对实现编程
如果说屠龙刀让你大砍大杀,酣畅淋漓的话, 倚天剑的使用更加考验你的编程智慧, 因为它的使用更加精细微妙, 它考验的就是你的抽象能力。
你怎么样才能把一些相似的职责再抽象一下,形成更高层次的接口让别人调用, 进而隐藏自己的具体实现呢?
例如有两个类,一个类是把内容输出到打印机, 另外一个类把同样的内容输出到屏幕, 是不是可以抽象出一个 print() 接口?
答案是: “不一定”, 得看你具体的业务,具体的代码。
我相信做接口抽象没有通用的方案,但是前辈们的总结已经给我们指明了方向和目标, 那就是“设计模式”。
只要你对职责的抽象向着设计模式的方向挺进, 基本上是不会跑偏的。
这里不会再展开讲设计模式,我记得我的 IBM 经理说过:”10 年前我们面试的时候,还会问懂不懂设计模式, 现在不会问了, 因为懂得设计模式已经是必备的技能“ 请各位程序员再仔细的品味一下《设计模式》这本书,我承认它举的例子比较古老,读起来也非常费劲, 但它里边散发出的思想是永恒的。
从具体到抽象是你能力的更大跨越, 很多程序员迈不过这一步,或者说他自以为迈过去了,实际上却没有, 因为不恰当的抽象、或者过度的抽象反而是一种危害。 我现在也不敢说掌握了这个技能, 只能说继续学习,继续进步。
6. 无招胜有招
好了,上面的都是废话,你现在可以统统忘了,:-) 但是要记住下面讲的终极武器:无招胜有招。
仔细想一下为什么我们编程序这么费劲呢?
说白了就是复杂的需求和“愚蠢”的编程语言之间有极大的隔阂,所以需要我们程序员的大脑来填补。
别看现在有各种各样的编程语言出现, 每个语言都吹得天花乱坠,但其实还都是”很低级的“ ,到目前为止,我们依然没有办法以自然语言的方式来编程序, 程序员为了把现实的业务映射到计算机实现, 需要累死无数脑细胞。
由于人脑同一时刻不能处理太多东西, 当我们面对太多的变量因素时,只能处理其中有限的几个, 这就逼着我们使用”发现变化,并且封装变化“, ”对接口编程而不是对实现编程“ 这样的武器, 把细节隐藏,把变化隔离。
其实这两样武器的终极目的就是为了达到程序的”正交性“。
“正交”在数学上讲的是线性无关, 是说一个维度的变化不影响另外一个维度, 你想象一下我们常用的二维坐标系(x, y) , x 轴的变化不会影响到 y 轴的值, 反之亦然, 这就是正交性的体现。
但正交性的威力远远不止于此, 对于(x,y) 能表达二维空间中的所有的点, 如果我们再增加一个新的和 x,y 正交的维度 z 轴, 那一下子就能表示三维空间中的所有的点了!
软件编程也是如此,无论你使用何种方法, 就是让程序形成互不影响、可以独立变化的多个维度, 这样的程序不仅优雅漂亮,更是容易理解,容易维护。
我想“正交性”应该是我们编程时追求的终极目标, 你可以忘掉其他招式,无往而不胜。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论