读完ixu 的JAVA EE开发难经,叹服其深邃的思想,以及其独到的方式。不由的设身处地,能否如他般天马行空地穿梭于软件开发世界?在此结合自己的实际情况,凸显出自己的不足,以便以后纪念,努力去追求先进的思想!
最终对问题的迎刃而解,发现一个共同之处,就是对背后原理的毫无遗漏的揭露,这就是问题的本质!当真相大白于天下时,感觉很简单,如我等IT妇孺都能够清清楚楚,明明白白。但是价值不在于答案,而是探幽(借用ixu的术语)答案的旅途!
首先看看探幽的生命周期:问题---原理的分析--最终解决过程!这之间最容易卡壳的地方时哪里呢?我再来细化这一过程,问题现场---分析问题--联系到原理----原理分析----最终的解决之道。对于此,我觉得最容易的地方是在问题现场,和最终解决地方,这两地方是显而易见的。中间就是难以跨越的鸿沟,三座大山!
三座大山之一:分析问题。分析问题,对于技巧和经验的需求最大的。技巧:结合自己所有经验,走一次最容易排错的地方。结合成功的例子,走一遍与问题出现现场异同的地方,发现共同点和特殊性!这一步或许你能够解决问题,但是如果不继续探幽下去的话,留下的只是一堆一堆容易遗忘的离散的丁丁点点,这个虽然重要,但是会随着潮流过时的!
三座大山之二:联系到原理。我这里的原理应该确切的讲,是你应用层的框架层,或者源代码层。这个不仅需要DOCUMENT,SRC。更重要的是:对整体战局的把握,对细节的取舍,简化!这个我觉得是最具有难度的!这个的完成或许用类图,流程图帮忙,是我们思想的利器!
三座大山之三:对原理的分析,这个要结合问题,再现问题,以及找出真正的元凶,用流程图,顺序图是最好的帮手!
写到这里,我停下来思考一番:如果把软件从字节码到应用作为一个由你主导的整体的话,那么解决问题是自顶向下(相对于问题)的过程,而开发是个自底向上的过程。当然这不是绝对的,我姑且为了理解如此般的简化!
如果让我把软件的本质在来抽象的话,我觉得软件就是一堆规则。规则可以引用嵌套规则!现实世界是问题现象驱动式的,而我们的思维是盘根错节的纠缠缠绕式的。出现问题则是规则的违背。假设我们可以晓得一切规则,那么问题就不在了!这种假设是根本不可能实现的永动机!或许它能指明方向,让我成着应对!
软件应该用哲学去简化。