这些不良习惯可能会导致你的代码无比糟糕

OSC开源社区 · 公众号 · 程序员 · 2017-04-24 08:37

正文

请到「今天看啥」查看全文

举一个例子，在这个项目上，我会发现一些代码明显在其他地方已被写过，但是好像当时急于交付，一些开发者也就懒得检查是否有其他人在此之前已经写了相同的方法或者SQL查询。

有些时候，预算可能是假的。例如，Agile有一个术语叫“速度”，这个概念是为了计算你的团队交付有多快，然后做一些必要的调整来提速。问题是在短期到中期里是不太可能算出一个精准的速度的。平均法则强度，你不能凭借过去的业绩来测量你现在的速度，因为过去的业绩并不是一个好的未来结果的指示器。

（注：平均法则是一个外行术语，认为一部分小样的数据分布的结果肯定会反映整个数据分布的结果）

事实上，一个开发者可以一天可以编写很多的代码，也可以在读完文档并在考虑和同事们如何合作后，三天只写五行代码。平均预算并不会在短期和中期得到有价值的反馈。

不重视项目知识

随着您的项目的推进，您的团队会学习业务，业务背后的概念以及它们是如何联系在一起的。他们还会在编写代码时研究实现方式，因为您无法完全了解业务的演变以及将会面临的挑战。一些业务领域甚至本身就很复杂，需要很长时间才能消化。

由于这是对旧代码的全面重写，在这方面特别有趣，因为它可以显示您的团队的管理层是否了解项目知识以及它对开发的影响。 如果你在一个大型项目中，没有专家，没有人过问项目知识，这是一个很大的危险信号。 重写代码的价值完全在于利用你第一次学到的项目知识，所以项目知识很珍贵。

如果你把不同的团队放在一起做重写，就像我的情况一样，你忽略了所有的项目知识学习，只依靠你的新队员的技能，这可能不会弥补缺乏的信息。 比起把工作完全交给别人，一个普通的开发人员能更好地重写他自己写的内容，他会做的更快。

即使招聘也受到项目知识的影响。项目的信息越多，人们成长需要的时间就越长，所以不仅仅知识很重要，还要注重招聘好的人才。如果招的不好，你会忙于应付一个糟糕的团队，几个月内什么事也做不成。

重点关注诸如 “关闭的问题” 或 “每天的提交” 等不好的指标

当一个政策变成目标，它将不再是一个好的政策。 - 古德哈特定律（Goodhart's law）

一些时候当我开始着手于推进项目的进度，一些人会问我为什么另一些开发者关闭问题的速度远远快于我，似乎解决得越快是一件好事。你可以想象到，当我去瞥一眼他写的代码，在一行里面发现了 4 个 bug。 关注于像这样不可靠的指标完全是与项目脱轨的，会引起人们类似于项目截止期即将到来般的压力。