注：本文档已提交Github，地址是这个
欢迎大家通过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究竟适不适用？团队会不会对这方面有所要求？
-
书中6.3关于敏捷的团队这里提到了每个人要联合起来对项目负责,落后还要帮忙改进。但是书中也提到过我们在团队中要各司其职，如7.2.4。这冲突吗？我觉得这应该是不冲突的，因为就是是各司其职也同样对项目共同负责，在敏捷的团队中也有任务的分配。但如果项目出问题了，普通情况下肯定是由负责这部分任务的人负责，但在敏捷的团队中，也一样吗？不是说每个人都全面负责，有人工作落后了还要帮助他改进吗。我感觉我有点混乱。
-
在12.1.3中提到的了
a．软件用得越多，一样难用
b．软件用得越多，越发难用
c．软件用得越多，越来越好用
软件是否好用和硬件也是相关的，但硬件发展很快（摩尔定律），所以软件开发的时候也要考虑硬件。这时abc三种情况是可能同时出现的，那么开发者如何把握软件功能的提升和对硬件的要求提升的平衡？
- 书中16.3.0提到的改良式创新(Incremental Innovation)和颠覆式创新(Disruptive Innovation)
提到了个故事：
雅卡尔( Joseph Marie Jacquard ) 1752年出生于里昂，一成年便在丝绸工坊打工，并且很快成为一个有创意的、技艺娴熟的工匠。
他的改革计划在法国大革命期间多次中断，但1805年一大批改革后改进后的半自动织机最终在法国运转了起来。
新织机不但缩短了产品的成型时间,更重要的是减轻了劳动量，减少了工作人数。这必然引起大批工人的恐慌和随之而来的抵制及破坏，
因为使用雅卡尔织布机后，原来需要六名工人完成的工作现在只需一名，这就意味着大批工人的失业。雅卡尔多次受到人身攻击，甚至有人对他以死相逼，
更严重的是，工坊里的新型织机不断被损坏和焚烧。尽管如此，革新的成果还是迅速遍及全国。1812年，整个法国已装置了一万一干多台雅卡尔自动织布机。
颠覆式创新的影响这么大，会不会对这种创新起到致命影响？比如因人身攻击之类*停止。有没有办法减小影响的同时改变社会？
-
我阅读了 12章 用户体验的关于短期刺激和长期影响的内容：
“在实验室里;大家心里想着，我要品尝饮料啦!漱口之后，品尝几口或一听饮料。反馈是:新产品甜味较大，口感很好,我喜欢!
在家里:美国消费者一次买一箱（24听)，随意坐在沙发里，一边看电视一边喝。反馈是:新产品甜味较大，喝多了太腻味,喝不下去,再也不买了!”。
例如一个游戏（如农药，吃鸡等），当人们热衷于它时，能够获得短期的快感，游戏公司开发了防沉迷，是为了减低长期的负面影响。但对于某个不知名的游戏，不言而喻其短期刺激显然更为重要。所以我的疑惑是：短期刺激和长期影响是一个软件不同时期应该考虑的事，还是一开始就应该一起考虑？
-
我阅读了 8章 需求分析 关于获取和引导需求：
“需求不仅来自外界，还可以来自软件企业本身。一个免费的互联网服务到达一定规模后，企业就会考虑如何让这个服务带来收入。例如一个免费的互联网电子邮件服务会考虑对用户收费，支持几种不同等级的用户，在邮件中附带广告，或者在页面显示广告，等等。”
现在一些小程序如嵌入至qq中的小程序，大多没有一定用户数量和规模，但程序内部依然包含大量的广告，这不是本末倒置了吗？用户需求都没有先得到满足，但是存在即合理。这些软件程序依靠什么在市场上能够继续生存？
-
我阅读了 8章需求分析(p158) 关于提高估计能力的招数：
"实际花费取决于两个因素--多某件事的估计时间X，以及他做过类似开发工作的次数N，Y=X +/- X/N。当N等于1时，一项工作的估计的实际花费范围是[0,,2X]"。
实际开发工作中时间不可能为0，此处去左边取闭区间，是否不妥？还是我没有理解其真正含义？
-
当出现不容易复现但又存在的bug时如何解决？
-
如何判断”过早优化“？判断一个优化是否为当前必要的？编写程序时遇见这样的情况，事先不容易判断是否需要优化，如果当前不进行优化，最后发现程序进 行这样的优化是必须的，而又不得不修改大量代码。这种情况如何判断“过早优化”？
程序员小飞原计划三天完成某个任务，他说服了同事，坚持采用自己独特的实现方法。现在是第三天的下午，他马上就可以做完。但是在实现功能的过程中，他越来越意识到自已原来设计中的弱点，他应该采取另一个办法，才能程免后面集成阶段的额外工作。但是他如果现在就改弦更张。那就意味着公开承认自己的设计不好。并且会花费额外的时间。这样他的老板、同事也许会因此看不起他。如果他按部就班地按既定设计完成，最后整个团队还要花更多时间在后续集成上。但那就不是他个人的问题了。怎么办?
这也是我个人的疑问，同时也是时常出现在我身上的问题。之前在做团队比赛的时候时常会因为自己的独特的想法干扰到队友，甚至会因此导致比赛的失利。
-
在书p65页的讨论中有提到当代码量与成长的关系。我有所疑问的是，倘若在项目上遇到自己不会学的已封装好的库，例如在sk-learn库中早已封装好各类机器学习的库，但只会调用库无法提高自己对于知识方面的进一步了解，但去彻底的了解源代码耗费的时间与得到的收获并不成正比，如何平衡这一方面的矛盾呢？
-
书p53页中阐述了过于细致的深究每个问题导致在项目上一开始就困难重重无法进行。那么一个项目想要正确的进行是应当只要求大方向正确接着慢慢去分小方向交接给不同的人去做吗？还是应当不求甚解，从头开始慢慢探索呢？
-
软件开发是一门工程，是一门艺术，还是一门手艺？
-
我看了邹欣老师的博客园讲义中有关创新的章节，那么如何持续创新呢？
-
如何在用户体验方面创新呢？
-
如何进行软件设计？
-
测试要达到什么样的目标才能算通过？
-
如何得出程序员在工作中的贡献值？
-
在实际开发中要如何权衡的软件质量成本？
-
当测试人员与开发人员产生冲突时，如何让他们摒弃前嫌更好的协作呢？
-
当有两个团队邀请你，一个是较好的团队但工作风格与自己差异较大，一个一般团队但工作风格相似，应如何选择？
-
小强地狱部分，提到“阈值不宜频繁调整，最好事先宣布阈值”，这要怎么尽量一次性做到？此处阈值指的是bug数量的界限，如果开发人员“入狱”的比例过高，说明了阈值设置或者bug计算不合理，需要调整。我的想法是，假设在bug计算合理的条件下，阈值设置直接按照书上所说的5%-30%设置，还会不会出现不合理的情况，仍需要调整？如果仍然需要调整，那么多次调整会不会带来开发效率下降等不利影响？（可能多次调整才会趋近于合理）
-
CMMI是如何运行到实际的软件质量保障方面的？
-
如何把握好”灵光一闪“的机会？既然IT行业需要站在前人的肩膀上才会创新，那么就算“站在前人的肩膀上”，要怎样才能像牛顿、阿基米德等人把握好“灵光一闪”的机会？这个问题不是很明白。
-
书中提到了两种电脑键盘布局，两种键盘就其效率而言，更高效的那种反而不是我们日常使用的键盘样式。好的想法不一定赢，但是好的想法和成功的关系是完全意义上的必要不充分条件吗？查阅了相关资料，发现清一色的都是“有想法就去做，去尝试，想赢但也不怕输”的类似观点。也可以说，好的想法出现是想赢，但不一定会赢。那么虽然还提到了“提出一个创新的想法时需要考虑的问题”，对照一下本案例，仅仅是与大众习惯不符，为什么就输了呢？我认为这些问题仍然不是很理解。还有，如果是必要不充分条件，那为什么还要鼓励大家有更多的想法，而某些人有好多好的想法却没有赢，阻碍其他更多想法出现，自相矛盾？
-
如何平衡大量收入但在减少的软件产品和没赚钱但用户量上升很快的软件产品之间的投入。
-
效能过剩是否也暗示了另一种效能不足？效能过剩大概指的就是一个技术达到了持续阶段以后，他的效能已经远远满足大部分用户的需求，就会出现效能过剩的问题，例如书中举得U盘的例子：
2013年打算购买2GB的U盘（需求仅有2GB），但是市面上的U盘都是4GB以上的（效能4GB以上）
这里就是U盘储存空间的效能过剩，但是如果我开发一种快速的读取方法，使用空间换时间的策略（计算机很多优化都可以遵循空间换时间和时间换空间的策略），把原本2GB的文件，额外加上1GB的驱动文件来加速读取，并把这部分内容附在U盘的空间中，那么就可以得到一个3GB空间大小的快速读取的U盘，缓解了存储空间上的效能过剩，也提高了读取速度上的效能。这种情况下，是不是就证明在其他方面（如此处的读取速度）存在着效能不足，可以同时改进二者。
-
在一个技术产品的不同生命周期都有他不同的动量和加速度，当进入衰退阶段以后甚至是成熟阶段的时候，如果通过加入颠覆性的革新，来使得他的加速度猛增（有点像老树开新花的情况），此时这个技术产品生命周期是否算是回溯了，还是应该把新加入的技术部分当作一个独立的技术产品来看待？比如前几年很多的自走棋玩法，游戏Dota2再加入自走棋玩法以后，用户量和用户粘性激增，迅速拉拢了一大批的下棋玩家，甚至一度超远原来的成熟期的高峰。虽然后来热度又被其他的自走棋游戏瓜分掉了无独有偶，游戏英雄联盟也推出云顶之奕玩法，炉石传说推出酒馆战旗玩法，我很喜欢这个模式，至今有在玩，甚至是王者荣耀也推出过类似玩法。再比如有很多游戏也都效仿PUBG的成功案例，加入了大逃杀的玩法。这些个情况是否算是同一个技术产品的生命周期，如果算，其中很多产品已经到达用户量下降，但仍然有收益的衰退阶段了，焕发第二春以后要怎么算他的生命周期。
-
认领和分配任务是一件很难权衡的事，对于同样的一个要求，大牛和狗熊程序员需要的时间和精力肯定是不一样的，可能对于有的人来说很简单很快完成的工作，换另一个人就要处理很久，那这种时候是该考虑重新安排任务，还是考虑更换就职人员？假如说没有可换人员的情况下，按能力分配任务，将会出现每个人虽然花的时间精力差不多，也没怎么摸鱼，做的内容却不一样多，会不会导致一些人心里不平衡？此时又要怎么安排薪酬？我自己之前和同学一起做项目就遇到过这种情况，一开始对于要做的任务的难度和体量没有太大的认识，导致后面有的人很划水，有的人却忙不过来。最后好歹是把项目完成了，可是心里却挺不平衡的。
-
在非常小规模的代码时是否还需要在单元测试上花费大量的时间提高覆盖率呢？
-
PM和乐团指挥的作用是一样的吗？在查了资料以后发现，大部分乐团指挥都是精通乐理，对音乐会有自己的理解，并不会精通每一种乐器，但是一个人可以提升整个乐团的水平，所以我觉得PM和乐团还是有区别的，在教材中看到更多的是PM是在交流和沟通；根据在之前的写代码实践经历以及UML项目设计经历中，每个成员都在沟通，就像大家全是PM一样。
-
看了十六章的IT行业创新的16.1.6 迷思之六：技术的创新是关键。我有一个问题，最关键的是技术创新还是好点子呢。在查了资料以后发现，大部分的人都认为技术创建是关键，在曾经的学习中也曾学过“科学技术是第一生产力”。但是在看到如今社会上很多例子并不像这样，如一些外卖程序和共享某某物的程序。并不是在技术上的创新而是有一个超前的思想把握了当下的热点而取得的成功。所以我的困惑是，在以后的从业生涯中，如果想创新是把握机会还是刻苦攻坚技术突破呢？
-
我有一个问题，我们在创新时是应该寻找一个没人涉及的地方还是从已经广为流传的方面下功夫想创新呢。
-
在二人合作时是要互相了解并介入对方的工作时刻监督对方还是完全信任，注重反馈互相鼓励呢？
-
既然我们学会了单元测试之后，那么应该在什么时候进行测试呢？又比如像C++、java这类面向对象的语言，我们是应该每构造玩一个函数之后再测试还是在每一个类完成之后统一测试？如果每完成一个很小模块就进行测试不久会很繁琐且费事吗？但是如果在整合小模块之后再测试，虽然会减小工作量，但是万一出错的话不就很难查找到问题所在吗？这两者之间该怎么权衡呢？
-
像“将六面魔方还原然后再将其打乱成原样”一般地两者都精通自然是好，但是鱼和熊掌不可兼得，那么在我们学生时代结合当代的软件开和未来的就业形势，当前我们更需要哪一种技能来提升自己呢？
-
用户的反馈显得非常重要。不断完善功能的过程很冗长，这样不就会使得软件开发周期很长吗？而且如果市场反馈不是很积极的话，该软件的开发就十分被动和艰难，甚至有可能会消失，遇到这样的情况该怎么处理呢？
-
小强地狱讲的是开发人员可以忽视一定量的bug，优先保证核心功能的实现。
然而在我看来这是一种不太好的开发模式，开发人员往往会受到心理惯性的作用从而导致bug的堆积，测试人员处于长时间空档期或者突然一大堆东西需要测试，很浪费时间和精力。而且经历过修改bug的我们都知道，这是一件很容易让人心态崩掉的事，所以会降低开发人员的工作积极性。所以在软件开发的过程中，同时进行一些简单的数据测试，同时修改bug，通过了之后再拿到测试人员处进行更精密的测试，找出更棘手的bug，再统一修改，而不是一昧地开发。这是不是一种更好的开发模式呢？ -
构建之法8.3获取用户需求中，提到“A/B测试”以及其弱点，但我认为判断A/B测试是否做过头很难，当你意识到做过头时候，用户都跑光了。（比如我玩的梦幻西游，就因为全新的建模导致一群人弃坑）所以选择性的拿老用户当“小白鼠”会不会更合适？（比如美团试探性的增加老用户的配送费）
-
构建之法8.7的WBS（分治）中提到做好WBS的要点中，认为“要从结果出发，而不是团队的活动” 的意思是，两者是优先级先后关系吗？如果是这样我认为，其实团队的活动也很重要，因为整个工程肯定得交流的好，分工合理才能井井有条否则做出来也是残次品。后期维护沟通也麻烦。
-
构建之法16.3.4中提出产品的生命周期各个阶段，通过“动量”“加速度”来判断，产品到底属于成熟期，还是衰弱期，但一般来说衰弱期再往后留下的都是老用户，如果是游戏，他们往往会舍不得离开，如果此时导入新鲜血液，刺激消费，或许某些情况下，会比文章中提到的“以低成本维护产品”会好呢？亦或者像很多国产游戏一样是在快关服的时候宰一刀老玩家跑路。
-
构建之法16.1.3中提出创新之人，如何让别人接受自己的创新中提到“目前大众习惯，已有系统是否兼容”。这句话的意思我感觉自我矛盾，。这样子只能算是改进，而不是创新不是吗？
-
在构建之法NABC框架模式中有人提到的“D”推广，指出Delivery是在前人实践后意识到Delivery的重要性，那这个D是跟开发人员 完全无关的吧，在我的认知中推广似乎和技术层面没什么太大的关系吧.所以书中只是提及一下子，并没有什么太深刻的意思是吗？
-
一个需求可以即归为产品的功能性需求又归为综合需求吧，这种的情况下应该归为哪一个分类？
-
主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他。主治医师模式可以理解为只有一个“明星”，这是不是说明一般情况下明星模式优于主治医师模式？
-
书中提到：PM通常也能写代码，能玩转Excel、PPT、Visio、甘特图，会PS，有文字功底，写的博客有人爱读，反正，总得有几招绝活吧！不用说还要有大量的阅读，对IT行业、用户心理、社会都要有广泛的了解。PM的能力要求太广泛了，那么做好一个初级PM的切入点是什么？
-
对场景的重要性如何排序？
-
一些bug可以被认为不予解决,会不会因此出现Bounce问题？
-
事后诸葛亮会议是用来探究发布后产生的问题，还是总结开发过程中的问题？
-
我们是否应该在单元测试中测试代码是否达到了性能上的要求？（尤其是时间性能）。
-
我们测试的时候应不应该使用真实的用户数据（不敏感数据）来进行测试？这一点在文中没有提到，使用真实的用户数据可以使得我们的程序更加贴近真实的运行环境，而且可以极大地减小我们花费在测试上的精力。比如我们写了一个统计人口各种信息的程序，测试的时候我们需要创建一些“不存在的人口数据”，这些数据极多，包含了住址、电话、姓名、政治状况等等信息，可能我们当当创建测试用的数据就要花费时间，更别提测试数据的质量如何。如果我们使用了真实数据，不能说我们不需要创建测试数据，但是我们可以只创建一些真实数据覆盖不到的地方，只创建一些边界数据等等。但是如果我们使用了真实的数据，测试中出现bug，那么在debug的过程中就必需要查看这个真实的数据，这样的话就容易造成用户数据的泄露，而且这哪怕不是敏感数据，似乎也会侵犯用户的隐私。市面上有很多的测试数据生成工具，比如datafaker，不过它的原理似乎也不是根据真实数据来构造数据的。
-
文中第4章代码风格规范中提到一个观点：注释应该只用ascii字符，不要使用中文或其他特殊字符。这一个观点我不认同，注释都使用英文等有可能反而会增加程序员理解的成本。我认为应该要根据具体情况来定。例如我们写的某一部分代码开发者都是中国人，而且这一部分代码是公司内部程序的主要逻辑代码，不能对外公开，那么使用中文注释会极大地降低理解成本，毕竟对于大多数中国人来说，肯定是对母语汉语的理解成本更小，日常的交流也使用中文交流。如果对英文不熟悉的人，很有可能会对某些注释产生误解，增加理解成本。而如果我们维护的是一个开源代码库，参与开源的开发者来自世界各个国家，我们代码的读者和使用者也来自世界各国，那么使用英文注释是最佳选择。我不知道现在主流开发者是否有使用英文注释的一些规约，这里引用一下阿里巴巴《java开发手册》2020嵩山版中的观点：24页第6点：【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。
-
关于第4章的结对编程部分，首先谈一谈我的理解，我认为这种方式处在单人编程和团队编程的中间地带，其兼具了两者的一些优点，同时也多了一些缺点。优点很明显，因为人数少，沟通成本较低，不需要考虑团队编程中沟通的问题（关于这一点文中也做了详细的说明）。而人数少不代表效率低，相较于单人编程，结对编程可以分工合作，产生1+1>2的效果。我的问题来自于文中的观点：结对编程是一个渐进的过程，一开始可能不比单独编程效率高，但是度过学习阶段后会有明显改善。那么我可以认为结对编程的一个关键是如何快速地度过有效阶段？关于这个问题文中也说了很多技巧（4.6节），但是这些技巧都是注重花费时间来培养两个人的默契，帮助更好地合作的。这就带来了结对编程的一个缺点：找到一个适合自己的伙伴不容易，相互之间培养默契度过学习阶段也需要时间，在这之前，可能效率不如单人分开编程。人数少的一个缺点是如果有人中途离开，那么很难在短时间内找到一个合适的替代者，毕竟他可能承担了50%的任务！我想知道有没有一些较为有效的方法能够快速度过学习阶段？如果结对的伙伴中途离开，或者中途换人，有没有有效的解决方法？现在的编程很难有两个人一直长期合作，培养默契需要时间，经常变换不利影响大，换人带来的后果比团队编程严重得多，我想知道现在开发者结对编程的多吗？
-
关于第9章项目经理的部分，提到微软PM负责开发和测试之外的所有事情，其中包括了产品市场定位、优化方向、和各方面沟通等等职责。关于这一部分，我有一个很大的疑问是他们是否也是一个多人组成的团体？他们是否也应该要有一个精细的分工？
-
在我的认知中，产品定位、市场发展的重要性远远高于软件的开发和测试，毕竟一个不符合主流、不符合需求的软件项目是不会被市场接受的，一旦因为产品定位的问题导致整个团队多个月的成果白费，责任在谁？
-
在一个10人以下的小团队中，PM负责了客户、开发者之间的沟通交流，还负责了项目开发流程的管理，总之是开发和测试之外的所有事情，如果因为某些原因，该PM中途离开，那么可能直接导致这个项目失败，毕竟PM可能就他一个人！相较而言，开发者的离开可以很快地找到下一位替代者，或者由其他开发者代劳，而PM的离开，导致短时间内开发者需要直面客户，可能之前所有沟通的成果都没有了，新来的PM并不能短时间内接上上一位PM的工作，而且新来的PM可能要更改工期的安排，又会打乱各方面的工作进度。我想知道，有没有比较好的办法可以降低更换PM所带来的坏处？比如更换了一个开发者，新的开发者只需要看懂需求文档等各种文档就能很好地上手工作，而更换了PM，可能会出现更严重的后果，比如新的PM可能认为之前做的工作不符合市场定位，要重做等等情况。
-
如果有小公司（比方叫A）创新发展出新的产品，在膨胀期或者迷茫期时大公司（比方叫B）中途插入开发一个类似的产品，用自己庞大的用户量来挤压A公司产品的空间，那么A公司该如何继续发展下去呢。如果长期如此，A公司花费心血研发出产品后反而大部分的收益被B收入囊中，A公司还能继续研发创新吗？（事实上也确实不缺乏此类例子，例如近几年大火的自走棋模式，原版刀塔自走棋在腾讯推出云顶之弈后，热度就开始一直持续下降）
-
在结对编程时，有时候伙伴的某方面的能力会不匹配，我记得在我一开始跟我们的小组进行人工智能课程的实践时，因为我在一开始忙着处理别的事情，在水平上没有跟上组内的一名成员，导致整个项目几乎没给他提供帮忙。个人疑问：如果在结对编程时出现这种情况，是不是应该先让两名成员在项目所要用到的知识水平上处于一个相对平等的状态。然后如果两个对于一个问题起了争执变成了谁嗓门大谁说了算该怎么办。
-
在技能的反面这门课的内容里，作者认为精通一个技能是要做到知其所以然，并且做到创新，并用魔方做了个例子。个人理解：但是比如三阶魔方目前的世界排名第一杜宇生，他也能在四秒内复原一个魔方，但是也是使用的大家都会用的公式，只是他在观察能力和手眼协调能力远超他人，我觉得即使他没有创新，也可以称之为精通魔方了。又比如nba的退役巨星蒂姆邓肯，被称之为大基本功的代言人，虽然也没有开创什么新技术，但是他对比赛的影响力也是十分巨大，我想这时候他也可以被认为是精通篮球了。
-
软件工程 之 动物世界这一篇文章中提到鹦鹉是一种围观的态度，虽然可能会提出一些点子，但是鹦鹉是不会去执行的，他们只会提出一些云观点做一些空谈，总结起来就是一阵口嗨。但是如果项目没有开发好，他们又会立马跑到别的项目去，仿佛公园里围观下棋的大爷。个人理解：在我看来这类人对于团队的项目进展没有任何帮助，反而他五花八门的思想还可能拖累开发速度，如果在团队中发现这类人，是不是应该采取一些措施，例如将他踢出，或者对他做做思想工作。
-
在这个内卷化日益严重的年代我们是否要跟着一起内卷？当初选择软件工程的原因是因为兴趣，但是为了未来的工作，我现在也需要和别人一起内卷，但是这样我选择软件工程的初衷也没了，可以预见的是这样内卷下去，我的激情会消耗殆尽，而且甚至因为996，007工作的原因而进入不健康的状态。
-
正如书中所说绝大部分软件工程师都不是技术天才，那么我们应该如何选择自己的发展方向，或者说如何发现自己在软件工程中的长处
-
如何解决课外实践与课内学习的冲突？我们如何划分课内学习的时间和课外实践的实践，有时候课外实践占用的实践太多影响到了课内学习，我们应该如何把握？如果实践太少的话，毕业出去就被卷没了，如果太多的话，我们的基础知识就不牢靠了，基础知识是我们以后发展的根基也不能轻易忽视。
-
现在有那么多种语言，我们如何选择一种语言作为自己的主攻方向？想要做到文章说的大脑自动操作，这无疑是需要大量的时间和实践，而到现在为止我接触到的语言有python,php,java,go,c,c++,c#,js,shell,powershell,bat,vb,ruby，而这些语言我都无法做到大脑自动操作，总是这个学学那个学学，不知道以哪个为重点，有时要求这个，有时要求那个，那么我们如何选择一门语言作为自己的主攻方向。
-
我们如何才能进入团队，而不是被当成完成工作就领钱的乌合之众？我在网上看的一些帖子，很多时候都体现了与公司对立的情绪，很多人都说公司不把程序员当人看，996，007压榨，严重的甚至有一些人选择了轻生或者是猝死了，我们在未来找工作的时候无疑会遇到这样的公司，那么我们如何鉴别出他们呢，如何知道他们团队的工作氛围，公司内部真的是一个团队一起工作学习吗？
-
为什么有工作经验的软件工程师比学生在“需求分析”和“测试”上所花的时间多，但编码时间短？我们应当怎么去安排“需求分析”、“测试”和“开发”的时间呢？
-
怎么才能避免“为了自己的角色而做绩效优化”？
-
产品经理要不要懂技术？众所周知，产品经理的主要任务是：有自己的产品思维，具备出色的判断力，形成自己的商业分析逻辑，能够帮公司赚钱(或具备这个意识)，有获取新用户的意识。产品经理花时间在技术上到底值不值呢？
-
设计产品时是否需要考虑不直接给企业带来利润的用户的体验？对于浏览者在网上浏览、比较货物、但并不购买，这种不直接带来利益，但有极大可能成为企业用户的用户在设计时是否需要考虑其需求？（放在Stone网中可能就是考虑未登录能否浏览商品等等）
-
什么样的软件工程作业才叫好作业？
-
P33 为什么使用了int count=m_wordList.Count 后System.Collection.ArrayList.get_Count的调用次数和实践都大幅度减少
-
P51 瓦茨总结说，软件领域分为技艺创新的大爆发和坚持不懈的工程工作，而其中工程工作占了90%-95%的比例，那么剩下的技艺创新具体体现在哪些方面呢？怎么看出来有技艺创新？
-
P65 程序设计进行到一半，发现自己原来设计中存在弱点，要解决这个弱点才能避免额外工作，但是如果现在改变设计，会不会让公司、同事以为自己能力不行？
-
P86 结对编程虽然能够不间断地复审，使代码质量提高，但是编写效率明显下降，要怎么比较质量和时间哪个更重要？怎么能够看出项目是结对编程更好还是个人编程更好？
-
P117 当自己想认领某个任务时，发现自己不具备足够的知识去完成这个任务，而团队里面其他成员对这个任务不感兴趣时，该怎么办？有些人认领的多，有些人认领的少，忙闲不均怎么办？
-
P142 高质量的代码在当用户改变了需求，并且这个需求非常模糊时，是否要舍弃掉之前的高质量代码，选择重新编写？
-
结对编程两人水平相差较大应该怎么协调？
-
团队模式会因为哪些因素而发生变化？
-
长期使用但逐渐厌弃该软件，这是用户的问题还是开发团队的问题？
-
在角色-PM这小节，有个标题“PM做开发和测试之外的所有事情”，之前也学了一点和产品有关的知识，发现PM至少要学会Axture、墨刀等这些软件来画产品原型图。除此之外，和程序员的沟通交流也十分重要，也有过这样的疑惑：对PM来说，开发和测试并不是硬性要求对吗？
-
本书第4章“两人合作”中介绍到：代码复审核查表的其中一项内容是“代码容易维护么？”因为容易是个相对的概念，于是产生了这样的疑问“代码的容易维护是站在复审人员认为的容易还是代码达到了团队规定的编译警告等级”？
-
讲义中将代码量比作树叶量，“代码量等于树叶量，当作如是观。 ”，那么，是否代码量越多，该程序员能力就越强？
-
为什么要进行单元测试？
-
书中第17章第4小结提出了一个萝卜与白菜的问题。大致对比了两种开发风格：一种是“萝卜快了不洗泥”，开发速度很快，但bug量惊人的萝卜类型；另一种是“慢工出细活”，速度较慢，但能赶上截止时间且功能稳定，bug量少的白菜类型。究竟哪一种类型的开发者更受青睐？
-
书中关于“代码复审”的章节有提到：鼓励不同职责的成员交叉相互进行代码复审，有利于相互学习。但如今大部分项目开发都奉行前后端分离的模式，各自专注自己精进的部分，甚至存在前端开发者不懂后端语言、后端开发者不懂前端语言的情况。这种团队协作的执行成本和对开发者的要求是否过高？
-
似乎大多数人都对官僚主义嗤之以鼻。而书中第5章第2节列举的十几种软件团队模式中，官僚模式格外显眼。软件开发团队中是否也存在官僚主义？这种官僚主义是否与在行政机关里很常见的官僚主义有本质上的区别？如何避免团队向官僚模式发展？
-
书中第3章第1节用足球运动员类比软件开发工程师。除了体能、技术、意识、配合、临场应变等专业领域的品质外，还需要良好的沟通能力。那么软件开发工程师除了必备的专业知识和技能以外，还需要具备哪些良好的品质呢？
-
计算机硬件的能力在快速发展，为何服从硬件的软件却没有提速？
-
一个工程师具有绘制完整UML图的能力，那么他是否具备对通用的软件设计思想的理解？
-
结对编程双方水平上的差距，不会导致决策权力偏向一方吗？
-
我看了书中p363的这段文字：
螳臂当车
在游戏中，经常有一两个同学逆历史潮流，提交一个99.999之类的分数。但是从大趋势来看，这些捣乱分子对大局影响不大。我经常看到几个同学面带微笑小声商量，一起提交几个最高分来搅局，但是G-number还是由大多数人决定。
作者的文字对搅局的同学带有贬义，但从另一个角度看，搅局的同学试图打破现状，实现颠覆性的创新。就好像对于电报来说，电话的出现是一种搅局；对于传统的制造业来说，机器的出现也是一种搅局。这种从传统的收敛于0的结果中跳脱出来的思维方式，难道不是创新者应该具备的吗？
- 我看了书中p363的这段文字：
赢者通吃
这个游戏规定第一名得到全部的分数，第二名（不管多接近）到倒数第二名都是0分，最后一名还要倒扣分。软件行业就是一个赢者通吃的环境，最后一名还要把自己的身价倒贴进去。
有这个问题：软件行业真的是一个赢者通吃的环境吗？赢者通吃，也就是所谓的垄断。举个最近的例子：华为开发的鸿蒙系统有望打破安卓系统的垄断。与其说软件行业是一个赢者通吃的环境，但所谓的赢者还会遭到后进者的打击。我更认为软件行业是一个不断创新迭代的环境。
- 文中说到：
“70% 的创新者说, 他们最成功的创新, 是在他们的拿手领域之外发现的。”，
虽然文章中举了些例子，但我对这个比例还是有疑问。按我个人的经验，一个外行人如何能在其他领域创新呢，在某领域创新难道不需要精通这些行业的知识吗？就算真的出于某些偶然的因素，他做到了，但这个比例也不应该是70%啊，难道大部分创新都是偶然？鉴于个人观点的片面性，我就这句话百度到了几篇相关文章博文，其中有赞同的，也有反对的。但并没有直接证据说明这句话的对错。
-
创新的时机跟黄金点游戏有关联吗？我看了《创新的时机 – 黄金点游戏》这篇博文，博文中邹老师谈到了黄金点游戏以及对这个游戏的几点领悟，但是我觉得跟创新的时机没什么关系。关于时机，“只先一步”部分有这样一段话：“那些成功的企业只是比大众的平均值先走了一小步（平均值 * 0.618）, 就是这一小步, 让大部分人看到了产品的“相对优势”从而接受产品。关于技术创新, 一些趋势（例如社会网络），大家早就看到了, 也有一些产品推出, 但是往往最后成功的产品成功在时机上。”，“Technology Hype Cycle”部分也提到：“说到时机, 任何新技术都有一个自身发展的规律，Gartner 的Jackie Fenn 写了一个很有意思的报告, 提到了Technology Hype Cycle。”我对这两部分的理解总结为：新产品在合适的时机推出才能获取成功，此前这个产品可能经历了几个发展换代阶段。但我觉得创新是创造新产品，创新的时机肯定是领先于产品推出的时机，正如文中说的：“做前沿研究的人, 可以早于其他人很多年提出新想法, 但是这些想法一般都是在“Innovator” 那个圈子里有影响, 这些想法要等若干年才能由成功的企业家看准时机推向大众市场。”，所以我认为黄金点游戏是跟推出新产品的时机有关联而不是创新的时机。
-
软件创新的出路真的是“走进作坊”？邹老师在《软件工程讲义 9 创新的出路 走进作坊》中对于软件创新的出路提出了“走进作坊”的观点。原文中有这样一句话：“这些好的作坊, 都有这些核心特性: 从小事做起, 讲究质量, 信用, 对产品负责, 对工作自豪。”，我学识有限，对这篇文章笼统地理解为：创新的出路是作坊是因为好的作坊有匠人精神。感觉我的怀疑没什么依据，要说源头大概就是如原文中说的“哪里都有盗版, 哪里都有抄袭, 哪里都有竞争”，上网去搜索出路什么的大部分都是讲创新是出路，缺少实践的东西。只能说直觉告诉我走进作坊不错，但实际操作起来把它当做创新的出路真的可行吗，是不是大家一起“走进作坊”，我国软件业的创新就能搞起来了呢？
-
如何应对“主治医师模式”? 我读了《团队和流程》这篇博文，里面谈到了几种团队模式和软件开发模式。原文中有这样一段话：‘主治医师模式的退化: 在一些学校里, 软件工程的团队模式往往退化为“一个学生干活, 其余学生跟着打酱油。”’，即将面临软件工程实践课的组队，由于能力、性格的不同难免会形成各种团队模式。如果我有幸遇到这种模式，估计就是一打酱油的。所以一个团队如果能干活人的较少，但是为了项目能够进行下去，应该怎么做？
-
什么是单元测试的自动化? 读过《单元测试&回归测试》这篇博文，谈到了单元测试的自动化。原文是这样的:“另一个重要的措施是要把单元测试自动化，这样每个人都能很容易地运行它，并且可以使单元测试每天都运行。每个人都可以随时在自己的机器上运行。团队一般是在每日构建中运行单元测试的，这样每个单元测试的错误就能及时被发现并得到修改。”，虽然这次作业大概走了一遍单元测试流程，我还是想弱弱地问一句，比如VS上新建单元测试项目，编写好单元测试运行，是不是就算单元测试自动化了？
-
我看了第3章3.1里的“c.质量如何？”部分和“d.是否按时交付？”部分，产生了这个问题：一个软件产品质量的好坏，软件工程师们的技术水平和软件交付期限都是很重要的因素。但如何在软件交付期限内充分发挥软件工程师的水平和价值？首先是对项目的用时估计，但估计就会有偏差，那么就有可能出现一个情况：项目的前90%都是按照A级标准在开发，可是这时突然遇到一个难点，整个团队的人都没法解决，拖延了一段时间，这时考虑到交付期限，只能按照B级标准降级开发，满足基本需求的基础上尽量降低开发质量，最后呈现的结果可能就好比是科尼塞克车身即将完成后发现卡钳生产遇到困难，最后用了次级质量的卡钳去代替，结果顾客反映车子速度可以很快但是制动效果不好，安全性不足，影响了用户的体验，最终导致口碑下降，销量下滑。受按时交付的影响，团队必须在限定时间内做好产品，那么产品开发前的估计就尤为重要，完全按照B级做可能就没法发挥团队水平，无法吸引更多客户与其合作，按A级做又可能存在预估时无法估计到的困难，这实际上是一场冒险，是一个如何平衡开发水平和开发时间的问题。查了资料，大部分说法是追求交付时间内保守开发。有的项目可以先B级，然后有时间慢慢继续改进；但有的项目做不到，因为从底层开始设计就大相径庭，回溯修改极其困难。根据我的作业经历，我是按照交付时间内保守开发的路子在做，因为作业的难度和体量与实际开发项目差距颇大，很多地方量变引起质变，不好直接类推，所以我对实际开发项目的此方面问题有些许疑问。
-
我看了第4章4.5.3“同时，结对编程避免了‘我的代码’还是‘他的代码’的问题，使得代码的责任不属于某个人，而是属于两个人，进而属于整个团队，这样能够帮助团队成员建立集体拥有代码的意识，在一定程度上避免了个人英雄主义。”部分，产生了这个问题：文中提到，结对编程会起到互相督促，互给压力的效果。但我想可能存在一种情况：某个人与团队内编程能力最好的那个人结对编程，那么这个人会不会因为和高手搭档，就形成依赖而不是激起自己的好强心态。自己编程的时候想着反正有大佬在复审，就没有那么投入，也没有那么苛求细节，如此一来，出Bug的数量和概率肯定会上升。而且大佬的操作甚至让这个人复审不知从何下手。查了资料，有如下说法：和实力相近的人结对编程可以解决这个问题。按照我的实践经验，此举确实可以避免上述问题出现。但我又想，这好比一个班级里作业得分最高的双人组和最低的双人组，一个团队中的人实力水平差距是必然存在的，如果说按照水平两两结对编程，避免了上述情况，但此时最强的那组和最弱的那组之间的差距就会被数倍扩大，那么同一个产品的两个模块之间可能就会存在极大的质量差距，显然不是我们想要的结果，那又如何解决这个问题呢？
-
我看了第5章5.3.6 MVP和MBP，产生了如下问题：条件允许的情况下，MBP显然看起来比MVP更加具有吸引力，也更能一举征服用户。从我个人观点来说：MVP模式大部分是受委托进行合作的商业开发模式，而MBP则更多是创业者追求的模式。他们最大的区别在于MBP往往需要更多的时间和更好的技术团队，以及对用户需求的更精确定位。那我是否可以理解为MBP模式是MVP模式的进化和升级？MVP模式是MBP模式的跳板还是说这只是两种不同的开发模式，之间并无太多的进化关系？假设是跳板，那么就是多次MVP累计经验进行MBP，但此时或许早就过了最佳的市场抢占时期，往往都是创造性的挑战MBP产品才能形成创新，在市场中鹤立鸡群。那么它们之间的到底是否存在进化与升级关系？查了资料，并未得到一些能对我的疑问有所帮助的回答。根据我的学习实践，我的经验是：同等时间内MBP模式或者MVP模式的选择取决于个人的编程开发水平，有的同学只能完成仅满足最低需求的编程作业，但编程能力强的学生可以将编程作业做到十分完整的地步。但这情况与实际商业开发有所不同，也就是目前的实践学习经验并不能解决我的疑惑。
-
我看了第9章9.3中“在一个项目中，PM的具体任务是：”这一部分内容。产生了这个问题：对于PM的选择，是用更偏向市场的PM还是用更偏向技术的PM会比较好？按照书中描述，PM的任务大概是作为开发人员和用户之间的桥梁，并带领开发团队完成任务。如若是偏向市场的PM，可能在获取客户需求方面会做得更好；若是偏向技术的PM，他会更好的将客户需求转换为开发团队的具体任务。当然可以说，找两者平衡的PM，但也许事实上，既有强大的市场敏锐度又有精锐的开发技术的PM毕竟还是少数。查阅资料：大部分说看具体的项目类型以及面向的用户群体而定。我感觉这种说法过于空泛，具体如何通过判断项目类型以及用户类型来选择PM我还有疑问。
-
第二章P34页开始提到了PSP个人开发流程，我们这次作业也有要求用PSP表格记录自己估计将在程序的各个模块的开发上耗费的时间。但是我在估计时间的时候感觉力不从心，不知道该怎么估计，最终也和实际耗费时间相差甚大。要怎么才能更好地估计自己估计将在程序的各个模块的开发上耗费的时间呢？我目前的观点是随着自己个人能力的提升和经验的积累会对估计有所帮助。
-
“我们是预期变化,不是期望变化”这一句话我没能理解。对于前半句中的“我们是预期变化”，我的理解是我们要未雨绸缪，通过不断提高自己的能力来应对未知的变化。但是后半句中“不是期望变化”我没看懂，这里期望的是什么变化？
-
书中说到：
大牛:最近业界有人总结，项目需求的生存期是18个月，就是说如果一个项目的需求是18个月前确定的，而产品还没有做出来，那几乎就可以不做了，因为需求肯定已经发生了很大变化。大家有没有注意到微软的一些成功项目的各个版本之间也是间隔18一24个月。现在软件开发的重心从桌面软件移到了互联网软件和服务,项目的版本更新就更频繁了。
“项目需求的生存期是18个月”所说的项目是否更多的适用于对那些已经投入使用的产品的更新的项目？那些未开发出来的项目，比如某款游戏的开发，我认为“18个月的生存期”应该不太能适用。
- 书中提到：
第十二章P266页开始，提到了在用户体验方面要不让用户犯简单的错误。书中举了飞机上的遥控器：“左上角:呼叫乘务员，右上角:取消呼叫，下方:阅读灯。可以想象,在长途飞行、照明不足的情况下，乘客很容易按错。据报道，很多乘客为了避免误按[呼叫]按钮,干脆连阅读灯也不想开了。” ；手术室中的两根输液管：“在医院手术室里，麻醉师在给病人实施麻醉的过程中会用到不同的输液药品，有两个管子一模一样，但用途截然不同,这成为不少医疗事故的问题根源所在。” 等例子。
那在软件开发中，要怎么做到尽量避免让用户犯简单的错误？又还有哪些用户犯简单的错误的例子呢？我的观点是异常处理就是一个这方面很好的例子。
- 书中提到：
第十六章P356页，成功的团队更能创新吗？书里提到1.成功的企业要满足股东们的巨大期望值。2.成功的公司有价值观——追逐利润。3.成功的公司有流程。4.成功的公司重视用户。5.成功的团队有老大心理。
可是我觉得成功的企业拥有更多资金、资源，这些可以给创新带来非常有利的条件。成功的企业也更容易招聘到高端人才，而人才是第一资源。有了这些条件，成功的企业应该是更有创新能力的。然而小企业创新资金不足、人才短缺的风险应该会更大，企业创新本身我觉得也是很冒险的。
在网上搜了一些观点：
大企业创新能力优势强：原因在于因为大型企业的品牌号召力、市场的拓宽能力、和人脉能力资源能力。比小型企业有更大的发展空间。故此创新的能力强。
大企业吸引的人才更多，有思想有创新的人才也就更多，但是受限于一些大企业传统的发展模式，创新程度不一定比得上某些小公司。
小型企业创新能力优势强：原因在于它与大型企业创新的不同是大企业结构和模式固定单一不易轻易改变。而小型企业反之亦然，创新价值高、模式可多样变化。
很明显众说纷纭，所以想知道现实到底是大企业还是小企业更能创新？
- 大多数人的思维方式是不一样的，一个问题解决也有多个解决方法，两个人结对编程过程中自己在解决问题，同时也在看对方解决问题，思维在自己和对方的解题思路中不断跳跃，这样花费的时间不会更多吗？怎样才能找到适合结对编程的搭档呢？怎么和搭在合作中达到1+1>2的效果呢？关于如何结对编程有相关的理论方法吗？比如如何达到高效合作。
- 书中介绍了很多开发流程的方式比如：写了再改、瀑布模型、瀑布的各种变形等。问题：一个刚组成的软件开发团队，彼此都还不是很了解，如何选择适合的开发流程呢？这几种开发方式有比较低风险的吗？如果在团队合作过程中，发现一开始的方式有问题，但内部的调动又会消耗大量的精力，这值得半途换开发流程模式吗？
- 文中写道“自己最喜欢的一个项目是微软学术搜索，尽管许多用户觉得它的UI不错，它仍有很多可以改进的地方，一个叫西乔的同学就给提出了下面的建议：建议采用不同的样式，将submit按钮突出，Cancel按钮样式弱化，降低用户丢失操作的可能性。”我联想到，如果存在这样希望降低用户损失（但不是很大的影响）更改界面，但是会使界面变得不美观的情况，应当如何选择？
- 那在实际项目中，整个团队在每个阶段的时间怎么分配才合理呢？哪个阶段的时间应该花最多的时间和精力。
- 团队里出现‘不做事’、‘不让别人做事’等之类的人，应该怎么办呢，是耐心的沟通交流，还是粗暴的踢出。
- 创新真的要顾及到一部分人的利益吗？我感到很困惑，书中提到了很多人都讨厌创新，因为这可能会影响到其他大部分人甚至自己的利益，可是，如果不创新，怎么能开发出新的市场？我觉得这样顾此失彼的做法是有待商榷的。
- 如何实现单元测试的自动化？这一次的作业中使用到了单元测试，可是我对单元测试还是不太了解，文中提到测试最好使用自动化，可自动化是什么呢？和自己手动测试有什么比较大的不同呢？
- 什么阶段最适合“效能提高”？
34页：“大家也要注意避免没有做分析就过早地进行“效能提高”，如果我们不经分析就盲目优化，也许会事倍功半。”
书中说到如果太早的进行“效能提高”，可能会导致盲目话，可我认为如果不能再最开始就进行一个完善的算法思考，最后进行提高的话不仅会增加工作量，而且会导致大规模的代码变动，这样难道会更合理吗？
- 是否在项目正式启动前确定代码风格？每个程序员都有属于自己的代码规范，那么在集体编程的时候，是应该按照一个统一的代码规范来编程，还是按照自己认为正确的代码规范来编程呢？
- 一个对算法熟悉的程序员和一个对算法一知半解的程序员差别有多大？
- 如何避免自己成为鹦鹉？
有些人是 鹦鹉 - 他们有漂亮的羽毛, 能说会道, 联系广泛, 能提出很多建议, 很多点子. 但是他们
不执行, 除了一些人云亦云的观点和一些关于架构的空谈之外, 他们没有其他投入. 一旦项目失败, 他们就会
飞到另一个项目中去。 他们的投入级别是 – 围观 (bystander).
- 遇到技术上的困难时，应该自己解决，还是应该去问别人？
- 不同用户需求矛盾时如何处理？对于一个程序某个功能，有的人认为是bug，影响个人使用，有的人认为这个功能不错。如何取舍呢，根据用户比例吗？
- 敏捷流程发生人员变动怎么办？一个团队自然会碰到离职，请假等，敏捷流程要求“冲刺”，但人员变动影响原来任务的分配，其次，缺人手后新人加入也会带来问题，给其他人带来压力，这种情况下如何“冲刺”呢?
- 每次软件版本更迭都需要需求分析吗？随着软件的不断发展，用户量不断增加，当这个软件越来越大后，用户好像离不开这个软件（竞争者都被干掉了）。软件的发展似乎不再需要用户提什么需求，而是软件想给用户什么功能，用户只能“自己承受”。 需求分析随着软件发展成熟后还有必要吗？现在许多app功能越来越多，偏离了最初的目的，如何看待这种情况？
- PM与团队平等相处是幻想还是可以实现？在产品设计过程中可能会发生许多分歧，谁也说服不了谁，这样是不是反而影响效率？表格中一个团队可能有多个PM，这些PM发生分歧又该如何解决？如果出现一个PM有了决定权，那么是不是就无法平等讨论？
- 测试人员在什么时候进行测试？书本上说测试人员进行测试几个模块之间的联系，具体时间如何确定呢？开发人员利用单元测试进行测试基础功能，如果测试人员也要进行测试，开发人员能否不再进行单元测试，把工作都丢给测试人员。如果测试人员等到开发后期进行测试，则可能导致整个程序改动。如何确定测试人员开始测试的时期呢？
- 在第五章团队中的角色和合作中提到“开发项目的时候才觉得实际情况和书上讲的都有一些出入，偏偏一些重要的出入书上没有提。我们很多人是边看asp.net的书, 边开发asp.net的项目，这相当于一边看医学书一边动手术。”在我看来这个是初期项目开发者都会遇到的问题，其实在一定程度上确实影响了自身的开发效率，那面对这样的情况应该要怎么处理呢？
- 在第五章的团队不同的投入中作者提到团队中有一类人为
鹦鹉：“他们有漂亮的羽毛,，能说会道，联系广泛，能提出很多建议，很多点子但是他们不执行,除了一些人云亦云的观点和一些关于架构的空谈之外，他们没有其他投入，一旦项目失败, 他们就会飞到另一个项目中去。”这种类型在团队其实是很影响队员效率的，那应不应该适当的提醒她呢？或者应该怎么处理这样的情况呢？ - 在第九章创新方面作者提到了两种如何在一个创新性的市场上后来居上的观点，分别是“改变游戏规则”和“转换目标用户”。其实我认为“居上”最多也就是几乎齐头并进，但是还是无法超越之前的产品，这样的想法是否正确呢？对于这个观点，我觉得最好的例子就是拼多多的崛起，在淘宝已经占据了绝大部分市场份额的时候，拼多多以一个“砍一刀”的规则重新进入了大众的视野，同时商品定位比较亲民，他利用了大众心理制定的政策，果不其然，确实很成功。同时，在后续的使用过程中我们也先后发现了其他app也出现过类似的板块。这其实就正好契合作者所提到的这两个创新的办法，但是在市场上看淘宝还是大部分用户的第一选择，因为前者可以向新的创意学习，可能两者的起点就是不同，但是不可否定的是拼多多的创新确实做的很成功。
- 在第七章设计阶段分析中作者提到对于需求分析不应该条条框框的完成需求内的要求，但是也不可以一味追求“最大的扩展性”。所以在需求分析和设计的时候我们应该保留什么样的弹性呢？
- 在七章开发阶段的日常管理中作者提到“要尽量减少非开发时间，不要动不动就开“全体会议”。团队成员们自我时间管理也很重要。”这个全体会议其实是很经典的问题，感觉其实当团队积极参与度不高的时候，全体会议就显得很没有效率，但是有时候又是必要的需要告知大家，或者希望大家参与讨论，应该怎么处理呢？
- 事后诸葛亮会议是对整个项目的回顾，总结经验教训，但是一些公司里人员流动大，去去留留一个项目能换几茬人，那么事后诸葛亮会议还有意义吗？会不会变成甩锅大会呢？
- 结对编程的好处书中已经详细描述了，那结对编程的不足之处呢？结对编程在现实生活中国内的公司似乎很少采用，是有什么局限吗？
- 典型用户是指，按不同维度来区分用户的过程中，在每个维度中能代表目标用户的那类群体。比如，按人数多少来划分的，能代表最多用户特征的群体；按盈利来划分，能代表带来最多盈利价值特征的群体。但是典型用户的定义和删除让我觉得非常奇怪，典型用户在何种情况下需要进行删除呢？
- 第三章提到过早扩大化/泛化会使整个软件变得四不像最后只能让后人来完善，怎样才能避免陷入这种误区，又应该在什么阶段对软件进行扩大化/泛化，使得程序更加完善？
- 第四章提到结对编程使用同一机器一同完成工作，那么应该如何根据各自的特长分配两个人的任务范围以取得更高的投入产出比？
- 第五章中提到为解决瀑布模型的问题提出了生鱼片模型和大瀑布带着小瀑布模型，分别有什么优缺点，这两种模型分别适应与哪种开发场景？
- 第六章中提到Scrum/Sprint能成功实施的关键在于Scrum Master，那么应该如何判断一个人能否胜任Scrum Master的工作？
- 第九章介绍的PM对团队起着重要作用，但应该如何处理好与团队成员的关系，了解成员的状态，合理分配工作来提高项目的完成效率何工作质量？
- 面对庞大而又零碎的需求，是如何从中化繁为简，捋顺思路，将各个需求串起来已进行功能的实现的呢？
- 那么作为团队中的一员，如何快速的找到自己的定位，完成自己可以胜任的任务呢，并且作为初入职场的新手程序员，如何让正确而又全面的向领导展现自己能力呢？
- 假如作为一个个人开发者，考虑的测试情况总是有限的，有什么办法可以帮助我们拓宽自己对软件可用性测试的思维呢？
- 有着各自的见解，无法迅速的达到统一，所以请问在这种情况下到底应该如何达成一样的意见，团队又应该如何去沟通交流思想呢？
- 我有个疑问，例如现在的某手机支付软件，为了利润投加了很多影响用户观感的广告，经常在使用的时候会无奈地误触到，作为用户我感觉软件的使用不够清爽，而反观某b视频软件，在广告以及一些不影响软件主要播放功能的小功能方面安排的很好，请问作为程序员在接受了用户这样的体验反馈后会做出如何的调整呢，如何在软件收益和软件使用体验之间做出均衡呢？
- 书中提到：
《构建之法》3.2 软件工程师的思维误区
“不分主次，想解决所有依赖问题：想马上动手解决所有主要问题和次要问题，而不是根据现有条件找到一个足够好的方案”
疑问&思考