软件开发的艺术

相对于那些不善运用隐喻的人，那些使用隐喻来照亮自己的软件开发过程的人，他们对于编程的理解会更好，并且能够更快地写出更好的代码。

 有专家说，软件开发是一门科学，是艺术，是一个过程，是在驾驶汽车等等。

文字写作隐喻软件开发，暗示其过程是一种代价昂贵的试错过程，而非仔细的规划和设计。

有人将软件开发比作耕作，“每次做一点”，最后添加到整个系统。实际上，应该对系统计划施肥，对细节设计蔬果，并通过有效的管理土地来增加代码的产量，最终取得代码的大丰收。

不如用系统生长来做隐喻，相近的词如“增量的”、“迭代的”、“自适应的”、“演进的”。以增量方式进行设计、编译和测试，都是目前已知的最强有力的软件开发概念。

构建骨架－>附着肌肉和皮肤－>接受真实的输入和输出（一次增加一小部分代码，直到得到完全可以工作的系统）

 

软件开发如建造房屋：

问题的定义－－想要建一个什么样的房子

软件构架设计－－和建筑师探讨总体的设计

软件的详细设计－－画出详细的蓝图，承包出去

软件的构建－－打地基、搭建房屋构架、砌墙、盖房顶、通水、电、煤气等

软件的优化－－喷漆、装修、美化

软件复查和审查－－整个过程中监察人员检查工地、地基、框架、布线等

      建造一个房子时，不会去自己动手建那些现成的买得到的东西，如电视、沙发等。软件开发会大量使用高级语言所提供的功能，不会自己去编写操作系统层次的代码，还有一些程序库、容器类、科学计算函数、用户界面组件、数据库访问组件等。总之，自己编写那些能买得到的现成的代码是没有意义的。

      但要造一个一流的高档住宅，需要订制。开发一款一流的软件产品，可能自己编写函数以便获得更快的速度和更高的精度，还可让产品的各部分无缝拼接。适当的多层次规划也是很重要的，按照错误的顺序构建软件，那么编码、测试和调试都会更难。精心计划，也不用事无巨细。

      项目的准备工作很重要，计划要建造什么，防止浪费钱去建造错误的东西。多花时间了解客户真正想要的东西，比”做出一个错误的东西出来，然后扔掉，并从头再来“成本低。程序员是软件食物链的最后一环：架构师吃掉需求，设计师吃掉架构，程序员消化设计。

      问题的定义，是对这个系统要解决的问题做出清楚的陈述。“在射击之前，确信你瞄准了正确的目标“。未能定义问题的处罚在于，你浪费了大量的时间去解决错误的问题。重视需求有助于减少开始编程开发后的系统变更情况。如果在编码中发现一个代码上的BUG，只需要改几行代码；而在编码时候发现了一个需求错误，那就得改变设计。

      针对客户需求的变更，”It sounds like a very good idea，但不是需求文档里的内容，需要整理一份修订的进度表和成本评估表，再做决定“。

    

      软件架构architecture是软件设计的高层部分，用于支撑更细节的设计框架。离开了良好的软件架构，你可能瞄准了正确的问题，但却使用了错误的解决方案。

      架构应该描述一份管理稀缺资源的计划。稀缺资源保护数据库连接、线程、句柄等。在内存受限的应用领域，如驱动程序开发和嵌入式系统中，内存管理是架构应该认真对待的另一个重要领域。架构应该估算在正常情况和极端情况下的资源使用量。

      架构应该描述实现设计层面和代码层面的安全性的方法（建立威胁模型）。在制定编码规范的时候应该将安全性放在重要位置，包括处理缓冲区的方法、处理非受信数据（用户输入数据、cookies、配置数据等）的规则、加密、错误消息的细致程度、保护内存中的秘密数据等。

      软件的性能包含速度、内存、成本等目标，即时间、空间的预算。可伸缩性是系统增长以满足未来需求的能力。架构应该描述系统如何应对用户数量、服务器数量、网络节点数量、数据库记录数、数据库记录的长度、交易量等的增长。I/O（输入输出）是架构中值得注意的另一个领域。架构应该详细定义读取策略是先做、后做还是即时做；还应描述哪一层检测I/O错误：在字段、记录、流，或者文件的层次。

      错误处理已被证实为现代计算机科学中最棘手的问题之一，程序中估计高达90%的代码是用来处理异常情况、进行错误处理、或做记录工作（log）。错误处理是纠正还是仅仅检测？错误检测是主动的还是被动？程序如何传播错误？错误消息的处理有什么约定？如何处理异常？在程序中，在什么层次上处理错误？每个类在验证其输入数据的有效性方面需要负何种责任？

      健壮性是指系统在检测到错误后继续运行的能力。通常架构详细描述的系统会比需求详细描述的系统更健壮。

转载于:https://www.cnblogs.com/LarryGen/p/4968390.html