现代软件工程系列 学生的精彩文章 (6) 项目总结
学做一个PM By Cheng Lu
对于我们的SmartMe，我是真正倾注了感情的。看到今天SmartMe走出了坚实的第一步，心中首先是感谢，感谢LunaR团队四个好兄弟为咱们的软件付出的心血；然后是欣慰，我们几个月5个人的共同奋斗没有白费；最后更是展望，我们希望我们的SmartMe不因课程结束而销声匿迹，我们希望我们的SmartMe能真正成为一个成熟的软件产品。
在SmartMe中，我专注的只有一件事情：学做一个PM。
我是在软工课上第一次接触PM这一概念的。虽然一开始被指派有些鬼使神差，但是现在自己还是感觉很庆幸能得到这方面的锻炼。程序能力的提高固然是软件工程课程必不可少的要素之一，但是在工程的整个运行和管理方面能力的提高，以及一个商业视角的培养，我想才是软件工程这门课区别于其他程序设计课程最显著的地方。
虽然以前在别的组织中做过一些项目的负责人，在一个技术团队中做管理者自己还是头一回。开始我并不知道该怎么做。自己一直坚信代码是一个软件的灵魂，而PM是要负责除代码以外的任何事情，这让我更加迷茫，不知所措。好在我有4个最靠得住的兄弟和我并肩作战，他们对我犯的错误的容忍和他们的帮助，让我慢慢上路，谢谢你们。
我觉得PM最重要的事情是要团结整个团队，让每一个成员有一种归属感，他们能够在团队奋斗中感受到快乐。我努力让每一个人做的事情对于整个项目来说都是实实在在的贡献，并且尽量保证合理的分工，让每个人的工作量相差不多。一方面实实在在的贡献会产生成就感，这是快乐的重要源泉，另一方面平均的工作量又不会使任务重压力大的组员心生怨怒。福利政策自不可少，我们每周在翅香园或考研院开组会，作为PM，多花点钱也是义不容辞的。
PM另外一个重要的责任就是要保证项目能够按照计划前进。这个我走了一些弯路。一开始我尝试完全脱离我们的代码来进行项目管理，但是很快我便发现在技术项目中这么做是举步维艰的。因为如果不了解每个人实实在在的工作，那么我很难判断他们是否完成了这一阶段的任务，并且和他们一同讨论下一步的方向。感谢吴昊和蒋叶，让我迅速了解了咱们整个程序的具体框架，之后项目的统筹规划自己才感觉更游刃有余。这是一个很有意思的事情，我需要了解具体的程序以制定项目的前进方向和我们要实现的功能，但是我又没有必要精通每一个细节，因为那样我就越权了。如何保持这么一个平衡是对技术类PM的一个挑战。：）
在项目的关键时候，在团队中出现争论的时候，仲裁和做出最后的决策是我的责任。这方面我有功有过。在Alpha版出来前，决定我们完善UI而暂时放弃历史记录的设计，我觉得是我做得好的。在历史记录基本完成后，看到林添UI部分的压力太大，进度跟不上时，决定之后的工作重点在于推进UI，放弃设计更多Feature，并且在最后关头组织大家一起突击攻关，我觉得是SmartMe得以最后发布最关键的几个时间点。但是这些决策我做得还是不够及时和果断。如果我们能够更早地意识到UI的巨大工作量并且平摊，如果我们能够更早地在一起协同攻关，那么我们的SmarMe肯定会更早地发布。
我必须要对SmartMe用心，团队中的其他人才会对SmartMe用心。我向整个团队道歉，在项目的前期，因为自己的事情，拖累了团队和项目的进度。之后的日子，我一直在努力用行动弥补我的过失，维护好咱们的Blog，做好项目进度管理，了解每个人的工作量， 督促大家同步前进，最后一起突击攻关。这些其实还不够，Beta之后的日子我还会尽好我的职责，因为这样我觉得才对得起大家共同的努力。
我是幸运的，能和4位如此踏实靠谱的兄弟一同工作。谢谢林添，你的投入让我牢牢记着自己身上的责任，鞭策我用心努力工作。你对整个软件理念、对软件框架和UI设计的贡献不可磨灭。谢谢吴昊和蒋叶，你们脚踏实地的工作是我们最后能够成功发布的根本保障。谢谢马成龙，你最后阶段的付出让SmartMe锦上添花。
我的软工总结 By Chenglong Ma
写代码使我很喜欢做的一件事 上了3年的大学 学了不少代码的知识 但真正做出来的产品大多是面向老师的产品 能够面向用户的却很少 这不能不说是一个遗憾 软件工程这门课就实现了我的梦想 让我真正体验了做用户喜欢的软件的感觉
由于种种原因 软工的理论课我上的比较少 但是上过的课我都会认真的去听去想去躬行 在做Individual Project的时候那个题目让我百思不得其解 后来得到了一篇论文 根据文中的算法我才顺利的解决那个题目 这启示了我一定要把学习和研究的重心放到算法的设计上算法是代码的灵魂 在做第一个Pair Project时 我和朱晨光同学合作了一个web平台3D中国象棋的项目我学习了这个项目所涉及的一些新知识 并将其运用到项目中 这个项目做得还算成功 算是我参与制作的第一个比较像样的游戏了同时我也第一次了解了合作开发的理念 第二个Pair Project我没有参与开发 确实很对不起谭宸浩同学
真正让我体会到作为工程的软件开发是Team Project 在Team Project中 我参与了前期的策划设计 中期少量的coding 和末期的rush test debug的工作 虽然时间不长 但我很积极很拼命 临近发布的时候工作到早上四五点钟 虽然我没用过C# WPF这些新生事物 但我也尽量去了解她们最终我们的项目 SmartMe取得了前所未有的成功 这让我们很欣慰 多月来的工作终于有了结果 而这一切都归功于大家的合作其中包括吕诚PM的调度指挥 林添 吴昊 蒋叶的拼命coding 以及我对这个团队默默的支持 由于邹欣老师传授给我们软件工程中先进的理念和方法也由于我们将所学到的知识在项目中认真的贯彻执行 我们的开发得以有条不紊的进行 基本按期实现了每一个环节 也赶在课程结束前发布了我们的软件经过这次合作开发 我深刻的意识到扎实的业务基础 积极的态度 高效的沟通是一个团队成功的三要素
感谢邹老师的辛勤付出 贝助教的认真负责 同学们的团结合作 让这门软件工程不仅仅是一门课 也是我们挥洒青春的舞台 更是我们IT生涯新的起跑点
软件工程感想 By Tian Lin
软工感想收获 By Ye Jiang
PProject II，只是简单的用了贪心，没想到效果还不错。另外多亏老朱的最后的测试数据比较温和，不然我的程序的bug就会被发现了。另外杨松写的描述太赞了！
TProject，SmartMe最初的定位并不太明确，中间在理念上和技术上也经过了一些转变。不过幸好我做的最主要部分——从网络抓取结果——基本没有怎么变化。比较遗憾的就是，没有从一开始就用后来林添提出的基于javascript的方法，而是用了一个类似SAX那样的解析器，导致后来吃了不少苦头，而且功能上不够灵活，扩展性不足。而词典部分选用了 Dictcn这个网站也不太靠谱，在我们快发布时居然大改版，而且还挂掉了一段时间，访问速度也不快。当初选择它主要是觉得它页面结构最为合理，处理起来也最方便，现在看来似乎有点得不偿失了。后来做了一点点的UI，感觉做UI还是挺麻烦的，林添真是辛苦啦。另外就是，每次开会的时候林添，吴昊和马成龙总会争论，然后吕诚就会仲裁，从中我也学到了不少social skills。
软件的艺术
软件工程课明天就要完结了，尽管我们还计划了后续的工作，但是对于此课程应该没有什么影响了。对于这门本科阶段最“工程”的一门课程，我总觉得还是应该留下点什么的。也许将来我不会以做软件谋生，但是对这门课程，乃至整个软件工程的体会予以总结，也许在若干年后回来看的时候，会有什么深刻的感想也说不定。为了给将来留念，特此写下此文。闲话休提，言归正传，就以软件工程课最后的团队项目——SmartMe的感想来收束我的软件工程课吧。
最新的技术不一定是最好的，因为用户很可能有一台不能使用这种技术的计算机。尽管.NET确实是非常好的技术，而且我们5组当中有4组使用了此技术，但是我们的目标用户群当中，有不少使用的是Windows XP的机器，并且没有装.NET Framework，这使得一些人未能选择试用我们的软件。但我觉得此牺牲是必要的，因为对于我们来说，三要素（时间、资源、质量）中其实最缺乏的是时间——质量好固然好，资源也可以想办法获得，但是时间是定死的——无论如何一定要在1月4日交付，而且越早交付越好，获得的好处甚至可能超过质量。因此，为了节省Dev的编程时间和测试及调试的时间（如果用C++&MFC实现，肯定将要多花很多时间，这是看iHunter的Blog总结出来的），做这一点牺牲应该是必要的。
模块化编程，但是尽早综合到一起。我们从一开始就把所有代码综合在一个Solution当中，尽管不同的Dev编写不同的模块，但是模块之间从一开始就是能放在一起工作的，避免了某些小组出现的一开始各写各的模块，最后发现无法综合到一起的问题。不过这种方法也有缺点，就是大家发现不能运行的时候，有可能会选择改动别人写的代码的Bug，而不是交由编写该模块的人去Debug。事实上最后我基本上所有文件都修改过，其他Dev也差不多。
尽早开始测试工作。我们启动测试有点晚了，结果1月4日才能将所有问题Fix，比预定晚了1天发布。关于测试还有一个问题，就是是不是即便有已知Bug的软件也要发布？邹欣老师虽然举了一个例子（Excel的纪年，将1900年记做闰年），但这是一种特殊的情况。我最初一直觉得最好不要发布，但在1月4日之后我发现这是不对的，因为我在书上看到这样的话（忘记那本书谁说的了），“推迟半个月发布或许是个好主意，但是只有在竞争对手不会在这半个月发布的时候”。有的时候，发布早也是优势，甚至是一个很大的优势。即使早一小时发布，也是能有很大很大的收益的。
要使用管理工具，比如Google Code。如果不使用的话，我难以想象那些Bug是怎么Fix的，不同人写的代码是怎么同步的，怎样避免冲突代码带来的问题。Google Code确实是很好用的平台。它最大的好处是，所有源代码、剩余bug/issue，软件文档等等，都记录了下来，而且只要Google Code本身不出问题，这些东西都能轻易转移到以后想接续开发的人手里！使用TFS管理或许方便很多，但是如果那台服务器Down掉的话，数据可能就丢失了。而且将来的接续开发者很可能不能再访问这台服务器，这样他们获得源代码和文档等就比较麻烦了。
一定要进行代码复查。事实证明，出错的代码基本上都是没有被复查过的，被复查过的代码错误只占很小的比例。而且，代码复查的最好时机，就是代码刚写出来的时候。因为首先，代码刚写出来的时候，写代码的程序员对这段代码最清楚。然后，代码刚写出来的时候，其他程序员对它的关注也是最高的，这是由于人们对新鲜事物总是比较关注的，也比较能认真审核它们。如果等待一段时间之后，在管理机制不完善的情况下，可能就忘记代码复查了；即便仍然记得或者通过管理工具提醒，由于其关注度没有之前高，也就没有之前那么用心的检查了。
要写单元测试。这个对复查代码是必要的，而且也能检验局部代码（例如，一个类）是否正确，避免到综合起来之后才发现问题。而且，当代码修改或者重构之后，通过这些单元测试，可以验证修改后的代码没有破坏原有的逻辑，方便了测试工作；而且在写代码出错的时候可以用来快速区分是破坏原有代码还是新出现的问题，这也方便调试。
最后，这些方法，不是做好软件的全部，甚至不是最重要的部分。我看了《走出软件作坊》这本书，这本书的主要宗旨是如何做好一家小型的软件公司，也许跟我们的项目关系不大。但是，这本书讲述了一些很基本的道理，这些不仅仅是在软件工程上，而是在其他工业活动当中也是有借鉴意义的。例如，做一款软件，或者说，做一个项目或产品，真正的目的是什么？对于一个小公司的老板来说，目的可能是为了赚钱；对于一个开源项目的管理者来说，目的可能是为了扩大自己的影响等。而对于我们来说，目的究竟是什么？我曾经认为我们的目的很清楚，是要做一款足够优秀的软件。但是，在读过《梦断代码》之后，我发现这一目的，正是Chandler项目走向困境的主要原因，因为事实上这根本不能称为是目的。或许我们的目的是“无论如何，一定要在1月3日或之前发布我们的软件，并且以任意方法宣传以尽量增加我们软件的下载量”？这似乎是说，我们写软件的目的就是为了分数（但说不定这才是我们写此软件的真正目的吧）。跟这种迷惘相比，用不用什么管理工具，方法好不好之类的问题都是小Case了。我们究竟如何处理做软件和课程管理之间的矛盾？这也许才是做SmartMe过程中最大的问题吧。
谨以此文，献给陪伴一个学期的软件工程课，邹欣老师，贝小辉助教，LunaR全体成员(吕诚同学，林添同学，蒋叶同学，马成龙同学)，尹杰同学，印奇同学，以及一起参加软件工程课的其他同学们！