事实上,对于列表,被读取机会最多的应该是列表的第一页,这个时候我们只要缓存了列表的第一页,基本上就解决了列表被处理的问题.之前我总是想,对于列表首页缓存:章士挺

之前的算法:章士挺

1 我们必须知道哪些数据的修改会导致列表首页的变化;章士挺

2 如果发生了变化，我们需要重新加载列表然后更新缓存来保证列表的真确性; 章士挺

这个算法的问题是，每次我们都需要读取数据库来同步列表的缓存章士挺

那么如何才能在发生变化的时候不读取数据库呢?章士挺

假设我们只需要在一些数据发生变化的时候修改被缓存的列表首页,这些修改仅仅是局部的和最少量的.同时我们又要保证列表的顺序.这个要求让我想到了栈.这个后进先出的数据结构.用类似于这样的结构来处理我们的列表缓存问题是一个绝妙的搭配:章士挺

现在的算法:

我们需要一个这样的数据结构:后进先出的,同时数据进入的时候如果超过设定的数据容量,删除最早进入的数据.可以指定结构中任意一条和多条数据的删除,同时重新整理数据次序,然后返回剩余的数据数量.我们还需要该数据结构提供修改任意一条数据在该结构中的位置.我暂时称它为缓存栈章士挺

1 首先我们第一页列表，放进缓存栈进行缓存;章士挺

2 发生数据变化的时候，第一种情况是新的数据添加了,那我们需要修改第一页缓存的时候，我们仅仅是往缓存栈里面放入新的数据,第二种情况是一条记录被更新了，我们需判断要将这条记录放入第一页缓存栈中还是已经在缓存栈中，我们需要更新它的位置;

3 这个时候我们必须注意，我们放入的数据是否是在缓存栈中已经存在，如果存在，我们需要剔除;

3 当被有数据被删除的时候，我们需要到缓存栈里去判断，是否有数据已经需要剔除.这个时候问题来了,我们缓存的数据变少了,变少带来的问题是我们第一页显示给用户的时候也少了,例如我们每页显示20条的,现在却只有19条了.为了解决这个问题，我在设计这个缓存的时候，我从数据库加载了超过一页20%的数据,以减少数据被删除而去加载数据的问题.因为我们的数据被批量和大量删除的比例很小.章士挺

4 仔细想象删除数据的问题: 我们又如何定位删除的数据就在我们缓存的位置间呢?首先，我们不能去读数据库来判断;其次,我们一定需要知道哪些范围内的数据在我们缓存的列表数据间.很好，这个时候我们需要保存缓存数据的列表范围.只要我们有了范围可以直接知道需要更新被缓存的列表缓存栈数据.

5 这个时候又有问题出现了: 被缓存的缓存栈中删除的数据到了不够一页的时候,我们怎么处理呢?首先, 我们必须判断这个时候一定条件下总的数据列表是否已经超过了一页，如果超过了.更新缓存栈的工作就会被激活.否则这个动作永远也不会被调用.章士挺

欢迎加我MSN交流: avazst@hotmail.com

1、细粒度的设计：大数据表的拆分和冗余，比如我们将文章实体的基本信息拆分成文章的基本数据表和文章的统计数据、时刻变化的数据两个表。使用中心缓存服务器缓存文章基本数据表的数据，第二张数据表保留了统计数据和复制了基本表中需要列表内显示的基本数据，包括作者名称、发布时间、修改时间等关键的数据。还有对于特定应用的缓存进行按需设计，只对我们需要的数据进行数据的缓存，进行特定模块的缓存编程，解决缓存数据的利用率和命中率。

2、建立职业博客首页的快照，通常我们保证这个快照在24小时内更新一次时刻在改变的统计数据，或者会在更短的时间进行数据的更新。在这个设计上，要点是：在首页中哪些数据的变化会造成快照的同步更新？包括留言、文章等这些关键的数据。为什么不使用简单的中心缓存来解决页面的复制呢？主要的问题是，我们将首页的数据变化以静态文件的方式进行异步的数据复制，也就是说，当我们认为一些数据的更新需要更新快照的时候，程序只发出更新的请求，客户端程序不关心更新的过程和结果，以及是否失败。理想的情况下，会有某些主机专门处理这些异步的数据复制。

3、缓存变化相对小的列表数据，这里指我们把数据缓存在中心缓存服务器。比如我们缓存文章、图片的第一页评论，缓存博客首页的最新留言，置顶文章、第一页文章列表，以及各种评论等这些相对变化小的数据。

