致软件开发初学者

本文是我作为一个入门两年的半生不熟者给刚刚入门的新人的一些建议。主要针对的是新人开发过程中遇到的问题，发表的一些建议。针对的问题主要是问题的难易，基本概念的认识，以及系统框架的认识，文章初步对这些问题进行了探讨。

1.       难与易的关系

庖丁解牛，是一个众所周知的故事。游刃有余，这个词语，几千年来，是人们在各个行业追求的一个目标。面对一头牛，对于一个才开始学习宰牛的人来说，那简直是一个浑然一体的复杂的东西，简直无从下手。在接受一门新的技术或者是新的学科的时候，很多人也会跟那新学徒有同样的感叹。

 

软件开发，这个领域，对于很多门外人来说，也是一个神奇的领域，高深莫测。即使是很多在本行业的人，也会发出同样的感慨。蜀道难，难于上青天，李白感叹，是因为他缺乏交通工具，缺乏徒手攀登的技巧和准备…我们感叹的人缺乏什么？

 

从实践的角度看，我们中的很多人缺乏一种视角。那就是如何看待难的问题。世界上几乎任何一个难题，难度之大，很多时候不是它本身有什么奇异，而在于我们的认知的方法和程度。去找问题里或者说领域里的规律，掌握这些规律，那么我们就能把握这个问题，真正理解这个领域。这里说的理解把握，是很笼统地口号式的方法，但我们要看到，它为我们指出了方向，也仅仅是指明了方向：事物自由它的规律。软件行业里，小的方面，比如语言（比如C），大的方面比如软件的发展趋势，自有其发展的规律。如果我们能够知道语言是为了更好的表达，在把握某种语言，我们就能够不被各种天花乱坠的语言所迷惑，如果你能够综合归纳这些语言，那么你也许能够也去发明一种语言。如果你能够明白，软件是为人服务，是一种工具，那么你就能够明白，它的复杂性不在它本身，而在于它服务的行业的复杂性和特征。

 

规律并不会告诉我们，我们仍然无法操作，难题仍然是难题。具体操作的时候，关键还是我们首先要去掉畏难的心理，去除那些神秘的想象，这样其它相应成章的事情就能够顺利进行。

 

一种方法是化整为零。我们可以看到，很多时候，或者经验告诉我们，很多问题，都是我们一步步去解决的。这也就意味，这些问题是能够细分的。而我们面对这些小的问题的时候，相对就会容易得多。这时候，复杂的问题也就变得简单了。比如一个算法，一段复杂的程序，一个复杂的项目，我们同样可以看到这种相似的细分的痕迹。复杂的算法，可以分成几个简单的小算法。复杂的程序，可以分为几个简单的模块，一个复杂的项目，可以划分为几个小的项目等等，都贯穿了一种化整为零的思路。化整为零，也就是展现了一种我们面对难题，所应该采取的方法。

一种方法是先易后难。这似乎是一个很好懂的道理。但在具体的实践中，我们发现，我们总有一个一揽子解决某个问题的倾向。我们这里不去追究这种倾向的内部根源，但这种倾向往往是造成我们面对难题束手无策的局面，或者更有甚者是徒劳无功。先易后难，其实是我们一直以来认知事物的一种方法。面对难题，我们如何采用这个方法？自视很强的我们，还是先抛开那些无关紧要的问题，动手或者思考一个简化的问题，然后把这个问题逐步的复杂化：加入各种限制的条件，各种边界处理，各种以外的情况，逐步使得这个简单的问题接近实际的问题，从而使得问题能够得到解决。如此，当我们按照这样的思路解决问题的时候，会觉得很容易。

化整为零适合那些我们有所理解的系统，而先易后难，适合对付那些很复杂而我们根本没有经验的问题。

 

总之对于一个问题，我们应该先分析，而不是用难字作为我们懒惰或者逃避的借口，而是应该积极地去面对，克服畏难的心理。容易简单的工作，同样也能逐步解决复杂的问题，或者说难题是由简单的问题的有机结合。拥有这样的视角和态度，那么难题，也会迎刃而解。

2.       重视基本概念

从大的方面而言，是概念缔造了文明这座巨塔。小而言之，概念，是我们表达思维的一种基本的方式。概念对于软件行业而言，它们是一系列的规范。基于这些规范，我们创建一个复杂的软件的世界。

 

由于我们现在的工具越来越智能，我们的概念之概念越来越花哨，很多时候，我们似乎可以在一知半解的情况下，搭建一些 令我们自己挺得意的东西。但当问到细节，我们很多人不甚了了。也许对于我们一些自娱自乐的东西，这样做没有什么大不了的。但当这些东西真正需要发挥效能的时候，我们会发现，我们常常陷入一种迷宫，迷宫里有很多很多神秘的东西。我们不知道错误所在，不知道如何解决。

 

问题在哪里？不知道我们是不是都有这样的经验，当我们在发现自己的错误的时候，我们发现我们错误不是我们不知道一些繁琐的东西，而是在于我们一些基本概念的似是而非的理解。

 

人们对于新概念和看似繁琐的东西的追逐，而对于一些小的东西的忽视，这是这个时代的通病。而基本概念，可以说是一个行业的基础。如果忽略它，漠视它，会使我们在解决问题的时候，走更多的弯路；会让一座大厦建立在流沙之上。因此，对于真正想从事软件行业，或者其它行业的人来说，基本概念，这种行业基石，不能忽略，遗弃。否则，如果能够成功，那也只是侥幸。

