上次谈到了稳定和高效，今天来谈谈易用这个问题。
貌似易用和开发的关系不是很大，毕竟，软件好用不好用更多的是设计上的问题，这话不假。其实呢，易用和开发也是有关系的。最简单的一条，你的软件不好用，就没人买，没人买你就没钱拿，没钱拿就只好回家喝汤了，呵呵。
言归正传。
易用的原则，第一，是忽略一些细节。这里说的细节是说业务的细节。也就是说，一般情况下乃至绝大多数情况下用户不会和不需要在意的东西。举个例子说，比如到书店有两条路可以走，但是一条好走，另一条全是野狗挡道- -#，那就没必要给用户选择了吧，毕竟喜欢没事做飞檐走壁的不多嘛。换到实际业务中，就是有一些可有可无的细节，就不用罗列出一大堆来给用户选择了。毕竟真的专业系统能做的机会太少了，只有那种系统需要大把大把的选项来控制。这种系统一般来说有个专用名，叫工控系统，也就是工业控制系统。
其次，是和项目部署有关系的。尽量不要弄太复杂的东西，比如配置文件一大把，每次发布后要修改的配置文件搞上几十个，那还是算了……这么说的原因是软件最后的发布都不是开发去，都是实施人员去。而实施人员很少会对开发非常了解，即使了解了人家也不知道你要怎么配是不是？而且最麻烦的是，配置越多，越容易出错。减少出错，也就增加了软件的可靠性，对不？
下面来谈谈和开发有关的易用性。个人的意见很简单，开发里面，尽量不要用太过复杂的技术和框架，除非你很精通，否则不要冒险。因为开发是个技术活不假，但是实际上，开发是为商务服务的。商务能卖出去东西，你就能有收益。而客户那是不会管你究竟用什么技术的，你用JSP来写也好，用JSF也好，用EJB也罢，客户多数情况下是不会理睬的，人家只管这东西好用不好用。用最趁手的工具来做最优秀的产品，而不是炫耀技术。虽然一般来说，程序员之间互相比的就是技术，但是那不是团队合作的思想。团队的目标是把软件卖出去，然后挣钱养活家人和自己。
举个例子，我曾经见过一个项目。客户说，我们要写报告上去申请资金，你们能不能用点新技术？然后PM回答了一句，好的，我们会有新技术的。这个所谓的新技术是EJB。
且不论EJB算不算新技术，一个MIS项目用EJB，至于么？需要分布式，需要这么重的组件么？后续的开发任务就很明朗了，写一大堆Bean，一大堆代码，就为了用一下EJB。然后发布的时候，很无语的给了发布人员一个war文件，我反正没搞明白怎么打包的。然后就完蛋了，展示会被搞的一塌糊涂。不过最后项目还是过关了，这个就不是技术解决的范畴了，呵呵。
易用这个东西没多少好写的内容，先说这么多吧。易用的范畴，更大程度上是在产品设计阶段，而不是在开发阶段。