一般而言，有两种类型的开发者。一种编码速度快，喜欢一大段一大段的组合代码，然后看它是否能顺利运行，这是编程中的“快枪手”，还有一种在朝着目标前进的时候比较淡定，他们会确保他们所写的一切代码都是精心设计的，可维护和可扩展的。因为这个原因，使得他们在速度上显得比别人慢，所以是“慢悠悠”。
 
两者之间的区别是，前者完成的效率更高，但代码的错误率更大（除非他们特别幸运），而后者代码的错误率就少多了，并且易于扩展和维护。亲你是哪一种呢？

愚蠢的“快枪手”？
 
大多数开发人员可能不敢承认自己是那种以良好的体系结构为代价的“快枪手”。为什么呢？因为这样可能会产生更高的错误率。但是回过头来想想，哪个系统没有代码错误？
 
拿我自己举个例子。
 
我如果接了个单子要写程序什么的，会有来自客户方面的压力，因为我必须及时交付。而客户对于软件的要求大多是通过电子邮件，电话告知的，或者在某些情况下，客户会直接写在票务系统里发过来。我的责任就是，确保程序的功能可以准确反映这些要求。而大家都知道，有时候客户想要什么却并不说出来，而这一点也是我必须考虑进去的。
 
在开发团队中，有写的快的成员也有写的慢的，有代码错误率高的也是错误率低的。而我我大部分时间在做的是，怎样将这些人员有效分类。
 
继续讲那个例子。那么我该如何确保客户的要求能实现呢？答案是，我得看到实现要求功能的代码在哪里。所以，我就有两个选择了。第一个选择是把单子交给能快速交付的“快枪手”，这样我便可以及时看到运行结果（无论代码是否有bug也不管后期是否易于维护）。另一个是让“慢悠悠”来做，有可能直到最后一分钟他都交付不了，但是拿出来的解决方案必是精品。
 
第一种情况下，我能很快拿到成果，而且如果客户不满意，还有时间去修改，但是我可能不得不面对不支持扩展和不可维护等等方面的缺陷。而在第二种情况下，因为没有多余的时间，所以将不能按客户要求进行修改，但是代码简洁优雅，如果未来有需要的话还可以进一步扩展。
 
在这里要着重讲一下，可扩展和不可扩展以及可维护和不可维护的区别。例如，我们已经按客户要求搞定了所需的软件，但是它的代码是不可扩展的，那么如果用户喜欢并且想进一步扩展的话，那你就只能叫苦连天了。但是如果是可扩展可维护的，那么用户想在某个方面扩展的话，那就是小菜一碟了。
 
所以，如果用户没有要扩展某个方面的想法，那么我会选择“快枪手”。反之就需要“慢悠悠”了。但是如果你想保证100%选择正确，那就只能让事后诸葛亮出马了。
 
因为这是一个主观判断。
 
不可协同工作
 
上面我讲的例子如果能团队中实行，肯定可以提高整个团队的工作效率。在分配过程中，我认识到，“快枪手”有快速编码快速交付的特点，而“慢悠悠”有完成的代码简洁明朗易于维护的特征。
 
随着社会的发展，CI / CD已经变得适用于多种环境。并且现在推陈出新也是越来越便宜。即使代码不可扩展，人们也负担得起更新迭代，甚至哪怕就是再次重新架构也可以承受。这样一来，我们就需要“快枪手”按照要求尽可能的快速开发，而在需要架构或者重构的时候，再青睐“慢悠悠”来大显身手了。
 
但是如果“快枪手”的代码写得太快以至于“慢悠悠”完全跟不上，那时候就悲剧了，因为你得到的只会是一个千疮百孔，满是bug的系统。
 
谁都不希望得到这样的结果。
 
预见机制
 
为了解决上述问题，我们可以使用预见机制，用于衡量开发人员的bug在代码运行时会导致什么问题。这样既可有效控制“快枪手”的错误率，也能确保“慢悠悠”的代码火车不再晚点。
 
有没有觉得，“快枪手”好像文献资料或者是验证器？而“慢悠悠”则更加适合放在设计和架构功能方面，以便于这些方面今后有需要的话，容易维护和扩展。
 
也许我们可以叫“快枪手”为功能团队，而“慢悠悠”则更趋向于是一种工程团队。
 
最后，问问你自己，“快枪手”和“慢悠悠”，亲你是哪一种呢？