共享软件--1任何正规程序开发团体都要建立一个“已知漏洞列表”的漏洞数据库

1.进行技术积累,面向用户开发.

我对共享软件开发的一点建议:

一、献给某人的话：

　　首先说一下，这篇文章仅仅是一个入门、是一个讨论，我也仅站在门外汉的角度上对共享软件开发所需要注意的几个方面进行罗列，文章并不能将所有需要注意的环节写清楚，因而如果你认为此文不好，大可不看。

　　另外一点，我上面已经提到了，这是给刚刚接触共享软件开发的人阅读的，在他们看来也许能够有些收获，而在于高手看来，这篇文章中所述也许并不值一提，但是请不要忘记，新手在学习类和继承的时候，感觉是多么困难，因而请不要用你那种评委般近乎苛刻的目光对本文进行挑剔。

　　二、开发需要整体规划：

　　我们在做大多数事情的时候都需要进行整体规划，共享软件开发也是如此。如果你希望做一套功能完善、健全，能够经得起时间考验的软件，就一定要在开始写代码之前做一个整体的功能列表。

　　这个功能列表至少应该包括软件的所有功能、功能细节、功能实现的方法，并且为日后可能加入的功能做好充分的准备工作。为什么要这么做呢？原因很简单，如果你在编写的软件中包含多个功能，而功能之间又相互存在某些联系，那么如果你没有进行很好的规划，在编写代码的过程中你就会发现自己的思路越来越乱，直到最后几千行的代码到达“牵一发而动全身”的混乱局面，让你根本就没有可能对软件继续开发下去，结果可想而知。

　　举个例子，不知道大家知不知道网景公司的浏览器，曾经就因为混乱的开发模式而最终走向了死亡。那是一家大公司，开发团队的程序员很多，而程序员之间没有达到很好的默契，自己做自己的，做到最后竟然把一个功能强大的浏览器做死了。

　　个人编写共享软件虽然有别于团体开发，然而也可以看作是一个“大脑内部的团体”，你在编写软件的每一个功能的时候，都要充分考虑到其他功能对此可能带来的影响，因而开始之前的规划尤为重要。我曾经编写软件并没有注意这一点，因而一个软件通常要经过两三次的失败，然后在脑子中有了软件的整体印象，才能最终完整，与其这样反复，不如开始就作出完整的需求分析，所谓磨刀不费砍柴功。

　　三、建立漏洞记录和解决记录：

　　在编写程序的过程中，共享软件作者也许只有一个人，而所要进行的工作却非常多，美化、编码、调试等等，如此多的工作要由个人独自完成，脑子必然混乱，不要在这里说我牵强附会，谁敢说自己编写程序的时候脑子从来是清醒的？

　　因而无论是发现了程序中的错误，还是有了更好的想法，都要将它记录下来。如果是程序中的错误，至少应该记录下错误产生的原因、操作过程，并且把错误的解决方案也一同写出来。这样做并不是我个人的经验，任何正规程序开发团体都要建立一个“已知漏洞列表”的漏洞数据库，这是为多人之间配合而设立的此表，而我们虽然只有一个人，但是这个记录也是必不可少的。

　　想想看，如果你今天写程序已经写到深夜，而正当你准备睡觉的时候，突然想到了程序中的一个错误，如果你没有把这个错误记录下来，等第二天你是否还能记得昨晚临睡觉前所发生的事情？你又要和我叫真，非要说你能记住？好吧，那么假如是30个错误呢？假如你第二天有事情要出去，写代码的工作一定要两个星期后才能继续呢？不要说我走极端，在你看来多么不可能发生的事情也有可能发生，好记性不如烂笔头，将问题记录下来是最牢靠的。

　　四、注释要内外兼修：

　　也许有些人看到这条建议又要倚老卖老：我从来只把注释写在代码里面。我不和这些人顶撞，他们既然能说出这种话，说明他们没有遇到过苦头。但是亲爱的朋友们，如果你们还没有什么习惯可言，那么从现在开始要养成这条习惯。

　　写程序一定要写注释，同时还要写“外部注释”，也就是说你的代码中嵌入注释，同时还要为整个程序或者某个功能模块写份详细的外部说明，这份说明也需早在你做整体规划的时候就***出来了，如果没有，那么就请在完成每个函数之后将函数的作用、调用方法、实现方法都写出来，写出来的目的无非就是为了更好的维护。

　　假如你不这么做会怎么样呢？我们做个假设：你的软件经过了3个月的搁置，现在又要继续进行开发了，这次开发的主要目的是完善程序。当你打开了代码之后，你要在代码中不断的阅读自己3个月前编写代码的时候遗留的注释，那写注释也许只是只言片语，从这种断断续续的言语中，你是否还能够回忆起3个月前究竟是为什么写的这些注释吗？

　　而假若你拥有完整的函数说明，那情况就大不一样了，你只要阅读完整的说明文字，就能够很快的回忆起自己的代码是如何编写出来的。什么？你编程已经达到融会贯通的程度了？那你还看这篇文字做什么？

　　五、还说注释：

　　注释的重要性我就不说了，要说的是如果你的代码中某个地方进行了修改，千万不要忘记加上注释，并且暂时不要删除原来的代码，将原来的代码也用注释注上，这里要说明为什么进行更改，原来的代码存在什么问题。

　　如果你在某个地方进行多次更改，就为每一个更加加上注释和日期，因为我说过，你的代码中的每个函数见也许都相互关联着，它们之间的联系很可能达到牵一发动全身的效果，因而尽可能不要将自己辛辛苦苦编写的代码随便删除，也许那一天你会发现原来曾经认为有问题的代码还要使用，到那个时候想单凭记忆找回来就有些困难了。

　　六、保留软件的重要版本：

　　除非你的硬盘很小，否则建议将代码的重要版本都保留下来，原因和上面第5条差不多，因为你不知道什么时候会需要以前的代码，做好备份工作是非常重要的。我曾经参与学校内的某个项目，虽然说是个非常简单的项目，但是每天晚上的时候，我们都要将整个程序的所有代码、文档用刻录机做成光盘，并写上日期保留起来。

　　虽然说每天的任务之向前推动了一点点，但依然是如此“浪费”的将曾经已经保存过的代码在保存一便，这样做的原因还用说吗？说说吧，原因就是一旦在哪一天你的程序出了问题，直接将上一次的保存拿出来，然后继续开发就可以了。但是如果你每天保存的都只是“当天新写的代码”，那么你就会发现你还要经过一步或多步的“还原”操作，你能保证自己所有新写的代码都不会对原来的代码进行任何修改吗？

　　另外保存软件的早期版本还有一个妙用，那就是你在***过程中也许会发现自己的代码有不同的发展方向，这是在一开始并没有发现的。从某一版本开始，你就已经开始策划另一个软件了，那么只要将那个“分支版本”拿出来，从那里开始继续你的工作就可以了。

　　七、善用免费的公共代码：

　　也许你有这样一个想法：我要自己完成程序中所有的代码。那样的话我要说你有些傻。网络上有很多免费的代码可以直接应用到你的程序中，当你发现自己正需要某个功能的时候，先到网上找找有没有适合自己的代码，如果有直接用就是了。

　　记得曾经听过一个笑话，高级程序员和初级程序员遇到相同的问题需要编程解决，初级程序员会查阅资料编写代码，高级程序员会打电话问其他程序员要一份代码，两者不同之处在于后者懂得了“拿来主义”。做为共享软件开发人员，大多数是通过程序解决实际问题，这样就好像搭积木，只要你手里“积木”够多，通过不同的组合就能够写出多个优秀的程序。而前者则更好象是用原始的木料***积木，做了半天也没有成型的产品，那么前者所做的工作并不是***软件，而是在***零件。

　　当然对于此点在标题中已经鲜明的指出“善用”，便写程序不要一味的编写代码，也不能完全“拿来”，如果是完全的拿来主义，那你不如直接拿一个现成的软件通过修改资源界面痛快。

　　八、结语：

　　天下文章没有任何一篇能涵盖古今，即使恢弘的《史记》也无法道尽历史沧桑，更何况不足万字的这么一篇短文？因而你无法通过这篇文章掌握所有共享软件开发需要注意的事项。

　　另外，对于文章而言，只是一家之词，其中错误难免。但是正象余秋雨先生所说，读文章重在正篇的意义，而不应该拘泥于某些微不足道的问题上。如果楞有人在这篇文章上咬文嚼字，那也只能用可笑两个字来形容。

　　我希望能够有人来一同交流讨论，总结个人的心得体会，同时我也希望大家不要迷信这种理论性的总结，因为每个人的实际情况不同，在你真正开始进行某项工作的时候，也许你会发现他人的总结并不适合你，因而对于指导性的讨论并没有过多的意义，重在实际应用。