3.       系统框架的理解

一叶障目不见松林。这说的是我们常常被一些细枝末节的东西蒙蔽，而没有看到整体，正如盲人摸象里的道理。作为一个经常外出的人，知道一张地图的作用，而一个深谙某个领域的人的头脑里会有一个清晰的脉络，他明白这个领域的过去和现在，以及未来。作为一个初次接触某个新事物的人，很容易在新事物的细枝末节里迷路，或者说很容易被一些东西迷住，而忘记去了解这个事物的根本性的结构，很多时候，这无可厚非。因为，这是一个过程，只是这个过程有长短之分，知道树叶来自松林总是好的。通过这个过程，我们才能获得一些感性的认识，为以后更进一步的了解打下基础。下一步怎么走？

 

人们常说，人需要有梦想，我们可以把这个梦想看作是一个的基本的框架。从而他的所做所为很大一部分将来自对这个梦想的逼近。那么，系统框架，从某种意义而言，是一张地图。它能够给我们指引一个方向，给出我们能够做什么，并且能够达到什么程度的标准，同时也是我们理解这些系统的基础。对于软件开发而言，这里的系统框架可以从两方面去理解，一种是我们需要开发软件环境某部分的系统框架，一种是我们开发的软件的系统框架。开发环境的系统框架，是支撑应用软件的平台，它给出了理解系统架构的思路以及关键技术和设定。比如局域网系统的系统构架，比如操作系统构架等等。

 

我们中有一种趋势，恨不得自己很快了解和掌握整个系统的所有的东西，人的求知欲和新鲜感让我们乐此不疲，再加上我们这个时代的传染病，很多人给自己制定很多的计划，埋头苦干等等，希望一夜之间成为大师级的人物。这也是一个梦想，但我要说这个梦想几乎总是破灭的，这个梦想本身就不切实际。这里有两种结果，一种是眼高手低，滔滔不绝，却一无所成；有一种，使一知半解，半瓶子的水，几年下来可能，差不多成为口头禅。我们这里不去分析这里的种种原因，只是指出其中的一点，那就是很多人对于系统框架的忽视，没有方向。我们需要在林子里探路，我们更需要常常爬上一颗大树或者是山岭上去辨别方向。在软件行业，那就是要常常注意各种系统框架，更要注意开发软件的系统的框架，否则就会在那知识的或者代码或者细节的森林里迷路，徒耗人力物力。

下面是一个系统框架图（Agilelabs EnterpriseFramework）：

 （图略）

 

 

 

这是一个典型的系统框架结构。我们通过它可以很快了解这个框架的方方面面，但不是细节，细节是实施过程的关键，那是另外的一个话题。

 

4.       参照,参照再参照

方法亦无常法，是要根据不同的情况，采取不同的方法，这里只有一个是共同的，那就是要解决问题。我们很多人束手无策，不是因为我们头脑不聪明，而是我们的头脑不够智慧，缺少一种变通，换句话，就是不够的灵活。

刚出校门的我们，很容易进入一个误区，在学校，我们习惯于一个人啃着笔头，去解决一个问题。如果我们一个问题不是啃笔头啃出来的，那么我们就惶惶不安，一是我们长期以来培养起的考试教育的自信，一是我们害怕会有某些很多难以预料的结果。我们却不知道，凭我们小小的脑袋，想去独自理解或者重新创建一个领域或者是系统，如果我们能够看到那些系统或者领域是很多很多人经历几十年或者几百年为创建完善这个领域或者系统而努力，那么我们就知道自己有多么的可笑。我们必须去搜索，去学习，去实践。

 

在软件行业，我相信，我们如果不能做什么，或者难以理解一个概念或者是知识点，那么，我们的方法是什么？

 

有人会到书店买大部头的书，一页页的啃；有人独自钻研，不停地按照自己的方式去试验；有人却到网上搜索解决方案，在帮助文档里寻找解释，在自己的键盘上啪啪的敲击小的示例。结果我们可以预料，那就是啃书的，很长时间还是一筹莫展，得出书很好的结论，仅此而已。埋头钻研的人，头发都白了，最终说：这个东西太难太难，然后灰心地走开了。最后一个很快就拿出方案，问题得到解决，虽然还不够圆满。一段时间下来，进步最大的也是他。

 

上面提到的情况完全是来自于现实中的人，问题在哪里？书要看，钻研也必须，问题在于，我们没有意识到，软件开发是一门实践的科学（很多学科都是实践的科学，管理更是如此）。只有在实践中才能成为一个比较合格的开发人员。有人会说，书，网络，等等，是不是不需要，恰恰相反，这些东西，是别人的实践，是宝贵的财富，但那仅仅是别人的，如果你不去理解，不自己动手去实践，那也还是别人的。比较合适的态度，对于我们这些平凡的人来说，最好多看别人写的东西，多听别人的意见，多动手去实践印证想法，我们时间有限，那么我们就要吸取别人的实践；我们无从下手，就要去动手，从最基本的做起。只有这样，我们才能取得进步。

 

现在是一个信息发达的世界，各种资料，在书店，在互联网，比比皆是。学习能力成为最重要的能力之一。上面的方法，简单地说，就是多参照帮助，多参照他人的文章，多参照他人的代码，并且不断地将这些得来的知识转化为自己掌握的东西。