| SG's profileGreen的共享空间BlogListsNetwork |  Tools  Help |
|
|
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 |
|
|
