近期总结

问题

1. 每个人都感觉自己非常忙却产出非常的少
2. 从我这个角度观察，每天有大量的废话时间，尽管废话时间是与客户交流的
3. 主管人员缺少决断却没有人能够站出来说背起责任
4. 我仍然是缺少项目管理经验，同时还有分出时间来分析任务和分派任务至开发人员

问题的分析

1. 从产出少的角度举个例子
   首先是我们的需求没有人做管理，每个人都围着需求说明书在转圈，没有一个富有项目管理经验的人能够明确的说，好的，我们这个文档做到这里，可以了，更多的情况是，你们这个文档不行啊，太不丰满，继续去摘要输入输出流程描述，不然对不起那几百万的钱。
   以上事实得出一个结论是，缺少文档管理及写作方面的人才
2. 每个人都感觉自己非常忙
   这个的问题是我们前期参与项目的几个人，对着同一个文档，各自不同的部分，做了非常多的重复工作，举个例子是，客户的商品管理，前后出了十个版本，没有一个版本是和客户核对过的。
   这个问题的结论是，在缺乏项目管理经验的状态下，对于项目进度及内容的失控
3. 废话时间这个问题
   废话指的是什么呢，是客户自己无意识中在发散，但是我们这边需求调研人员没有抓住自己的工作主要目的，亦即确认客户需求，客户天花乱坠的吹，我们静静的旁边听，或者是在旁边，嗯，是的，好的，没问题，您听我解释，而正常的情况应该是，大家针对目前的目标，针对性的，比如说630我们只要A需求落地上线，而A中需要拆分成几个不同的过程或者是需求，主导权应该要在我们开发系统的人手上。
   这个问题的结论是，主导项目管理开发的人员缺少决断，并且没有意识到整个项目的拖延是因为自己的没有决断导致的
4. 缺少决断，没人背起责任，这就很清晰了，我在项目开展的第三周，反复提出，已有的不成熟的文档也最好能尽快和客户对接，通过客户的帮助来完成我们的文档，我的提议不一定是好的方案，但是却被很粗暴的驳回（三次），同组另一个同事也曾提出和我一样的意见，驳回的理由很苍白，我的做法是互联网做法，在我们公司不成立的，不能这样搞，在项目依旧进展缓慢的情况下，我其实也已经心灰意冷了，正常来说，在事情出了风险的情况下，只要能推进项目进度的做法都应该是可取的
   这个问题，我认为是领导在制度缺失的情况下，在压力下做出了不正确的做法，他在沿用了他曾经经历过的安全的做法
5. 缺少项目管理经验，这个责任在我，我在这一个月内没有成长起来，例如CMMI实践操作文档我也是最近一周才去看

我提出的解决方案

1. 从总公司抽调两个具有专门技能的人才
   1. 具有丰富的项目管理经验的人一名
   2. 具有现有框架开发及设计经验的人一名
2. 需要以上人员扮演保姆或者是老师的角色
3. 需要有个人提出来，出错在我，你们放心干

有意思的一点是，其实是每个人看起来差异不大，但是人与人通过语言交流真的特费劲，有的人喜欢做什么事情都要先解释一番，有的人很急躁。
抓住一个主要矛盾是，在项目尽可能的规范下，尽可能的快速推进事物。
每个人的立场不同关注点不同，心平气和，放平心态

业务需求分析

1.     调研需求宿主的原有业务

2.     调研需求宿主的诉求

3.     调研需求宿主是否由清晰的规划

业务分析阶段

1.     协助需求宿主梳理原有业务

2.     协助需求宿主新增业务

3.     协助宿主将新增和原有业务合并梳理并确立开发任务

业务需求转化开发需求

待完成

 

首先的首先

调研客户的现状，输出产物，现有流程图+要素表

然后要反复与客户确认流程图是否与客户达成了公式

接着才是将现有流程+客户诉求分解成功能点~！！！！！！！！！！！！！

更新1：按照此思路实现的简单版本

又是面试总结时间

这次面试的是一个初创公司的职位，其中一道题是不可能现场能够给出正确答案的，这里我的思考用时为六个小时。

原命题是：

如何设计一个LRUCache的System。能在接近O(1)时间内完成操作

那么以前两次提到的如何问问题，我们先确定使用场景，这是一个K-V键值系统，其中K-V值很小，但是延时要求高。

我们要求是在普通的服务器环境中构建一个尽可能低延时的LRUCache系统。

第一点是：确定数据结构

因为要以O(1)时间做查询，那么Map结构是跑不掉的，那么我们知道Map从语义上来说不一定是有序的。为了达到有序一定会有个辅助数据结构，这个结构一定是有序的。这是在我脑子里面第一个是小堆。小堆的维持堆结构操作最坏是nlogn，那么在频繁的写时候，并不能满足O(1)的需求，放弃掉；

第二个出现在我脑海中的数据结构是树，同样维持树结构仍不能满足需求；

第三个是我已经离开了面试地点想到的，跳表

这不是一般意义上的跳表，我们按照时间先后使得跳表的查询能够想hash操作一样是计算出来的，此时的hash函数一定是个递增阶梯函数

自然而然的引出了我认为最正确的答案，则是对数据集进行划分。

第二点是：具体怎么做

首先我们按照内存大小进行划分，按照面试官的提示，内存为8GB左右，我们估算一个k-v键值对大约占用100bytes，那么最差会有8.6kw个键值对，我们知道CPU的一二三级缓存速度非常快，即使是遍历也会极快，我们假设CPU的三级缓存有16MB，则我们对数据块的划分为16MB一个那么我们就拥有了512个块，我们可以近似认为在其中遍历只需要O(1)的时间，假设我们拥有一个足够均匀的hash函数能够使得key平均的分布在者512个块，那么我们查询的时间为O(1)+O(k)；k为块的大小远小于整体数据量，此时删除和查询一个或者插入一个元素，近似时间都在O(1)完成。

第三点是：一些其他问题

第一点是，我们的hash有可能不能使得key均匀分布

第二点是，假设服务器还部署了其他应用，那么还要能对空闲的块进行回收合并

总结是：

大部分这种面试题如果当场做不出，也很难当场做出的，要多和面试官探讨

 

持久化

考虑到我们的系统是不稳定的，内存一定不充足的，故而我们要进行持久化，以下是完成持久化类的类图：

缓存层

从技术上考虑，该系统Query的请求会占到绝大多数，且并发数量会高，如果只有DB那么压力会单点压在数据库读上，故而对Query请求增加缓存层，同时考虑到部署的机器会有多台，还要使得多台机器上缓存一致性。

我这边是使用了Redis作为集群通信的中心，完成了一个本地存储的类不便展示，思路是将最近刷新应用信息的时间放在Redis上，只要节点当前的时间比redis的时间新或者相同则不处理，否则重新从数据库中拉去数据

为了简便，没有单独的建立cache的package，只是单纯的在持久层增加了一个ClusterMap，持久化类直接使用

1. 反正内容足够简单
2. 这是我第一次用DDD+充血模型的方式对项目进行分析
3. 这是我第一次完整的完成了整个项目的

其实这次放出来的，是我者离职了半个月之后提炼的，原有的代码其实很冗余，我刚开始建模的时候并没有说把流程，职责区分，也没有把持久化代码和业务模型本身的代码进行区分，导致了后期改动相当的难，最主要的点是有部分业务代码直接用SQL实现了，这并不是一个好习惯。

接下来还有具体实现一个函数时候的状态转换图，还有生命周期图还没有总结好。希望我不要弃坑了