梦断代码阅读笔记03
细节视图
程序员和机器、程序员和程序员、程序员和用户之间往往达不到某种共识。
程序员们对于信息的需求显而易见。他们需要细节。他们需要蓝图。他们需要规格说明(specifications)。
规格说明是程序员的圣经,而且,通常程序员也会是忠诚信徒:规格说明就是法律。
需求搞错的严重后果,18英尺的巨石拱门变成了18英寸的石桩子。
最著名也最声名狼藉的匈牙利命名法:在匈牙利语标记法中,程序员给每个变量名加上前缀, 好让代码阅读者了解变量的类型。
匈牙利命名法可能在用C++写Windows程序的时代是需要,因为各种类型、结构、枚举、控件等等让人眼花缭乱,让人容易出错,而在Java和C#等这种强类型的语言中,这类命名法完全是对程序员审美观的践踏。
这让我想到了,JAVA中的种种的变量类型,尤其是Float类型的精度处理问题,计算机和程序往往不会按照程序猿的设想进行,在这之前从来没有注意过处理精度这一问题,在之后的项目编程中一定要时时提醒自己,变量类型!变量类型!变量类型!
瀑布模型
将项目切分为依序进行的多个独立阶段,比如需求定义、设计、实现、集成、测试和发布。每个阶段需在下一阶段开始前完成。
这套做法在纸上看似合乎逻辑,但实践起来却总是导致延误、混乱和灾难。每个阶段都耗时无算,但没一个工作正常的。“大设计优先”引发大延误,“大爆炸式集成“一一单独编写代码的各个主要部分,在项目将近结束时拼到一起——导致系统崩溃。
这一章节,给我的印象极深,在大作业组合时,就出现了类似的状况,在项目初期,对工作进行了划分,按照划分完成之后无法按计划组合,这就是分配任务不细致,编程环境不统一造成的。在以后的团队开发中一定要提起注意。