怎样用智睿的哲学思想来指导软件开发过程?

zhongling520

怎样用智睿的哲学思想来指导软件过程。
为什么会出现bug？
马克思唯物辩证论认为物质决定意识，意识具有能动作用。代码是属于物质范畴的，代码衍生出来的bug是属于意识范畴的，所以
我们开发的软件出现bug，这是事物的必然性，但是由于意识是具体积极的能动作用的，也就是说只要我们从意识上重视软件开发过
程，是可以大大减少bug的；客户体验也同样如此。

怎样进行测试？
辩证唯物法认主张联系和发展的观点，在软件测试活动中，我们要站在全局的角度，用联系的思想去主导测试，整个的软件内部必然
是存在千丝万缕的联系的，在软件测试的活动中，看到A功能，必然要有能联想到和A功能所有相关联的功能模块，明白在某个页面上
对某个数据/记录进行任何的操作，这些操作在系统的后台会影响到其他页面的哪些功能，又是怎么影响到软件的其他相关功能的？只
有明白这些，测试工作才能做到有的放矢。

开发人员总是会纳闷，看到测试人员提交的bug，总是会诡辩我们这里没有这样的bug啊？这就可以用因果关系的辩证原理来解释，bug
的产生是一种结果，那么必然是由某种原因而产生这种结果的，bug不会是凭空而来的（这样也是违背了唯物论的观点的），且测试人员
也不会无故的冤枉开发人员，所以开发人员看到bug，在意识层里，首先应该想到产生bug的原因是什么，是代码有问题，还是由于环境导
致了这个bug，总是会有原因的，就算是找不到原因，找不到原因本身也就是一种原因。

怎么利用全局整体的思想来指导软件过程？
对于一个系统设计师或是系统架构师来说，你不能站在全局整体的高度来架构一个系统，到测试阶段必出大乱，一个软件设计师在设计架构时，
不是揪住某些细节的时候，而是应该以整体全局的意识来设计软件系统。对于测试而言，尤其是到了后期的系统测试阶段，也必然要以全局整
体的思想意识来主导测试工作，系统测试阶段不再是真对某个功能某个页面做具体的测试，而是应该纵观全局（整个系统的方方面面），来检测
系统还会存在哪些缺陷，这也就要求测试人员站得高。对于项目管理来说，全局整体的思想同样重要，不但要把独立的开发和测试当做一个整体，
还应该全局考虑开发过程之外的某些因素。

辩证唯物法很是强调发展的观点，任何一个软件产品发布之后都不会是个完美的产品，一个完美的产品是经过不断的改造的，也就是不断的发展而来的。
我们的产品经过不断的改造发展，怎么可能不成为一个完美的产品呢？

辩证唯物法的核心思想是矛盾论，矛盾的作用就是推动事物的优化。测试和开发本身就是一对尖锐的矛盾，但是测试却不会阻碍开发，相反，测试还大大
的驱动、优化了开发，这就是矛盾的作用。但是测试开发这种矛盾处理不好，又会带来消极作用，或许还会正常影响开发活动；这就体现了一分为二的观点。
那么究竟在整个团队中，测试是优化了开发还是影响了开发，这不是某个人说了算，这就用认识和实践的辩证关系原理论来回答这个问题，马克思认为，实
践是检验认识正确与否的唯一标准,我实践的结果是对这个矛盾的公正评判。

[ 本帖最后由 zhongling520 于 2009-11-18 17:40 编辑 ]

puchonghui

原帖由 zhongling520 于 2009-11-18 17:23 发表
怎么利用全局整体的思想来指导软件过程？
对于一个系统设计师或是系统架构师来说，你不能站在全局整体的高度来架构一个系统，到测试阶段必出大乱，一个软件设计师在设计架构时，
不是揪住某些细节的时候，而是应该以整体全局的意识来设计软件系统。对于测试而言，尤其是到了后期的系统测试阶段，也必然要以全局整
体的思想意识来主导测试工作，系统测试阶段不再是真对某个功能某个页面做具体的测试，而是应该纵观全局（整个系统的方方面面），来检测
系统还会存在哪些缺陷，这也就要求测试人员站得高。对于项目管理来说，全局整体的思想同样重要，不但要把独立的开发和测试当做一个整体，
还应该全局考虑开发过程之外的某些因素。

如果按照传统的软件工程里所谓的设计的概念，那么做设计的人必须是既要把握全局又要揪住细节，否则就不会去分什么概要设计和详细设计(high level design & low level design)了。

事实上现在的软件质量差，撇去外部因素不谈，从软件工程本身来看，最根本的问题在于很少有人能够胜任需求分析和系统设计的工作。 大量应该在需求和设计阶段解决的问题被拖到了后期，自然项目就会变得很难掌控。

其实做测试和做需求、设计是一码事情。 我曾经在一个很小的项目中尝试把所有系统测试用例当成需求分析文档的主要部分，效果还是不错的。
至于做设计，lz提到的：
“怎样进行测试？
在软件测试的活动中，看到A功能，必然要有能联想到和A功能所有相关联的功能模块，……”
这纯粹是设计的问题。作为设计人员，块间联系小，块内联系大，这是基本常识。 至于块与块之间的联系，必须要在设计文档当中指明。 否则设计文档要了干嘛？

如果真的理解测试与需求设计之间的关系，应该不会认为“测试和开发本身就是一对尖锐的矛盾”。 实际工作中的矛盾在于整个项目的首要目的是赚钱，软件质量只要客户认可就行。 在这个前提下测试人员作为乙方人员，自然就会被开发排斥了。