提问回顾与个人总结

提问回顾与个人总结

项目	内容
北航2020软工	班级博客
作业要求	提问回顾与个人总结
我的课程目标	学习软件工程，掌握团队合作，锻炼自我
个人博客	提问博客链接

问题解答与分析

问题1 过早优化。我们如何来鉴定某个优化是否是过早优化，还是压根就先不考虑优化，最后进行量化后再优化，这样不是又会导致重构等一系列问题？

这一问题也得到了轮子哥的回答：

“一般来说，优化要满足两个条件。第一个条件，就是你知道这个需求很可能再也不会改了。这个时候你可以尽情地把代码写得又复杂又高效，不会对maintainability带来太多影响。但是问题在于你如何知道这个需求可能不会改？这需要你有丰富的领域知识。如果你的领域知识越丰富，对甲方了解的越深刻，你的猜测就有可能越准。第二个条件，就是你的优化要足够地local。我们学习设计模式，就是要懂得封装和隔离。封装的意思，就是把会变化的地方封装掉，以后需求发生变更，就只是局部变更。当然这也会有第一个条件说到的问题，你怎么很好的预测什么地方会变化？你需要丰富的领域知识和对甲方深刻的了解。隔离的意思，就是把你的代码用架构组织起来之后，组件之间的依赖关系要足够清晰，并且尽可能少（这也是要取得一个平衡）。只要组件每次变化，都不会动接口（这里不仅仅是代码里面的interface，还有设计这些interface的时候采取的假设，很多人很容易忽略假设，这是不对的），那不管你的代码改得多烂，烂到最后受不了需求已变更只能重写，那也只是这个组件的问题，不会导致整个项目失败。”

笔者在写代码的时候经常会考虑这样做会不会快一点，性能会不会更好一点？于是翻来覆去的修改，而最终的效果也没有想象的那么好。经过这几周的开发，笔者认为自己并不具备轮子哥所说的“丰富的领域知识”，所以提前的优化对于笔者来说是副作用，只会带来思维负担，影响开发进度。

而且有一说一，有时候很多的优化，编译器可能完全能够代替我们完成，自己去做着实有点不理智，变相造轮子。

所以笔者现在的开发思路就是先使用简单的方法实现，在最后进行性能优化的考虑（即使需要重构）。

因此，笔者目前不会进行任何的早期优化。

问题2 代码设计规范

4.3.1 函数：只做一件事，并且要做好

4.3.2 goto：只要有助于程序逻辑的清晰体现，什么方法都可以用，包括goto

这里笔者之前困惑的是一件事的定义如何界定，以及这样多层的封装不会很繁琐吗？

现在笔者的看法是：首先多层的封装只要符合结构，就不应该认为其繁琐，而且多层封装带来的性能影响也可以忽略不计。

其次，一件事的界定，还是要根据项目来说，我们开发的软件可扩展性可能没有那么大，开发初期笔者是没有考虑封装函数的。但是在开发过程中遇到了访问数据库的操作，笔者就发现如果不对这一点进行封装，会导致之后的修改极为繁琐且容易出错，所以花费了一定的时间进行了访问的封装。

所以笔者认为只要两个函数有共同部分，那么就可能会有第三个函数使用这个共同部分，不妨将其封装为一个函数。

至于Goto的使用，这一点笔者目前持保守看法，选择不使用。

这一点笔者在思考，高级语言一般以实现逻辑为主，往往不涉及到底层的操作，如果可以用其他的语法实现同样的效果，goto这样的原语现在是否还有存在的必要呢？

问题3 关于敏捷开发

这一点笔者目前还是比较困惑。

我们的团队项目因为典型用户不是学生，导致反馈较少，因此并没有机会进行这种频繁的迭代，主要是不断地完善。因此，笔者还是有些疑惑软工这门课程真的适合敏捷开发吗？一方面我们有其他的课程压力，不一定能够把所有的精力都投入进来；另一方面不是所有的项目都适合迭代开发，因为用户群体本身就不好找，有的项目很难推广。

因此笔者对于本课程是否适合敏捷开发持怀疑态度。

问题4 创新对于专业度的需求真的不高吗?

这一问题，笔者还是保持之前的观点，创新是基于一定的专业的，需要一定的积累。我们不能用个例来解释这一问题，大多数的创新绝不是起于平地的。

问题5 软件不遵守原则

p412 17.8软件工程师的职业道德

原则2 客户与雇主

软件工程师应以其客户和雇主的利益最大化的方式做事，与公众利益保持一致

这一问题，笔者暂时无法给出回答。是要面包还是理想，是一个个人的选择，没有绝对的答案。

新问题

• 团队开发模式中如何找到一个成员的定位呢？我们实际的开发过程，其实是投票以及自主选择，并没有时间或者说方法来进行试错，而且很多团队一开始是不具备技术基础的，这种情况下，如何做到尽量避免成员与工作不适配造成的问题呢？

• 作为PM，在团队中是否一定要承担开发任务呢？还是只需要进行团队管理等工作，这样的话贡献分如何有效的衡量这种工作？

学到了什么

需求