4、有一些数据是系统中到处都会被用到数据，这些数据有时候是我们通过访问多个数据库表格获得的，比如用户的数据包含了用户头像、名字、登陆名、职业类型、最近文章等这些需要多个地方获取的数据视图，而这个视图数据的更新频率是可以预测和不会太频繁的。那么我们缓存这部分数据，当任何模块需要用到这些数据的时候很多时候都是读取了缓存的数据。

5、在应用程序和数据库之间使用数据库中间件，使得支持伸缩性、高效、失败转移的等特性的数据库集群.这样我们就可以考虑使用用例驱动的分表分库等设计,在客户端程序避免了对复杂分表分库带来的不透明的编程难度和没有宽展性.

6、非同步修改的多层缓存：在中心缓存中的数据将被整个集群服务器访问，而对于客户机来说，需要的数据总是要从中心缓存服务器获得，这个时候，为了避免频繁的通过网络去获得一份可能在一段时间内不会发生频繁变化的数据所带来的网络吞吐开销，我们设计在得到数据的同时复制到客户端进行缓存，这个层面的缓存是一种完全的复制，包括缓存所使用的key和value，设计上我们需要保持第一次读取的时候设定一个和中心缓存一样的缓存过期时间，这个地方为了避免在客户端缓存可能将要过期的中心缓存数据，我们设定了客户端缓存的过期设定策略：对某一个时间段内要过期的数据不进行客户端缓存。

...........

1、必须明确目标，当然这个目标包括组织的大目标和个人的小目标。这个目标体现了能够为我们的商业价值提供什么？我们要得到什么？个人的目标应该更多的问自己你为组织付出什么？你的使命是什么，什么对你来说是重要的？明确一个目标就是明确了一个团队的方向，在经历了一个公司的多次失败过程中，我深刻的体会到明确目标对团队的重要性。

2、决策和执行，没有决策的人是无法学会管理的，学会在一些结果和做法之间决策。光有决策没有执行力就是空谈。决策并不是行政术语，决策是对太多信息的有效判断和决定，也是对太少信息的推测能力，没有决策就会失去方向，就会使得团队疲于奔命。而执行力就是决策的延伸，执行力不是严格的管理术语，因为执行力是团队每个成员的高效的基本素质。

3、诚信和遵守诺言，在一个团队中，这些决定了你可以获得的信任，也是团队合作的基础。如果没有了这个，团队就无法高效的合作。作为团队的领导者，人格魅力就是你的价值。

4、富有激情，我始终相信激情是创造力的根源，有碰撞的团队和思维活跃的团队才能创造奇迹，才能更加有效的达到伟大的目标。其实我相信每个成员都会有激情，关键在于如何去挖掘。鼓励成员去探索，远比你告诉他要怎么做来得有价值，因为我们需要思考的团队，需要有创造力的团队。当然培养思考问题的方法和富有激情的环境是领导者的任务，我们不能将这个责任推卸给团队的其他成员。

5、适应能力强的团队,如果说一个团队无法面对时刻发生的变化,那么面对激烈竞争时失败的机会就会远远多于成功的机会.不论从管理机制上我们需要适应力强,每个成员也需要有一种面对变化快速适应的能力.只有这样才可能在竞争的环境中脱颖而出.

6、团队合作精神，这个也许是团队管理中最重要的部分，没有协作就没有生产力。我们鼓励个人能力的提高，但是更加坚持协作的重要。如果因为个人而对团队造成大的影响，这无疑是团队领导者的责任。

1.4. How does it work?
C-JDBC provides a flexible architecture that allows you to achieve scalability, high availability and failover with
your database tier. C-JDBC implements the concept of RAIDb: Redundant Array of Inexpensive Databases (see
Section 10). The database is distributed and replicated among several nodes and C-JDBC load balances the
queries between these nodes.

1.4. 它是如何工作的？
C-JDBC 允许你实现可扩展，高可用性和失败转移的数据库层灵活的体系架构。C-JDBC实现了RAIDb的概念：廉价的数据库冗余阵列(查阅第11部分).这些数据库是分布式的和在一些结点之中复制以及C-JDBC在这些结点之间进行查询的负载均衡。

C-JDBC provides a generic JDBC driver to be used by the clients (see Section 4). This driver forwards the SQL
requests to the C-JDBC controller (see Section 6) that balances them on a cluster of databases (reads are load
balanced and writes are broadcasted). C-JDBC can be used with any RDBMS (Relational DataBase Management System) providing a JDBC driver, that is to say almost all existing open source and commercial databases. Figure 1 gives an overview of C-JDBC principle.

                                                                        图例 1. C-JDBC原理

