小阳日记 03-28 细节

中学时候,数理化都会有一些“应用题”,大概就是用所学知识去解决一个具体的问题。这类题在作答时,都被要求写出中间的计算步骤,最后算分时即使结果不对,也会根据过程酌情给分。特别是有的题目涉及到许多的计算时,中间的步骤稍有差池,便跟容易把结果算错。这种打分的原则也算比较“人性化”。

可如果仔细想想,若不是想要把学生分成三六九等,这种算分方法并不合理。因为当需要真正应用知识时,是少不得半点马虎的。特别是在一些实际工程领域,算错一步就可能会造成不可估量的后果。

编程也是这样。在我中学初学编程时,就认识到细节的重要性。那时候为了参加全国编程比赛,需要做很多算法题。算法题会要求你编程解决一类问题,并提供10个左右的测试数据。10组数据每组10分,每一题满分100分。而这10道题目中,一定会出现三类数据:普通数据、边界数据和极限数据。

一般写完第一遍,多半可以过了普通数据。运气好、思路对,极限数据也可通过。只有这边界数据,非有一遍遍的看代码,在心里模拟系统走上几遍,才能找出那些需要特殊处理的地方。做一道这样的题目,20%写出代码,但却要花80%的时间去调试。

随着接触的软件系统越来越复杂,不同模块的集成度也随之变复杂。这样一来,模块内的这种边界情况,随着系统慢慢变大,组合出的可能性也呈指数级增长,出现bug的几率也会越来越大。基于这样的原因,维护现有系统往往会变成一个非常痛苦的事情。

不过既然是工程,就总是会有系统的方法去解决这个问题。比如单元测试,灾难恢复等。不过想要真正让这类问题出现的概率变低,最好还是在一开始就能识别并解决这类问题。不过这只是变相把维护系统的时间,提前消耗在了构建系统中。根据对系统健壮性的要求,酌情分配这类时间即可。

细节是魔鬼,过多的把时间消耗在细节上,即不能帮你利用技能做更多贡献,也不能让你从中学到多少有用的东西。所以,在日常工作学习中,也应多思考,如何才能避免过度纠缠细节。

You Might Also Like
发表评论