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