对于一个要解决的问题，总会提供一种解决思路。这种思路如果是成熟的，不一定处处都是部分最优，但是能够保证全局最优。
所以我在这里总结这种编程中常用的成熟的设计思路，避免自己再走弯路，提高自己在开发和设计时的效率。
这一年主要使用c#开发系统，我们使用的orm是XAF下的XPO，XPO是一种强大的ORM工具，能够通过数据库表生成业务模型，也可以通过写好的业务模型直接去生成数据库表。
而且你在使用XPO的时候，使用什么类型的数据库对于orm而言是完全透明的，根本不用关心，只要配置一下连接字符串就行了。
但问题是如果我们通过业务类来直接生成表结构，而在开发的过程中，我们又修改了业务类，那么orm会如何处理？保证业务类和表结构同步？
在《thinking in c++》这本书上，作者将一段代码先用c去实现，然后再用c++来重写它，通过这种方式来论述c++在面向对象方面的优点。
这里可以看出，其实C也可以写出“面向对象”的代码，只不过非常蹩脚(据说当年oop正当流行的时候，将汇编代码设计成oop的)，因为它不支持这些语法特性。
而支持面向对象的语言可以将面向对象的功能做的很好。而作为支持面向对象的语言，如果面向对象编程都不能解决复用性和可维护性等问题，这个时候就需要使用设计模式了。
也许将来会有一种语言直接支持设计模式吧。
教科书会告诉你，面向对象是“封装，继承，多态”。所谓封装，就是为了隐藏一个对象的实现细节，对外提供接口。而继承，是为了提高软件的复用性，父类的属性和代码可以直接继承，不用重复编写。多态，则是在运行时通过对一个对象指针赋不同的对象，而表现出多种形态。
本文算是两部分，一部分是对《编写可读代码的艺术》一书的总结，一部分算是自己这一年来对代码书写的心得体会。
虽然项目的整体构架和设计模式很重要，但程序员日常工作的大部分时间，还是会花在一些“基本”的事上，所以写的一手“好代码”，也十分重要。
这些代码洁癖包括：
命名，注释以及审美-可以用于代码库每一行的小提示。
简化循环和逻辑。
在程序中定义循环，逻辑和变量，从而使得代码更容易理解。
重新组织你的代码。
在更高层次上组织大的代码块以及在功能层次上解决问题的方法。
而代码洁癖，本身就是为了使代码更容易理解，你会发现，如果一个人的代码写的很干净，那么他的编程思路也绝对是清晰的。相反代码写的乱的人，他们的编程思路，甚至做事态度都是含糊不清的。
关键思想: 代码的写法应当使别人理解它所需的时间最小化。
首先我想引用《Unix编程艺术》中的几段话，我太爱这本书了。
在输入输出方面，Unix传统极力提倡用简单，文本化，面向流，设备无关的格式。在经典的Unix下，多数程序都尽可能采用简单过滤器的形式，即将一个输入的简单文本流处理为一个简单的文本流输出。
Unix中，文本流之于工具，就如同在面向对象环境中的消息之于对象。文本流界面的简洁性加强了工具的封装性。
要想让程序具有组合性，就要使程序彼此独立。在文本流这一端的程序应该尽可能不要考虑文本流另一端的程序。将一端的程序替换为另一个截然不同的程序，而完全不惊扰另一端应该很容易做到。
下面我从几个不同的方面，来讲述自己对输入输出的理解
经常使用linux和unix的同学，已经习惯于在命令中用管道链接输入和输出。
command1 | command2 paramater1 | command3 parameter1 - parameter2 | command4
工作相比于在学校会更加复杂，因为在学校你可以去上自习，可以学习学校的知识，也可以自由支配去图书馆或者在机房泡一下午。但是工作中则以处理任务和自我提升为主。
但是这个任务并不类似于“老师布置你作业让你做完”这么简单。
这种任务带有很高的决策性，比如突然来了许多任务，你要如何安排自己的时间。比如处理优先级。
而且可能还会带来很多隐性任务，比如你被外派到某个部门开发系统，具体操作时，琐事要比这个复杂。一方面，你要让自己领导知道进度，还要与这里的领导协调，还要与具体的使用此系统的人员沟通。
关键是这些事物越来越多，会让你产生混乱焦虑，你会变得无从下手。如果有GTD，就可以把握进度，分配时间处理。还可以不停的给自己反馈，增加自信，这类似于使用TDD编程。