关注细节但不陷入细节

 

 

我们经常说要关注细节，这个从大的方向上来说，是没有问题的。以前有一本书《细节决定成败》讲的这一方面。在对于某些领域，细节是需要关注的，但是不能陷入细节。换个说法，如果你一直纠结与细节的上的问题，就很难突破自己，把握全局，毕竟人的时间是有限的，能够把握整体，抓住重点细节，关注核心领域所处的细节才是王道。

以前做过很多项目，在项目整体业务确定之后，就陷入到细节的讨论之中，当一群人坐在一起，你说一句，我说一句，把大家都能想到的各种可能性都拿出来，然后你针对各种可能性找出相应的解决方案。这些细节中，有一部分是针对某一特例的，有一些是业务异常规则引起的，有一些是交互方面的，而有一些是具有抽象的，公共性质的。

在这些细节中，最有价值的就是具有抽象的，通用领域的细节，这些能够帮助你把具体的细节抽象出共同的特性，并且可以把这些抽象细节应用于其他领域，从而能够达到举一反三的效果。举个例子，在项目，我们经常会用到定时机制，一个关注的细节问题是，如果系统在维护，定时任务没有执行，那么如何进行重试。对于某一个特定的场景，可以写一个人工触发按钮。这个细节就可以进行抽象，就是如何补偿由于定时机制机制异常而导致任务没有执行这种场景，有多重方案，甚至可以开发一个专门的任务管理平台来做这个事情。类似这种可以通用和抽象出来的细节，比如业务并发控制解决方案 等，是非常值得关注和深度挖掘的。

对于某些特定场景的细节，比如我们和外部合作，定制了协议，但是对于极少数情况，不符合这个协议等，这种都是普片情况下的特例考虑，很难对这些问题进行抽象，因为这些都是对于特定领域和场景的。值能够针对特定的细节具体分析，这一部分的价值相对比较低。只能够加强你对某一领域了解的深度。

还有一类纯粹是浪费时间的讨论，这些完全是无意义的或者说没有太多可行性的参考价值。比如页面文本框的长度要多大，业务失败要不要发送邮件给用户，以及许多装逼问题：“对于一个可有可无的功能，考虑机器断电，磁盘写满等细节。

如果经常关注的第三类细节问题，就相当的无聊和无趣了，而最耗费和让人陷入的就是第二类或者第三类细节问题的讨论，这类细节问题很难帮助你或者让你站在更高的角度去考虑问题，可以了解这一部分细节，但是没有必要陷入这一部分细节，应该去专注细节问题的共同点，从着一些共同点中找出共性的问题并提出这一类问题的通用解决方案。

GodIsCoder 
博客园blog地址:http://www.cnblogs.com/aigongsi/ 
独立Blog: God Is Coder 
个人网站: iphone发码网 
本人版权归作者和博客园所有，欢迎转载，转载请注明出处