| SG's profileGreen的共享空间BlogListsNetwork |  Tools  Help |
|
|
November 16 参观IBM心得 我们的空间好久没人写过东西了，今天我参观了IBM的CSC(China System Center)和CDL(China Development laboratoris)，我特别想把我的心得体会写在我们的共享空间上，希望大家不要介意:-P
过去我只知道IBM电脑很实用，大家都很喜欢买IBM的电脑，今天我看到了很多IBM内部的我从没看到过的东西。
首先，今天我第一次知道IBM原来是International Business Machine的缩写，我居然从来没有注意过。。。
第二，IBM中有好多台机器，而且针对不同硬件需要安装不同的操作系统，管理员对机器的维护的任务很重，今天提到了云计算，这样可以有效的进行管理，减轻了人为的负担。
第三，IBM强调smart，强调make a difference，要创造智慧的地球，要敢想，要与众不同。今天演讲者举个例子挺逗的，他提出让狗来coding，这样人就可以做些其他的事了，狗coding完还会对人笑一笑，这样CEO一定会非常happy。一定会非常support这项研究，会support好多人和money来搞让狗coding这件事。我觉得这个例子有点夸张，但是演讲者就是想告诉我们IBM是非常提倡大胆idea的企业。
第四，今天我印象最深的就是z9 EC，今天介绍这个的时候真的有雷到我，z的意思就是zero，零down机，一年365天只需休息5min，这台机器要1亿多，只是里面的一个控制器就要几百万，要用特别的地砖才能承载住它，IBM用的可以承载1.4吨的地砖来承载它，听说一小块地砖就要2000多块，承载那么大的一台机器，只是地砖就要多少钱啊。。。
第五，IBM的存储设备也是很牛的，有一个机器好像是叫IXV，每个小的存储单元都有1TB，整个机器有180TB，当有数据需要存储，不是将这些数据存储在一个存储单元上，而是将数据打散，每个存储单元都存一些。当机器down掉时，可以在3s内恢复，而且数据不会丢失。
第六，IBM那么多台机器，每个月的耗电要几十万块，为了节省电量IBM采用了水制冷技术来对部分服务器、storage等进行制冷，这样可以节省好多电费。一共有两个水管，将水设定到一定的温度匀速从一个水管进入，然后从另一个水管将热水带出，水可循环用，可以和中心的中央空调共用，很节省能源，这样也可以有效的帮助机器散热，确实是一个好办法。而且在水进入水管之前要进入一个减压的装置，以免发生意外也只是会造成漏水或滴水，不会造成喷水的状况，考虑得真的很周全。
第七，机器的电源、CPU等都是有备份的，一旦有一方停止将不影响机器正常工作，否则后果将不堪设想。
第八，今天提到了一个问题很有意思，IBM的CRL(China Research Laboratoris)只有200名员工，可是CDL(China Development laboratoris)有5000名员工，问这是为什么呢？有人的回答很有意思，说CRL是花钱的，CDL是赚钱的，据说这个答案很接近，CRL是研发，是很大胆的idea，可能成功为公司赚很多钱，也很可能失败只是耗费了公司很多钱。CDL是为公司创造收益的，因此要多一些员工。而且CDL要面向的是广大的形形色色的用户，和CRL不同，因此要多一些人才行。不知道是不是所有的CEO，所有的企业都是这样想这样分配的呢？不知道Microsoft、Google等是怎样分配的呢？
第九，听说IBM是一个很适合第一份工作的地方，在里面可以学到很多东西，如果有什么问题可以有一堆人帮助解答，不知道是不是真的这么牛，但是还是觉得IBM是一个非常伟大的企业。
第十，IBM是一个很重视团队合作的企业，我觉得Microsoft也是，因为我从邹老师的课上就体会到了，团队合作真的非常重要。
嗯，差不多就这么多了，不知道有没有哪个地方说得不对，望指教！
------ by Wen Yue January 07 收获2009年1月5日，a special day,for all of us.对于做demo的人，他们展示了软件的最终成果。对于我，从他们的demo中学习到了很多。
软件的制作过程不是只会写代码就可以的，还有许多东西需要学习。例如，要学习一些和这个软件类似的软件，了解那些软件的实现。有那么多好的软件，用户为什么不选择那些软件而选择我们的软件呢？这是个非常值得考虑的问题。team4提到了他们要制作绘图软件，花了一段时间学习和使用了mspaint等软件。
team1,tank又有了新的变化，现在tank的行走不会显得不连续了，而且设计了几种tank的外形供选择，不知道外形不同的tank在各性能指标上有没有什么区别呢？
team3, 我最好奇的就是他们的界面做得怎么会这么漂亮，和ms一个风格，现在知道了，原来是他们用了microsoft的资源。iHunter要实现download,所以安全问题很重要。
team5，可以换皮肤，界面很漂亮，有天气预报，想得很周到。
在一个有时间限制的情况下要实现一个功能驱动的软件需要合理的安排时间，每个阶段都要有个明确的vision.即使到最后会和最初的构想不一样，但是如果没有计划会变得更糟。而且，要合理的分工。
在软件的实现中会有很多突发的事件，这时该怎样处理是很重要的。比如说，team1遇到disagree时选择了vote,是个很好的方法。
软件的工作量不能只用代码的行数来衡量，not everything is as it seems,用起来很方便的功能实现起来可能需要很深的算法。即使一个只有2000行的程序段，实现的算法的工作量可能是非常大的。
测试很重要，TFS很好，大家可以通过这个把软件的bug返回给设计者，可以使他们尽快的修复。有几个组修复了很多TFS上提出的bug.
软件实现出来，最重要的是得有人用，所以在把基本的设计出来后就要考虑如何使自己的软件变得popular，team4反馈了用户的使用信息，这个很好。软件实现的目的就是要解决用户的pain，只有真正解决才达到目的，所以要及时得到用户的反馈信息，然后及时完善软件。
软件实现出来之后，如何做宣传，如何去争取更多的用户也是很重要的。
January 01 TM 1.0发布感想课程快要结束了，回想起整个课程来，和最初的设想差别的确很大，我也没有想到我们这组的进展会如此的不顺利。用一句话来说，“很受伤”。我前段时间和一个J40的师兄（Mr. 8）聊天，他说他最近在看一本软件工程的书，书中提到了一个“人件”的概念，和“硬件”“软件”并列。他很黯然的对我说，软件工程其实就是“人”的问题，当时我就有“相见恨晚”的感觉，因为我当时也很黯然。还是一点一点来说吧。 首先，这门课程的确讲授了软件工程方面很多很实际的知识，同时课程也设计的循序渐进，一个学期下来，虽然失败了，但是我收获很多。以前不知道软件为何物，单纯的认为软件是代码堆起来的金字塔，现在看来软件工程中方法要比写代码重要，一个有效的方法可以有效的减少废代码的数量。 但是这么课最大的问题并不在于知识的讲授，而使如何在软件开发过程中处理人与人之间的关系。在现实的软件设计过程中，大家都约束在一定的权利和利益的关系之中，所以各个角色能够各司其职，各尽其能。但是在我们的课堂上，我们都是平等的，所以大家只是被约束在一个一文不值的“道义”之中，一旦涉及自己的根本利益，比如“玩的时间”，“排练的时间”，“陪女朋友的时间”，那么让“道义”见鬼去吧。有人提出让PM掌握一定的给分权利来约束大家，实际上没有从本质上解决这个问题，毕竟PM的地位和组员是一样的，甚至是至交关系，谁也不愿意看到自己的同学因为自己而挂了（虽然这是由于他没干活造成的），所以这个约束作用也是会大打折扣的。如何在软件工程这门课上模拟出类似真实软件开发的环境，还是需要“大智慧”的人去发现。 实际上周老师说一开始我们组是最安全的，着实把我吓了一跳，说的我都有点相信了。但是如果是我们班的同学应该知道我们组的成员是一种什么样的情况，某些人自己心里也是明白的。所以即使是设计过程说的多么天花烂醉，一旦到实现的时候总会出现很多掉链子的情况，因为在设计过程中他根本没有去考虑自己的利益，但是一旦实现了，那么他就开始后悔了，推三拖四的。其实我们组是最好的例证，虽然我们的计划是11月定的，但是我们组的代码大部分都是12月中旬写的，更不用说连调了，这其中就是因为有些人没有干活。还好，这些人不是很冥顽不化，在我的“悉心劝说”之下还是动手了，以至于我们的工作得以完成。 其次，我们组，应该说是我对软件的需求认识不够，在软件设计的过程中提到了自以为合理的需求，实现的时候却发现无比的艰难，后来我们的组员根据前面的设计进行了改进和简化，才使得我们的项目得以顺利进展下去。在很多软件工程的书中都提到过这种现象，不知道是不是叫做“软件黑洞”，如果对软件需求定义的不合理，会毁掉一个软件，但谁才能知道“合理”的真正含义？ 剩下的一些问题则是能力问题，比如语言不通，不懂C#，不懂Wpf，不懂Boost，不懂MySql，好像我们几乎没有使用什么以前会的东西来编程，不过现在这些应该都算弄明白了，也是一个不小的收获。又比如方法不通，很多人都没有学过设计模式，软件的可扩展性极差，可维护性野很差，给我的映像是，“我们始终在改代码”。 最后说一下这门课程的评分，其实作为一个大四的人，已经么有什么追求了，所以只要能够给我通过的话，我不是很在意我得了多少分。但是这么课程的给分还是有点不合理。首先PProject就像一个笑话，前前后后折腾了半个学期，还没有什么很好的结果（很多DEv都倒在了Test的手中），评测过程也极其的不透明（自己的程序怎么挂的不知道，Test甚至不通知一声），评测标准也很不合理（不知道是Test的方法错了还是Dev设计有问题，同时分别Test给分和Dev的给分本来就不公平）。其次是T Project用工业界的你死我活的方法（在P Project中也用了）来给我们评分，也就是说即使有时你很努力，但是你还是什么都得不到。但这只是一门课程，这样做使得这么课的性质就变了。 好吧，就写这么多吧~~ 有谁想拍就拍吧~~~~
------ by Hu Wei Troup Manager 1.0 ReleaseTroup Manager 1.0终于还是被干出来了，虽然过程坎坷了点，结果没有预想的好，有些功能尚未实现，但是软件在设计初的基本架构和基本功能都实现了。TM 1.0已经上传到了TFS上面，文件夹下面有一个ReadMe.txt提供了编译和运行的方法，不过要求比较苛刻，可能大多数人不能搭建起来，需要测试的请联系我们组的组员王乃峥同学和金石飞同学，他们的Email联系方式在Blog下面的列表中列出来了。我这段时间有点事情，所以不能帮组进行测试。 下面是目前版本的信息，其实在ReadMe.txt中的内容。
接下来则是晒一下几个GUI的截图（注：这个GUI不是最终版本，因为很多色彩和结构还未作精心的设计，所以看上去有点山寨） 登陆界面
浏览界面，可以看到评论和一些基本操作（浏览服装资源）
个人信息页面
FTP文件上传（图片）
实际上，目前的界面的很多元素都未做细调，界面的背景色是一直在变的，但是很巧的是每次的截图都是很难看的大红大紫，诸位就将就一下了。 ------- by Hu Wei 由分数引发的感想大家都很在乎分数，同样，我也在乎。尊重是自己赢得的，同样，分数也是自己赢得的。这个道理在软工这门课中体现得淋漓尽致。
我这学期刚刚来清华，一切都是新的，一切都要重新学起，一切都要重新适应。第一个走进的清华课堂就是“Adcanced Software Engineering”,让我流泪最多的就是软工这门课，让我笑得最多的也是软工这门课！第一次走进这样的课堂，一个词--“喜欢”！从来没有上过这么有意思的课！啊啊，原来可以这么开心的上课！啊啊，原来认为不公平可以和老师argue!最开眼界的是这门课，收获最多的也是这门课！最开心的是这门课，最头疼的也是这门课。当我看到IProject成绩排名中一个一个2005XXXXXX时我才知道，我居然糊里糊涂的跨年级选了软件实验班的课。大三的课就够我觉得难了，软工这门课对我来说更是难上加难！当我遇到IProject时，当我遇到PProject时，只有一个词可以形容我的心情--“茫然”！C#？What's this?我从来没有接触过！去图书馆看书，上网查资料，IProject终于过关！可PProject?......我真的曾经想过要把这门课退掉，好难呀！不是我能承受的！可是我怎么舍得？邹老师是唯一一个下课会问我听得怎么样的，会发email问我最近programming进展如何的！当我彷徨无助时，是贝帮我解决了大难题！当我编程遇到问题时，是胡巍教我该怎样写程序，该怎样调程序，该怎样养成编程的好习惯！听说一只小鸡很容易死掉，我很庆幸孤身一人在这里的我还可以活得好好的！软工课老师和同学的帮助和照顾是我生活的脊梁，my favorite course,my favorite teacher,my favorite TA,my favorite classmates都在这里，没有你们这趟清华来得就没有意义！第一次听说从来不翘课也会担心挂科的！即使分数对我来说很重要，但此时对我来说更重要的是我的收获！通过这门课我真的觉得我的编程能力提高了！
下面我来谈谈我对PM给分的看法吧。我觉得这部分最为难的不是我们，而是PM，即使是不干活的组员，可能PM也不会忍心或是不好给0分。胡巍我想对你说：“看到你写的几千几万行程序，我真的很惭愧！我们的TProject中没有一行代码是我写的。请给我0分或少给我一些分吧！看到你熬夜编代码，我却可以安稳的睡觉，我也觉得很不公平！怎么可以这样？我们是同一个team！我实在不能让自己和你们得同样的分数！”即使我被挂掉，那也只能是我的宿命！我不是不想为我们的TProject做事，而是这么难的代码我真的不会编！不过剩余的时间里我会为我们的TProject做一些我力所能及的事！大家也能做什么就做些什么吧！Team's score is our score !
最后我建议大家都主动的跟PM提出应该给自己多少分吧，不要让PM为难了。
------by Wen Yue 谈谈测试软件已经写得差不多了，下一步主要的工作就是测试了。下面来谈谈测试吧。
首先要搞清楚我们测试的目的到底是什么？该采用怎样的步骤及原则来测试？测试的结束点是什么？
测试的目的：
站在用户的立场，他们比较希望通过测试来暴露软件中隐藏的错误和缺陷，来考虑是否接受该软件。而站在软件开发者的立场，他们更希望软件不存在问题，并已基本满足用户的需求。Grenford J.Myers said: “测试是程序的执行过程，目的在于发现错误；一个好的测试用例在于能发现至今未发现的错误；一个成功的测试是发现了至今未发现的错误的测试。”
测试的步骤及原则：
正如邹老师在移山之道中说的，测试不能盲目的进行，要有计划的进行测试，要遵循一定的步骤及原则。 1.首先要写测试计划说明书，说明软件的功能是什么，要测试哪些方面？有哪些预期bug比较多的地方？如何去测试？。。。。。。 2.在具体的测试中，测试用例要包括合理输入和不合理输入以及在各种输入状态下的预期结果。因为在软件的实际运行中，用户很有可能会进行一些意外的误操作，如果软件遇到这样的问题时不能做出适当的反应，将会产生故障，轻则返回错误数据，重则整个软件都会废掉。
3.发现bug时要写出具体的错误报告，以便程序员能够很快的解决问题。
4.对于任何一个程序员来说，都不希望自己的软件有问题，而且也对自己的软件倍感信心，所以在测试时可能就会选择一些很小概率出现问题的test cases,而逃避选择那些易于暴露程序错误的test cases。因此在内部测试中最好的方法就是找同组的其他人来测，尽量避免自己测试自己的部分。 5.由于软件的复杂性，开发各阶段的多样性等因素，软件应尽早的进行测试。
6.要妥善保管测试计划，测试用例，错误报告，为软件维护提供方便。
测试的结束点：
按照错误的严重程度大致可分为：严重错误，主要错误，次要错误，一般错误，较小错误。确定测试结束时，首先要保证严重错误以及主要错误已经完全被解决，次要错误以及一般错误已经85%以上被解决，较小错误70%以上被解决，少量缺陷可以留到后面版本再解决。
结束语： 这一部分的工作是尤为重要的，如果我们的软件连我们自己测试的这一关都过不了的话，就根本过不了千奇百怪的用户这一关，就会是个不稳定的软件，就会是个不受欢迎的软件，就会是个逐渐走向灭亡的软件，所以我们要尤其重视这部分的工作。
----- by Wen Yue
December 28 影响软件品质的重要因素什么样的软件可以吸引更多的用户？什么样的软件可以让用户废寝忘食的使用？影响软件品质的最重要的因素是什么呢？界面？速度？功能？可扩展性？可维护性？安全性？操作简单？
因人而异，因软件性质的不同而不同。但是用户对软件速度的要求只会有增无减。有一个很有趣的现象可以证明这种说法：网页上一个链接如果打开超过2秒会有人抱怨它很慢，如果超过5秒则会直接取消链接操作;但是如果那个网页是必须要打开的，超过5秒还没有进入则很多人会选择强制刷新，刷新后如果又超过5秒则会直接关闭浏览器然后重启。我听有人说过：“我可以允许自己等女朋友2个小时，但绝不允许一个网页使自己等待5秒钟”。我还听说过，有人玩游戏因为响应速度太慢而重装系统。用户都希望软件使用起来舒服，至少不至于折磨人！美女大家都喜欢多看几眼，但也没见过哪个丑女大家见了都会骂的。同理，界面不够漂亮也不至于有太多人抱怨。但是如果速度慢了，可能就会有人砸键盘，摔鼠标，敲桌子，扔书。。。可见，软件的速度有多重要！ 对软件品质的要求在不断的变化，听说计算机系的人最喜欢的一个词就是"KISS(Keep It Simple and Stupid)"。界面要求简单而大方，功能要求精简而强大，操作要求简易而不繁琐，是为了更多的用户可以使用自己的软件吗？Maybe!看来用户才是最重要的！ 来想想我们的软件吧，Troup Manager，面向所有像清华大学这样的剧团或各种社团用于方便管理服装、道具、书籍、人员等等。面向的用户是社团中的成员，大多是不太会使用电脑的人，对于我们的软件而言，操作简单，那是一定要的啊！因为我们考虑到我们的软件的实用性，所以是要一届一届传下去的，所以可扩展性对于我们的软件而言也非常的重要。是剧团使用的软件，界面只要有些艺术气息就足够了，关键是实用，能真正起到方便管理的作用。我们不用联网玩dota，就算速度慢了也不至于被虐，所以我想只要是一般人能接受的速度就可以了。因为我们的软件所面向的用户和用处都比较单纯，所用到的数据也不是什么很机密的东西，应该不至于有哪个黑客来攻击我们的软件，所以安全性应该不用要求得太高。 恩，个人能力有限，就总结这么多，有哪里写得不够准确还请高人指点。 ------ by Wen Yue
November 24 WBS1. Feature Design
1.1 Frame work - 1
1.2 structure of GUI - 0.5
1.3 Distribute the feature to each part of GUI - 3.0
1.4 How to implement the feature in GUI - 3.0
1.5 Write document - 4.0
2. Database
2.1 Design the basic structure - 1.0
2.2 Design the interface
2.2.1 Inner interface - 2
2.2.2 Outer interface - 4
2.3 Implement the function
2.3.1 The public function - 4
2.3.2 The private function - 4
2.3.3 Debug by some testcase well designed - 8
2.4 Test the database
2.4.1 test by small amout of real data - 4
2.4.2 test by large amout of real data - 4
3. FTP
3.1 Learn Boost
3.1.1 Ask Mr. Ba for help - 8
3.1.2 Read the document - 3
3.1.3 Google it - 5
3.2 Implement the basic FTP-Server - 8
3.3 Test the Server in Linux - 8
3.4 Implement the basic FPT-Client - 5
3.5 (Opt)Extend the FTP-Server and FTP-Client by real need - 8
4. GUI
4.1 Learn WPF Document - 8
4.2 Discuss the feature document - 2
4.3 Analysis how to implement the feature - 8
4.4 Implement each feature - 8 per feature(8*5)
4.5 Improve the GUI
5. Background interface
5.1 Login and register - 8
5.2 Query - 8
5.3 Query the shared file - 8
5.4 Transfer the share file - 8
5.5 Functions of the administrator - 8
note : Recently there are at least 5 main features. So we know that there is a lot of work to do with GUI. I distribute the work to 2 persons.
---------- by Hu Wei November 16 11月14日组会概要1. Blog工作相关
1.1 进行资料共享
1.2 发布自己的主意或是想法
1.3 讨论
1.4 公布各模块的规格
2. 梦断代码启示
2.1 要尽快做出狗食版
2.2 要好的编程习惯
2.3 做好模块化
3. 进一步讨论程序的基本架构
3.1 弱化了FTP的功能
3.2 DateBase和FTP的同步
确定了分工：
FTP模块————王乃峥：
任务：实现一个可以稳定传输数据的类FTP服务器和客户端
DataBase————汪汀：
任务：实现一个管理剧团文件和物品的数据库
GUI————闻悦、赵育达：
任务：用WPF设计出用户界面的框架，做到如果提供一个软件功能，该界面能够快速的把该功能插入到界面的合理的位置
功能定义————金石飞，胡巍：
任务：提供软件的功能定义，协调DataBase和FTP的同步，指导其他模块的实现
------by Hu Wei 网络学堂之痛 网络学堂是给上课的学生和老师用的，同时也是清华大学的一个门面，让外面的人知道清华大学的教学现代化程度能够有多高，即让校外的人也能够享受一些清华大学的教学资源。这个想法是不错的，整体上也坐到了，但是细节上做的很不好，可谓怨声载道（当然，很大一部分是针对某一特定的Bug，因为现在形而上的修复了 -_-b）。
1. 用户界面不够友好，或者说太难看了，这可是清华大学的门面，还做成这样
2. 服务器有时不稳定，特别是Deadline那天
3. 上传文件不稳定，有时候会覆盖其他作业的文件，而这次作业显示未交
4. 讨论论坛不友好
5. 有一些功能基本没有用过，比如课程答疑等等
6. 没有用户偏好设置，管理死板，比如我想按照我的分类方法来管理以前学过的课程
7. 校外登陆困难，传文件困难
8. 教师权限管理混软，比如微软的老师不能用网络学堂之类的
9. 没有提醒服务，比如作业快到期了，发邮件或短信提示赶紧交吧
10. 待续
如果需要我去设计软件，我会先做出一个整体的框架出来，然后再去考虑细节方面。相信如果尽早的让别人使用，了解客户需求，必定会在细节方面更胜一筹。
-------by Hu Wei 如果我是卡普尔——《梦段代码》续 如果当年我在OSAF做Chandler，尽管是事后诸葛亮，我也不见得比他们做的更好。Chandler遇到的问题是现在软件开发中的典型问题，似乎没有很好的解决办法。
首先我会跟倾向于有纪律约束的开发，而不是OSAF这样比较松散的管理。可以看出Chandler在开发过程中进度总是落后于计划，然而这样却没有什么“惩罚”的措施，这使得没有什么动力去推动项目进展。人么都会想进度又延误了，我们得多花点时间，然而除了卡普尔没有任何人为此“买单”。有了纪律，他们会更谨慎的定制计划，这样至少整个项目是在前行的，而不是停滞不前。
然后我会把愿景分成多个层次，每个层次难度不一样，我们一个一个层次的实现。首先我们实现一个拥有基本个人管理的软件，然后扩展成可以整合特定数据类型的，最后可以整合全部的数据类型，最后实现共享功能。这个设计是凭空想出来的，可能或者说一定不是很合理，但是至少我们可以很快的做出狗食版，或者说我们没有停留在原地。
或许他们需要一套很合理的进度管理的方法，但是这和实际相关的，而且需要丰富的经验，我很难想出合适的方法。
------- by Hu Wei November 14 这个Blog真难用半天才弄明白怎么把URL修改的有意义，然后还得去研究怎么添加好友。
更郁闷的是，发表一个日志，点击了一下发表按钮，居然给我发表了两篇相同的日志，难道服务器被驴踢了？？不过服务器觉得这样不够，他还告诉你发表失败，暂时无法使用发表功能，这个服务器真谦虚呀~~~我只好重复点了3次发表按钮，这下好了，我的日志瞬间增长了6篇-_-b
哎，太有爱了~ 《梦断代码》终于看完了《梦段代码》。
其实整本书就是讲图灵机的不可判定性————软件开发过程中，很多过程都不知道什么时候能不能结束，甚至说能不能做出来，这导致整个软件工程不能够停止，这不是暗合了“停机问题”？纯属玩笑，问题并没有这么简单，否则Scott Rosenberg的书也不会这么畅销。
我最感兴趣的是如何能够在10个小时之内读完这本书的英文版，因为我十个小时才刚完成中文版的一半，而且只是大概的了解。不得不说，我不是很习惯作者的写作风格，以记叙文的风格去写说明文，必然会给信息的提取带来很多的不便，说白的就是文章中的“废话”太多，以至于不认真看还真找不到课上讲的东西，比如“Feature Driven”之类。不过话说回来，Scott Rosenberg真乃神人，能够把这么一件很理性的事情以如此幽默的方式表现出来而且不失深厚的文化底蕴，使得全文行云流水，酣畅淋漓的展现自己在项目管理和代码编写方面的才华，获得这么多读者的支持也是有理由的。
《梦断代码》以OSAF开发的名叫Chandler的PIM软件的开发过程为主要的线索，阐述了这个软件的4年来开发过程，这个梦并不是很美好，实际上是痛苦的，软件开发过程中的典型问题在Changler的开发过程中到能找到。不过本书主要还是要说明如何有效的应对由于生产力的发展而导致预期目激增而导致项目目标发生的变更，这样的变更通常是不可预知的，似乎在和你进行一场不公平的游戏，你在明处，他却在暗处————被动的总是你。
1、信仰
如果一个软件项目没有任何追求，那么可以做的很平庸，这样也就很难遇到Chandler开发过程中的种种困难。这不是作者考虑的范围，作者希望一个软件开发出来，必须要有“杀手级”特性，比如文中提到的Lotus 1-2-3，这样便是软件开发中目标变更的源泉。软件必须是有区别其他软件的特性，而不是简单的仿照，我们不希望做出复制品。我觉得Chandler开发过程中的主角卡普尔坚信“Agenda之魂”便是一个似乎不可完成的特性，他希望PIM能够任意的整合个人数据，这个“任意”就让人摸不到边了。不过正是卡普尔坚信这样的信仰，才是他能够在OSAF看着Changler举步维艰的前行了6年（今年初卡普尔貌似从OSAF撤资了，不过Chandler似乎还在继续前行）。
2、一个接一个的问题
很多问题看似简单，实际上却很难解决。比如“代码复用”问题，是重用他人的成果，还是另起炉灶，从头开始，这有点像哈姆雷特的抉择。文中提到了，“代码复用”实际上非常困难，因为没有两片相同的树叶，任何功能都不是完全相同；即使有适用的代码，如何在浩如烟海的代码库中找到也是个问题。实际上“代码复用”和软件的信仰有点相悖，重复他人的成果还是自我创新，不过文中还是给出了答案，“拿来的代码所不能做到的部分，恰是项目与众不同的创新之处”。
软件开发过程中遇到的最多的问题是“项目的进度远远落后于计划”。Chandler计划是3~4个月发布一个版本，但是每个版本都花了6个月以上的时间，这里面有诸多的原因。首先合理的衡量开发进度本身就是一件非常难的事情，也就是说计划本身太苛刻了。即使是检测软件开发的进度也是一件很痛苦的事情，用代码数量或者缺陷减少数目来衡量有过偏颇，文中提到了MBWA的方法，但是这个方法很难得到一个总体的开发进度。其次是软件开发的计划往往超出了能预见的范围，致使软件开发一只停留在设计阶段，引用文中的一句话,“用今天的工具和过程，加上昨天的内存限制，我们真的能做的更好”。另外就是软件的缺陷，Chandler在开发过程似乎中似乎掉进了缺陷的泥潭中，他们花了大量的时间用于修复软件的缺陷，如何减少软件开发过程的缺陷也是个头大的事情。
还有就是开发者的心态也是需要注意的，如果软件长时间停留在设计阶段，没有任何的程序甚至是代码，那么很容易让人悲观，会影响生产力的发展。文中记叙了一件很有趣但是也很无奈的事情，Chandler 0.2发布的时候，发布者在Blog中恳求大家不要下载，甚至不要去宣传，原因是Chandler 0.2是一个几乎不能用的版本。但为什么要发布呢？“如果没有中间版本期限的话，就会导致在充满各种编码可能性的土地上漫无目的地四处游荡”。
3. 我们要迎难而上
当然，作者不是简单罗列Chandler开发中的问题，他还是提出了许多开发过程中的一些方法和注意事项。作者很看重方法的选择，对于不通的情况，应该采用不同的方法，他说“决定采用何种工具和方法有可能成就或毁掉项目”。
首先是如何设计项目的目标。这个和项目的信仰很矛盾，理想是做一个很出色很优秀的软件，但是很多情况下是力不从心的，项目过大很容易埋葬自己。文中有一段很有意思的对话：“你对那些刚开始做大型开源项目的人有何建议？”“别做大项目”。卡普尔在Chandler的设计过程中一直想坚持“Agenda之魂”，现实却一次次的消磨这种想法。后来他只期望做出一个“狗食版”，但是“狗食版”都是一件多么奢侈的愿望。实际上大家都希望看到自己的努力有实质性的成果，做出一个“狗食版”有利于较大目标的实现。“尽快的做出可用的软件”（原文中“狗食版”是指给自己用的版本，来源于一个美国卖狗食公司的广告，该公司的老板用自己生产的狗食喂自己的狗）
其次是进度管理，这在软件工程中是不可预知的。首先是进度的衡量难，不能单一的用代码数量和缺陷减少数量。在软件过程中有很多很顽固的缺陷，在当前很难快速的解决。还有就是人与人之间是很难协调的，比如新加了个成员，需要新成员培训；比如更换了项目经理等等。文中提到“特性驱动”“进度驱动”等，在实际的管理过程中两者兼有，只是侧重点不通罢了。对于是否需要用强制进度纪律来管理，作者谨慎的给出了说明：这要看情况来定。有些程序员不喜欢被强制管理，那么强制纪律最好不要用。如果进行强制进度管理，那么在评估进度的时候要符合现实，采用“自底向上”的方法评估。比如文中的CMM管理。
还有缺陷管理。现在的编程模式基本上都是先编些代码，然后修正缺陷，实际上很难写出没有缺陷的代码来。直觉上，文中也是这么说的，在开发过程中越晚修正缺陷，代价就会越高。所以要尽早的发现缺陷。如何减少缺陷，文中给出了一些方法，比如“螺旋模型”、“极限编程”、“祖尔测试”等等。作者还提到了OOD的思想，要合理的抽象和模块化，同时鼓励使用代码注释。（实际上代码注释可以很好的发泄自己的情绪~~）
当然，一个项目的成员自然需要交流，交流的方法有很多，可以用Blog、wiki等等，但是不要忘了一些非正式的交流方法，比如在“冷水机”旁边交流。
-------by Hu Wei
November 05 Mission1. Design a good database to handle all the issues
1.1 Arrange all the things used in the troupe, like props, books and so on.
1.2 Arrange all the documents of the troupe, like diaries, notes, pictures, vedios and so on
1.3 Sort all the documents according some properties
1.4 Search some item in no time and without fault
1.5 Add a new kind of item easily
1.6 Won't crash after a long run(long = years)
2. Design a convinient UI
2.1 The UI must be idiot-proof such that you can use it with little compute knowledge
2.2 Beautiful
2.3 Easy to add more functions
3. (Opt)The function of the software can be changed to suit different situations |
|
|
