2007.1.29 [关于MSF过程模型中设计阶段]

刚才抽空看了些关于MSF的资料。MSF（Microsoft Solution Framework）作为VSTS世界观和方法论的基石，所以还是很有必要学习一下的。通过以往项目经验的结合，看的时候有不少地方存在着共鸣。所以赶紧这里写下来~

MSF过程模型是一个瀑布模型和螺旋模型结合的综合产物。为什么这么说呢？因为它结合了瀑布模型中Milestone，以及螺旋模型中的迭代，这两大优点。总体的过程被简化为了5个阶段：构思、计划、开发、稳定、部署。然后部署再一次的过渡到构思以成为一个迭代。在每次迭代中，它使用了版本的概念来代表此次的成果，而不是像瀑布模型中，走完一个周期就等于完工了。

以上的阶段与阶段之间使用里程碑进行分割，目的是为了确保整个软件开发方向的正确性，并且硬性的确定了在什么时候应该要完成些什么东西。同时，每个阶段的内部也定义了中间里程碑，在阶段内部进行划分工作和任务。

。。。。。。

有一点是我比较感兴趣的，就是在计划设计阶段，说实在点就是为项目作架构设计的阶段。这里它定义了4个diagram很清晰的说明了在架构中，我们需要关注的内容。（以前架构老挂在嘴边，但是真正的架构应该是像下面这种方式进行的）

1. 画功能图：功能图使我们从最上层的业务角度来看待整个系统，而不是从技术角度。

2. 画应用图：应用图使用了组件化描述方式对上面功能图中的每个业务功能进行定义。

3. 逻辑视图：这里在是真正的通过技术角度来说明我们应用图中定义的组件是如何实现的。

4. 物理视图：定义了系统在物理服务器上是如何部署的。

。。。。。。

想起当初做课程项目的时候，写软工文档。所有的设计，业务的技术的物理的，统统都混在一起了，其实都是错误的。老师的确也不太负责任就给了个还算满不错的分数，以至于我以为架构就是这么一个模糊的事情。到头来学了一学期的课，逃课担惊受怕不说，还学到了许多错误的东西。呵呵~不过现在搞清楚了，也算是一个很大的收获啦~~

2007.1.28 [心情日记]

我觉得我是这样的一个人：对待任何事情，风再大，浪再高，经常也只是微微一笑。遇到挫折、痛苦么，我也很少会多说些什么。当然如果事情严重程度比较高的话，我还是会郁闷个两三天的，但是仅此而已。从小到大印象中就没怎么把这种东西当回事。我信仰这个世界上没有什么挫折是我不能克服的。个人感觉这句话应该对任何人都成立。

e.g.，相信许多人都会有这样子的经历：常常会在一件痛苦的事情发生之后，再回过头来看，就会觉得这些根本不算什么痛苦。所以明知道会这样子，现在也就没有必要对它有太多的顾虑了！！大胆地去做，即使是犯错也好，体会痛苦所带给你的宝贵的经历，从当中努力地学到些什么，这才是最关键的！！如果只是一味的深陷进去，在里面无法自拔，那才是失败中的失败了！！

还有，我不是一个很会生气的人，因为我没那么小气！再说得准确点，我也没有时间和精力，更不想把自己体内好不容易通过呼吸作用而产生的能量花在这种没有意义的心情之上。所以如果有某个人能够让我愿意为之生气的话，那说明，他/她是对我来说很重要的人。

呵呵~就讲这些，睡觉去了~~

2007.1.18 [无比重要的一天]

我觉得我可能一辈子都没法改掉急性子的脾气了。没办法，我的天性咯~就像上个星期，也就是10号发工资那天，又买了一部手机回来一样，瞒着父母把所有的钱花了个精光。但是这次的代价更大，更具有历史意义。因为~我把自己给“卖”了。没有很多繁琐的思考，纯粹是为了能更接近于实现自己的梦想，所以一切凭自己的感觉而已~