C-JDBC为使用它的客户端提供一个通用的JDBC驱动(查阅第4部分)。这个驱动将这些SQL请求转发到在数据库集群之上均衡处理(读取负载均衡和写入广播)它们的控制中心(查看第6部分)。如果使用一个JDBC驱动C-JDBC可以使用于任何RDBMS(关系型数据库管理系统)，即几乎全部现有的开源和商业数据库。图例1大致说明了C-JDBC原理.

C-JDBC allows to build any cluster configuration including mixing database engines from different vendors. The
main features provided by C-JDBC are performance scalability, fault tolerance and high availability. Additional
features such as monitoring, logging, SQL requests caching are provided as well.
The architecture is widely open to allow anyone to plug custom requests schedulers, load balancers, connection
managers, caching policies, ...

C-JDBC允许你构件任意集群配置，包括不同的供应商提供的混合的数据库引擎。由C-JDBC赋予的主要的特性是性能可扩展性，容错能力和高可用性。同时也赋予了其它的特性，例如监控，日志，SQL请求缓存。该体系结构也是完全开放的，它允许插入自定义请求调度程序，负载均衡，连接管理，缓存策略，...

1.5. What does it cost?

From a software point of view, C-JDBC is an open-source software licensed under LGPL which means that it is free of charge for any usage (personal or commercial). If you are using commercial RDBMS (such as Oracle,
DB2, ...), you will have to buy extra licenses for the nodes where you install replicas of the database. But you can
possibly use open-source databases to host replicas of your main database.
You need to buy extra machines if you want more performance and more fault tolerance. C-JDBC has been
designed to work with standard off-the-shelf workstations because it primarily targets low cost open-source
solutions but it can work as well with large SMP machines. A standard Ethernet network is sufficient to achieve
good performance.

1.5. 使用它有什么开销？
从一个软件的观点来看，C-JDBC是基于LGPL许可之下的一个开源的软件，这就意味着任何使用都是免费的(包括个人或者商业)。假如你使用商业RDBMS(例如Oracle, DB2,....)， 你将必须为这些商业数据库结点购买额外的许可来安装你的数据库复制功能。但是你可以使用开源数据库来支持对主数据库的复制。
假如你想具有更高性能和容错能力，你需要购买额外的硬件设备。C-JDBC 被设计成可以工作在不需要定制的标准工作站，因为它主要定位于成本低廉的开源解决方案，但是它同样也可以工作在SMP(大型对称多路)主机系统。一个标准以太网就可以发挥非常好的性能。 

1.6. What kind of modifications are needed?
You do not have to change anything to your application or your database.
You only have to update the JDBC driver configuration used by your application (usually it is just a configuration
file update) and to setup a C-JDBC configuration file (see Section 11).

1.6. 需要什么样的调整的？
你不需要改变任何应用程序或者你的数据库。
你仅仅需要更新你的应用程序所使用的JDBC驱动配置(通常仅是一个配置文件的更新)和配置一个C-JDBC配置文件(查看第十一部分)。

第一部分结束 待续. 

总体的一些思路章士挺

1、  在不进行任何折中和成本考量的前提下，想出任何你的好建议和好的想法，并且进行罗列；

2、  彻底寻找问题，对目前的已有的设计和方案提出任何疑问，不要考虑任何因素；

3、  以上两种情况下产生的结果进行整理和排列，列出结果矩阵，然后权衡和度量可行性。

模块设计的大致需要考虑的方面章士挺

1、  关联性：考虑和当前的模块关联的全部其他模块章士挺

这里的核心是这样的，你必须真正的了解所要完成的功能的全部需求和真实的商业价值的预期。哪些功能模块直接关联你完成的功能，哪些间接关联你完成的功能，你使用什么样的策略来进行关联，如何才能解决耦合。

考虑当前模块未来可能会和谁关联，怎么样关联。

2、  模块稳定性：考虑当前模块在未来可能发生怎么样的变化，你的设计是否可以在一定的程度上适应变化

你的设计是否可以比较容易的面对变化，或者说未来代码改动的余地不会是大面积和大动作的？从最低层的数据库层，我们需要知道哪些数据是永远固定的，哪些数据是暂时固定的，哪些数据是完全不固定的，而哪些数据是未知的。从功能上，必须分析出哪些功能是稳定的不会发生变化，哪些功能是容易发生变化的。针对可变的进行扩展开发，不会变的进行稳定的设计。

3、  复用性：尽量的寻找成熟部分，进行高层的抽象，使得可以很好的被今后的代码复用，提高效率和降低维护成本。章士挺

