优化杂谈
前言
这是一个宏大的话题，本不太适合作为一篇文章的内容。
实际上，在程序员这个行当，哪怕仅仅只是做一般性开发的java工程师，需要掌握的优化技能也是非常之多，而每个优化有关的主题，其实都可以写一本厚厚的书。
本文最要的目的是对优化做一个最简单的说明，提醒读者：优化很重要，要有技巧，要认真持续不断地学习！
虽然优化是吃饭一样想当然的事情，但是还是有些人不太了解，主要是那些新入行的工程师。
限于篇幅，不会讨论具体的优化技术。本文只讨论一些技术之外的内容，希望引起工程师对于自己代码的重视。
优秀的工程师和优秀的医生是一样的
优秀的工程师常常要诊断问题，面临问题的时候，他们的表现和医生以上：
- 望闻问切-从巨多的信息中发现病灶
- 开药方-找到问题之后，采取对应的措施
要成为一个优秀的工程师/医生，都必须付出无数的辛劳，对有关的技术必须千锤百炼。
为了做好项目，优化应该从头开始
团队接到项目之后，一开始就必须重视优化的事情，这个最重要。
之后有关人了解需求，展开设计，并确立需要优化的内容！这个思想和中医差不多，好的设计项目应该从需求方面就开始预防可能的性能问题。
从头开始，会简化优化的工作，也会提升优化的成效。
不要到最后才考虑优化。所谓“一步错，步步错”，也是这个意思，有时候头没有开好，想要调整或者逆转就会格外费劲。
至于是否“万劫不复”，则看开头的时候错得多不多！
所以，每个项目都应该首先充分重视需求和设计。
问题定位
这是解决问题的第一步，又是又可能是最难的。
我们的身边都有很多亲戚朋友，有许多的熟人。活得久了，就会发现医生的诊断水平千差万别，庸医居多，而良医和神医总是很少。何也？
因为要成为良医/优秀的诊断工程师，有些条件是不可或缺：
- 仁心/职业道德
- 天赋
- 努力
- 机遇，足够的经验
世间，总是庸医巨多，这是符合实情的，因为要满足以上4个条件，并不是那么容易。
一个人/工程师如果总是关心自己的吃饭技术，对行业有所敬畏，那么必定会非常努力，非常认真地去学习，去实践！
权衡和选择
发现了问题/病灶之后，如何救治，则会面临许多现实的问题：
- 要不要治疗
- 应该用什么药
因为这些都和各方金钱/时间/能力密切相关。
如果是举手之劳，自然乐得卖个人情。如果要耗费许多的资源，那就需要好好斟酌。
例如发现系统太慢，仅仅是因为服务器硬件的性能太差，那么要不要优化？钱谁来掏？还是说把系统的需求削减？
不同的需求可能会有完全不同的设计(实现方案）
这个也很容易理解，譬如甲方给100万建设桥梁，那么必定有巨多的选择。
例子-文件服务器设计
企业要求建立一个云文件服务，存储所有员工的文件，要有权限控制，要有一定的性能，要方便使用！
于是让设计师A主导设计。
第一次设计
- 存储：使用一般的操作系统文件方式
- 能够上传/下载就可以了
用户反馈问题：有时候非常卡；有时候不小心网络断开了，还得重新上传；每次只能上传一个；用了一段时间之后，下载速度巨慢；
第二次设计
针对用户提出的问题，仔细分析了下可能导致出现问题的原因：
1.有时候非常卡，通常是因为同时又许多人上传，已经超过了
2.网络断开，这是不可避免
3.用了一段时间之后，服务器已经有超过30000个大大小小的文件，占据的空间大约有200g左右
针对以上问题，A的措施是：
- 增加流量监控功能
- 增加限制流量功能
- 增加断点续传
- 高速客户文件多了就是慢
第三次设计
用户过了一段时间又反馈问题：
- 还是非常慢，虽然有时候可以同时上传的人多了
- 断点续传的功能可以用
- 下载的问题没有解决，愈加严重
用户告诉A，如果需要可以多购买几台云服务器，但是问题一定要解决。
于是A采用了以下方案
- 让用户再购买两台服务器，一台做负载郡城，一台是把同样的程序再部署一台
第四次设计
过了一段时间，客户还是抱怨：
- 用户数量在缓慢稳定地增长
- 上传和下载还是很慢
- 同一时间可以得到服务的用户数量增加了
.. A不知道怎么办，就去找S，S改了改设计
第n此设计
客户反馈，最近不需要那么多用户能否访问，要求减少服务器！
S：分布的文件怎么办？
略。
终于，系统已经可以完全满足用户要求，只要客户有适当的钱去升级带宽和增加新的服务器，当然这些新增的投资也是有一定额度，同时用户的数量也不是一直增加。
