实效性软件构建的途径-下

PokPok

2020-04-15

阅读次数

Page content

前言

如果一次性总结，文章太过于冗长，上部分更加是一种在编程中会碰到的技术细节，而这一部分是一些编程中需要记住的良好习惯。

1000字节数据通过路由器需要多少时间？类似这样的问题需要有个大致的答案，通过学习估算，能将估算发展到对事物的数量级有直觉的程度，就可以确定方案的可能性。

无论什么时候有人需要你进行估算，你都可以给出答案。如果没有经验，估算通常可以去问问已经做过该事情的人。追踪自己的估算能力，如果估算错了，找出什么事情与自己的预期不同。

这里不讲技术上怎么调试，而是另外一种途径进行调试：向别人一行一行解释代码的作用，并且详细描述假定的情况，可能在解释的过程中就可以知道哪里处理问题。

花很长时间找到bug后，想想可以做点什么使找到这个bug更加容易，例如内建更加好的测试。

不要害怕重构，老旧的代码如果不适用，所有代码都可以被替换。重构往往在非正交设计，违反DRY原则、过时的知识、性能缺陷存在时发生。

那么如何合理地进行重构？

根据合约(契约式编程)进行单元测试，先测试子模块，再测试模块自身子模块，再测试模块自身。单元测试应该在模块目录，使测试代码容易找到，既可以说明怎么使用模块的功能，又可以用于构建回归测试，验证未来对代码的改动是否正确。

另外测试都应该具有以下功能：

曳光弹原本是指在机枪子弹中间接出现的用于显示子弹射击目标的子弹，比起精确计算风向、射速、角度再射击，曳光弹的方式更加实际。曳光弹的原理就是指，尝试制作一个项目，慢慢地靠近客户需求的一种构建方式，可以有效的展现工作进度，并且这种构建方式的每一段代码都需要有完整的错误检查，结构，文档，以及自查。

而原型开发这种方式通常是一种实验性的探索，为取得某种功能，不必关注太多细节情况，通常没有太多文档和注释。

这一点对自己的要求比较高，在团队合作中，写出很好的代码，让团队的其他人大吃一惊，渐渐影响他们，从而提高项目质量。

这和过早优化的概念同理，但概念更加偏向于用户，今日了不起的软件往往被明天更加完美的软件更加可取，让用户先使用，用他们的反馈引领软件走向最终解决方案。但是并不是说就可以用不整洁的代码，或者制作糟糕的代码。

对于金融资产的管理：

而程序员管理自己的知识资产可以类比：

所以可以给自己设立一些周期性的目标，防止自己的脱节：

交流很重要，即使是“自闭”人群，该说话的时候还是得好好说话。

书中提到的最关键的几点：

对于前者，你不听别人讲话，别人也懒得听你的：）；及时回复这一点，在现代社会中其实很容易遗忘，但是即使简单回复，”我稍后回复你“，也会显得礼貌。