4、  效率：考虑你当前的设计和算法是否是目前为止最高效的章士挺

必须使用最高效的算法来进行你的设计，一般来讲，可以只操作数据库一次完成的事情，坚决不使用两次，可以只取一个字段的情况，坚决不取两个字段。当然这个并不是绝对的，应该也有一个度，在保证代码可读性和一定的可扩展性的前提下，适当的使用资源是被允许的，同时局部性能必须保证全局的性能。这里比较典型的一个例子就是当你删除一条记录的时候(使用hibernate的时候)，能不先加载对象就坚决不加载对象，如果是有条件的，那么请直接使用delete语句加删除条件。

5、  易用性：考虑你当前的设计是否是界面友好，而且已经足够简单容易操作的。

不论什么时候，要把用户想象成最没有耐性的最恶劣的和最无知的操作白痴，然后再设计你的用户界面和流程，尽可能的简单和容易理解。比如可以在一步完成的工作千万不要让用户操作两步，任何可能造成误解的地方必须提供详细的说明。在成本允许的前提下，任何可以改进的用户操作的地方坚决不能放过改进。

编码基本原则

1、  只暴露最少的接口到外部

暴露的接口必须是完整的，对于外部，尽量不要让客户代码调用多次不同的操作才完成一个功能。学会使用作用域来控制访问的范围。比如，内部重构出来的辅助接口，尽可能设计成protected，复杂和不想被复写的接口，请使用final关键字等等。

2、  对已有代码进行重构重构，再重构

只要发现可以重构，就马上重构，然后尽快的单元测试。

3、  充分考虑功能操作时的环境资源情况

功能必须充分考虑执行的权限和任何执行的资源。比如删除功能中，必须考虑什么时候、谁、什么条件下可以删除。发生这个动作的时候，要知道需要系统处理什么内容，如，是否使得缓存无效，是否要通知其他某些程序(类似于需要implements某些监听接口、需要callback、还后我们系统中部署的JMS服务)。

4、  充分考虑可能发生的任何异常情况

对于一个功能的任何异常情况必须非常正确和完整的告诉用户发生了什么异常，设计的过程中必须认真的寻找可能发生的异常的各种情况，给出完整的异常处理方案。代码中也要正确和完整的设计异常体系，不允许对关键异常抛出Exception、RuntimeException之类的异常，请务必包装。

开发规范的细节：章士挺

