梦断代码阅读笔记03

细节视图

程序员和机器、程序员和程序员、程序员和用户之间往往达不到某种共识。

程序员们对于信息的需求显而易见。他们需要细节。他们需要蓝图。他们需要规格说明（specifications)。

规格说明是程序员的圣经，而且，通常程序员也会是忠诚信徒：规格说明就是法律。

需求搞错的严重后果，18英尺的巨石拱门变成了18英寸的石桩子。

最著名也最声名狼藉的匈牙利命名法：在匈牙利语标记法中，程序员给每个变量名加上前缀， 好让代码阅读者了解变量的类型。

匈牙利命名法可能在用C++写Windows程序的时代是需要，因为各种类型、结构、枚举、控件等等让人眼花缭乱，让人容易出错，而在Java和C#等这种强类型的语言中，这类命名法完全是对程序员审美观的践踏。

这让我想到了，JAVA中的种种的变量类型，尤其是Float类型的精度处理问题，计算机和程序往往不会按照程序猿的设想进行，在这之前从来没有注意过处理精度这一问题，在之后的项目编程中一定要时时提醒自己，变量类型！变量类型！变量类型！

瀑布模型

将项目切分为依序进行的多个独立阶段，比如需求定义、设计、实现、集成、测试和发布。每个阶段需在下一阶段开始前完成。

这套做法在纸上看似合乎逻辑，但实践起来却总是导致延误、混乱和灾难。每个阶段都耗时无算，但没一个工作正常的。“大设计优先”引发大延误，“大爆炸式集成“一一单独编写代码的各个主要部分，在项目将近结束时拼到一起——导致系统崩溃。

这一章节，给我的印象极深，在大作业组合时，就出现了类似的状况，在项目初期，对工作进行了划分，按照划分完成之后无法按计划组合，这就是分配任务不细致，编程环境不统一造成的。在以后的团队开发中一定要提起注意。