作为Individual project的一部分，每位选修高级软件工程的同学都要选择一本与软件工程多少有点儿关系的书来读。记得当时接到邮件之后，大家从四面八方涌向课代表的座位，想挑一本适合自己的“教材”。等我匆匆赶来的时候，课代表的桌上早已一片狼藉，我隔着千山万水，随便抽了一本《走出软件作坊》，心里想着“作坊”，这书名字有意思！对于编程，咱本身就是野班子出来的，路子从来不正，除了知道点儿什么“冒泡”算法，其他专有名词基本不懂，为了早日走出民间作坊，实现从野路子到正规军进发的梦想，我毫不犹豫选择了这本书。
书的序言中提到“三五个人，十来条枪，如何走出软件作坊”，可见其团队的规模和我们team project的情况很相似。结合在软件工程小组中的一些实例，我谈谈自己的感想。
1.项目经理（PM）
文中提到，提拔项目经理，要看全面素质！其实对项目经理最早的认识是，此人不用写代码，但是在rosting小组，由于人手有限，PM还是承担了很重的编程任务的。书中提到了一名新项目经理在“新官上任”时遇到的各种问题，小到每日报告字体的大小和穿衣习惯，大到和客户交流和项目运营的方式，再到如何调节团队的气氛，都是对一名PM的重大考验。一名优秀的PM要做到眼光敏锐，思路清晰，目标明确。除此之外，普通程序员不能当项目经理，因为程序员的世界中没有模棱两可，没有区分不清的界限，只有分明的0与1，这不符合作为一名PM要遵循的“有原则性的灵活”这一准则。我以为所谓“有原则性的灵活”，就是有张有弛，松紧得当，这也是一名优秀的PM所需具备的最重要的素质。在涉及目标和方向的时候，PM要有能力驾驭和把控全局，同时要坚定立场，但在涉及具体执行方案的时候，要在把握大局的前提下，有放缩的空间。文中提到的“手里有5个球，你要玩好，不能掉下来，让别人看着还姿势漂亮，这才叫调度的好”让人印象深刻。
2.老系统维护
其实在本次的team project中不太涉及什么系统维护的问题，但由于是在IEG组原有架构的基础上，增强功能，所以同样涉及使用和修改大量原始代码的问题。文中提到：其实很多时候，觉得原有程序很烂，是由于与以前程序员排版不一致。其实在于读代码的过程中，有些变量命名方面的区别，并不影响理解代码，也不会造成理解歧义，只不过感觉“不爽”而已。读了这段文字，我果然像作者预测的那样——会心一笑，“不爽”这个词儿用得，简直说到心坎儿里面去了！每个人编程习惯不一致，所以在读别人代码的时候，即使是再简洁高效的代码，读起来也不会像自己写的读来那么流畅，总是感觉磕磕绊绊的，要是赶上没有注释，就更痛苦了。但是换到自己写代码的时候，总觉得每条代码都写的合情合理，再自然不过了，根本没有必要做多余的注释。由此，程序员小分队总在痛苦的“读代码”中开始，在草草的“写代码”收尾中结束。程序员的小心思被作者剖析的非常一针见血！
3.自我时间管理
这是一个老生常谈的问题，我自己在给mentor的weekly reports中经常不自觉地流露出time conflicts之类的话题。在本书中，作者提到了四象限法，即把需要处理的事情分为四类：重要且紧急，重要不紧急，紧急不重要，不紧急不重要。作者作为一名CTO，用目标和赚钱来作为导向对需要处理的事物进行分类。这与第一次Advanced Lecture中张磊研究员为我们介绍的时间规划方式不谋而合。在我看来，无论有没有计划，我们都知道自己要首先完成重要且紧急的事物，然后着手紧急不重要的事物，既然紧急，就总会有某些必须迅速达到的目标。然而，如果没有良好的规划，我们很容易忽略那些重要不紧急的事物！比如说在平时注意提高自己的软技能，可谓无比重要，但是这些只会潜移默化的影响着我们，因此往往不容易被重视。
4.未来软件开发模式
书中在讲到相关章节的时候引用了李维先生在《Borland传奇》中的一段文字：所有的读者都可以感觉到，现在系统开发的时程要求的越来越快。信息机构的调查显示，系统和项目的开发时程将持续地缩短，到了2012年居然只有一天的时辰。在这段文字右侧的空白处，本书的上一位借阅者加上了如下的批注：“不靠谱，我等着那一天。”这引发了我的兴趣。文中提到，在互联网时代，网上可以找到合作伙伴，可以找开源学习资源，可以找公共code库，也可以发贴子，搜blog，其实这些办法我自己都亲身体会过，现代的网络的确为我们提供了很多便利。如文中所说，各种强大的管理工具也大大提高了工作效率。我虽然体会到了这些优越性，但同上一位借阅此书的师兄或是师姐一样，我认为一天的时间开发项目有点儿夸张！像我们在开发中使用的Team Foundation Server，个人认为存在着很多冗余的部分，有些过细的条目其实反过来降低了效率。至于未来的开发能否在真的一天内完成，让我们拭目以待吧！
by Minghui Tan
281
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
