| 项目 | 内容 |
|---|---|
| 这个作业属于那个课程 | 软件工程 |
| 这个作业的要求在哪里 | 第一次个人作业 |
| 我在这个课程的目标是 | 和志同道合的小伙伴一起开发出一款令自己满意也令市场满意，课程结束后还能维护下去的软件 |
| 这个作业在哪个具体方面帮助我实现目标 | 快速阅读《构建之法：现代软件工程》，了解软工理论知识 |
Q1：关于『软件工程师的职业发展』
- 原书第三章第三节描述对职业的态度有5种分类：临时工作（work），工作（job），职业（profession），事业（commitment），理想（calling）。
- 我希望日后我能以软件工程师为职业甚至是事业甚至是一种追求。这导致了我在很多软件开发中过于追求一些较为极致的东西（譬如更高的性能，或者更高的代码复用性，或者更通用的代码），但是过于追求极致会导致开发时间与精力消耗巨大，难以负担。
- 有时就和书中的Emanuel Derman一样，对其他东西有明显的排斥感（譬如看不起低效的代码和冗长的代码）。E.D.在35岁时有了改变，但是他说的那句话对我而言实在有些难以理解。
回首当年，我（的态度）的确是错了。任何事情，当你仔细探究，你就会理解它的量和质；当你对一个领域的神韵足够了解，并开始连接这个领域的表现形式和实现细节的时候，任何一个领域都是会变得引人入胜的。
Q2：关于MSF中的充分授权和信任
- 书中第七章联系与讨论中提到，如果团队给予个人过于充分的授权和信任，会导致某些人不自觉，敷衍了事（尤其是大学里面的团队）。
- 周围很多同学也提到：不怕团队里有人摆烂啥也不做，就怕有人把工作接下了却敷衍和拖欠。
- 恨不得团队中的所有人都是我自己，这样就不会有矛盾和冲突了。
- 我认为团队肯定是需要激励机制的，企业可以有绩效奖&末位淘汰，但是大学团队恐怕做不到这一点，我们到底应该如何处理那些不自觉的队友呢？
Q3：关于A/B测试
- 书中第八章有讲述A/B测试的具体含义：将用户划分为两类，分别提供不同的功能，观察哪一部分用户更喜欢对应的功能。
- 微信也经常做A/B测试：当微信希望提供某种新功能的时候，会将该功能随机下放给少量用户，如果他们使用这些功能的频率提升了，说明该功能更好。
- 但是我对此有很大的疑问，微信的测试时间实在是太长了，很多功能始终停留在测试阶段，有的用户明明很想要该功能却迟迟无法使用到。既然可以做A/B测试，为什么不设置一种可选功能呢，让有需要的用户自己diy自己想要的功能（就像买电脑一样，有的用户买整机，但是也有用户自己选择和购买各个零部件然后组装）。
Q4：关于PM的选择
- 书中第九章介绍了PM的来历和PM的职责。
- 书中认为PM更重要的是协调和沟通，但这对一些强势的技术极客来说是不太能接受的。对于一个大学生团队来说，通常需要选择一个有较好编程能力的人作为项目PM才能让人信服。
- 我身边既有不善于编程的PM，也有善于编程的PM，他们都难以完全让人信服，这该如何解决呢？
Q5：关于测试
- 书中第十三章介绍了各种测试的方法。然而大学生团队鲜有重视测试的。甚至有的项目已经进入长期维护阶段，维护人员也换了一代又一代，并且实实在在有很多用户了，也没有一个像样的测试。添加新功能难免会对原有功能进行改动，但也只有当一个功能崩溃后用户反馈后，才能开始修复。
- 测试真的非常重要，尤其需要从一开始就有一个完整的测试规范，否则很难在后期改进。
- 但是大学生团队很多人认为自己开发的软件也就是一个原型，课程结束就丢掉了，如何说服大家多写测试呢？
–7bdecb6d239e349489702b82f14f251c–