这一个阶段是分析项目的NABCD，主要是学习了如何具体分析需求、做法、好处、竞争、推广。其中我认为推广是最不可忽视的一个点，我们一开始并没有很好的考虑这一问题，导致用户数较少，而软件一定是有用户的基数才有发展的可能性（根据用户反馈来进行修正等）。需求也是很重要的一个点，有必要尽量准确的描述需求，确定软件的主体功能，这样后续需要修改也不会伤筋动骨。

设计

设计阶段主要是学习了如何进行任务的拆解、设计技术规格说明书和功能规格说明书。

• 任务拆解：在Alpha阶段这一点做的就不是很好，较为笼统，导致在开发时有些摸不着头脑，Beta阶段就进一步细化，尽量把任务拆解为最小的模块。
• 技术规格说明书：使用的技术是一个值得认真考虑的事情，有一些问题可能在设计阶段没有考虑到，导致后续没有技术能力实现。
• 功能规格说明书：设计要实现什么功能，体会就是设计阶段的一些功能可能在开发阶段是不必要的，但是设计阶段还是应该尽量全面，后续可以有选择实现。

实现

这一阶段，笔者认为文档和注释是一个很重要的部分，尽管写起来有时候比代码都费劲。

工程量变大的时候注释不仅仅对开发者有很重要的提醒，对于后续的开发者也是一个了解项目的重要工具。

文档则是从另外一个角度介绍项目，对于用户和开发者都有重要的意义。规范的技术文档可以让开发者更快的了解函数的使用而不必深究内容，也减轻了开发者之间的对接工作。使用文档方便用户了解软件的使用方式，而且最好是在开发阶段就维护更新，而不是到了发布阶段再去写使用文档。

测试

这一个阶段是如何进行单元测试和自动化测试。

• 单元测试没有必要完全覆盖，主要测试核心函数的功能和非核心函数的分支覆盖。
• 自动化测试一方面可以简单高效的进行功能验证，在之后的回归测试也可以起到很大的作用。

发布

发布阶段学到了推广的重要性，推广不到位，潜在用户就得不到挖掘，软件就无法根据用户的反馈来进行更新。

维护

一方面，需要根据用户的反馈及时修复BUG，另一方面需要每天检查软件的运行情况，以及如何根据后台的日志查看软件的运行情况，错误原因等。

理解与心得

个人项目

作业的基础题目难度绝不算大，但是如何行之有效的优化加速，确实是难倒了笔者。

这个作业更多的感受是关于测试和调研，首先得承认，笔者面对这一作业，前期准备是略有不足的，属于边走边看的类型。这样导致期间有过多次修改，之后反思，这种做法面对较大一点的项目绝对是事倍功半，所以在之后的结对项目和团队项目中都尽力避免这样的事情。

测试的话，笔者的教训是，在设计初期就把测试的方面设计好，这样之后按照章程来，就行云流水。如果凭借一腔热血来冲冲冲的话，测试会很令人头疼。

突然想起，会不会有人和我一样不知道VS的debug和release模式的区别呢，尤其是在性能方面！

结对项目

笔者是首次接触结对项目，之前也是没有想到结对编程如此强大，两个人的合作甚至可以超过两个人的能力，实现1+1>2的效果。

和结对队友之前是同学，相互之间比较熟悉，所以交流起来也比较方便，工作开展的也很顺利。

整个过程中，我学会了如何有效的和队友沟通。以及如何进行有效的测试，这个作业主要是进行单元测试，以及随机测试，通过和其他团队的合作，进行了对比测试。

在结对编程的学习过程中，我也进一步学习了GitHub如何管理项目，为团队项目做好了一定的准备。

团队项目

• 作为开发人员：

在Alpha阶段是作为团队的开发成员，负责后端服务器的开发，在这一过程学习了无状态服务器、python语言Http服务器开发以及一些REST ful的相关知识，还有就是如何利用测试工具进行TDD软件开发，这些都是个人新的体验，收获了很多新的知识。

这一阶段的心得就是“learn by doing”，因为上面的知识都是新鲜的，需要先进行知识学习才可以胜任工作，而在开发的过程也会遇到无法解决的问题，需要进一步的学习，这样不断的推进，最终掌握了相关的技术，也完成了开发。这样的过程反馈和学习同步，是最有效的！

• 作为PM：

在Beta阶段，笔者是担任了团队的PM，负责管理团队，推进工作进度，同时也负责后端服务器的开发和维护。这一阶段是比较辛苦，作为PM要整理文档，记录每日例会，提醒组员，协调沟通，也需要承担好开发任务，最重要的是要对项目整体有一个宏观的控制，根据情况及时调整项目的方向和功能。总之，虽然辛苦，但是最终做出来一个可以使用的软件还是很欣慰的！

最后，再次感谢组员们的辛苦付出！👍

最后：

给出一点小建议，关于平行项目的可能性。不太了解为什么老师不允许这样做，是不是从评价的角度考虑的这一问题。

笔者个人的理解是平行项目是可以做的。确实不同的团队能力不同，实现的最终版本不同，但是可以从实现的程度以及最终的各种指标来进行评判，这一次其实就有两个团队的项目我觉得功能是非常相似的，一个是PC端，一个是移动端，是否可以考虑这样的形式来让小组有平行项目的选择呢？