程序员如何面对需求变化
在工作中也接触过各种各样的项目，有的注重时间，有的注重质量，有的注重成本。有些项目会随着时间的推移侧重点会有所改变，比如刚开始可能注重质量、后来开始注重成本、最后可能注重时间，因此在这个变化中项目经理为了整体把控好这个项目，一些需求的变动也是再所难免。即使没有上面说的这些情况，一个项目从开始到结尾，需求的变化肯定是会有的。对于互联网行业，一个新产品的出现往往会立为一个项目，这里主要也是针对这样项目来进行描述。产品需求需求变化意味着什么，意味着程序要要不停的修改之前编写的代码，同时也就意味着不能按时下班。那么程序员怎么才能够更好的应对产品的这些快速的需求变化呢？于是乎，业界的高人提到了敏捷、迭代，但是真正能运用好，还是要经过千锤百炼。
我总结了以下几点，如有异议，欢迎指出
1. 了解好项目目的与计划，然后设计基础架构
这里所述的架构是指根据业务需求，决定使用编程语言，程序框架等。
2. 代码要更简单，易理解
程序中，如果非必须，不使用一些奇怪的写法。各函数、类之前的调用方式统一，这样可以减少新人熟悉代码的成本。看一个函数调用过程，就明白其他也类似，好处不言而喻。
3. 模块间要保持松耦合
各模块数据存储要分离，相互间调用使用统一的函数或者类方法。这是因为某些模块是产品的试验性功能，运营一些时间会下掉，或者用其他功能来代替。如果耦合太深，一旦发生这样的情况，其他模块也就遭殃了。更何况每个程序员都有个洁癖的习惯，不希望项目仓库中存在丝毫的无用代码，又不想因此而修改太多代码，所以一定要记得保持松耦合。
4. 可扩展
新增、移除一些功能要非常容易。
5. 性能
提到这一点，每个开发人员都能说出好多条，但是这里不是来讨论如何优化程序性能。刚毕业参加工作的小朋友可能对这个没有太多的接触，但是对于工作有了几个年头的同事来说，常常为了这个要费尽心思。
目前常用的数据存储方式还是 Mysql，有时会加上一个缓存 memcache ，但是在快速迭代的开发中竟可能先不加入额外的存储。最好是使用只mysql，缓存也不使用，这样开发效率就会提升一大截。那聪明的读者你可能就会产生疑问了，上线后服务支撑不住，服务要挂了，怎么办？没错，需要考虑这个问题。架构中设计灵活的插拔式缓存尤为重要，可以在需要的时候开启，不需要的时候关闭，与业务逻辑没有太多耦合。
示例分享：
前段时间，开发一个项目，在某次讨论技术方案的过程中涉及到保存用户基本信息。一些同事认为这个数据会在每次请求中均被调用，放在持久缓存中比较好，可以提高性能，还有一些同事认为把这些信息保存在mysql中，然后在前端加一层内存缓存。乍一看，第一种实现起来比较方便，性能也得到了保障，但是仔细盘算一下第二种方式更好。原因如下：
1. 目前公司提供的统一持久缓存组件偶尔会出现连接错误，如遇此种情况，服务则不可用，而mysql 确是比较可靠。
2. 如果框架中已经设计好了针对 mysql 前端缓存实现，现在需要做的就是对 mysql 表的操作，开发成本也是比较低的。
3. 缓存是基于key-value格式，对一些特殊条件的查询有限制。需求瞬息万变的年代，这个还是要注重考虑的。
4. mysql 是基于磁盘存储，成本低。持久缓存是基于内存+定时落地存储，成本相对较高。好消息是公司内部新版本持久缓存组件已经在底层优化了这个，只在内存中保存热数据，冷数据在磁盘中保存，这样一来成本就差不多了。