本文献给那些无经验无意识的年轻编程菜鸟和那些人老珠黄却又投身IT致力于信息产业繁荣的程序员们。
最近, 我和很多工程师在一个很平常的伦敦码农之夜讨论了一下怎么我们要培训新入行的那些菜鸟这么多东西。有人要知道一个大学毕业生如何进行单元测试,有人要跟他们解释为什么依赖注入比以来查询要好。于是我思考了一下走过的人生,简单扼要的解释了一下我们为什么要进行单元测试和我们为什么需要它们。
你根本不需要它 —— 这里的问题是,人们往往写了远多于解决问题或者实现程序功能所需的代码。一种典型的情况:在Java EE的session beans中加入根本不需要的finder方法。
不要写重复的代码——在方法、类、包和包对象中大量重复地编写代码。一种典型的情况:在单元测试中复制和粘贴代码,在实体和前端重复元数据。
保持简单(或者愚蠢),是一句高级程序员间的口头禅。只针对需要解决的问题码字而不是写稍微复杂一点的代码。 同理见 奥卡姆的剃刀 (如无必要,勿增实体)。
常见错误: 程序中含有过多的抽象层
其它翻译版本 (1) 加载中每次重写 —— 避免重复的反模式, 当代码被有意识的在不同的包,类或者函数中重写一次又一次。
症状: 决定用自己的方式做一件事,来代替和其它的开发者合作,并且发现大家做的事情有许多共同点。
典型的解决方法: DRY(避免重复原则)单元测试 和重构
将一切写上一万遍——WET的夸张的通俗版本
三的规则——这不是一个与R3同名的专有操作系统,或者经典的80年代的电子游戏,或者一款大众高尔夫的极限改装车; 但是这个想法当你的代码在一个方法、函数或类中有三个重复的部分时,那么你就需要把这些重复的部分重构到一个方法里。 与 DRY 和WET原则相关。
典型症候:因为时间的压力而忽略重复代码,或者团队管理者说我们不需要在这个阶段重构
契约式设计 - 它的核心思想是在建立一个服务之前,首先定义出正式的、精确的、可验证的接口. 用Java写一个接口,然后可以很容易的围绕这个接口来编写实现类;由于一个接口可以有不同的实现类,所以,接口可以使你的架构得到高内聚、低耦合的效果(译注:java中的接口就是契约).经典例子:JDBC规范从1.0版本以来,有很多不同的关系数据库的实现,包括:MySQL,Postgres, H2, Derby等。每一个Java程序员都知道如何对JDBC进行编码,因为他们没有与一个不同的实现作战,因为DBC已经保证了它在大部分时间都会做正确的事。.
同样与之相关的是标准的应用程序接口
大型的软件前端设计,对于企事业厂家来说,存在一个问题;比如:有时候需要一百到一千页程序文件,这些软件项目开发已经通过了涉及项目不深的架构师和业务分析师需求,他们花了几个星期调查投入和对文档的要求业务进行聊天洽谈,但是仅仅得到一个结果,这些文件实际上一无所值。
解毒剂:技术领先和一些重要的架构师与分析师和顾客洽谈的项目开发人员,大家会话思考
症状:瀑布开发方法和投资银行it文化要求方面
解毒剂:未知,许多人企图把”agile“用一个大A和小A到企事业厂家多多少少取得了一些成功,但同样也面临着一些失败
2KB项目(www.2kb.com,源码交易平台),提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务