签约，一切都很顺利。向HR询问了所有早已在脑子里列出的问题，什么四金啦、保险啦、调薪啦、年终奖啦，反正能够问的都问上了。与其说是谈合同，不如说是HR老师给我上了一堂很生动的法律知识课。作为本科生，这点我还是很惭愧的，自己一点法律意识也没有，法律课基本是白学的。还好HR姐姐很热情很热心的帮我解释这个解释那个的。然后花了2个小时才把所有的疑惑都解开了。哈~相信以后再找工作的话，这点知识也已经足够受用了。那个~关于工资么，这里就保密了，我没怎么和公司要求抬高工资，所以很一般般的，呵呵~

在将来的2年中，我的工作是在Microsoft的GTSC的news group作developer support的工作。其实工作的具体内容还不是很了解，根据面试情况，应该就是帮助微软的客户做技术支持吧。呵呵~很底层的工作哦。补充一下，其实我非microsoft的fte，只是vendor，由微软的第三方公司，中软派驻微软的。不过，这2年的工作，我的目标不是为了赚钱，而是为了experience。能够在世界顶级的公司，一流的团队里工作，很荣幸，好好学习收获会很大的。我始终坚信，在本科毕业的前两年，找一份比较具有挑战意义的工作要比稳定的那种要好的多多~~

嗯，对于昔日工作过的Kodak嘛，的确有些舍不得。好不容易认识了一群不错的同事哦，尤其是可爱的印度同事kumaran，教会了我很多。很对不起当，没和他说。不知道家伙他最近心情怎么样了呢？？不可否认，如果留在Kodak的话，待遇可能会更好。但是既然已经选择了并且走出了这么一步，我就会坚持走下去的。明天我会回Kodak，鼓起勇气和leader商量去的~

2月5号，会去徐家汇的美罗大厦报道。会努力工作的，新的开始哦~

2007.1.14 [对最近工作的总结]

最近的日子过得有些不太顺利，充斥着对加班的恐怖。为什么？加班要跑去远在金桥的公司；加班要自己先垫车钱，尽管可以报销，但是因为自己是research组，报销过程比其他组都麻烦，所以很种很讨厌的感觉；更因为加班表明着自己在工作上出了问题了。对此我一向比较恐慌，也许是自己比较单纯的缘故吧，总是怕自己的工作如果作得不完美，会在很大程度上影响同事们。

上周的双休日去加班，是因为kumaran要走了。kumaran是印度来的同事，来kodak作技术支持的。因为他的离开，我们需要额外的时间把剩余的手头上的工作都解决掉，而且还要从他那边接手他的工作。比较麻烦的，虽然和我们的这位印度同事混了那么长时间了，但是交流上始终存在着困难。

接下来一周就是作自己的unit testing。把自己的project部署到另外一台机器上去不是一件容易的事情，有时候IIS的确很让人戳心戳肺，权限什么的都ok，代码也都ok，数据库也ok，但是它就是不让跑。然后还要为ADS配置domian，由于lab的机器不是同一个网段的，所以还费了很大的周则，找人帮忙自己建了一个。testing是按照自己写的test case测的，test case是根据kumaran的high level design设计的。一切都很顺利，发现了一些逻辑上的小bug，自己也都处理掉了。然后写了份恶长的report，mail给了上面的头头。

这周3晚上，产品release新版本，结果发现在新的双核的机器上居然跑不起来。这点很是丢脸~大伙一起找原因，后来发现是现有的安装包的框架有问题，赶紧双休日加班把这个框架改了个遍，等到我今天到公司去翻新的安装文件的时候，已经都不怎么认识了。汗~

改过之后的安装包总算是可以用了，但是web console这边始终还存在问题。就是出在硬编码问题上，还好大部分的path都已经被我老早move到web.config当中去了，但是还是有部分，由于没有做过完整的code review而遗漏掉了。

在debug过程中还发现了一个有意思的问题。关于master page，我本来以为aspx页面继承他之后应该是首先运行它的codefile，结果竟然是先跑aspx的cs。这个以后要注意，这边的先后顺序设非常重要的，尤其是在这种统一页面框架的web app中。

