欢迎大家通过PR的方式或者在本博客下留言的方式随时补充意见和建议，我们会持续更新
书中7.2.4的表7-1 MSF团队模型和关键质量目标里面提到的“出口条件”是什么意思？比如开发的出口条件是：我们是否按照功能说明完成了各项功能。
书上8.8.3提到了一个软件团队一开始预计每次天做30小时工作量，做到一半时每天做15小时工作量。我自己在之前的软件编写和大作业上也常常有这样的烦恼。做到后面就要做大量的测试工作，很劳累。和针对测试出的错误修正并确保正确，又很心累。除非快到死线，不然效率都很低。有什么改进的办法吗？
12章的用户体验让我想到了微信。作为被广泛用于社交，办公的软件。他限制了大文件只能在200Mb以下，朋友圈发的图片和视频画质压缩严重。这两方面跟书上说的好的用户体验背道而驰。这是否说明软件发展到一定阶段用户体验反而不太重要了？
15章中提到了在时间不够，功能不能实现时候去砍掉功能。我之前就有一次比赛中一个队友说他想到了一个他刚学会，性能很好的一个方法,做出来肯定二等奖以上。但是3天的比赛我们花了一整天还没有实现，最后只好放弃，而那个队友接下来的时间基本就是在罢工的状态，偶尔还偷偷去做他的功能……遇到这种傻子队友怎么办？
第二章说到单元测试不适合用随机数来做，但应该集成到自动测试框架中，把我有点绕晕了。那自动化单元测试到底是什么？
我看了P25的对话，我不是很理解对话中提到了任何一个需求都可以表示成一个单元测试。我查了下百度有个叫‘需求覆盖’的说法，但也没说任何需求都可以对应一个单元测试，但根据经验，貌似任何需求都确实可以对应一个单元测试，感觉只要涉及某种输入输出情况肯定可以对应单元测试的。但对于性能的需求貌似不是用单元测试的吧，这个疑点不太明白？
还是P25的对话，最后两句对话可以得知单元测试如果不是写着玩玩的，在模板被使用下还是很有必要写单元测试的。我有个问题：我以前从来没写过单元测试，即使经常出现bug，但我总觉得单元测试从性价比上还不一定有找bug来得快？我查了下知乎关于开发要不要单元测试，发现很多人也说时间成本太高了，认真的话可能的有2/3时间在单元测试，而且有人说大部分公司都是选择不写单元测试的，即有这样一个现象：所有人都赞同单元测试非常重要，然而很少人做单元测试。根据我以往的经验，没有单元测试开发除了在用户没有具体提出的要求如输入异常检验这类东西没有实现好，其他功能在‘正确’使用下最后也都没有问题。所以我对单元测试的必要性不太认同，只觉得可以但没必要？
看了P32的效能分析，但效能分析什么时候终止，是主观判断吗？ 我查了下效能分析貌似不能直接得出算法是否好，而是通过人对数据的判断，这样可以逐步升级算法。如果有被硬性要求还好说，但根据经验没有要求的话往往直接凭感觉已经优化到极致了就不优化了。难道效能分析程度是取决于人而不是需求吗?
书本中提到软件测试人员的代码能力要很强，我认为说法不太正确。书上的解释是因为测试人员是最后一道防线。感觉意思是测试人员写的代码没专业人员测试所以对原代码质量要求高，不然出问题就麻烦了。但我还是不太懂，这不就是在说没有经过专业测试的代码必须由代码质量高的人写才安全，这貌似和测试人员代码质量要求高没什么关系，而是没人能测试的代码质量要求高才对？
P324页形容全栈工程师为‘一个乐团的优秀小提琴手在交响乐演出的时候在台上跑来跑去，搞定其他所有乐器’，有这个问题：我认为这个形容不够贴切，软件又不是边开发用户边使用，应该形容成‘一个电音从业者，使用用各种演奏声音合成一个乐曲然后发布’。这样一来全栈人员的就有其存在意义了。虽然很明显，全栈开发不了太大的项目。但我有个困惑，很多知名的软件一开始立项和前期研发只有一两个开发人员，但后期产品火爆再招人不断升级产品不也是最开始的那个全栈起了个好头吗，全栈不也可以成就一个大项目嘛。
在3.1中提到了关于团队对个人的期望，那个人应该对团队有期望吗？还是说应该如何选择适合自己的团队？看了网上的些回答，我就感觉，好像领导者，领头人或者说团队的管理者非常重要，甚至是起决定性作用，我认为除了对领导者个人的要求外的几点，像是团队价值观、
团队风气、这些似乎也和领导者有很大关系。就好像我们不是在选团队，而是在选领导，或者说选团队本质就是选领导？
关于书中4.3.2提到goto，实际应用中，goto究竟适不适用？团队会不会对这方面有所要求？