摘要：
上一篇说道遇到紧急情况考虑三个问题：具体发生的原因，何时可以修复，接下来的对策。 判断条件：影响用户的层级，越影响付费用户，严重程度越高。 越严重就越需要调动其他资源来帮忙处理，可以相应推延手上任务。 阅读全文
摘要：
不能当传声筒，交给下面的需要必须先理清楚然后才能交给开发人员。交付的时候必须说明为什么要做这个功能，需求来源和目的。 工作汇报的时候抓住重点，主要实现哪些功能，接下来要实现哪些功能，简单明了。必要时提出相关问题。 遇到突发事件，责开发的小伙伴沟通，然后随时跟进处理情况。抓住三点：具体发生的原因，何时 阅读全文
摘要：
项目管理流程 流程 目的 注意事项 相关人员 可行性分析 由产品或运营处获取大概需求后，从公司的硬件水平，软件水平，工时排期，所需资源等几个方面评估需求的可行性。 重点考虑所需技术实现难度和人员学习投入资源时间，决定不了可以咨询CTO，不能妄然下结论。 需求方（产品、运营），技术支持（CTO） 投入 阅读全文
摘要：
访问者模式：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。 访问者模式适用于数据结构相对稳定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由地演化。 访问者模式的目的是要把处理从数据结构分离出来。有... 阅读全文
摘要：
解释器模式：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。 如果一种特定类型的问题发生的频率够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。------正则表达式 阅读全文
摘要：
享元模式：运用共享技术有效地支持大量细粒度的对象。 在享元对象内部并且不会随环境改变而改变的共享部分，可以称为是享元对象的内部状态，而随环境改变而改变的、不可以共享的状态就是外部状态了。 享元模式可以避免大量非常相似类的开销。在程序设计中，有时需要生成大量细粒度的类实例来表示数据。如果能发现... 阅读全文
摘要：
中介者模式：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。 优点：Mediator的出现减少了各个Colleague的耦合，使得可以独立地改变和复用各个Colleague类和Mediator。由于把对象如何协作进行... 阅读全文
摘要：
职责链模式：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。 好处：接收者和发送者都没有对方的明确信息，且链中的对象自己也并不知道链的结构。结果是职责链可简化对象的相互连接，它们仅需保持一个指向其后... 阅读全文
摘要：
命令模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录日志请求，以及支持可撤销的操作。 第一，它能较容易地设计一个命令队列；第二，在需要的情况下，可以较容易地将命令记入日志；第三，允许接收请求的一方决定是否否决请求；第四，可以容易地实现对请求的撤销和重做；... 阅读全文
摘要：
对象的继承关系是在编译时就定义好了，所以无法在运行时改变从父类继承的实现。 子类的实现与它的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。 当你需要复用子类时，如果继承下来的实现不适合解决新的问题，则父类必须重写或被其他更适合的类替换。这种依赖关系限制了灵活性并... 阅读全文