这几个月一直在做一个基于 FastDFS 的分布式存储系统，从前期调研、测试到后面的设计、编码、测试等。其中设计部分，每个环节都和当时带我入行的一位大哥讨论过，时而愁眉不展，百思不得其解；时而一拍脑袋，找到一个很巧妙的设计方法。已经有两个月没有什么大的改动了，上周实在无聊，就把我当时赶工写的，现在看来不堪入目的代码进行了重构。

一切看起来很美好的样子，只是看起来。

部门的开发主要分为后台组和系统组，我属于系统组，主要职责是做底层 linux c 方面，譬如 Nginx 模块开发，存储系统开发等；后台组的职责就是要能从 web 上和我们的系统对接，在更高层面上进行管理，一方面是为了便于公司内部系统的部署和监控，另一方面也是为了和客户对接。

问题就出在和后台对接上，昨天把我们组以及后台组的几个同事拉过来 review 我的代码时，发现现有的 redis 中设计的存储结构存在一定的缺陷。而这种设计的缺陷在公司现在一个主要的视频 cdn 产品中也有，所以后台组的同事们强烈要求在这个分布式存储系统中避免这个问题。

意识到了问题后，昨天下午几个人就在一起把解决方案给讨论出来了。

一切看起来还是很美好。

经过多次血淋淋的教训，我知道肯定不能开始写代码，于是今天我又把这个新的设计拿出来，在纸上画了画，在大脑里细细的想了想。一个让我心惊的问题突然冒出来了，而以昨天讨论的方案，根本无法解决这个问题，吃一堑长一智，这次赶紧把几个主要人员叫到一块反映了这个问题。大家板着小板凳，围坐在小黑板前写写画画，一个小时后终于讨论出一种解决办法。与昨天的方案不同，这次的修改是大规模的，整个 redis 中的数据结构要完全重新设计。

想起以前在华为时的开发场景，软件的架构都是架构师们设计好了，一般情况是没什么问题的，因为架构确定前会经过无数次的大大小小的会议评审。一旦架构、方案确定下来，下面的兄弟们就在各自从属的模块里垒着代码。你不用考虑任何架构方面的问题，你的代码对其他模块的影响也已经降到了最低，一方面是由低耦合的架构决定的，另一方面华为的软件质量体系也予以了保证，例如，可能外面的公司很难理解，华为的一个产品的开发周期内，会专门有一个从上到下的团队，负责版本的构建，通俗点说，就是操作 svn，监控、测试着每一笔代码合入。当然这也是我离开华为的原因之一，螺丝钉感过于强烈。

记得当时主管挽留我的时候，说华为的软件流程在外面是很难找到第二家的，而且这个流程已经深入到制度里了。不管项目多大，涉及到多少团队多少人，正是因为这个流程，这个制度，保证着都能在规定的时间内把东西做出来。

当时我嘴上不说，心里多少还是有点不以为然。

现在到了一个新的公司，做一个新的产品，写了些代码，对软件流程、大公司和小公司的区别有了一些思考。

  1. 积淀、传承。这一点上大、小公司的差别太大。在华为，如果前一个项目的设计有缺陷，在下一个版本时，必然会将其当做重中之重，而不会出现我今天发现的问题。其实只要一个软件的质量够稳定，那么其架构肯定经过千锤百炼才设计出来的。而很可惜的是，再大的公司也不会把这个架构的历史变迁列出来给你看，只能靠自己慢慢深入体会。所以，如果有还在类似于华为的公司工作的同学，对现状不满，但是又不能决定离开时，可以从这一点入手，改变自己的心态，在华为能学到的东西不是没有，而是太多。
  2. 灵活性。这一点大公司当然完全不如小公司了。我今天发现了这个问题，毕竟只是一个小项目，即使完全重做，也没多少难度，但在大公司则很难如此轻松应对了。
  3. 主观能动性。如前所述，在华为做一个小兵其实不用操多少心，但在小公司，如果在你的同事或上级给你一个架构或方案，你当时发现了问题，一定要尽快如实的反馈，和稀泥的方式不会对你有任何帮助。那我今天的事情举例，当时这个 redis 的结构设计，是由那个带我入门的同事设计的，当时我也想到了这个问题，后来不知怎么就自己说服自己没问题了。大公司由于历史积淀深，新员工一般会对老员工带有一种学生膜拜老师的感觉，胆怯，不敢指出问题，而小公司相对而言，很可能里面的资深员工也只比你多工作一两年，年龄相似，发现问题嘻嘻哈哈把问题沟通下就行了。

想的不多，暂时写到这里吧。