软件开发有哪些方向，该如何规划？
软件开发全景图.jpg
什么是软件开发？
软件开发是根据用户要求建造出软件系统或者系统中软件部分的一个产品开发的过程。软件开发是一项包括需求获取、开发规划、需求分析和设计、编程实现、软件测试、版本控制的系统工程
软件的价值
软件是为解决现实问题而生。技术如果脱离了业务，那么技术应用就无法很好的落地，技术的研究也将失去场景和方向；而业务如果脱离了所需要技术，那么业务的开展就变得极其昂贵和低效。
软件从业人员的品质要求
编码能力对新技术保有好奇心极强的动手能力深耕细作的精神广阔的技术视野快速了解一个业务领域的能力良好的沟通表达能力抽象能力和系统化思维何谓软件危机？
1968年，北大西洋公约组织（NATO）在联邦德国的国际学术会议创造软件危机（Software crisis）一词。1960年代中期开始爆发众所周知的软件危机，为了解决问题，在1968、1969年连续召开两次著名的NATO会议，并同时提出软件工程的概念。一直到了1980年左右的面向对象技术才解决了一部分在软件危机上的窘境
项目运行超出预算。项目运行超过时间。软件质量低落。软件通常不符合需求。项目无法管理，且代码难以维护。何谓软件工程？
将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中。软件工程包括两个方面：软件开发技术和软件项目管理。
软件技术
操作系统
数据库技术
编程语言
软件需求
【故事1：丰田的五个为什么】
有一次，丰田汽车公司生产线上的机器总是停转，虽然修过多次但仍不见好转。于是，丰田汽车公司前副社长大野耐一与工人进行了以下的问答：
一问：“为什么机器停了?”
答：“因为超过了负荷，保险丝就断了。”
二问：“为什么超负荷呢?”
答：“因为轴承的润滑不够。”
三问：“为什么润滑不够?”
答：“因为润滑泵吸不上油来。”
四问：“为什么吸不上油来?”
答：“因为油泵轴磨损、松动了。”
五问：“为什么磨损了呢?”
再答：“因为没有安装过滤器，混进了铁屑等杂质。”
【故事2：要一匹更快的马】
福特公司的创始人亨利·福特先生到处跑去问客户：“您需要一个什么样的更好的交通工具？”几乎所有人的答案都是：“我要一匹更快的马”。很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求。但是福特先生却没有立马往马场跑，而是接着往下问。
福特：“你为什么需要一匹更快的马？”
客户：“因为可以跑得更快！”
福特：“你为什么需要跑得更快？”
客户：“因为这样我就可以更早的到达目的地。”
福特：“所以，你要一匹更快的马的真正用意是？”
客户：“用更短的时间、更快地到达目的地！”
于是，福特并没有往马场跑去，而是选择了制造汽车去满足客户的需求。
真正了解客户需求不是一件简单的事情。客户不一定愿意告诉你他真正的需求。即使愿意，也不一定能反映深层次的动机。更有甚者，连他自己都不清楚自己的需求是什么。其次，由于知识领域的差距，沟通过程中还有出现表达和理解偏差的情况。最后也是最麻烦的是，客户的需求是不断变化的，导致软件项目的个性化开发严重。
什么是软件需求？
软件开发时应满足的功能与非功能要求
什么是需求分析？
准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应的形式功能规约（需求规格说明）的过程。
需求分析的目标是什么？
需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。故而，需求包括功能性需求、质量性能需求和约束。
业务需求：反映组织结构或客户对系统、产品高层次的目标要求，在项目远景和范围文档中予以说明。
用户需求：描述用户使用产品必须要完成的任务，在使用实例文档中予以说明。
功能需求：定义开发人员必须实现的软件功能 ，在软件需求规范中予以说明。
非功能需求：描述系统展现给用户的行为和执行的操作，包括质量性能要求、约束等。
什么是软件架构？
软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
其实所谓架构就是限制，限制源码放在哪里、限制依赖、限制通信的方式，但这些限制比较上层。
编程范式是最基础的限制，它限制我们的控制流和数据流。三个编程范式提出的时间顺序可能与大家的直觉相反，从前到后的顺序为：
函数式编程（1936年）、面向对象编程（1966年）、结构化编程（1968年）。
为什么要做架构设计？
解决沟通障碍达成共识减少歧义架构设计的4+1视图
用例视图：描述需求,负责从用户角度,识别业务需求，描述业务场景,是架构设计的起点和终点。
逻辑视图：从对象角度，构建对象模型，用以确立逻辑分层、模块划分、模块功能、模块间依赖关系等。其中，模块功能，既包括可见的业务功能，也包括不可见的系统功能（日志、权限、事务等）。
开发视图：开发环境、技术框架、分层结构、静态目录、其他中间件
过程视图：从过程角度，描述系统的并发和同步设计。旨在解决进程、线程、并发、同步、通信等方面的问题；
物理视图：负责从部署角度，描述软硬件的映射关系，以及系统在分布/部署上的设计。旨在解决系统安装、系统部署、网络分布等问题。
在现实的系统中，在决定系统的成功或失败的因素中，满足非功能需求往往比满足功能性需求更为重要。”
——Robert Charette
“架构指明了功能必须以何种品质交付，才能被系统的相关人所接受，系统的结果包含这些人的既定利益。”
——John Klein & David Weiss
质量属性
安全，韧性，可靠，可用，隐私，Safety性能，可维护，可伸缩，可扩展，节能，易用可供应/可制造，可部署开放，可定制，易集成，兼容可构建，可演进，可替换，可重用，可测试，易学习面向对象的设计原则
单一职责：就一个类而言， 应该仅有一个引起它变化的原因。（高内聚）
开放封闭原则：类、模块、函数等应该是可以扩展的，但是不可修改。（扩展性）
里氏替换原则：所有引用基类的地方必须能透明地使用其子类的对象。（抽象继承，但要慎用继承，继承是侵入性的）
依赖倒置原则：高层模块不应该依赖于低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。（面向接口编程，降低实现类间耦合）
接口隔离原则：一个类对另一个类的依赖应该建立在最小的接口上。（细化接口、提高内聚）
以上（单一职责、开闭原则、里氏替换、接口隔离、依赖倒置）五个原则被Bob大叔在21世纪早期定义为SOLID原则。作为面向对象编程的5个基本原则，当这些原则被一起使用时，它们使得一个软件系统更清晰、简单，最大程度地拥抱变化。
迪米特原则：一个软件实体应当尽可能少地与其他实体发生相互作用。（封装）
