单元测试方法论(clean code阅读笔记之八)

单元测试

注:正文中的引用是直接引用作者作者的话,两条横线中间的段落的是我自己的观点,其他大约都可以算是笔记了。


对于很多人来说,所谓「单元测试」只是在我们艰难地写完一些类或者方法——甚至一个工程——后,写下的一些「专用代码」来测试它们,而且这些代码往往都是一些简单的驱动程序来帮助我们和我们刚写好的程序进行交互。比如某些人写的单元测试会是这样的,单元测试跑起来后会监听键盘,然后我们键入某一个字母或者直接点击回车来执行某种测试步骤。

KK笔记:kknotes.com
本文链接地址: 单元测试方法论(clean code阅读笔记之八)

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading

代码中的边界问题(clean code阅读笔记之七)

不要轻易跨越边界

注:正文中的引用是直接引用作者作者的话,两条横线中间的段落的是我自己的观点,其他大约都可以算是笔记了。


在一个完整的系统开发过程中,我们一般不会所有的代码和细节实现都自己去完成,那么不可避免地要用到第三方类库、开源实现或者公司内部其他团队的子系统的实现。在这种时候,我们就要给自己负责的这部分定义「清晰的边界」,来让我们的软件更加健壮。本章将讨论一些对边界问题的处理的几个实践和技巧。

KK笔记:kknotes.com
本文链接地址: 代码中的边界问题(clean code阅读笔记之七)

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading

如何优雅地进行错误处理(clean code阅读笔记之六)

程序出了问题怎么办

注:正文中的引用是直接引用作者Bob大叔的话,两条横线中间的段落的是我自己的观点,其他大约都可以算是笔记了。


错误处理是十分必要的,但是如果对错误处理使用不当则会让代码变得十分臃肿,让阅读者看不清代码的逻辑,更严重的是,这也会让程序变得十分脆弱。本文中将列出一些使用错误处理的技巧,帮助你写出既简洁又健壮的代码。

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading

并不是一切皆对象(clean code阅读笔记之五)

Star Trek中的机器人Data

注:正文中的引用是直接引用作者Bob大叔的话,两条横线中间的段落的是我自己的观点,其他大约都可以算是笔记了。

本文中的函数方法是一个概念

本文读起来可能比较晦涩,其实通篇只讲了一件事情:在面向对象的环境里有两种方法去定义一个类,面向对象(本文中一直谈到的对象)和面向过程(本文中谈到的数据结构),它们各有优劣,在开发的时候要合适地做出选择。

由于「Clean Code」整本书都有很浓厚的Java的色彩,所以大部分代码和概念都是Java中比较常见的,不过在面向对象的语言中大致能找到相应的东西


KK笔记:kknotes.com
本文链接地址: 并不是一切皆对象(clean code阅读笔记之五)

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading

代码的颜值—格式化(clean code阅读笔记之四)

代码的颜值很重要

注:正文中的引用是直接引用作者Bob大叔的话,两条横线中间的段落的是我自己的观点,其他大约都可以算是笔记了。 


从这一章的第一段就能看出来,Bob大叔对格式化是非常看重的,他连着使用了几个排比句来说明代码的格式化对于一个工程作为一个整体的重要性。所有的代码—不论是一个人不同时期写的代码,还是一个团队不同的成员写的代码—都应该是一致的、优雅的。

KK笔记:kknotes.com
本文链接地址: 代码的颜值—格式化(clean code阅读笔记之四)

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading

如何写出优雅的函数(Clean Code读书笔记之二)

第三章讲了在写函数时应该注意的事情,作者首先拿一个开源的测试工具(Fitnesse)来举了一个例子,来说明好的函数该是什么样子。原则上其实和上一篇中讲到的命名的一些原则很相似,就是一个名字要是能够自解释的,当然这一章还会讲到很多新的东西,这里拿这个函数作为一个引子。

