有的东西是必须天天吃的，才能保证机体健康。在此初步列出几个以供自律： 设计模式:此物保证在生产一个信息系统的软件部分时，赋与其与环境相适应的生命力，可以配合进化。防止环境变化成为其自杀毒药。 识别需求：服务于社会生产实践的信息系统需求多得无可胜数，但实践中因为成本约束，能上的系统或无或不完美。在新闻的痛苦表述中，我们会发现它的蛛丝马迹。信息系统不服务于实践，其存在的价值如何表现呢？当然，服务得

简单问题要放大了看，深入了看，找出它有多少外延，内涵的本质有多深。简单问题不能简单对待。因为它是复杂的基石。 复杂问题却要简单对待，要离远了看，要从关节点看，形成远景图，你才不会迷失在细节中。 这好比人的眼睛一方面要能看近，就是没有花眼呀。 一方面要能看远，就是没有近视呀。 二者缺一不可，这样才能在脑中反映出完整的事物。 学习与工作中二者都要“相得益彰”。

摘自：http://pm.csai.cn/manager/201009062249021331.htm 如何建立起一支高效的团队，并有效的管理团队，一直是IT项目经理津津乐道的话题。任何一个IT项目经理对此都有自己一番不同的见解，根据自己团队特点，项目经理正在用自身独有的管理艺术改变着自己的团队。 　　项目团队要以十当一，不可以一当十! 　　世界上没有任何两个人是完全相同的，任何人管理自

看了很多人写的关于语言封装的大论。从其表述看，大多是对类这个语言现象的客观描述，比如成员归入类中，隐藏属性，公开接口。 个人认为换一个角度看，试图揭示其本质，是一件能反过来认识真理的思想旅程。 这个角度实际是要先把视线拉回到这两个点上：一是信息，二是责任。你能拉得回来吗？如果拉回来，我们就开始了。 信息如果被看成一件新商品，它将经过很多地点，并经过很多加工后形成。从用户请求它，到返回的期待的

摘自：http://www.cnblogs.com/xuhuan/articles/1417286.html 前面看了前两次的需求分析，虽然其条目扯清了，但仍没有抓住根本，有的甚至把需求分析和类的设计相混淆了。我在这你有必要理清一下做一个项目的思路。学了这么久的程序，也做了不少的项目，但从来都没有顺心过。希望后期有所长进。 一个项目，从客户需求到项目交付，其间要经历很几个阶段，而往往阶

在买商品的过程中，正常人在交钱后，一定会把商品收到自己的手中，细心的人还会检查一下是否有问题。请想一下，这是不是常识呢？ 可奇怪的是，学生在花了钱买教学服务后，收货态度很不正常。经常有人不收货，有人收货不全。实际就是不愿完成基本的作业要求。这样的状态，商品别人又用不上，对教学资源（有限的）形成严重的浪费。这是为什么呢？ 我思考后，发现原因可能有以下几个方面： 首先，没有认识到：知识做为商品，

关于为什么要务虚，请看我的这个博文《务虚的程序员有前途，还是务实的有前途？ 》。 最近压力很大，但坚持务虚不止，收获却很大。 那些看得人头昏脑涨的书越看越有味道。这就是必由之路之一吧。 但在看到每一个技术时，我脑子里却立即想着应用场景中的好与坏。这里，我要特别推荐修行者，一定要时时想着客户。这是个商品社会，你要实现自己人生价值，离开交易是不可能的。你不考虑客户，客户有什么义务管你呢？正所谓

关于为什么务实，请看我的这个博文《务虚的程序员有前途，还是务实的有前途？ 》。 务实，就是与时俱进呀。与什么时，与技术的时。这是个人力量无法抗拒的。 程序员总是要学技术的。 我想从几个方面谈谈如何务技术这个实。 首先，个人必须了解技术潮流的变化。有渠道学习到新技术。这不必多说。要多说，最好有一个优良的技术友人圈。 再次，要掌握度，一定不要沉迷到技术中，并自以为是。一定要明白，你所谓的精通也

有点标题党的意思哈。不过，题中还是应有其本意的。 这就还要看我如何定义虚与实。 先说实吧，因为虚的可能看不着？ 实，硬件是是实，语言是实，操作系统是实，数据库是实，各种API是实，各种框架是实。它们看得见摸得着，对吧？那看看这些实所受到的人类的待遇吧。 先说计算机，买过机算机的人自己算个账，自己淘汰了多少次开始喜欢得不得了的机算机呢。就算升级，它是不是也是对它状态落后的不满呢？况且，升级受

学习过程经常是很累的。学习过的人都有体会。 但进入丛林中也就意味着发现有趣东西的机会。 如果身边的人也有同感，路上会有一只快乐的百灵鸟在歌唱。 创新的成果会释放比drug更强更长久的兴奋。当然最好是价值正向的。

转向分为内部转向和重定向，其技术原理已经有很明确的说明了，在此不想多谈。但在实际应用在struts.xml中时，会有实际应用中的问题，经过学习理解，产生了自己的看法如下： 断定条件：因为用户要的是动态变化的信息，所以转向页面数据要能更新，变化后的数据必须给以呈现。 在控制层中做return返回转向UI页面时，一定要把这个要点做到。其中:delete()，edit()和add()方法(这些方法名

请张开想像力的翅膀：FileterDispatcher大侠眼睛盯着配置文件（struts.xml），右手拿37个过滤器，迎着tomcat送来的滚滚请求， 根据每个请求按配置文件应用其规定的过滤器，把请求送往专业部门人员(类别名和其方法)。当处理结果（result）回来时， 它又根据配置文件的要求，左手拿相应的过滤器处理完后，送到相应的送货部门（v 显示插件12中的一个），交给tomcat,用户

在跟着培训教师的学习过程中，感觉从e-r图开始写出类文件，再写关系用了很多时间。 写完实体类后，还要翻译很多属性类型成为对应的实体类名 。然后再写配置文件。中间费时非常可怕。这相当于一条路，走下去，一定是一条远道。 突然相起来， 有比从e-r实体图开始更正确的起点。 java的根本思想是面向对象。这是不用争论的了。可从e-r图写类是不是反了呢？不要说记不得了，面向对象对软件项目的贡献，我们一开始