首页 > 编程语言 >程序员修炼之道:从小工到专家阅读笔记3

程序员修炼之道:从小工到专家阅读笔记3

时间:2022-10-10 19:57:52浏览次数:65  
标签:代码 估算 模型 曳光弹 正交 程序员 修炼 文档 小工

注重实效的途径
2.1 重复的危害

    1. DRY: 系统中的每一项知识都是必须具有单一、无歧义、权威的表示
    DRY: Do not repeat yourself
    2. 文档与代码:你撰写文档,然后编写代码。有些东西变了,你修订文档、更新代码。文档和代码都含有统一知识的表达

2.2 正交性

    1. 正交性:如果两个或更多事物中的一个发生变化,不会影响其他事物,这些事物就是正交的。在设计良好的系统中,数据库代码与用户界面代码是正交的;你可以改动界面,而不影响数据库;更换数据库,而不用改动界面

2.3 可撤销性

 

  1. 要把决策视为是写在沙滩上的,而不是把它们刻在石头上。大浪随时可能到来,把它们抹去
  2. 不存在最终决策

2.5 曳光弹

    1. 曳光弹:
    (1) 定义: 曳光弹是一种"原型制作" 。曳光弹代码虽然简约,但是完整的,并且构成最终系统的骨架的一部分;"原型制作"是用来生成用过就扔的代码。
    (2) 曳光弹并非用过就扔的代码;你编写它,是为了保留它。它含有任何一段产品代码都拥有的完整的错误检查、结构、文档、以及自查。它只不过功能不全而已。但是,一旦你在系统的各组件间实现了端到端(end-to-end)的连接,你就可以检查你离目标还有多远,并在必要的情况下进行调整。一旦你完全瞄准了,增加功能将是一件容易的事情
    (3) 优点: a. 用户能够及早看到能工作的东西; b. 开发者构建了一个他们能在其中工作的结构; c. 你有一个集成平台;d. 你有了可用于演示的东西; e. 你将更能够感受到工作进展
    (4) 曳光弹并非总能击中目标。但是,小段代码的惯性小,要改变它更容易、更迅速;你能够搜集关于你的应用的反馈,而且与其他方法相比,你能够花费较少代价、更为迅速地生成新的、更为准确的版本

2.6 领域语言
2.7 估算
时长    报出估算的单位
1~15天    天
3~8周    周
8~30周    月
30+周    在给出估算前努力思考一下

  估算来自哪里:去问已经做过这件事情的人;在你一头钻进建模之前,仔细在周围找找也曾处在类似情况的人
    理解提问内容:需要把握问题域的范围;需要养成在开始猜想之前,先思考范围的习惯
    建立系统的模型:
    将模型分解为组件:
    给每个参数指定值:
    计算答案:在计算阶段,你可能会得到看起来很奇怪的答案。不要太快放弃它们。如果你的运算是正确的,那你对问题或模型的理解就很可能是错的。这是很宝贵的信息
    追踪你的估算能力:如果结果证明估算错了,不要只是耸耸肩走开。找出事情为何与你的猜想不同的原因。也许你选择了与问题的实际情况不符的一些参数。也许你的模型是错的。不管原因是什么,花一点实际揭开所发生的事情。如果你这样做了,你的下一次估算就会更好
    在被要求进行估算时说什么:你说:"我等会回答你"。需要放慢估算的速度,花一点时间检查&思考

标签:代码,估算,模型,曳光弹,正交,程序员,修炼,文档,小工
From: https://www.cnblogs.com/kun1790051360/p/16776944.html

相关文章