关于RESTful不足的思考

Related image在Amazon的时候,公司内有大量的组来维护不计其数的service,而service之间的通用通讯方式是公司内部的一个框架,协议是自定的,客户端也是内部的;现在到了Oracle,我看到这个变成了RESTful,也就是说,协议本身变成了最常见和适用的一种。我看到有太多论述RESTful优点的文章了,而实际工作中也确实有所体会,比如接口和报文的可读性好,不需要特制的客户端,上手和调试都比较容易等等。但是,如果看到某个东西被冠以过多正面的评价,就要当心了。我也慢慢地体会到了一些问题。不过,在谈谈我的思考之前,我想先明确一下我对REST的认识,而这点,鉴于历史原因,也是我不太愿意花时间争辩的内容。我

[……]阅读全文

追求纯粹

pure

偶然想到的这个话题,工程师做工程是一方面,而作为单纯的程序员,总是充满对于纯粹的追求。

最近又负责了一个使用Angular的项目,我们知道最近Angular很火,其中一个重要原因就是它给前端开发带来的变革,第一次发现可以让以前如此恼人的变量绑定消失掉。以往变量绑定的语句放在附属于页面的一个js片段(文件)里面,颇有些无奈的意思,如果把它视为展现层面的东西,显得很不直观(声明式编程才是最直观的方式),而且让这一层变得啰嗦;而如果把它视为下面一层的东西,这又让逻辑代码变得不纯粹——凭什么要让逻辑代码去了解哪个dom叫什么id?于是Angular来了,引入了$Scope这代表上下文的东西,变量绑定

[……]阅读全文

重新发明轮子

wheels

“不要重新发明轮子”是总是可以听到的话,在评判一个设计的时候,总是听到这样的话。但是凡是不绝对,而对于这句话来说,很多情况下,都是错误的。我甚至都不能说出“大多数情况下不要重新发明轮子”这样的话,因为具体问题,实在没法用大多数还是少部分来概括。重用轮子有什么好处?省代码;轮子已经经过千锤百炼,质量有保障;轮子功能在逐步更新中,可以看到未来的获益。但是,也有一些情况让我无法重用轮子。

第一种情况,我只需要一点沙土,我不需要整座大山。

比如,我只需要一个StringUtil.isEmpty这样的方法,判断字符串是否为空串或者null,如果引入

[……]阅读全文

Hackweek几点感受

hackweek

最近参加了Amazon Forecasting的Hackweek,大致就是给你一周的时间,你可以找一个感兴趣的项目,找几个人组个队,然后把想法实现出来。从整个项目来看,虽然时间只有一周,但是安排得满满当当,基本上把最初的想法实现出来了。趁着新鲜劲儿,我简单记录一些概况和感受:

  • 我们组做的项目是去互联网上把热门的事件(比如Google的Hot Trends)扒拉下来,然后根据事件的各种属性(包括媒体新闻的内容),和Amazon卖的产品匹配起来,即找出最近发生的大事会影响到哪些产品的销量,接着通知相关的用户。这里的用户一般都是库房经理,在得到这样的消息以后可以采取相应的行动,避免因为热

[……]阅读全文

模板引擎随谈

template engine

模板引擎是为了解耦而产生的,从编程范型的角度来说,写模板属于“声明式(Imperative)编程”。JSP大概是最早接触也是最基础的模板引擎,本来写Servlet嘛,一大堆一大堆的print,实在是没有任何结构性可言,然后JSP出现,先被处理成实质为Servlet的Java文件,编译以后变成class,接着一样执行。所以本质是编译型的模板引擎,当然模板引擎也有解释型或者二者混合的。通常说来编译型的执行效率要高得多。只要是和显示相关的编程语言,都会发展出一套或者N套模板引擎,用得多了觉得很多情况下都大同小异。

几年前我在工作中折腾过一段时间的服务端模板引擎,最早遗留系统使用的Velocity

[……]阅读全文

关于 if (someobject != null) 的问题

NPE

以下内容来自于在StackOverflow上的有一个有趣的讨论,说的话题很小,就是对于这样的对象为空的检查:

if (someobject != null) {
    someobject.doCalc();
}

为了避免空指针异常,看起来也没什么不妥。不过代码里面一片一片的对象是否为空的判断,实在难看。

对象是否为空的契约

通常我们在定义API的时候,是遵循一些规矩的,这些规矩可以叫做规约,比如这样的接口:

public Set<String> getCollections();

通常情况下,或者说没有特殊说明的情况下,返回的set是不能为null的,如果没有元素,应当是一个

[……]阅读全文

过多if-else分支的优化

