程序之美。

程序的美要从两个方面进行品味，一是程序整体的架构之美；一是程序的代码实现之美。 编码之美： 编程就是为解决一个计算机能够解决的问题写出具体的程序实现。 开始，人们总是从发现代码之美开始的，从把代码一股脑的写在main方法里，到把一些有独立意义的代码片断写成不同的方法；从不知道代码重用，到把有重用性的代码抽象出来在不同的地方重用；从类与类之间没有什么组织结构，到开始把程序中的类组织成不同的目录结构，让不同的类担当不同的责任。这个时候才第一次和OO思想沾边。从把类看成程序最大的组织形式，到把程序设计成不同的模块；从不知道接口有何用处，到发现自己离了接口竟然有点不会写程序了。这些是我编程的不同阶段，相信大多数人也都要在不同的阶段走过。代码之美还有很具体的地方，实现同样的功能，有人做不出来，有人用1天写出一个一千行的实现方案，需要运行1s钟解决问题，有人用10天写出一个一万行的实现方案，只要运行0.01s就能解决问题。通常来说，要解决一个问题，人做的工作越多，计算机做的工作就越少；思维越缜密，就越能减少程序出现的bug，同样，代码长度也就越长。一万行的程序不一定比一千行的程序慢。说起代码之美，我想起以前看到的一个小题目：用最短最高效的代码实现一个方法，判断一个32位的int数num是不是2的幂数（既是否存在一个n是的n个2相乘，得到num），存在则返回0，不存在返回非零。 我见过的最牛的实现： public int count(int num){     return x&(x-1); } 代码之美体还现在很多地方，比如说优秀的算法，命名规范、代码格式等等。 架构之美： 好的架构是系统成功的一大半，有了好的架构，实现起来只有好坏之分，基本不存在能不能实现的疑问。对系统进行架构的过程就是对现实世界中的事物和过程进行抽象的过程，抽象的越接近事实的本质，适应性越强，系统的生命力也就越强。作为一个还没毕业的大学生，我不敢说自己对架构一个系统有什么独到的见解。唯一一次像样的架构程序也就是做那个项目，架构总体还算成功，采用插件式设计，这个思想使得我们整个程序各个模块之间的耦合度都很低，几乎完全是面向接口编程的。系统架构这个东西感觉一是要学习理论知识，学习成功案例，多想想如果是自己会怎么办，有机会自己要多实践，理论联系实践是最重要的。同时还要多思考，思考世界，思考事物之间的关系，将它们抽象成计算机可以表示可以处理的模型。   系统越小，编码显得越重要；系统越大，架构越显得重要。 但是具体到我现在接收的一个半路项目，其架构是比较好的，完全能够达到应用的实际需要，但是代码实现却做的非常差导致整个项目质量严重缩水，这也是让人很无奈的。   阅读优美的代码，体味优美的架构，一种思想的美总能止不住的从心中油然而生，如同醍醐灌顶。