//代码2-1
public static String renderPageWithSetupsAndTeardowns(PageData pageData, boolean isSuite)throws Exception{
    boolean isTestPage = pageData.hasAttribute("Test");
    if(isTestPage){
        WikiPage testPage = pageData.getWikiPage();
        StringBuffer newPageContent = new StringBuffer();
        includeSetupPages(test Page, newPageContent, isSuite);
        newPageContent.append(pageData.getContent());
    }
}

KK笔记:kknotes.com
本文链接地址: 如何写出优雅的函数(Clean Code读书笔记之二)

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading

命名的艺术(clean code阅读笔记之一)

本文是「Clean Code」(英文版)第二章的读书笔记。

第二章简单地列举了一些命名规则,我们在coding的时候会不断地对我们的变量、函数、参数、类、package,甚至源文件、和包含源文件的目录等等进行命名,这里是简单的几个命名规则能帮助你更好地对这些命名。

1. 使用名副其实(Intention-Revealing)的名字

  • 不要定义无意义的名字
  • 不要使用magic numbers
  • 例子:
    // 坏代码例子
    public List<int[]> getThem() {
        List<int[]> list1 = new ArrayList<int[]>();
        for (int[] x : theList)
            if (x[0] == 4) list1.add(x);
        return list1;
    }
    
    //不是很坏的代码
    public List<int[]> getFlaggedCells() {
        List<int[]> flaggedCells = new ArrayList<int[]>();
        for (int[] cell : gameBoard)
            if (cell[STATUS_VALUE] == FLAGGED)
                flaggedCells.add(cell);
        return flaggedCells;
    }
    
    //好代码
    public List<Cell> getFlaggedCells() {
        List<Cell> flaggedCells = new ArrayList<Cell>();
        for (Cell cell : gameBoard)
            if (cell.isFlagged())
                flaggedCells.add(cell);
        return flaggedCells;
    }
    

KK笔记:kknotes.com
本文链接地址: 命名的艺术(clean code阅读笔记之一)

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading

Restful API设计思路及实践

记得第一次写APP的时候,那时还完全不知道REST这个东西,对Web Service也是一知半解。我和另一个同学在讨论使用什么协议来交互时,通过各自充分的调研之后(其实就是搜索引擎找一找。。。),一致认为,HTTP这个东西本身就对带宽的消耗这么大了,这么多Web Service(当时还是SOAP当道)还是基于HTTP之上的,这得浪费多少带宽啊。最后一致决定使用Socket来通信,现在想想当时也是挺不容易的,我们硬是在Socket上搭了一套通信协议,还发展到了第二版。

今天在移动应用普及、前后端分离的大浪潮下,RESTful风格的API大行其道,可是因为它本身就是一个比较模糊且宽泛的概念,所以每个人对它的理解都有千差万别。我觉得我们在技术选型的时候,在自己的技术积累以及参考已有的行业最佳实践的基础上,应当首先考虑自身系统的需求,思考「选择某一种技术」会对系统的开发和维护带来哪些好处与坏处,而不是人云亦云看着别人用什么自己就用什么。而且RESTful API设计目前并没有一个公认的行业最佳实践,故而开发者在设计一个API系统时,更应该根据自身的情况量身定制,千万不要说「我照着某某公司的开放API照搬」就好了。 本文将根据我使用REST的经验来总结一下RESTful API设计的一些知识和经验,自勉。本文将不讨论Oauth等安全问题。

KK笔记:kknotes.com
本文链接地址: Restful API设计思路及实践

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading

在Apache环境下配置Playframework的双向HTTPS验证

httpd-ssl.conf

Listen 443

<VirtualHost _default_:443>

#   设置Apache转发与https相关的 header

#  这样在Play中就可以中国request().secure()获取是否当前为https链接

RequestHeader set X-Forwarded-Proto “https”

ProxyPreserveHost On

KK笔记:kknotes.com
本文链接地址: 在Apache环境下配置Playframework的双向HTTPS验证

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading