发现csdn blog中的网页的记数器停止了。

现在连写blog都没有激情了。。。。。。

出来第二期院刊。。。。。介绍本院。。。。。。。

不过感觉办得还是与期望差了些。。。不过大一的办成这样应该也算可以。。。

一

在业界，软件体系结构和建筑学的设计框架可以类比。如果把软件体系结构类比做建筑学的蓝图，那构件就可以比作一砖一瓦，或者更大概念如：庭院，花园等。

软件体系结构之所以可以独立于软件的数据结构和软件的算法，是因为业界把软件的数据结构和算法看做了烧砖的方法，或设计庭院的思想。

但没有扩展到整个软件系统。一个软件系统是庞杂的。但是分治之后的东西仍然用到了最基本的软件算法和数据结构思想。之所以也有些人说SA可以不用，是因为算法和数据结构的扩张有代替现在的SA的可能。

完美的构件是可以进行黑箱复用的。不太完美的复用构件就是白盒复用，要在原来代码的基础上做些必要的改动。软件工程的思想正是体现在软件流程、软件模块和软件文档的复用之上。否则也就没有工程的说法。

但是又有人提出软件体系结构复用的思想。这应该被认为是迄今为止最大粒度的复用。如果建筑师可以把自己以前的建筑蓝图拿来稍作修改就可以进行多次施工，那么软件架构师们为什么不能拿过去的系统设计方案稍作修改并实施到新的项目中去？

但是很可惜，没有一个企业的业务流程和另一个企业是完全相同的。所以软件体系结构的复用起来比建筑蓝图的复用要复杂的多。软件体系结构直接决定了软件系统的运行框架,其优劣不但决定了软件系统是否可以满足针对此软件的功能需求,而且还决定了这些功能需求是否能被合理、高效地实现,即也决定了软件系统基本的非功能属性[1].

每个用户的非功能属性多多少少的有所不同，也就决定着软件体系结构的复用的复杂性。软件体系结构是描述软件单元(element)、软件单元的属性(property)以及这些单元之间关系(relationship)的结构[2].这里的软件单元应该就是构件。

软件体系结构是构建计算机软件实践的基础，与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样。没有蓝图就不能构建出雄伟的大厦。没有好的体系结构也就不能构造出庞大的系统。

但是对于小型的系统，体系结构的思想似乎是一种多余。对于大厦，我们应该有建筑蓝图，但是对于建造小茅屋，似乎再画草图就是一种多余。软件体系结构表示了一个软件系统的高层结构，主要特点有：
1）软件体系结构是一个高层次上的抽象，它并不涉及具体的系统结构（比如B/S还是C/S），也不关心具体的实现。
2）软件体系结构必须支持系统所要求的功能，在设计软件体系结构的时候，必须考虑系统的动态行为。
3）在设计软件体系结构的时候，必须考虑有现有系统的兼容性、安全性和可靠性。同时还要考虑系统以后的扩展性和伸缩性。所以有时候必须在多个不同方向的目标中进行决策。[3]抽象的东西之所以对我们有指导的意义。是因为我们可以运用这个抽象的东西对具体问题做具体分析。法无定法，也就是这个道理。

[1] Bass L, Clements P, Kazman R. Software Architecture in Practice. Addison-Wesley, 1998.
[2] Sun CA, Jin MZ, Liu C. Overviews on software architecture research.Journal of Software, 2002,13(7):1228−1237 (in Chinese with English abstract).
http://www.jos.org.cn/1000-9825/13/1228.pdf
[3] http://www.itisedu.com/phrase/200602281725525.html

二

构件的概念类似于通用模块的定义。如同小时候我们玩的积木一样，可以松散连接，自由组合。但是业界还没有真正的这样的一个标准来制定构件，让它能同积木一样好用。实际上我们使用的“构件”还要进行一些修改之后才能满足一个系统的要求。构件应该是系统中实际存在的可更换部分，它实现特定的功能，符合一套接口标准并实现一组接口。

【1】 软件复用一直被视为改善软件工程的重要手段，软件复用是将已有的软件及其有效成分用于构造新的软件或系统。它不仅是对软件程序的复用，还包括对软件生产过程中其它劳动成果的复用。因此，软件复用包括软件产品复用和软件过程复用两部分的内容。借此来提高生产率，改善产品的质量。软件复用一般又分为源码级复用和二进制级复用。
【2】也就是白盒复用和黑盒复用 黑盒复用指对已有产品或构件不需作任何修改，直接进行复用，这是理想的复用方式。白盒复用指根据用户需求对已有产品进行适应性修改后才可使用。
【3】 无论白盒复用还是黑盒复用，都需要花费一定的代价熟悉和掌握被复用的软件系统。作为经济上的考虑，要求复用的代价必须大大小于重新开发的代价，否则就不应该考虑。
之所以业界使用构件这个概念，也是为了扩大复用的粒度。因为曾经的函数和过程已经不能满足日益庞大的软件的需要。

【1】 http://www.itisedu.com/phrase/200604161439595.html
【2】 http://arch.pconline.com.cn/pcedu/empolder/life/0403/343931.html
【3】 http://www.tongtech.com/jsqy/yqxwview.asp?id=209

个人认为软件工程所要解决的问题有3个：

1. 程序（代码）连接－－－并行开发

2. 需求变动－－－软件变动

3. 人员交流

大一时认为鱼与熊掌可以兼得；

大二时渐渐了解鱼与熊掌不可兼得；

大三时知道什么是鱼什么是熊掌；

大四时有人去煮鱼，有人去炖熊掌。

而我想喝些别人的鱼汤再去炖熊掌。。。。。。

数据结构其实是从各种应用中抽象出来的东西。刚开始学习的时候可能感觉有些费力。而且不知道学了有什么用处。这对于大二的学生来说，是很正常的事。而且大二刚学会c与c++，对模版，指针的编程可能还有些困难。

但是只要从简单的做起，从最基本的线性表开始编程，也还是会有突破的。但要切忌：绝对不能比这书本敲代码，即使书本已经帮你实现了。因为那样写出来的代码不是自己的。要学会自己思考着写代码，写自己的代码。

数据结构的精髓就在于它的思想。而并不是编程怎样实现。因为现在c++，java，c＃都已经帮你实现好了这些数据结构。要学会怎么利用这些数据结构来解决现实中的问题。而不是单单只会编一个栈或着一个树之类的。

在学数据结构的时候，可以把思路放开扩些。看看现实中什么地方用到了这些数据结构。也多想想这些数据结构将会用在什么地方。

现在要编写数据结构的代码，不一定非用指针不可，也不一定非用模版。链表可以用数组代替，指针可以用数组下标代替。虽然写出来的程序不通用。但是却可以掌握了某种数据结构的特性。（虽然在一定的情况下，数组不能代替链表）

数据结构本来就应该用在应用中间。当没有任何需求的时候，任何数据结构都是垃圾。所以我主张大家学数据结构的时候先写main来进行测试。将想实现的功能先放在main中，然后在一点点的实现自己的数据结构。

上士闻道，勤而行之；中士闻道，若存若亡；下士闻道，大笑之——弗笑，不足以为道。

翻译成现代文:

优等学生听人讨论道以后，学以致用，勤奋实践；
中等学生听人讨论道以后，将信将疑，辩证推敲；
一般学生听人讨论道以后，断章取义，驳斥讥笑；

天下评注:
其实，讥笑是必须的，因为没有经历讥笑或怀疑的阶段是无法真正领会“道”的。就像大家嘴上经常说的：
最近的道路也许乍眼看去格外得昏暗曲折。
前进的道路可能暂时导致无奈地远离目标。
平坦的道路有时暗藏隐密众多的陷阱障碍。

小卒观点:

感觉中士之道更值得自己学习,毕竟这世上的理论不能全盘否认,也不能全盘肯定.听说最近西南交大的一名硕士生在理论上证明爱因斯坦的相对论有误,并且也认为牛顿的万有
引力要改正.很多理学专家和他辩论几个小时,仍然未果.如果那个硕士是正确的,那就意味这我们曾经学过的各种物理书籍都将变为一堆废纸.不过如果他错了有能怎么样呢?
不过是真理愈辩愈名罢了.但是不过结果怎样,我们都不应该大笑之.毕竟,人家那气魄和胆识也是我们常人说没有的.

天下语论"亲朋友众":

第一类人是用缘分沟通的，叫做亲。
第二类人是用兴趣沟通的，叫做朋。
第三类人是用机锋沟通的，叫做友。
第四类人是用权势压迫，用利益引诱的，叫做众。

小卒观点:

看后认为这可谓至理名言.透彻的分析了人与人之间的关系.每当我们见面打招呼的时候,都可以用这四条标准来衡量自己身边的人.虽然口头上说是朋友.但是不是呢?用以上
四条分析过后就彻底明白了.

1. Please drop the wickedness programmes or projects even if they are perfact.

放弃或停止邪恶的完美代码。程序员们或许感觉有段代码写的很经典就继续保留或使用，但希望那些代码不是邪恶的。

正如过去的“大脑”病毒一样。代码写的很完美，但是却是人类邪恶智慧的结晶。

电影中同样造出了拥有智力的邪恶代码，编制者极力的保留这段代码，但最终还是害人害己，没有一个好的下场。

2. There is no perfact thing in the world.

不知道什么才是完美。但是这世上的确没有完美的东西。

程序也罢，人也好。总是有各自的缺点。正如程序中没有bug一样，人也不可能没有任何缺点。

拥有智力的代码终究被人删除。其放在人类世界中的炸弹也被人拆除。

没有什么可以做到完美。因为这世上根本没有完美。

好友的父亲去世了.就在十一前后.自己身在别处,没有给他帮上什么忙.想安慰他,有不知道说什么好.最后还是发了封不知所云的短信.

人生实在太短暂,终止的也太突然.正如诗人所说:" 人生苦短,多有患难,出来如花,又被割下.飞去如影,不能存留."活着好端端一个人,突然就消失在我们眼前.有感生命的脆弱.

现在想想海伦的<<假如我只有3天光明>>,感觉光明对于生存又算得了什么?如果题目改为<<假如只有3天生命>>不知道海伦又将怎样去写.不管题目是什么,海伦都将积极的应对吧.

想看破繁华似锦的世界,3天毕竟太少.但是能知道自己生命还有几天也必定会珍惜.最可怕的是根本不知道自己生命还有多长时间,却导致最终碌碌无为的走过自己的一生.

学校里学到的东西为什么没有用处？主要是学到的东西大部份都有人去实现了。比如数据结构中学做一个二叉树。其实在外边干活的时候根本不需要。谁会让你去编写一个二叉树？即使做项目的时候真的有用，大概也有已经实现的类代替了。所以有人说学校里学到的东西基本没有用。不过也难怪，因为这些人只是学到了原理或者方法。

学校教授的知识大概都是一些原理性的知识，或者是真正做项目要用到的一些方法。掌握了这些知识或者方法只是算一个平常的学生。

在往上走就是多做些项目，在项目中得到一些技巧性的东西。这样的人，在学院也好，工作岗位也好，都是一个很出色的人。从程序员的角度上讲，那是一些编程高手。

但是我总感觉这还是不够的。其实如果把每一本计算机的书理解透了。在某种意义上讲：那就是一本数学书。老师授课也好，学生学习也罢，都只是学到了表面的层次。好的或许可以提高到熟能生巧的地步。但是在表面层次之下隐藏的数学逻辑，如同操作傀儡的细线，把一本本计算机的书做成了傀儡。

为什么程序员们很累？为什么技术总是在变化？我们并没有发现其中最本质的东西。有些东西其实就是数学的延伸。只是做到了应用的层次上。

做一个题目也好，做一个项目也罢。有时我们只是知道方法再去应用。有时我们懂得原理再去实践。但是我们没有想过各种原理的相通之处。在各种原理的背后是不是还隐藏着什么？我们没有挖掘过。

当个程序员是很累，也很少有时间去想想各种技术的背后究竟隐藏着什么。不过如果能做到这一点，以后定不会被世界的潮流所抛弃。。。。。。