过了今天，我们的产品的大部分问题都处理掉了，不过这里有很多点地方是很值得吸取教训的。我要指出的是，code review和unit testing对程序员来说是相当的重要，并不是说我们按照requirement，实现了functionalies，并且能够跑得起来了，就算是任务完成了，其实还有很多地方是需要做的，这些对将来的代码维护和功能扩展都能起到很好的作用。这里参考了vsts中的msf 4.0的一些方法论，总结为如下：

(1) 花些时间来进行检查

这里就是需要我们程序员在完成了编码任务之后要多检查自己写的代码，从各个角度，比如代码的安全性，稳健性，规范性。这里规范性很有必要调出来长篇大论一番，限于这里的篇幅，我就不想多说什么了。但是我在工作中一再强调，但是始终没人回应，貌似很多人觉得这个是多余的。难看的代码结构，说真的，这点我很火大。代码结构的清晰，使用语句的规范化，足以可以使我们避免很多上面加班时发现的问题。

(2) 让审阅者来推动检查工作

就像徐曼涛老大说的，团队中就是需要一个“催催”！！不过这里不是催进度，而且要经常要主动的带领程序员开展检查工作。拿我个人来举个例子，有时候的确是很懒的，也像很多其他程序员一样，作个testing也都是草草了事，其实这样是不对的，隐患很大！！

(3) 在召开检查会议之前，阅读代码或设计文档

在一个人编码结束之后，同时也是需要其他人来协助审查的。根据设计文档，检查xx程序员所写的东西，是否和requirement上的一致，设计方面是否合理，代码逻辑是否正确，哪里存在可以提高的地方。以上这些都可以以一个小的检查会议的方式进行，当然在以上审查过程中，代码的作者不应该参与，这里的原因很简单，可能包括人际关系的处理，rp问题，以及人和人之间交流的理解问题，等等。

(4) 使用团队项目门户为小组检查工作提供帮助

一般来说，可以使用一个门户网站来刊登近期的update，这样所有成员都可以看得到。但是由于公司条件的限制，要搞这个貌似很困难的样子。

(5) 使用检查表，列出以往可能发生的错误

在代码审查期间，应该要列出以前发生过的一些错误，对这些错误进行必要的检查。没人能够保证以前的错误现在不会再次发生。对伐？这里我觉得，应该要建立一个knowledge DB，可以估计也很困难。

(6) 跟踪在代码检查期间发现的所有问题

很多问题发生的时候可能不容易立即就fix掉，而后很容易让人忘记。我就经常发生这样的错误。总是。一？怎么这个版本中还有这个问题，检查clear quest后发现原来是自己漏掉了，雪特！不过也难怪，公司很多新的functionality是直接来自于service的，因此很多都没有文档化，这个是极其极其的错误。首先将来跟新service maunal就会有困难。其次是需求变更的管理也会产生很大的问题。很多新的需求不是说客户或者是service那边说加就加的，这怎么可以？？以前太老实，不懂，加就加，一改代码结构越来越乱，bug不断，娘俄！！这些都是需要重新review的地方。对于新需求的可行性，大家都要拿出来一起讨论，确定。设计文档也要拿出来一起review，然后再编码！！

(7) 不要在不通知审阅者的情况下更改代码和设计

这次的integration test当中也出现了很多很可笑的地方。这里我不是说某某人不好，还是交流和管理上的问题。居然有人会问我，某某功能到底是什么？这个怎么会和以前不一样？是bug吗？娘俄，kumaran更新过design document，你怎么不看？测试的时候跑过来问我什么什么。相当的火大，文档他妈的不是放在clear case上摆摆样子的，就是让你们去看的，不看的话，这个测试怎么做的好？？把我新加的东西也拿出来提交为bug了。这里我可能说偏了。但是以上的问题很值得提一下，需要吸取教训。徐老大说的没错，我们只是个junior team，还不成熟！！言归正传，在代码审查阶段，以及测试阶段，作为程序员，不要急着去改代码，等所有的report都出来后再说！！以免将来又搞伐清爽了|||

很多人可能会说以上的部分很麻烦，有必要这么做吗？我觉得在一个project中，尽管很忙，但是还是需要抽时间去做的，这样也不至于在关卡上出现那么多问题，令人不愉快是小，产品跑不起来才是真的要人老命。

