《编程珠玑(续)》计算机科学箴言

时间 2019-12-07

标签编程珠玑(续) 计算机科学箴言繁體版

原文原文链接

因为搜索引擎收录及编辑问题，从https://taceywong.github.io/迁移至此.git

如下为原文：
程序员

真真是字字珠玑，因此我全抄了。github

剽窃便是最诚恳的恭维算法

——佚名编程

编码

若是好没想清楚，就用蛮力算法吧。
不要使用反正弦和反余弦函数——你总能用优美的恒等式，或者是计算向量点积来更好地解决这些问题.
在存储日期的年份的时候，请使用四位数字：千禧年快要到了。（我挺心疼日本和中国的程序员的）
避免不对称结构
代码写的越急，程序跑的越慢
你用英语都写不出来的东西就别期望用代码写了。（此处英语指代人话、天然语言）
注意细节
若是代码和注释不一致，那极可能二者都错了
若是你发现特殊状况太多，那你确定是用错方法了
先把数据结构搞清楚，程序的其他部分自现（对于一个多个组件的系统，现把通讯“协议”搞清楚）

用户界面

【最小惊异原则】尽量让用户界面风格一致和可预测
计算机生成的输入一般让一个本来设计接受手工输入的程序不堪重负
手工填写的表单中有20%都包含坏数据
80%的表单会要你回答不必的问题
不要染过那个户提供那些系统已知的信息
全部数据集的80%中，有95%的信息量均可以用清晰的图表示（对于人类大脑，有时一图胜千言）

调试

在我全部的程序错误中，80%是语法错误，剩下的20%里，80%是简单的逻辑错误。在剩下的4%中，80%是指针错误。只有剩余的0.8%才是困难的问题
在系统测试阶段找出并修正错误，要比开发者本身完成这一工做要多付出2倍的努力。而当系统已经交付使用以后找出并修正一个错误，要比系统测试阶段多付出9倍的努力，所以，请坚持让开发者进行单元测试吧。
不要站着调试程序，那会使得你的耐心减半，你须要的是全神贯注
别再注释里陷得太深——注释极可能会误导你，你要调试的知识代码
测试只能证实程序有错误，而不能证实程序没有错误
新系统的每个新用户均可能发现一类新的错误
东西没坏，就别乱修
【维护者箴言】若是咱们没能力修好它，咱们就会告诉你它压根没坏
修正程序错误的第一步是先重现这个错误

性能

【程序优化第一法则】不要优化。【程序优化第二法则——进队专家适用】仍是不要优化
对于那些快速算法，咱们老是能够拿一些速度差很少可是更容易理解的算法来替代他们
在一些机器上，间接寻址比基址寻址要慢，因此请把结构体或者记录中最经常使用的成员放在最前面(这个在现今这个时代除非是核心部分，基本没有必要这么苛刻了)
在一个非I/O密集型的程序中，超过一半的运行时间是花在不足4%的代码上的
在优化一个程序以前，请先用性能监视器工具找到程序的“热点”
【代码规模守恒定律】当你为了加速，把一页代码编程几条简单的指令时，请不要忘了增长注释，以使源码的函数保持为一个衡量（😁哈哈😄）
若是程序员本身模拟实现一个构造比编译器自己实现那个构造还要快，那边一块儿的做者也是太失败了
要加速一个I/O密集型的程序，请首先考虑全部的I.O，消除那些没必要要的或冗余的I/O，并使余下的部分尽量的快（有些I/O没办法消除，起码在工程上消除会形成很大的麻烦）
最快的I/O就是不I/O
那些最便宜、最快并且可靠性最高的计算机组件压根儿就不存在
大多数的汇编语言都有循环操做，用一条机器指令进行一次比较并分支；尽管这条指令视为循环设计的，但在作普通的比较时每每也能听派上用场，并且颇有效
【编译器做者箴言——优化步骤】把一个原本就错了的程序变得更糟糕毫不是你的错
电每纳秒传播一英尺
Lisp程序员知道全部东西的值，殊不知道那些东西的计算成本

文档

【否认测试】若是一句话反过来就必然不成立，那就根本不必把这句话放进文档
当你试图解释一条命令、一个语言特性或是一种硬件的时候，请首先说明它要解决的问题（嗯嗯，深觉得然）
【一页原则】一个「规格说明、设计、过程、测试计划」若是不能再一页信纸上写明白，name这个东西别人就没办法理解
纸上的工做没有结束，整个工做也就还没结束

软件管理

系统的结构反映出构建该系统的组织的结构
别坚持作那些没用的事
【90-90法则】前90%的代码占用了90%的预订开发时间，余下的10%代码又花费了90%的预订开发时间
只有不到10%的代码用于完成这个程序表面的目的，余下的都在处理输入和输出、数据验证、数据饥饿否维护等家务活
正确的判断来源于经验，然而经验来源于错误的判断
若是有人基本上作出了你想要作的东西，你就不必本身写一个新程序。就算你非邪不可，也请尽量多地利用现有的代码
代码能借用就借用
与客户保持良好的关系可使生产率加倍
把一个现有成熟程序转移到一种新语言或者新平台，只须要原来开发的十分之一的时间、人力、成本
那些用手作就已经很快了的事情，就不要使用计算机去作了（~~~~）
那些能用计算机才迅速解决的问题，就别用手作了
我想写的程序不仅是程序，并且是会写程序的程序
【Brooks原型定律】计划好抛弃一个原型，这是早晚的事
若是开始就打算抛弃一个原型，那恐怕你得抛弃两个
原型方法能够将系统开发的工做量减小40%
【Thompson望远镜学徒定律】先作一个4英尺镜片的望远镜，再作一个6英尺的镜片的，这比直接作6英尺镜片的更省时间。
拼命干活没法取代理解
作事应该先作最难的部分。若是最难的部分没法作到，那还在简单的部分上浪费时间干吗？一旦困难的地方搞定了，那你就胜利在望了。作事应该先作最简单的部分。你开始所预想的简单部分，作起来多是颇有难度的。一旦你把简单的部分作好了，你就能够全力攻克最难的部分了

其余

【Sturgeon定律——在科幻小说和计算机科学中同等适用】毫无疑问，90%的软件都没什么用。这是由于对任何东西而言，其中的90%都是没什么用的
对计算机撒谎是要受到惩罚的
若是不要求系统可靠，他可能作任何事情
一我的的常量是另外一我的的变量（呜哇呜哇）
一我的的数据就是另外一我的的程序（哈哈哈哈）
【KISS法则】用最简单、最笨的方法作事（Keep it simple 、stupid）

把一般状况和最坏状况分开处理
在分配资源的时候，请努力避免引发灾难，而不是妄图得到最优