微服务所需要的基础设施 在每一个软件工程师的职业生涯里，都会有一个疑问“软件到底是制造出来的，还是创造出来的？” 随着互联网公司的崛起，传统软件企业，如微软、IBM等，都在逐步的“没落”。国内的如用友、恒生等公司， 在互联网公司的光芒之下，也显得非常的落寞。 落寞的不仅仅公司的市值、股价和吸引力，还包括他们在软件领域所引领的哪些理念。 在敏捷软件开发、Devops、微服务等新的理念逐步取代瀑布式软件开发、领域驱动模型、RUP等概念后，还有谁会记得CMMI，ISO9001， UML、软件设计模式这些10年前非常火热的词汇？ 我曾经和一些有4-5年经验的工程师沟通过，大部分人都认为，UML已经过时了，因为它“太重了”。 于此同时，在另一方面， 当“小步快跑”、“快速试错”等理念深入到各个软件开发人员的脑海之后，大家似乎变得越来越“不会”写软件：
- 产品和实现之间缺乏逻辑关系。没有人能保证，开发出来的功能和产品设计是一致的。 产品和实现之间的矛盾越来越大。
- 当“试错”成为一个习惯后，软件错误往往触手可及，而且要使用非常高的成本才能够修复。 还有一个问题是，很多错误，得到用户使用后才发现的。
- 软件生命周期越来越短，伴随着维护成本急剧升高。 推到重来成为常态，往往是新人接手的代码，几乎不可维护，只能重写。
诸如此类的问题，仿佛让我们又回到了20多年前，软件工程刚刚被提出来的时候，那种依赖业内精英随心所欲开发的场景。 而造成这种“返祖”现象的原因，我认为是在软件开发中，我们和传统软件开发切割的如此彻底，而导致工程师失去了必要的基本软件修养导致。 这个系列的文章，是针对新入职场的工程师，重点在于培养一种软件思维。
- 我们不提倡瀑布式软件开发模型，但是我们主要遵循软件开发的客观规律，使用新的方式来实践需求、分析、设计、开发、测试、部署的流程。
- 我们不提倡在软件开发中全部使用UML来完成设计工作，但我们需要掌握UML的精髓，用它来指导我们设计和审核工作。
通过这个系列文章，我们可以了解：
- 怎么设计一个可靠的需求，避免出现纰漏。
- 如何验证需求是完整的。如何评估需求的实现难度，安排优先级和确认进度。
- 如何确保你的设计和实现，和产品经理的需求，是一致的。 既不会多做需求，也不会漏掉需求。