嗯，就说这么多了~

我说的不对的地方，希望各位老大可以帮我指正，谢谢啦！！！

2007.1.4 [AJAX学习笔记1]

这些日子，也不知道为什么突然想学些ajax方面的编程技术。也没多考虑所学之物对工作是否有用，就趁上班时间忙里偷闲，翻阅了网上一些关于ajax的入学者文章^ ^。大多文章都很乱，也很不系统，草草地将所有技术灌输一通。娘俄~就像看白话文一样，不过我还算是比较有毅力的，啃掉了不少|||所以，想在这里把自己做的一些读书笔记整理一遍，以便自己或者有兴趣学的朋友将来一起查阅。

作为第一篇，自然应该从最基础的开始入门。从网上拷了一段例程如下：
<script language="javascript" type="text/javascript">
    var xmlHttp=new XMLHttpRequest();
</script>

这里的XMLHttpRequest对象就是整个ajax技术中最核心的对象了，掌握它基本上就可以掌握ajax的半壁江山了。俄~关于这个么，网上就是这么说的，不是我自己瞎讲的，求求你相信我。创建它的方式也很简单，普普通通的一句javascript语句嘛~但是由于不同浏览器厂商生产的browser处理xml的方式是不同的，比如微软的ie和网景的netscape就有很大的区别。所以在创建以上的HttpRequest对象时最好是能够采用更通用的方式。

 

这里可以稍微的深入一下，微软使用自己的msxml解析器来处理xml，这就是可恶之处！！根据ie中安装的javascript的版本不同，与之对应的msxml也有两个不同的版本了，雪特~

 

有了以上这些知识，各么我们就可以理解如下的代码的用意了-.-

var xmlHttp=false;
try{   

    xmlHttp=new ActiveObject("msxml2.xmlhttp");}
catch(e1){
try{   

    xmlHttp=new ActiveObject("Microsoft.xmlHttp");}
catch(e2){   

    xmlHttp=false;

}}

其他非微软的浏览器直接使用new一个XMLHttpRequest对象就可以了。据说在大多数浏览器上面都支持。

接下来，我们就可以开始研究下使用XMLHttpRequest来收发ajax的请求和响应了。看了就知道其实很sb，没什么技术含量的>"<
首先是一个统一的流程（我一向喜欢统一的风格！！为什么？因为简单）：
1. 从Web form中获取需要发送的数据
2. 建立目标url地址
3. 打开到目标url的连接
4. 发送请求
5. 么了~

继续看我从网上k下来的代码：
function callServer(){
  // 传说中的从web form中得到数据，这里是大家已经很熟悉的dom
  var city = document.getElementById("city").value;
  var state = document.getElementById("state").value;
  
  // 建立url，其中有要发送的数据使用了查询字符串的方式
  var url = "/scripts/getZipCode.php?city=" + escape(city) + "&state=" + escape(state);
  // 打开到目标url的连接；这里是要注意下的最后一个参数为true，表明请求一个异步连接                                                   
  xmlHttp.open("GET", url, true);
  // 服务器会发通知来调用这个函数，返回是数据在里面进行处理                                       
  xmlHttp.onreadystatechange = updatePage;
  // 发送处理请求；为什么是null呢？管它的，以后再说！！！
  xmlHttp.send(null);
}

发送了，那么还要接收服务器回应的处理结果咯~
function updatePage() {
    if (xmlHttp.readyState == 4)

    {

        // 很喜人的地方，返回的数据就保存在responseText中！！
        var response = xmlHttp.responseText;
        document.getElementById("zipCode").value = response;
    }
}

有些小地方必须要注意！！xmlHttp.readyState属性是很重要的，由于是ajax嘛，异步的javascript和xml技术，所以理解他异步是如何反应的是很重要的！！所以我们要知道这个处理结果是否已经就绪了。这里4就是一个预定义的常量，我们用它来看看服务器的处理是否已经就绪了。个人感觉么，这个函数就像是个listener，client上定义好，由服务器来调用= =|||