柳波 五期信息技术提高班

通过工作的经历来谈，需要考虑：1、需求讨论      采用小型会议的方式，由项目负责人组织，大家逐条需求进行过滤和分析，在这过程中提出对需求的理解和实现思路，每人都要有会议记录。对于需求的不确认点要及时标记，并将最终的不确定需求由项目负责人联系相关业务人员进行确认和定稿。会议结束后，项目主要相关人员，要针对需要写出各自的设计文档，并最终由项目负责人审阅，直到通过方可认为设计完成。在设计

面向对象思维     从宏观上，主要体现在分层，采用包或组件来区分。每一层负责具体的内容。典型应用为mvc。这是保证系统扩充性，可维护性和灵活相应需求的必要条件。 各层之间耦合度尽量降低，如果说每层的业务比较复杂，我们也可以将各层独立出来成为一个服务器，具体的交互方式很多。这里也有很多的概念，比如面向服务，分布式，集群等等。        从细节上，各层直接唯一的交互就是接口或

Bug有一种是技术bug，另外一种是业务bug。目前来看业务bug存在较多。究其原因，还是对bug的态度问题：bug来了，恐惧。       由于出问题，往往会对用户的使用造成影响，因此面对这样的问题总存在一些恐惧。担心对用户造成的影响有多大，担心自己的名誉是否受损，担心自己不能快速解决问题。其实越是这样就越容易让自己无法快速解决问题。担心是无用的，问题来了就要勇敢面对。首要是

项目接近尾声了，在测试环节遇到一些问题，现在归纳如下：1、页面和用户提示与设计文档不符合        产生这个原因是由于长期的产品开发思维限制了我对用户的交互模式。产品力求交互的友好性，可以实施的复杂但是用起来一定要顺心和明了，并且要充分考虑到用户的误操作，基本上每次的动作在关键点上都会有提示，例如，用户数据的删除，关键业务点的提示，异常类型的整合，这样的严格控制保证将用

我们生活在各种各样的环境中，环境对我们产生了很大的影响。然后环境的影响直接反映到的是我们的大脑。最终大脑影响着我们的决策和最后的解决。当我们目标明确的时候，大脑总是积极的相应，它在以一种正精进的方式来影响着我们的行为模式，以致我们无论做什么都充满精力，而且富有效率。但是某种情况下，我们给大脑一个自己都无法察觉到的暗示：懒惰。       这是非常严重的，一旦这样，我们将不再敏感，对身边

讨论这个题目，是最近项目中遇到的一个需求让我联想到了这些内容，下面会有所说明。        依赖是对象之间关联最弱的一种关系，关联交依赖稍强。为了尽量的降低对象之间的耦合度我们推荐依赖而少用关联。具体的表现形式为：方法中的参数为依赖，而对象中的引用为关联。        下面我们结合分层来讨论下关联。我们应该将关联定义到那一层。控制层，还是模型层，模型层细分我们可以定义出业务逻辑

《软件项目管理一个统一的框架》，书中详细讲解了软件管理的复兴，引出了本书重点描述的迭代软件开发过程。       该书分为软件管理复兴，软件管理框架，软件管理规范，未来展望，案例研究和支持资料五部分内容。系统讲解了迭代开发过程中软件生命周期模型。区别于传统瀑布模型，将需求、设计、开发、实施，整合到迭代开发的工程阶段和生产阶段，包括初始、细化，构造、移交。明确了各个过程中产生的制品，包括：管理集

在SSH的开发过程中，常见的分层为：Action层,Service层,Dao层,JavaBean层,其它常量类，工具类，国际化类，Model类，还有视图层。       Action就是常见的Struts2等，Service是定义的一些列业务接口，Dao是定义的操作数据库类，JavaBean是对数据库的一个映射类，Model类是执行具体业务逻辑时为视图层服务。那么这样分层有什么作用呢？它对定义

沉稳，细心，胆识，积极，大度，诚信，担当1、  遇事不慌，说话走路不慌不忙。问题决策，冲动时能够冷静下来。隔天再说。自己不沉稳，难以散发出让人信服的力量。说话办事不可毛躁，问清，弄懂，三思再下决定。以柔克刚，兵来将挡，水来土掩。2、  说话办事有条不紊，学会摸着石头过河。步步为营。能够发现生活中的习惯，发现别人的习惯。对于事情的结果，要分析出因果关系。所有的结果都是有原因的。细心的总结和体

以前调试代码总会有这样一个习惯，问题来了总是盯着问题看。于是一遍遍的调试，每次调试都会到这个问题，于是又调试又是这个问题，往复几次仍然没有思路。问题在哪里呢？问题就在于总是盯着这个问题，没有去联系，发散。这样即便解决了问题也是偶然，下次遇到仍然是一个坎。          应该跳出这个问题，考虑是业务错误还是代码逻辑错误，从整体上分析这个错误，找到问题的本质。然后下手跟进错误。想办法，找思

如何学会发现：         平时多细心观察，多思考，多学习。总结规律。有一个两个，我能不能弄出三个四个，由三个四个我能不能弄出八个十个，以此我能不能弄出更多。如果这样都成功了，那么我们可以说这是一个较为科学的规律，在数学上叫归纳法。其实这样还不能完全下定论，我们只是假设这是可以成功的，然后去做，围绕着成功去做，将不成功的踢掉换成以为会成功的，然后再去做，然后再替换，那么最终我们必然会获取成

最近为客户写了一个Base64编码的实例代码，主要业务如下：        首先是A和B两个项目，在B调用A项目的一些服务过程中，A项目也需要在特定的时刻调用B项目的信息，所谓回调。当A回调B的时候，B需要准备一些数据，以xml格式封装，并经过Base64编码后传递给A，A接受到会Base64解码，然后分析xml数据最终给出提示。         实例代码很快就完成

背景:            统计当前店铺下订单信息。根据订单开始时间，结束时间，商品id，商品名称，商品编号来获取。并可以导出基本信息和详细信息。涉及主商品表，子商品表，订单表，订单商品关联表。其中商品表信息和订单表记录数较大。 实现思路：        1、  从数据库中获取店铺下所有商品信息P，而不是按照条件来查询。        2、  由于商品信息改动较小，因