序号	类别	说明
注释
1	注释的量应该是源代码的20%左右章士挺	代码中只要是有略微复杂的逻辑和算法的地方都需要进行注释，并且必须保证注释的可读
2	模块中全部文件都必须进行描述、版本著作的注释章士挺	具体的注释格式请参考编码规范
3	修改代码的同时必须同步修改注释，保持注释和代码的一致性	千万不能保留无用和过期的注释
4	注释必须放在逻辑代码的最临近的位置	语句上方，逻辑块的上方
5	常变量、方法、类等命名必须可以明确说明其含义，如果无法明确说明，就必须使用注释进行详细的说明	有一些逻辑可能过长，无法命名解决，那必须附上注释
6	注释必须和描述代码的排版一样保持同级别的缩进章士挺	章士挺
7	空行隔开注释上面的代码章士挺	章士挺
8	对条件和分支语句必须添加注释章士挺	在各个条件的开始说明，分支的开始地方进行说明，每个case语句都要进行说明
9	对与公开接口的注释必须是详尽完整的	包括接口的含义和需要注意的问题，甚至复杂的接口还需要包含使用示例。
效率
1	在正确性、稳定性、可读性及可测性的前提下，时刻保持对效率，稳定性的苛刻要求	写代码的时候要注意是否保证了最高的运行效率，当然局部效率必须为全局效率服务
2	变量、语句、算法逻辑等代码必须在这些最近使用到的地方进行定义和执行运算	不能将变量定义到很远部位，一直到执行了部分代码才调用。也不能将语句块的执行提前，一定要到需要使用的时候才执行。
3	在循环体内不能出现任何冗余的代码	把任何有办法可以在循环体外处理的代码移到循环体外进行，特别是对数据库的操作，以及复杂算法的执行。
4	对数据库操作，如果能一步完成的，如果性能可以提高的话，不要拆分成一步以上	特别是为了静态条件而加载数据库的一个对象，然后再依据条件加载另一个对象这种没有意义的操作。当然有时候不排除加载多次比join的效率高。
代码维护
1	必须注释或删除无用的代码，包括程序片段、方法、类、各种配置信息、数据库表、表字段等等。章士挺	这里可以使用注释的方式注释部分历史代码，方便查看改动了哪些问题。对于历史代码的清理可以方便维护人员定位问题，也保证了项目中可以不存在无用垃圾数据，降低了维护成本。
2	修改完成必须同步修改单元测试，保证单元测试的可测试章士挺	章士挺
3	保持每天版本更新的习惯	为了防止维护代码带来的系统bug和可能存在的版本冲突，必须经常更新的操作。
4	对于修改复杂的和重要代码必须说明原因	特别是一些会影响业务逻辑的代码，如果不加注释，定位问题的时候会非常的痛苦。
5	不能随意修改公开方法的接口和内部的逻辑，如果必须修改，必须严格的说明原因和修改的地方，以及之前的逻辑,在eclipse中使用Open Call Hierarchy查看接口或类被那些地方调用。	异常重要的点，特别是逻辑修改了以后。
测试
1	必须对全部的业务层的接口进行单元测试，包括领域逻辑层和控制层的代码	章士挺
2	对方法的测试仅可能的达到逻辑语句覆盖章士挺	比如判断、分支、条件、异常、状态改变等等这类语句发生的地方需要测试覆盖
3	保证单元测试的有效性。章士挺	修改代码完成的第一件事情就是重新修改单元测试
4	完成的功能要进行自我的集成测试，使用各种数据和各种操作方式进行测试。	察看修改后的代码有没有对别的功能产生影响
接口设计
1	设计接口的时候，尽量保证接口内的代码逻辑单一章士挺	通常不应该在接口内处理太多的逻辑，如果一个接口过分臃肿，应该考虑重构。
2	会发生各种情况的业务逻辑层接口尽量不要使用void作为接口的返回类型章士挺	逻辑执行的情况千变万化，如果没有返回值，就无法在调用它的客户端代码中进行有效的处理，这将严重影响接口的可扩展性。
3	必须完整的说明返回类别的意义，各种状态下的各种情况	章士挺
4	一个接口如果执行中可能产生多种不同的情况，那么我们不能返回boolean来仅仅判断是否执行成功	章士挺
5	如果对传入的值有特别的要求，需要在参数列表注释中明确的说明章士挺	通常，参数都需要简要的说明，比如参数可能在方法体内被改变，或者参数必须保持一定的格式，就需要很明确的说明。
6	遵守异常处理的原则，明确是否需要抛出异常。并注释说明为什么要抛出异常。章士挺	一般情况下对于无法预知的情形或者发生错误的时候希望外部知道，系统应该抛出异常，对于理论上不应该发生的错误，抛出运行时异常。尽量定义自己的异常类，不抛出高层次的异常类。
类设计
1	职责明确化章士挺	每个类只做该做的事情，不要让一个类过分庞大，过分庞大的类造成阅读困难，维护困难。
2	尽量使用接口隔离的模式，同时只暴露刚刚够用的接口到外部，使得遵守开闭原则。章士挺	面对接口编程，而不是实现编程。这样就可以有效的将依赖关系抽象到更高的层面。不同的底层细节对于客户端代码就没有必要知道了。特定的模块内如果需要使用其他模块的数据或者业务，坚决不能自己直接调用数据层进行硬编码，一定要协作，要求对方模块提供相应接口。
3	面对很大的服务接口，尽量使用接口分离的原则，比较好的模式就是使用聚合。章士挺	可以让一个大的服务对象聚合多个接口来完成不同的类别的业务操作，这样就可以在修改了其中一些接口的时候不影响其他接口调用者的代码。
4	只开放相对比较稳定的而且非得开放的接口章士挺	千万不要定义一堆public的方法，而根本就没有让客户端使用的打算。尽量的简化客户端代码的操作。
5	工具类应该尽量多重载方法，而不是使用参数决定执行不同的代码，执行代码的多寡章士挺	特别注意：工具类尽可能的给出接口示例，同时包括详尽注释，包括参数和参数格式、接口功能、异常处理、返回类型。

 章士挺

1、招纳优秀的测试人才；

2、统一进行bug递交的规范化管理；

3、培训各部门bug递交的有效性。

实施：

1、找到一个非常不错的bug管理软件，部署并且顺利的使用；

2、新招的测试FLY王很不错，做事情耐心细心；

3、我太缺乏管理经验，没有能很快的对她的工作进行一个有效和快速的安排；

总体来讲，这次缺陷管理的计划安排顺利，执行也顺利，各个部门和人配合积极，感谢同志们对技术部的支持。

总结：

敏捷方式的第二个实践点顺利部署，现在就开始要对缺陷管理进行更加细化的工作安排，找到问题，并且使得缺陷管理更加有效和规范。