构建之法五项问题回顾

1.我认为重复的工作会磨灭创新性，不停做同一件事，往往会忽视而难以发现新的东西。那么作为一个软件工程师，如何在团队工作中保留自己的创新能力呢？

答：重复的工作的确很无趣，不过也许一个合格的工程师可以编写一个脚本，让这样的工作由程序自己去运行，而这也不失为一种创新。

 

2.在团队中有可能会有这样的情况：“为什么他的任务比我的少？”，“为什么他工资比我高？”。那么团队中这样的分配是否要找到一个平衡点？还是说告诉他“绝对公平本来就不存在”？

答：在我们4-5人的小团队中，任务量分配以及分数分配往往达到大家都认同的状态即可，也许这也适用于其他的小团队中；至于大公司，他们应该有更加完备的体系，是大家足矣认同分配模式。

 

3.当发现之前设计会影响后面集成工作的进度，但是如果改弦更张会延误工期时要如何抉择？（进退两难，不知该怎样才好，因此在这里作为问题提出）

答：我们现在就遇到了这个问题，我们选择了“改弦更张”，通过加班加点来弥补之前的过错。

 

4.前面的阐述感觉更侧重于强调需求分析和设计的重要性，而敏捷强调“速成”，似乎与软件工程有所冲突？

答：敏捷并非是“速成”，或者说不仅仅是。敏捷开发侧重于可根据用户需求的变更即时的做出更改，并没有说需求分析和设计就不重要了；而且最初的认知中，认为需求分析和设计就是“浪费时间”，觉得“上手如有神”才是敏捷，这也是认知上的错误。

 

5.对于用户来说，一个软件不光要实用，还要界面美观：现在有这样一个问题，客户给的资金、时间都有限，我们只能保证功能完备和界面美观二选其一，这样应该如何抉择呢？

答：这样的限制在我们的开发过程中经常存在，或者说存在类似情况。之前我还说过“宁缺毋滥”（一项必须要有功能因为不够美观而被舍弃了），现在觉得有总比没有好，这就好比“0”和“1”的区别。所以，绝对完美是不可能的，有舍才有得；而如果两个都舍不下的时候，有可能什么也得不到。

 

总结：这一段时间的学习的确成长了不少，最初我说希望自己能成为一个成熟的软件工程师，虽然现在还差很多，但至少正在向目标靠近，这就足够了。