软件工程 - 提问回顾与个人总结
提问回顾与个人总结
一、提问回顾
“某个随机数导致程序出错，但是下一次运行又不能重复这一错误”，在随机生成单元测试的时候，为何下一次运行不能重复这个错误呢？随机生成的数据对测试者来说应该是可见的，在随机生成单元测试的时候，若某个随机数导致出错，可不可以记录这个数据，下一次测试就不需要重新随机生成了呢？
还有，对于类似随机数生成器这个程序本身，如果要进行单元测试要怎么进行呢？ 这是我在查询以上疑问的时候遇到的新问题，但是似乎没有得到解答。
正如老师在评论里说的，随机数不能产生一些具有代表性、典型性的数据来进行测试，还是自己设计一些条件为好。
对于随机数生成器本身，可以通过多次运行单元测试的方式在进行测试，项目中我们也是这样做的。
正如书中提出的问题，当PSP中数据不准确或有遗失应该怎么办呢？我个人觉得编造应该是不可取的，这样失去了PSP的意义。在回忆不起来的时候，如果单项时间缺失，可以从其他项目来计算时间；如果数据多项缺失… 有没有什么补救措施呢？
讨论得到的结论是数据多项缺失的时候，这次PSP感觉就难以继续进行记录了，只能在下一次进行更严格的时间记录。
书中用魔方的精通来类比编程技能的精通，这样说来，C++之类的语言精通应该远比C语言困难得多，但即使是c语言，达到“精通”的标准也有一定难度。很多人编程的过程都被调侃或者自嘲为“面向谷歌编程”，那么是否意味着一门编程语言，当我还不能脱离文档或者谷歌独立完成一个项目的时候，我就不能声称我“精通”这门语言呢？
根据我最近面试得到的一些反馈，”精通“一词的确是非常高的评价，当我写”熟悉“xx但是对于一些问题并没有很好地回答上来的时候，我都觉得自己称不上”熟悉"，所以“精通”的确如上所说。
这个问题感觉有那么一点点类似“电车困境”，对于这个问题，我个人的看法是向团队说明自己的失误，并想办法更正以前的错误，后者肯定是不可取的，浪费整个团队的时间同时也是浪费自己的时间。但是我在这里想提问的是，有没有更好的解决方案呢？
暂时没有想到更好的解决方案……自己的责任肯定不能让团队承担，还是主动接锅吧。
书上提倡每个大括号都占一行，但是没有提到过如上的大括号换行规范，即一个第一个大括号不换行。我觉得这种写法也是相对清晰的，并且在网上搜索了一下，采用上述格式和书上的格式D的人都有，甚至大家戏谑地称对方为“异端”。那么第一个大括号换不换行究竟有没有一些我没有考虑到的讲究呢？实例代码比较简单，显得我在钻牛角尖，但是我在想如果在复杂的代码中是否二者的某种优势或者劣势会被放大。
软工项目用python写的，倒是没有大括号的影响，不过再阅读了一些我以前写的C++代码，可能大括号换行层次会更清晰一些。
当你拿不定注意的时候，用成员函数，不要用运算符。
请问为什么这样说呢？我是这样想的，拿不定注意的时候，说明二者皆可，这个时候运算符重载会使得代码可读性更高，尤其是有嵌套调用的时候，所以我个人觉得运算符更好，不知道为什么要这个时候要用成员函数。
软工项目没有用到运算符重载。在C++的一些algorithm库里，重载小于号或者括号可以更好地复用一些库函数，比如sort函数。不推荐使用运算符重载的一个原因我查询不到相关解答，猜测是，运算符重载把函数运行过程隐式地表达出来，不利于发现问题。
文中的提到设定一个阈值，如果开发人员Bug数量超过这个阈值则需要他专心修复Bug，也就是掉进“小强地狱”。对于一个新的项目组，假如大家的代码能力我们都不是很了解，而本身这个阈值又不适合经常修改，那到底应该如何制定出合适的阈值呢？制定不好对于项目进度的影响是否会有负面效果？
陈彦吉助教的回答我觉得很棒：我们首先可以得到这个阈值的一个上界，那就是bug多到完全不能继续开发了。
二、知识点
需求
- 需求分析的时候要有明确的方向，再进一步细化，而不是想到什么就加什么，一些不必要的需求可以舍弃掉。
设计
- UI设计需要尽可能考虑到美观和用户体验，引导需要做好。
实现
- 可以使用一些设计模式来帮助设计，多线程设计部分考虑好线程安全。
测试
- 写单元测试的时间可以省下更多的Debug时间。
- 做好回归测试。
发布
- 发布后做好继续改BUG的准备。
维护
- 多进行反思总结，代码那些地方是可以优化得更好的，及时优化。
三、心得体会
一个学期的软工课程就这样结束了。之前问过一些其他学校的朋友他们的软工课程是什么样的，很多的都很水，写个需求分析书就完事了。
但是其实写代码是挺有意思的一件事情，能有代码写的感觉还是挺好的，但是这门课也不仅仅是在写代码， 而是实打实地在做一个软件，在维护一个项目，在与人合作。每天开会讨论的时候，也能讨论出一些想法和解决方案，这种思维碰撞的感觉还挺好的，也有过自己摸鱼了结果熬夜好几天加班把自己没做好的部分补上的经历，也有过自己做得不好差点把组员弄生气的经历，也算是给自己另一种程度上上了一课，teach a lesson。
除了团队合作的方面以外，完善的软件工程的开发流程对我也大有裨益，之前对于文档、测试之类我自认为“繁琐”的工作都很抗拒，然后就较为低效地自己写代码，在本科课设阶段写写toy还是没问题，工作了这样肯定不行的，软工课程对于我这样想本科毕业就去工作的也是工作的预科班吧，相信能让我在工作中做得更好。
最后，感谢老师，感谢助教，感谢我的组员们的包容与互助，希望大家以后的工程生活都能越来越好。
