软件工程的概念和原则

　　前期文中描述了软件的定义，以及作者和我个人推断的软件发展趋势，会朝着＂术业专攻＂，＂专业人做专业事情＂的方向发展，推断出3个趋势：1）系统软件归一化；2）构建丰富的中间件软件和模块软件；3）业务功能封装成细粒度可复用的模块，朝着积木式的开发方式演进。这3个趋势也符合软件工程去构建软件的思路，结合＂抽象、封装、复用＂普适的软件开发原则，使用明确的接口定义，并利用工程的思路去完成软件系统的构建。
　　软件工程粗俗的理解就是，用工程化的原则去完成软件系统的构建，目的是＂快、好、稳、省＂（快：开发速度快、运行速度快 ….；好：好代码、好质量、好使用 ….；稳：长时间运行稳、极限规格下稳….；省：最优的经济代价）。当然这是我个人粗俗的解读，专业的定义可以参考百度、谷歌或IEEE等。
　　回过头再看软件工程，表示软件+工程，软件是目的，工程是过程和手段，如果有更好的方式可以达到目的，为什么一定是＂工程＂呢？是不是可以是其他方式或方法？答案是＂肯定＂的。所以，千万不要盲从，一定要根据自己的实际情况选择方式和方法，我们聚焦的是目标，不是看起来花里胡哨的过程和手段。＂对于某个软件开发队伍来说可能是‘系统化的、规范的、可量化’方法，对于另一个团队却可能是负担。因此，我们需要规范，也需要可适应性和灵活性＂。
　　软件工程是一种层次化的技术，包括，质量关注点、过程、方法和工具。任何工程方法必须构建在质量承诺的基础之上；过程（＂全局＂）定义了一个框架，以完成对软件项目的管理和控制；而方法（＂具体＂）明确了一系列技术上的解决方法；最后，通过工具为过程和方法提供自动化或半自动化的支持 。最容易让人忽略的就是第一点 ——＂质量关注点＂，我们很容易片面地把软件工程理解为开发软件的一系列过程和方法，甚至在落地过程中完全变成那些让很多开发人员反感的文档、公式、模板。其实＂质量关注点＂才是软件工程的根基，也是软件过程不断改进的动力，只有明确了＂质量关注点＂以及相关的评价体系，才能选择或设计相适应的过程、方法和工具，而不是反过来的本末倒置。也再次强调了上面一段的观点，＂适合自己目的的，才是最好的＂，这或许也是高手和新手的差别。高手更多在意＂实＂，＂抓到老鼠就是好猫＂；新手很关心＂形＂，而容易忽略＂实＂，当然，有可能新手根本就没有理解或没有理解好什么才是他们自己需要达到的目标。
　　接下来，我们来一起了解一些软件实践的精髓，虽然在很多年前也看过，但回过头来再看，随着自己的阅历和经验越来越丰富，越发对这些国外的前辈发自内心的佩服。《How to Solve It》写于1945年，在文中，George Polya列出了解决问题的本质，（）中是对应的软件产品开发思路：
　　1) 理解问题（沟通和分析）；
　　2) 制定解决方案和计划（建模和软件设计）；
　　3) 实施计划（代码生成）；
　　4) 检查结果的正确性（测试和质量保证）；
　　上面4个步骤其实是面向所有一般问题的处理思路和过程，不论在什么场景下，任何方案和计划制定的前提肯定是理解问题，这个看似显而易见的事情，其实在软件产品研发中并不见得＂显而易见＂。尤其是那些涉及多级传递的客户需求，很容易偏离原来的问题。举一个非常常见的例子，在软件领域，有些业务涉及很多专业性的东西，对接客户是来自非此专业的人员。他们有时会将需求带回到研发部门，而研发部门可能会完全根据这些人员带回的信息，去做需求设计，而这些设计的需求可能并不客户想要的，或者至少离客户心目中想要的产品有较大的差距。如果再考虑软件产品研发过程中，研发人员的需求设计导致的错误理解或遗漏，类似的问题就更加普遍和严重了。所以，从最接近客户的一线人员，到完成软件产品构建的研发人员，需要一种机制完成问题的传递，传递过程丢失的信息，尤其是关键信息，越少越有利于问题的理解。产品需求的传递过程中，沟通和原始需求提出人的反馈是必不可少的 。
　　最后，看一下David Hooker在《Seven Principles of Software Development》中总结的7条关注软件工程实践的原则：
　　1) 存在价值：基础原则，为什么要做？价值是什么？价值是否是真的有价值？
　　2) 保持简洁：简洁而不简化。多次迭代，持续修改、维护、升级，简洁才能摆脱噩梦；
　　3) 保持愿景：保持一致性架构愿景，是软件成功的基础。否则，代码很快会发生腐化；
　　4) 关注使用者：客户、运维人员、接手代码的那位，都是使用者；
　　5) 面向未来：考验软件架构，不断应对变化。新场景、新运行环境、新需求等等；
　　6) 计划复用：软件开发的本质原则，＂抽象、封装、复用＂，没有复用就没有进步；
　　7) 认真思考：清晰的定位和完整的思考通常能产生更好的结果，这是一条最容易被忽略的原则；