写好软件不容易——读SouthSeven队软件工程博客有感

作为ASE的第一次作业，我选择了看以前学长的博客。记得招生宣传的时候，SouthSeven队的Kongfu Stonie给了我很深的印象。于是我用半天的时间看过了去年SouthSeven队的工程博客，从中体会最深就是：写出一个高质量的软件真的很不容易。

• 做一个实际的project设想

SouthSeven队成功的因素之一，在于最开始的设想新颖（声控+音乐游戏），而又没有太高的知识要求。回想我做过的机器人，10届师兄的真人拳皇都没有做成或没有完全达到预想，原因就是最初提出了太高的预期而中间又碰到了知识和能力准备不足的问题。所以这次要摒弃那种空想式的设想，拿出一个靠谱的project。

• 做一个好的计划

SouthSeven队的PM说：“看来一个总的纲领(User story)是支持开发的核心动力”。我非常同意。作为一个工程，像“游戏画面更生动，具有了扩展性能，界面更友好”这种大方向要在最开始就确定下来并一直坚持住，而具体的实现则可以遵循trail-and-error的模式，不必被最初的计划束缚住。而且软件是给用户用的，所以开发人员一定要知道用户想要什么，而不是遵循一个个与用户不相关的的工程要求。 虽然没有看到完整的计划书，但是从两次迭代的总结上来看，SouthSeven队做了一个完整的计划，Daily Scrum中每天每人都有各种具体的任务，有的甚至精确到小时完成，这个值得学习。

• 计划要考虑到意外的情况

软件工程是一个长期的工作，在这段时间里总会有人因为各种原因而缺席。PM去当自由人是一个解决办法，但是我觉得在分配任务时候也可以根据具体情况安排某个人的工作量和工作时间。此外，对于“修改别人的代码导致产生双方都无法维护的代码”这种事情一定要避免。

• 队员之间要相互沟通

在SouthSeven队PM的总结中，提到最多的问题就是几个模块间缺乏沟通导致互相等待，然后拖慢了整体的进展。我觉得，在紧张的Daily Scrum中，全组人可能需要一个类似于白板的在线交流工具，如果需要其他模块的人做的事情可以贴到白板上，及时被对方发现。这样也可以避免像“一方认为没有任务做，另一方认为需要等待其他人的工作”这样的误会。

• 关于文档

据SouthSeven队的经验，在这种小工程中，诸如Example.cs之类的示例很有用，而不会有多少人去认真阅读文档。从我个人的经验来看，某个接口的使用并不是看看函数头就能掌握的，像示例这种带有场景的代码能更快的帮新上手的人掌握这个模块。

最后引用胡越同学的一句话以自勉：idea不值钱，值钱的是踏踏实实把事干出来！

 

姚宏毅