if-else 我想谈一谈这个话题是因为我的上一篇博客在ITEye上有一些朋友回复,说if-else过多的分支可以使用switch或者责任链模式等等方式来优化。确实,这是一个小问题,不过我们还是可以整理一下这个小问题的重构方式。

为什么要优化?

你没有看错。这是要放在第一条谈论的。

有许多人会说,叠起来一堆if-else分支,代码就不优雅了。可是,怎样去定义“优雅”的概念呢?再退一步说,即便不“优雅”,又有什么问题?

对于这样一段再普通不过的代码:

int code;
if("Name".equals(str))
	code = 0;
else if("Age".equals(str))
	code = 1;

[……]阅读全文

代码洁癖症的表现

cleanliness 有下列情形之一的,你患上了代码洁癖症。症状程度可轻可重,轻者帮助写出优雅整洁的代码,重者走火入魔,万劫不复。

  1. 多余的空行、分号,没有使用的变量,见一个删一个。
  2. tab或者空格没有对齐的必须纠正过来,除了缩进用,不允许看到代码内连续两个空格。
  3. 看到一个类某个方法没有注释,不由自主地加上,不管有没有意义。
  4. 错误的拼写,无论是在命名还是注释必须纠正过来;不一致的大小写,必须要纠正过来;标点符号的遗漏,必须补上。
  5. 看到if(a==0)这样的代码必须改成if(0==a)这样的形式。
  6. 所有IDE对代码的告警必须消除,无论采取的方式是否有实际意义。
  7. 看到赤裸的数字,必须定义成常量,即便数字表意很直观,还

[……]阅读全文

史上最烂的代码

shit 其实本没有什么代码是“史上最烂”的,要有也只有“史上更烂”的,我想随便说说这个话题,也是源自豆瓣的一个讨论。事实上,系统复杂了被骂代码烂是一件司空见惯的事情。当然,也有一些短小的代码片段,就足以看出代码作者是个不怎么样的人。

布尔类型的使用是很容易变成最烂代码的:

if (isTrue()) 
    if (isTrue()) 
        doSomething();
if(boolVal == true) { 
    ..... 
}

有一些毫无意义的注释:

return 1; // 返回 1
//如果标志为真,就返回true
if(flag)
    return true;

更无意义

[……]阅读全文

编程的未来

1 最近在看一本书,加来道雄(Michio Kaku)的《物理学的未来》,第一、第二章是程序员更加关心的,对于下一个100年计算机和人工智能未来的预测。想想计算机发展短暂的历史,这些发生了的翻天覆地的变化,似乎都在弹指一挥间。谁的大胆预测可以那么准确?无论如何,书中对其这样几个猜想令我记忆深刻:

  • 因特网眼镜和隐形镜片
  • 无人驾驶汽车
  • 摩尔定律结束
  • 通用翻译器
  • 全息摄影和三维影像
  • 意识识别
  • 有意识情感的机器人
  • 模拟大脑

这是物理学家眼中的世界(另外推荐他的另一本书《平行宇宙》),激动人心;另一方面,我回想起小时候无比痴迷的机器猫,小小四维空间袋,寄托了孩子多少纯真的梦想,有多少神奇的

[……]阅读全文

设计之美

到处都在谈论UI的美感,仿佛“美”在软件工程中的定义就要落到界面上面。实际美的存在是广义的,包括架构设计,包括代码建设,包括接口定义,不妨在更多的场合引入对美的评审。软件本身就是一种艺术品,而程序员,应当是被赋予创造力的艺术工作者。

 

仅看这两张图,你觉得哪一张会更美一些?

我相信大多数人会选择第一张,因为后面那张图显得头重脚轻,事实上,后者也确实是一个短命的版本,只存活了不到半年的时间。这两张图,正出自淘宝发展的一个阶段(来自淘宝赵超的博客)。而且,进一步观察发现,对于许多设计图来说,狭窄的汇聚点往往成为性能的瓶颈。

另一个设计上典型的丑陋是混乱,如下面的设计图:

我不相信看到

[……]阅读全文

代码的变与不变

change 哲学上说变与不变,讲的是绝对运动与相对静止的道理,在代码设计中,也有许多变和不变之间的辩证故事。

 

有一些类在创建以后,整个生命周期内都不会发生变化,这种模式被称为Immutable Pattern。

较弱的不变模式:指的是一个类的实例状态是不可变化的,但是这个类的引用的实例却可以变化。

比如说:Visitor模式常常是这样的,整个流程是不可变的,但是我为我的整个流程提供灵活的切入点,提供出来访问接口,供变化的部分完成。

较强的不变模式:一个类实例状态不可变,其内部引用的所有实例也不可变。

这个就比较多了,JDK中的String、Integer、Byte等都是不可变的。

&nbs

[……]阅读全文

back to top