近期总结

问题

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

问题的分析

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

我提出的解决方案

1. 从总公司抽调两个具有专门技能的人才
   1. 具有丰富的项目管理经验的人一名
   2. 具有现有框架开发及设计经验的人一名
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均匀分布

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

总结是：

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

其实吧，这个问题问出来是没有答案的，因为在实际业务中会有很多种使用场景，我们需要按场景来分类才能得到真正的问题

必须要服务端全局有序的

数据量小的时候，直接快排

数据量较大时候，对数据做分段，然后归并排序

不需要服务端全局有序的

数据直接交付client处理排序

而client有区分是否是强力PC使用还是弱计算能力的计算设备

 

除了以上，还要区分，要求一直有序还是说，最后输出的时候有序，还是说其他需求

以面试时候提到的跳一跳排名来说，其实根本没有服务端排序这个事情，小程序获取成绩应该是三个步骤：

1. 获取用户列表中已开通跳一跳的用户
2. 获取步骤1中所有user的成绩
3. 对成绩按大小倒序排

就会发现和前K大这个问题没有任何关联。。。

总的来说。。我发现面试的数据结构题目对于强人和应试型人才很有优势。。but，我这种经常是时候脑袋一转发现不对的人来说是很难的。。。毕竟我的注意力也不在这里面。。

2017总结

时间线

一月份：还在华为忙活用户关键动作信息记录的系统

二月份：对接了OSS存储

三月份：接收到深圳市理才网的工作邀请，面试之后觉得公司还不错，工作氛围好，福利也不错。

四月份：正式入职深圳理才网

五月份：接手理才网应用市场

六月份：预研理才网应用开放平台

七月份到十二月份：理才网应用开放平台研发

十二月份：理才网融资困难，我这边就离职了

感想

• 其实大部分情况下，外包是可以去的，但是一定要了解清楚外包到什么平台去，具体项目组很重要，外包到腾讯阿里华为百度等公司其实这个工作经历也是能吸引很多HR的目光的
• 软件研发中，写代码真的是最不重要的一个步骤，更关键的是业务的设计，越来越讨厌一部分人的如下这些话：“不就是加个数据库字段嘛”，“不就是多展示一个页面嘛”，很大程度上这些需求的出现都是设计阶段的不合理。
• 一定要业务代码和SQL分离，否则你只是在用业务代码写SQL SCRIPT
• 在理才网的时候，同组的有位同事是曾经自己创业的，给我们还做了次分享教我们如何分辨一家公司是否真的有前途，真的觉得所谓技术就不一定是一个开发人员的所有。作为一个公司的员工，更重要的是学会分析你到底做了什么，你做的事情意义何在，代码更多是实现你做事情的手段。

其实扯这个话题是因为今天开会的时候我生气了，我其实真的很生气，还得笑着对人

第一点，作为一个领导，下属在任务进度迟缓的时候不应该是发脾气；

第二点，项目延迟也是作为领导拍板说用新技术带来的必然的结果；

第三点，作为一个开发，很清楚东西不是说加班赶进度就能出来的，加班能解决的，只能是设计好的东西。做到一半发现以前承诺的实现都是作废的，需求已经变更的很厉害。必然项目是会延期的。

 

 

 

 

领导力说穿了，不是说一个人对一个领域钻研的深了就自然而然的可以成为这个领域的领导人。

“领导”本身就是一个领域。这无关乎你对所在行业的钻研深度，而关乎待人接物的习惯。

其实这次让我回想起我在华为赶进度的时候。

我们当时真的就是项目定死了什么时候提测试就是什么时候提测试，每个人都有自己的工作，而刚好我手头上的任务的需求是从项目开始就在变更。

我在提测的前一天晚上都还在改需求（用户操作历史纪录）代码。其实我当时是真的非常紧张了的，当时也没有说平静的心态来写代码，这导致了，修了一个bug然后冒出另一个bug。

但是我的团队很给力，当他们手头上的事情忙完了，都过来帮我梳理需求，编写用例。经常负责事物类的兄弟还独立整理好用例表格，一起把所有事项确定下来。就算是我的直属领导也没有说发脾气什么的，也是说在人力上倾斜多一点到我这来。到了十一二点还和我一起打车一起回家。

我一直很感激我在华为这段经历，真心学到了很多东西，像项目管理的习惯，做事的方式，尽管我因为住的地方离华为实在是太远而且不方便搬家，才换到了新公司，我依然很是怀念这段日子。

 

软件开发的领导说穿了是什么：

1.项目的发起者；

2.项目进度的管理者；

3.项目的背锅者；

4.必要时候是软件开发的参与者。

起码我认为读过《极客与团队》这本书的人都能多多少少懂的点领导者的艺术。

三月十号提的离职，

接下来两周各种交接工作，第三周开始就开始无聊了。。。

说起来忙的时候反而更愿意学习，闲下来了反而不愿意，宁愿在网上瞎点。

包括连三月初我非常感兴趣的JVM的研究，Windows有时候真的对程序员不友好，起码各种工具的exe没有完整的注册自己，跟着一些教程走简直就是给自己挖坑。

蹲在公司有一点坏处，写的代码不能传网上，包括自己写的，这就很蛋疼了。而且不参与开发的话，就不会产生出一些idea

不过这一周准备过完了，马上就是放假了，期待新入职的公司能够得到一些我没见过的视野。

 

分别从用途，风险和好处来思考了下，只是很粗浅的思考，刚好我所在的项目就是做账号平台，才用来思考