青春时光犹如白驹过隙，1995年我在Turbo Basic写下第一行程序代码，1997年进入大学计算机系，2000年取得高级程序员资格，2001年就业开始在工作中写程序，至今不知不觉已有十六载，期间用过的编程工具和语言有TB、TP、TC、PowerBuilder、C++Builder、Delphi、ASP、PHP、JS、JSP、vs.net、VBA等等，可以说我的大学和职业生涯头十年，都是在程序代码的海洋里度过的。
每一种事业、每一种工作，除了是要谋生以外，还要为人带来成就感，要让人感到自己的存在是有价值的！厨师以别人喜欢吃自己做的饭菜为荣，理发师以别人满意自己做的发型为荣，导演以自己导的电影卖座为荣，而作为一个程序员，我以我做的程序服务于人、为别人带来便利为荣！这些年做过的程序大大小小起码有三四十种，服务的人起码超过数十万人次，我以此为荣。
随着年龄的增大，事务日渐增多，技术更新也日益难以跟进，现在继续写代码让我感到缺乏激情和乐趣，我想是时候告诉我自己：你要告别一个时代了。你不再是一个程序员了，如果要继续实现自己的价值，你可以利用你的经验，去指导其他程序员，这才是正路。想想也是的，一个人要想做出更大成就，就必须具备更大的能力，同时也要能调动更多的资源，包括人力和物力。一个人的时候，一天写几百行代码，大不了写几千行代码，毕竟这都是有限的，但是你如果能带10个程序员呢？甚至你能带100个、1000个程序员，那你的想法就能在更短的时间得以实现。当然，从一个单打独斗的程序员，转变为一个带兵打仗的系统架构师或项目主管，你需要很高的程序设计能力，能把握好整体方向、系统架构、设计模式、任务划分，还需要更多的非程序技能，特别是处理人际的能力，例如沟通能力、协调能力、激励、鞭策……
这篇日记是叫《告别一个时代》，我想还是为这个时代留点总结吧，也是无愧于我的程序员生涯，希望对其他后来人有所帮助！
我程序员生涯中所写的系统，绝大多数都是属于信息管理系统，这种系统有三低三高三多的特点：
1. 算法难度低、硬件相关性低、操作系统相关性低；
2. 数据相关性高、操作相关性高、时间相关性高；
3. 需求细节多、需求变化多、系统相关的人多；
从一开始写程序时的青涩，到现在写程序的成熟，我想就是在设计系统层面上，能够很好的平衡上述三低三高三多的特点！从刚开始的编程，着眼点在数据表、外联、代码，到后来逐渐注重操作人的感受，再到后来注重到时间的因素，再到后来考虑需求变化的因素…… 我想一个好的信息系统设计架构，应该有如下特点：
1、数据库层面（M）的设计，应该是简单、灵活、层次分明的。
“简单”的意思，就是能用一个表做完的事，不要用两个表，表之间的关联能少则少。
“灵活”的意思，就是能在需求有变化的时候，只需少量改动即可满足，无需伤筋动骨。
“层次分明”是核心，它决定了前两者的效果，层次分明就是让数据的分层要在逻辑上符合客观规律，也就是意义不同的数据要分离，千万不要为了方便，把不同意义的数据混杂起来。
举个例子来说吧：假设大家可以进入系统订餐，订完餐可以扣款，当然系统还有其它消费扣款，那么订餐产生的消费、和其它的消费，在数据上应该怎么进行处理？ 如果把订餐数据和消费数据放在一个表，那就是层次不分明了，虽然订餐数据也是一种消费，但是它毕竟不是最终消费，它主要是意味着“订了什么时间的什么菜”的问题；如果把订餐产生的消费数据、和其它产生的消费数据，放在不用的表，就太过于复杂了，毕竟两种消费说到底都是消费，都是描述“谁在什么时间，花了多少钱”的问题； 所以，可以分成两个表，一个叫订餐表、一个叫消费表，订餐期间产生的数据都放在订餐表，最后每一顿饭产生的消费数据，在扣款后都产生一条消费数据，放在消费表。这样子针对订餐的各种增删改查统计等操作，就只和订餐表相关；而针对消费的各种统计、查询等，则只和消费表相关了；而且把每顿饭订的多样菜式，合成一条消费数据放在消费表，也减少了消费表的数据量、方便查看。
而“灵活”的设计是怎么体现呢？再举个例子：还是以上面那个订餐为例子，发布的菜谱一般人逻辑是“某某餐厅的中午的菜谱”，就是三级的层次，首先有餐厅，然后这个餐厅有早餐、午餐、晚餐等餐次，然后才是这些餐次的具体菜式……那么我们能否设计成两个层次呢，就是菜式是某餐厅的菜式，同时它是中午的菜式？这样设计的好处，就是层次减少了，归属关系弱化了，其中餐次和餐厅并无任何关系，而菜式则直接和餐厅和餐次产生联系。假定未来需求变成“某某餐厅的菜谱”，它减少了一个层次，或者变成“某某餐厅的中午的特价菜谱”，它增加了一个层次，我们都无需对设计进行彻底的改动，因为这些非骨干的层次，我们其实都视作了核心数据的属性了，例如某餐厅、中午、特价等等，都是菜谱的属性，我们骨干只有一个，就是菜谱~~~
2、代码逻辑层面（C）的设计，应该是逻辑严谨、适度聚合、结构分明。
“逻辑严谨”的意思，就是要严格按照逻辑结构、事物之间横向的关联、时间先后因果的关联来考虑，每一段代码都不要漏掉考虑各种情况；
“适度聚合”的意思，就是同样的代码段，无需在不同地方重写，但是也要注意不要整合得太深太紧密，以免日后情况变化时分离麻烦；
“结构分明”的意思，就是一件复杂的事，就要分开代码来处理，不要写成长长的一堆，而是应该从整体到细节，逐一分解、逐渐深入，有层次写成调用的结构（如果封装成类当然更好）
这里我就针对“适度聚合”举举例子吧，因为其它两点应该不存在什么异议：就说上面的消费系统吧，它作为一个消费系统，肯定在很多地方会出现“存款”、“取款”、“扣款”、“退款”等事务，我想大家都能想象得到，其实这些操作在很多地方发生，但是它们的实质都是一样的，就是改变某个账户的余额、给该账户记录一条消费数据，那么我们是不是应该把这些代码都写成一份呢？ 例如写成一个“消费”函数，参数就是消费额、消费账户、消费类型、备注，然后在具体发生消费的代码里调用此函数即可。 这个就是叫“聚合”，这样的好处就是重复的代码无需多次编写，而且一旦消费逻辑发生改变，我们只需要修改一个函数的代码即可，不会漏掉代码没有修改。但是，这样把所有消费的情况，聚合成一段代码，好不好呢，这就需要衡量一下了。因为账户余额减少的逻辑、和账户余额增加的逻辑，虽然其根本是一致的，但是逻辑上有细微区别，如果放在一起，函数里就需要很多判断出现，另外为了防止调用出现错误、也是为了日后需求发生变化时候稍微灵活点，我们可以考虑聚合成四个函数，“存款”、“取款”、“扣款”、“退款”四个函数， 其中取款函数要判断取款额不能超过余额、扣款函数也要判断是否允许超支、退款函数则要考虑不是全部操作都允许退款的……
3、功能界面层面（V）的设计，应该是一目了然、方便快捷、意义明确。
“一目了然”的意思，就是在一个界面上，把别人把最需要了解的东西，都尽量合理安排地展现出来，一方面是有用的东西要在界面上、另一方面是无用的东西不要出现；
“方便快捷”的意思，就是点一下能操作的事，千万不要让别人点两下才能操作，很多事情要考虑是否需要批量操作，如果需要批量操作要尽量提供；
“意义明确”的意思，就是每个界面、界面上的每个数据、每个文字，都要考虑用户是否能理解，考虑用户是否能从界面上了解到数据之间的关系；
例子我就不举了，我想这些意思也很明确了，简单说就是“想用户之所想”，要多从用户的角度去考虑，他们所期望的、他们觉得方便的、符合他们工作上习惯的界面和操作方式是怎么样的？
未完，陆续编辑完善……[ 此帖被nichelous在2011-01-30 17:27重新编辑 ]
