Loading

【助教】阅读《构建之法》之FAQ

FAQ陆续迁移到 CSDN社区中，请访问：https://bbs.csdn.net/forums/SoftwareEngineering?category=14

欢迎大家通过PR的方式或者在本博客下留言的方式随时补充意见和建议，我们会持续更新

  1. 书中7.2.4的表7-1 MSF团队模型和关键质量目标里面提到的“出口条件”是什么意思？比如开发的出口条件是：我们是否按照功能说明完成了各项功能。

  2. 书上8.8.3提到了一个软件团队一开始预计每次天做30小时工作量，做到一半时每天做15小时工作量。我自己在之前的软件编写和大作业上也常常有这样的烦恼。做到后面就要做大量的测试工作，很劳累。和针对测试出的错误修正并确保正确，又很心累。除非快到死线，不然效率都很低。有什么改进的办法吗？

  3. 12章的用户体验让我想到了微信。作为被广泛用于社交，办公的软件。他限制了大文件只能在200Mb以下，朋友圈发的图片和视频画质压缩严重。这两方面跟书上说的好的用户体验背道而驰。这是否说明软件发展到一定阶段用户体验反而不太重要了？

  4. 15章中提到了在时间不够，功能不能实现时候去砍掉功能。我之前就有一次比赛中一个队友说他想到了一个他刚学会，性能很好的一个方法,做出来肯定二等奖以上。但是3天的比赛我们花了一整天还没有实现，最后只好放弃，而那个队友接下来的时间基本就是在罢工的状态，偶尔还偷偷去做他的功能……遇到这种傻子队友怎么办？

  5. 第二章说到单元测试不适合用随机数来做，但应该集成到自动测试框架中，把我有点绕晕了。那自动化单元测试到底是什么？

  6. 我看了P25的对话，我不是很理解对话中提到了任何一个需求都可以表示成一个单元测试。我查了下百度有个叫‘需求覆盖’的说法，但也没说任何需求都可以对应一个单元测试，但根据经验，貌似任何需求都确实可以对应一个单元测试，感觉只要涉及某种输入输出情况肯定可以对应单元测试的。但对于性能的需求貌似不是用单元测试的吧，这个疑点不太明白？

  7. 还是P25的对话，最后两句对话可以得知单元测试如果不是写着玩玩的，在模板被使用下还是很有必要写单元测试的。我有个问题：我以前从来没写过单元测试，即使经常出现bug，但我总觉得单元测试从性价比上还不一定有找bug来得快？我查了下知乎关于开发要不要单元测试，发现很多人也说时间成本太高了，认真的话可能的有2/3时间在单元测试，而且有人说大部分公司都是选择不写单元测试的，即有这样一个现象：所有人都赞同单元测试非常重要，然而很少人做单元测试。根据我以往的经验，没有单元测试开发除了在用户没有具体提出的要求如输入异常检验这类东西没有实现好，其他功能在‘正确’使用下最后也都没有问题。所以我对单元测试的必要性不太认同，只觉得可以但没必要？

  8. 看了P32的效能分析，但效能分析什么时候终止，是主观判断吗？ 我查了下效能分析貌似不能直接得出算法是否好，而是通过人对数据的判断，这样可以逐步升级算法。如果有被硬性要求还好说，但根据经验没有要求的话往往直接凭感觉已经优化到极致了就不优化了。难道效能分析程度是取决于人而不是需求吗?

  9. 书本中提到软件测试人员的代码能力要很强，我认为说法不太正确。书上的解释是因为测试人员是最后一道防线。感觉意思是测试人员写的代码没专业人员测试所以对原代码质量要求高，不然出问题就麻烦了。但我还是不太懂，这不就是在说没有经过专业测试的代码必须由代码质量高的人写才安全，这貌似和测试人员代码质量要求高没什么关系，而是没人能测试的代码质量要求高才对？

  10. P324页形容全栈工程师为‘一个乐团的优秀小提琴手在交响乐演出的时候在台上跑来跑去，搞定其他所有乐器’，有这个问题：我认为这个形容不够贴切，软件又不是边开发用户边使用，应该形容成‘一个电音从业者，使用用各种演奏声音合成一个乐曲然后发布’。这样一来全栈人员的就有其存在意义了。虽然很明显，全栈开发不了太大的项目。但我有个困惑，很多知名的软件一开始立项和前期研发只有一两个开发人员，但后期产品火爆再招人不断升级产品不也是最开始的那个全栈起了个好头吗，全栈不也可以成就一个大项目嘛。

  11. 在3.1中提到了关于团队对个人的期望，那个人应该对团队有期望吗？还是说应该如何选择适合自己的团队？看了网上的些回答，我就感觉，好像领导者，领头人或者说团队的管理者非常重要，甚至是起决定性作用，我认为除了对领导者个人的要求外的几点，像是团队价值观、
    团队风气、这些似乎也和领导者有很大关系。就好像我们不是在选团队，而是在选领导，或者说选团队本质就是选领导？

  12. 关于书中4.3.2提到goto，实际应用中，goto究竟适不适用？团队会不会对这方面有所要求？

  13. 书中6.3关于敏捷的团队这里提到了每个人要联合起来对项目负责,落后还要帮忙改进。但是书中也提到过我们在团队中要各司其职，如7.2.4。这冲突吗？我觉得这应该是不冲突的，因为就是是各司其职也同样对项目共同负责，在敏捷的团队中也有任务的分配。但如果项目出问题了，普通情况下肯定是由负责这部分任务的人负责，但在敏捷的团队中，也一样吗？不是说每个人都全面负责，有人工作落后了还要帮助他改进吗。我感觉我有点混乱。

  14. 在12.1.3中提到的了

a．软件用得越多，一样难用

b．软件用得越多，越发难用

c．软件用得越多，越来越好用

软件是否好用和硬件也是相关的，但硬件发展很快（摩尔定律），所以软件开发的时候也要考虑硬件。这时abc三种情况是可能同时出现的，那么开发者如何把握软件功能的提升和对硬件的要求提升的平衡？

  1. 书中16.3.0提到的改良式创新(Incremental Innovation)和颠覆式创新(Disruptive Innovation)

提到了个故事：

雅卡尔( Joseph Marie Jacquard ) 1752年出生于里昂，一成年便在丝绸工坊打工，并且很快成为一个有创意的、技艺娴熟的工匠。
他的改革计划在法国大革命期间多次中断，但1805年一大批改革后改进后的半自动织机最终在法国运转了起来。
新织机不但缩短了产品的成型时间,更重要的是减轻了劳动量，减少了工作人数。这必然引起大批工人的恐慌和随之而来的抵制及破坏，
因为使用雅卡尔织布机后，原来需要六名工人完成的工作现在只需一名，这就意味着大批工人的失业。雅卡尔多次受到人身攻击，甚至有人对他以死相逼，
更严重的是，工坊里的新型织机不断被损坏和焚烧。尽管如此，革新的成果还是迅速遍及全国。1812年，整个法国已装置了一万一干多台雅卡尔自动织布机。

颠覆式创新的影响这么大，会不会对这种创新起到致命影响？比如因人身攻击之类被迫停止。有没有办法减小影响的同时改变社会？

  1. 我阅读了 12章 用户体验的关于短期刺激和长期影响的内容：

    “在实验室里;大家心里想着，我要品尝饮料啦!漱口之后，品尝几口或一听饮料。反馈是:新产品甜味较大，口感很好,我喜欢!

    在家里:美国消费者一次买一箱（24听)，随意坐在沙发里，一边看电视一边喝。反馈是:新产品甜味较大，喝多了太腻味,喝不下去,再也不买了!”。

例如一个游戏（如农药，吃鸡等），当人们热衷于它时，能够获得短期的快感，游戏公司开发了防沉迷，是为了减低长期的负面影响。但对于某个不知名的游戏，不言而喻其短期刺激显然更为重要。所以我的疑惑是：短期刺激和长期影响是一个软件不同时期应该考虑的事，还是一开始就应该一起考虑？

  1. 我阅读了 8章 需求分析 关于获取和引导需求：

    “需求不仅来自外界，还可以来自软件企业本身。一个免费的互联网服务到达一定规模后，企业就会考虑如何让这个服务带来收入。例如一个免费的互联网电子邮件服务会考虑对用户收费，支持几种不同等级的用户，在邮件中附带广告，或者在页面显示广告，等等。”

现在一些小程序如嵌入至qq中的小程序，大多没有一定用户数量和规模，但程序内部依然包含大量的广告，这不是本末倒置了吗？用户需求都没有先得到满足，但是存在即合理。这些软件程序依靠什么在市场上能够继续生存？

  1. 我阅读了 8章需求分析(p158) 关于提高估计能力的招数：

    "实际花费取决于两个因素--多某件事的估计时间X，以及他做过类似开发工作的次数N，Y=X +/- X/N。当N等于1时，一项工作的估计的实际花费范围是[0,,2X]"。

实际开发工作中时间不可能为0，此处去左边取闭区间，是否不妥？还是我没有理解其真正含义？

  1. 当出现不容易复现但又存在的bug时如何解决？

  2. 如何判断”过早优化“？判断一个优化是否为当前必要的？编写程序时遇见这样的情况，事先不容易判断是否需要优化，如果当前不进行优化，最后发现程序进 行这样的优化是必须的，而又不得不修改大量代码。这种情况如何判断“过早优化”？

程序员小飞原计划三天完成某个任务，他说服了同事，坚持采用自己独特的实现方法。现在是第三天的下午，他马上就可以做完。但是在实现功能的过程中，他越来越意识到自已原来设计中的弱点，他应该采取另一个办法，才能程免后面集成阶段的额外工作。但是他如果现在就改弦更张。那就意味着公开承认自己的设计不好。并且会花费额外的时间。这样他的老板、同事也许会因此看不起他。如果他按部就班地按既定设计完成，最后整个团队还要花更多时间在后续集成上。但那就不是他个人的问题了。怎么办?

这也是我个人的疑问，同时也是时常出现在我身上的问题。之前在做团队比赛的时候时常会因为自己的独特的想法干扰到队友，甚至会因此导致比赛的失利。

  1. 在书p65页的讨论中有提到当代码量与成长的关系。我有所疑问的是，倘若在项目上遇到自己不会学的已封装好的库，例如在sk-learn库中早已封装好各类机器学习的库，但只会调用库无法提高自己对于知识方面的进一步了解，但去彻底的了解源代码耗费的时间与得到的收获并不成正比，如何平衡这一方面的矛盾呢？

  2. 书p53页中阐述了过于细致的深究每个问题导致在项目上一开始就困难重重无法进行。那么一个项目想要正确的进行是应当只要求大方向正确接着慢慢去分小方向交接给不同的人去做吗？还是应当不求甚解，从头开始慢慢探索呢？

  3. 软件开发是一门工程，是一门艺术，还是一门手艺？

  4. 我看了邹欣老师的博客园讲义中有关创新的章节，那么如何持续创新呢？

  5. 如何在用户体验方面创新呢？

  6. 如何进行软件设计？

  7. 测试要达到什么样的目标才能算通过？

  8. 如何得出程序员在工作中的贡献值？

  9. 在实际开发中要如何权衡的软件质量成本？

  10. 当测试人员与开发人员产生冲突时，如何让他们摒弃前嫌更好的协作呢？

  11. 当有两个团队邀请你，一个是较好的团队但工作风格与自己差异较大，一个一般团队但工作风格相似，应如何选择？

  12. 小强地狱部分，提到“阈值不宜频繁调整，最好事先宣布阈值”，这要怎么尽量一次性做到？此处阈值指的是bug数量的界限，如果开发人员“入狱”的比例过高，说明了阈值设置或者bug计算不合理，需要调整。我的想法是，假设在bug计算合理的条件下，阈值设置直接按照书上所说的5%-30%设置，还会不会出现不合理的情况，仍需要调整？如果仍然需要调整，那么多次调整会不会带来开发效率下降等不利影响？（可能多次调整才会趋近于合理）

  13. CMMI是如何运行到实际的软件质量保障方面的？

  14. 如何把握好”灵光一闪“的机会？既然IT行业需要站在前人的肩膀上才会创新，那么就算“站在前人的肩膀上”，要怎样才能像牛顿、阿基米德等人把握好“灵光一闪”的机会？这个问题不是很明白。

  15. 书中提到了两种电脑键盘布局，两种键盘就其效率而言，更高效的那种反而不是我们日常使用的键盘样式。好的想法不一定赢，但是好的想法和成功的关系是完全意义上的必要不充分条件吗？查阅了相关资料，发现清一色的都是“有想法就去做，去尝试，想赢但也不怕输”的类似观点。也可以说，好的想法出现是想赢，但不一定会赢。那么虽然还提到了“提出一个创新的想法时需要考虑的问题”，对照一下本案例，仅仅是与大众习惯不符，为什么就输了呢？我认为这些问题仍然不是很理解。还有，如果是必要不充分条件，那为什么还要鼓励大家有更多的想法，而某些人有好多好的想法却没有赢，阻碍其他更多想法出现，自相矛盾？

  16. 如何平衡大量收入但在减少的软件产品和没赚钱但用户量上升很快的软件产品之间的投入。

  17. 效能过剩是否也暗示了另一种效能不足？效能过剩大概指的就是一个技术达到了持续阶段以后，他的效能已经远远满足大部分用户的需求，就会出现效能过剩的问题，例如书中举得U盘的例子：

2013年打算购买2GB的U盘（需求仅有2GB），但是市面上的U盘都是4GB以上的（效能4GB以上）

这里就是U盘储存空间的效能过剩，但是如果我开发一种快速的读取方法，使用空间换时间的策略（计算机很多优化都可以遵循空间换时间和时间换空间的策略），把原本2GB的文件，额外加上1GB的驱动文件来加速读取，并把这部分内容附在U盘的空间中，那么就可以得到一个3GB空间大小的快速读取的U盘，缓解了存储空间上的效能过剩，也提高了读取速度上的效能。这种情况下，是不是就证明在其他方面（如此处的读取速度）存在着效能不足，可以同时改进二者。

  1. 在一个技术产品的不同生命周期都有他不同的动量和加速度，当进入衰退阶段以后甚至是成熟阶段的时候，如果通过加入颠覆性的革新，来使得他的加速度猛增（有点像老树开新花的情况），此时这个技术产品生命周期是否算是回溯了，还是应该把新加入的技术部分当作一个独立的技术产品来看待？比如前几年很多的自走棋玩法，游戏Dota2再加入自走棋玩法以后，用户量和用户粘性激增，迅速拉拢了一大批的下棋玩家，甚至一度超远原来的成熟期的高峰。虽然后来热度又被其他的自走棋游戏瓜分掉了无独有偶，游戏英雄联盟也推出云顶之奕玩法，炉石传说推出酒馆战旗玩法，我很喜欢这个模式，至今有在玩，甚至是王者荣耀也推出过类似玩法。再比如有很多游戏也都效仿PUBG的成功案例，加入了大逃杀的玩法。这些个情况是否算是同一个技术产品的生命周期，如果算，其中很多产品已经到达用户量下降，但仍然有收益的衰退阶段了，焕发第二春以后要怎么算他的生命周期。

  2. 认领和分配任务是一件很难权衡的事，对于同样的一个要求，大牛和狗熊程序员需要的时间和精力肯定是不一样的，可能对于有的人来说很简单很快完成的工作，换另一个人就要处理很久，那这种时候是该考虑重新安排任务，还是考虑更换就职人员？假如说没有可换人员的情况下，按能力分配任务，将会出现每个人虽然花的时间精力差不多，也没怎么摸鱼，做的内容却不一样多，会不会导致一些人心里不平衡？此时又要怎么安排薪酬？我自己之前和同学一起做项目就遇到过这种情况，一开始对于要做的任务的难度和体量没有太大的认识，导致后面有的人很划水，有的人却忙不过来。最后好歹是把项目完成了，可是心里却挺不平衡的。

  3. 在非常小规模的代码时是否还需要在单元测试上花费大量的时间提高覆盖率呢？

  4. PM和乐团指挥的作用是一样的吗？在查了资料以后发现，大部分乐团指挥都是精通乐理，对音乐会有自己的理解，并不会精通每一种乐器，但是一个人可以提升整个乐团的水平，所以我觉得PM和乐团还是有区别的，在教材中看到更多的是PM是在交流和沟通；根据在之前的写代码实践经历以及UML项目设计经历中，每个成员都在沟通，就像大家全是PM一样。

  5. 看了十六章的IT行业创新的16.1.6 迷思之六：技术的创新是关键。我有一个问题，最关键的是技术创新还是好点子呢。在查了资料以后发现，大部分的人都认为技术创建是关键，在曾经的学习中也曾学过“科学技术是第一生产力”。但是在看到如今社会上很多例子并不像这样，如一些外卖程序和共享某某物的程序。并不是在技术上的创新而是有一个超前的思想把握了当下的热点而取得的成功。所以我的困惑是，在以后的从业生涯中，如果想创新是把握机会还是刻苦攻坚技术突破呢？

  6. 我有一个问题，我们在创新时是应该寻找一个没人涉及的地方还是从已经广为流传的方面下功夫想创新呢。

  7. 在二人合作时是要互相了解并介入对方的工作时刻监督对方还是完全信任，注重反馈互相鼓励呢？

  8. 既然我们学会了单元测试之后，那么应该在什么时候进行测试呢？又比如像C++、java这类面向对象的语言，我们是应该每构造玩一个函数之后再测试还是在每一个类完成之后统一测试？如果每完成一个很小模块就进行测试不久会很繁琐且费事吗？但是如果在整合小模块之后再测试，虽然会减小工作量，但是万一出错的话不就很难查找到问题所在吗？这两者之间该怎么权衡呢？

  9. 像“将六面魔方还原然后再将其打乱成原样”一般地两者都精通自然是好，但是鱼和熊掌不可兼得，那么在我们学生时代结合当代的软件开和未来的就业形势，当前我们更需要哪一种技能来提升自己呢？

  10. 用户的反馈显得非常重要。不断完善功能的过程很冗长，这样不就会使得软件开发周期很长吗？而且如果市场反馈不是很积极的话，该软件的开发就十分被动和艰难，甚至有可能会消失，遇到这样的情况该怎么处理呢？

  11. 小强地狱讲的是开发人员可以忽视一定量的bug，优先保证核心功能的实现。
    然而在我看来这是一种不太好的开发模式，开发人员往往会受到心理惯性的作用从而导致bug的堆积，测试人员处于长时间空档期或者突然一大堆东西需要测试，很浪费时间和精力。而且经历过修改bug的我们都知道，这是一件很容易让人心态崩掉的事，所以会降低开发人员的工作积极性。所以在软件开发的过程中，同时进行一些简单的数据测试，同时修改bug，通过了之后再拿到测试人员处进行更精密的测试，找出更棘手的bug，再统一修改，而不是一昧地开发。这是不是一种更好的开发模式呢？

  12. 构建之法8.3获取用户需求中，提到“A/B测试”以及其弱点，但我认为判断A/B测试是否做过头很难，当你意识到做过头时候，用户都跑光了。（比如我玩的梦幻西游，就因为全新的建模导致一群人弃坑）所以选择性的拿老用户当“小白鼠”会不会更合适？（比如美团试探性的增加老用户的配送费）

  13. 构建之法8.7的WBS（分治）中提到做好WBS的要点中，认为“要从结果出发，而不是团队的活动” 的意思是，两者是优先级先后关系吗？如果是这样我认为，其实团队的活动也很重要，因为整个工程肯定得交流的好，分工合理才能井井有条否则做出来也是残次品。后期维护沟通也麻烦。

  14. 构建之法16.3.4中提出产品的生命周期各个阶段，通过“动量”“加速度”来判断，产品到底属于成熟期，还是衰弱期，但一般来说衰弱期再往后留下的都是老用户，如果是游戏，他们往往会舍不得离开，如果此时导入新鲜血液，刺激消费，或许某些情况下，会比文章中提到的“以低成本维护产品”会好呢？亦或者像很多国产游戏一样是在快关服的时候宰一刀老玩家跑路。

  15. 构建之法16.1.3中提出创新之人，如何让别人接受自己的创新中提到“目前大众习惯，已有系统是否兼容”。这句话的意思我感觉自我矛盾，。这样子只能算是改进，而不是创新不是吗？

  16. 在构建之法NABC框架模式中有人提到的“D”推广，指出Delivery是在前人实践后意识到Delivery的重要性，那这个D是跟开发人员 完全无关的吧，在我的认知中推广似乎和技术层面没什么太大的关系吧.所以书中只是提及一下子，并没有什么太深刻的意思是吗？

  17. 一个需求可以即归为产品的功能性需求又归为综合需求吧，这种的情况下应该归为哪一个分类？

  18. 主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他。主治医师模式可以理解为只有一个“明星”，这是不是说明一般情况下明星模式优于主治医师模式？

  19. 书中提到：PM通常也能写代码，能玩转Excel、PPT、Visio、甘特图，会PS，有文字功底，写的博客有人爱读，反正，总得有几招绝活吧！不用说还要有大量的阅读，对IT行业、用户心理、社会都要有广泛的了解。PM的能力要求太广泛了，那么做好一个初级PM的切入点是什么？

  20. 对场景的重要性如何排序？

  21. 一些bug可以被认为不予解决,会不会因此出现Bounce问题？

  22. 事后诸葛亮会议是用来探究发布后产生的问题，还是总结开发过程中的问题？

  23. 我们是否应该在单元测试中测试代码是否达到了性能上的要求？（尤其是时间性能）。

  24. 我们测试的时候应不应该使用真实的用户数据（不敏感数据）来进行测试？这一点在文中没有提到，使用真实的用户数据可以使得我们的程序更加贴近真实的运行环境，而且可以极大地减小我们花费在测试上的精力。比如我们写了一个统计人口各种信息的程序，测试的时候我们需要创建一些“不存在的人口数据”，这些数据极多，包含了住址、电话、姓名、政治状况等等信息，可能我们当当创建测试用的数据就要花费时间，更别提测试数据的质量如何。如果我们使用了真实数据，不能说我们不需要创建测试数据，但是我们可以只创建一些真实数据覆盖不到的地方，只创建一些边界数据等等。但是如果我们使用了真实的数据，测试中出现bug，那么在debug的过程中就必需要查看这个真实的数据，这样的话就容易造成用户数据的泄露，而且这哪怕不是敏感数据，似乎也会侵犯用户的隐私。市面上有很多的测试数据生成工具，比如datafaker，不过它的原理似乎也不是根据真实数据来构造数据的。

  25. 文中第4章代码风格规范中提到一个观点：注释应该只用ascii字符，不要使用中文或其他特殊字符。这一个观点我不认同，注释都使用英文等有可能反而会增加程序员理解的成本。我认为应该要根据具体情况来定。例如我们写的某一部分代码开发者都是中国人，而且这一部分代码是公司内部程序的主要逻辑代码，不能对外公开，那么使用中文注释会极大地降低理解成本，毕竟对于大多数中国人来说，肯定是对母语汉语的理解成本更小，日常的交流也使用中文交流。如果对英文不熟悉的人，很有可能会对某些注释产生误解，增加理解成本。而如果我们维护的是一个开源代码库，参与开源的开发者来自世界各个国家，我们代码的读者和使用者也来自世界各国，那么使用英文注释是最佳选择。我不知道现在主流开发者是否有使用英文注释的一些规约，这里引用一下阿里巴巴《java开发手册》2020嵩山版中的观点：24页第6点：【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。

  26. 关于第4章的结对编程部分，首先谈一谈我的理解，我认为这种方式处在单人编程和团队编程的中间地带，其兼具了两者的一些优点，同时也多了一些缺点。优点很明显，因为人数少，沟通成本较低，不需要考虑团队编程中沟通的问题（关于这一点文中也做了详细的说明）。而人数少不代表效率低，相较于单人编程，结对编程可以分工合作，产生1+1>2的效果。我的问题来自于文中的观点：结对编程是一个渐进的过程，一开始可能不比单独编程效率高，但是度过学习阶段后会有明显改善。那么我可以认为结对编程的一个关键是如何快速地度过有效阶段？关于这个问题文中也说了很多技巧（4.6节），但是这些技巧都是注重花费时间来培养两个人的默契，帮助更好地合作的。这就带来了结对编程的一个缺点：找到一个适合自己的伙伴不容易，相互之间培养默契度过学习阶段也需要时间，在这之前，可能效率不如单人分开编程。人数少的一个缺点是如果有人中途离开，那么很难在短时间内找到一个合适的替代者，毕竟他可能承担了50%的任务！我想知道有没有一些较为有效的方法能够快速度过学习阶段？如果结对的伙伴中途离开，或者中途换人，有没有有效的解决方法？现在的编程很难有两个人一直长期合作，培养默契需要时间，经常变换不利影响大，换人带来的后果比团队编程严重得多，我想知道现在开发者结对编程的多吗？

  27. 关于第9章项目经理的部分，提到微软PM负责开发和测试之外的所有事情，其中包括了产品市场定位、优化方向、和各方面沟通等等职责。关于这一部分，我有一个很大的疑问是他们是否也是一个多人组成的团体？他们是否也应该要有一个精细的分工？

  28. 在我的认知中，产品定位、市场发展的重要性远远高于软件的开发和测试，毕竟一个不符合主流、不符合需求的软件项目是不会被市场接受的，一旦因为产品定位的问题导致整个团队多个月的成果白费，责任在谁？

  29. 在一个10人以下的小团队中，PM负责了客户、开发者之间的沟通交流，还负责了项目开发流程的管理，总之是开发和测试之外的所有事情，如果因为某些原因，该PM中途离开，那么可能直接导致这个项目失败，毕竟PM可能就他一个人！相较而言，开发者的离开可以很快地找到下一位替代者，或者由其他开发者代劳，而PM的离开，导致短时间内开发者需要直面客户，可能之前所有沟通的成果都没有了，新来的PM并不能短时间内接上上一位PM的工作，而且新来的PM可能要更改工期的安排，又会打乱各方面的工作进度。我想知道，有没有比较好的办法可以降低更换PM所带来的坏处？比如更换了一个开发者，新的开发者只需要看懂需求文档等各种文档就能很好地上手工作，而更换了PM，可能会出现更严重的后果，比如新的PM可能认为之前做的工作不符合市场定位，要重做等等情况。

  30. 如果有小公司（比方叫A）创新发展出新的产品，在膨胀期或者迷茫期时大公司（比方叫B）中途插入开发一个类似的产品，用自己庞大的用户量来挤压A公司产品的空间，那么A公司该如何继续发展下去呢。如果长期如此，A公司花费心血研发出产品后反而大部分的收益被B收入囊中，A公司还能继续研发创新吗？（事实上也确实不缺乏此类例子，例如近几年大火的自走棋模式，原版刀塔自走棋在腾讯推出云顶之弈后，热度就开始一直持续下降）

  31. 在结对编程时，有时候伙伴的某方面的能力会不匹配，我记得在我一开始跟我们的小组进行人工智能课程的实践时，因为我在一开始忙着处理别的事情，在水平上没有跟上组内的一名成员，导致整个项目几乎没给他提供帮忙。个人疑问：如果在结对编程时出现这种情况，是不是应该先让两名成员在项目所要用到的知识水平上处于一个相对平等的状态。然后如果两个对于一个问题起了争执变成了谁嗓门大谁说了算该怎么办。

  32. 在技能的反面这门课的内容里，作者认为精通一个技能是要做到知其所以然，并且做到创新，并用魔方做了个例子。个人理解：但是比如三阶魔方目前的世界排名第一杜宇生，他也能在四秒内复原一个魔方，但是也是使用的大家都会用的公式，只是他在观察能力和手眼协调能力远超他人，我觉得即使他没有创新，也可以称之为精通魔方了。又比如nba的退役巨星蒂姆邓肯，被称之为大基本功的代言人，虽然也没有开创什么新技术，但是他对比赛的影响力也是十分巨大，我想这时候他也可以被认为是精通篮球了。

  33. 软件工程 之 动物世界这一篇文章中提到鹦鹉是一种围观的态度，虽然可能会提出一些点子，但是鹦鹉是不会去执行的，他们只会提出一些云观点做一些空谈，总结起来就是一阵口嗨。但是如果项目没有开发好，他们又会立马跑到别的项目去，仿佛公园里围观下棋的大爷。个人理解：在我看来这类人对于团队的项目进展没有任何帮助，反而他五花八门的思想还可能拖累开发速度，如果在团队中发现这类人，是不是应该采取一些措施，例如将他踢出，或者对他做做思想工作。

  34. 在这个内卷化日益严重的年代我们是否要跟着一起内卷？当初选择软件工程的原因是因为兴趣，但是为了未来的工作，我现在也需要和别人一起内卷，但是这样我选择软件工程的初衷也没了，可以预见的是这样内卷下去，我的激情会消耗殆尽，而且甚至因为996，007工作的原因而进入不健康的状态。

  35. 正如书中所说绝大部分软件工程师都不是技术天才，那么我们应该如何选择自己的发展方向，或者说如何发现自己在软件工程中的长处

  36. 如何解决课外实践与课内学习的冲突？我们如何划分课内学习的时间和课外实践的实践，有时候课外实践占用的实践太多影响到了课内学习，我们应该如何把握？如果实践太少的话，毕业出去就被卷没了，如果太多的话，我们的基础知识就不牢靠了，基础知识是我们以后发展的根基也不能轻易忽视。

  37. 现在有那么多种语言，我们如何选择一种语言作为自己的主攻方向？想要做到文章说的大脑自动操作，这无疑是需要大量的时间和实践，而到现在为止我接触到的语言有python,php,java,go,c,c++,c#,js,shell,powershell,bat,vb,ruby，而这些语言我都无法做到大脑自动操作，总是这个学学那个学学，不知道以哪个为重点，有时要求这个，有时要求那个，那么我们如何选择一门语言作为自己的主攻方向。

  38. 我们如何才能进入团队，而不是被当成完成工作就领钱的乌合之众？我在网上看的一些帖子，很多时候都体现了与公司对立的情绪，很多人都说公司不把程序员当人看，996，007压榨，严重的甚至有一些人选择了轻生或者是猝死了，我们在未来找工作的时候无疑会遇到这样的公司，那么我们如何鉴别出他们呢，如何知道他们团队的工作氛围，公司内部真的是一个团队一起工作学习吗？

  39. 为什么有工作经验的软件工程师比学生在“需求分析”和“测试”上所花的时间多，但编码时间短？我们应当怎么去安排“需求分析”、“测试”和“开发”的时间呢？

  40. 怎么才能避免“为了自己的角色而做绩效优化”？

  41. 产品经理要不要懂技术？众所周知，产品经理的主要任务是：有自己的产品思维，具备出色的判断力，形成自己的商业分析逻辑，能够帮公司赚钱(或具备这个意识)，有获取新用户的意识。产品经理花时间在技术上到底值不值呢？

  42. 设计产品时是否需要考虑不直接给企业带来利润的用户的体验？对于浏览者在网上浏览、比较货物、但并不购买，这种不直接带来利益，但有极大可能成为企业用户的用户在设计时是否需要考虑其需求？（放在Stone网中可能就是考虑未登录能否浏览商品等等）

  43. 什么样的软件工程作业才叫好作业？

  44. P33 为什么使用了int count=m_wordList.Count 后System.Collection.ArrayList.get_Count的调用次数和实践都大幅度减少

  45. P51 瓦茨总结说，软件领域分为技艺创新的大爆发和坚持不懈的工程工作，而其中工程工作占了90%-95%的比例，那么剩下的技艺创新具体体现在哪些方面呢？怎么看出来有技艺创新？

  46. P65 程序设计进行到一半，发现自己原来设计中存在弱点，要解决这个弱点才能避免额外工作，但是如果现在改变设计，会不会让公司、同事以为自己能力不行？

  47. P86 结对编程虽然能够不间断地复审，使代码质量提高，但是编写效率明显下降，要怎么比较质量和时间哪个更重要？怎么能够看出项目是结对编程更好还是个人编程更好？

  48. P117 当自己想认领某个任务时，发现自己不具备足够的知识去完成这个任务，而团队里面其他成员对这个任务不感兴趣时，该怎么办？有些人认领的多，有些人认领的少，忙闲不均怎么办？

  49. P142 高质量的代码在当用户改变了需求，并且这个需求非常模糊时，是否要舍弃掉之前的高质量代码，选择重新编写？

  50. 结对编程两人水平相差较大应该怎么协调？

  51. 团队模式会因为哪些因素而发生变化？

  52. 长期使用但逐渐厌弃该软件，这是用户的问题还是开发团队的问题？

  53. 在角色-PM这小节，有个标题“PM做开发和测试之外的所有事情”，之前也学了一点和产品有关的知识，发现PM至少要学会Axture、墨刀等这些软件来画产品原型图。除此之外，和程序员的沟通交流也十分重要，也有过这样的疑惑：对PM来说，开发和测试并不是硬性要求对吗？

  54. 本书第4章“两人合作”中介绍到：代码复审核查表的其中一项内容是“代码容易维护么？”因为容易是个相对的概念，于是产生了这样的疑问“代码的容易维护是站在复审人员认为的容易还是代码达到了团队规定的编译警告等级”？

  55. 讲义中将代码量比作树叶量，“代码量等于树叶量，当作如是观。 ”，那么，是否代码量越多，该程序员能力就越强？

  56. 为什么要进行单元测试？

  57. 书中第17章第4小结提出了一个萝卜与白菜的问题。大致对比了两种开发风格：一种是“萝卜快了不洗泥”，开发速度很快，但bug量惊人的萝卜类型；另一种是“慢工出细活”，速度较慢，但能赶上截止时间且功能稳定，bug量少的白菜类型。究竟哪一种类型的开发者更受青睐？

  58. 书中关于“代码复审”的章节有提到：鼓励不同职责的成员交叉相互进行代码复审，有利于相互学习。但如今大部分项目开发都奉行前后端分离的模式，各自专注自己精进的部分，甚至存在前端开发者不懂后端语言、后端开发者不懂前端语言的情况。这种团队协作的执行成本和对开发者的要求是否过高？

  59. 似乎大多数人都对官僚主义嗤之以鼻。而书中第5章第2节列举的十几种软件团队模式中，官僚模式格外显眼。软件开发团队中是否也存在官僚主义？这种官僚主义是否与在行政机关里很常见的官僚主义有本质上的区别？如何避免团队向官僚模式发展？

  60. 书中第3章第1节用足球运动员类比软件开发工程师。除了体能、技术、意识、配合、临场应变等专业领域的品质外，还需要良好的沟通能力。那么软件开发工程师除了必备的专业知识和技能以外，还需要具备哪些良好的品质呢？

  61. 计算机硬件的能力在快速发展，为何服从硬件的软件却没有提速？

  62. 一个工程师具有绘制完整UML图的能力，那么他是否具备对通用的软件设计思想的理解？

  63. 结对编程双方水平上的差距，不会导致决策权力偏向一方吗？

  64. 我看了书中p363的这段文字：

螳臂当车
在游戏中，经常有一两个同学逆历史潮流，提交一个99.999之类的分数。但是从大趋势来看，这些捣乱分子对大局影响不大。我经常看到几个同学面带微笑小声商量，一起提交几个最高分来搅局，但是G-number还是由大多数人决定。

作者的文字对搅局的同学带有贬义，但从另一个角度看，搅局的同学试图打破现状，实现颠覆性的创新。就好像对于电报来说，电话的出现是一种搅局；对于传统的制造业来说，机器的出现也是一种搅局。这种从传统的收敛于0的结果中跳脱出来的思维方式，难道不是创新者应该具备的吗？

  1. 我看了书中p363的这段文字：

赢者通吃
这个游戏规定第一名得到全部的分数，第二名（不管多接近）到倒数第二名都是0分，最后一名还要倒扣分。软件行业就是一个赢者通吃的环境，最后一名还要把自己的身价倒贴进去。

有这个问题：软件行业真的是一个赢者通吃的环境吗？赢者通吃，也就是所谓的垄断。举个最近的例子：华为开发的鸿蒙系统有望打破安卓系统的垄断。与其说软件行业是一个赢者通吃的环境，但所谓的赢者还会遭到后进者的打击。我更认为软件行业是一个不断创新迭代的环境。

  1. 文中说到：

“70% 的创新者说, 他们最成功的创新, 是在他们的拿手领域之外发现的。”，

虽然文章中举了些例子，但我对这个比例还是有疑问。按我个人的经验，一个外行人如何能在其他领域创新呢，在某领域创新难道不需要精通这些行业的知识吗？就算真的出于某些偶然的因素，他做到了，但这个比例也不应该是70%啊，难道大部分创新都是偶然？鉴于个人观点的片面性，我就这句话百度到了几篇相关文章博文，其中有赞同的，也有反对的。但并没有直接证据说明这句话的对错。

  1. 创新的时机跟黄金点游戏有关联吗？我看了《创新的时机 – 黄金点游戏》这篇博文，博文中邹老师谈到了黄金点游戏以及对这个游戏的几点领悟，但是我觉得跟创新的时机没什么关系。关于时机，“只先一步”部分有这样一段话：“那些成功的企业只是比大众的平均值先走了一小步（平均值 * 0.618）, 就是这一小步, 让大部分人看到了产品的“相对优势”从而接受产品。关于技术创新, 一些趋势（例如社会网络），大家早就看到了, 也有一些产品推出, 但是往往最后成功的产品成功在时机上。”，“Technology Hype Cycle”部分也提到：“说到时机, 任何新技术都有一个自身发展的规律，Gartner 的Jackie Fenn 写了一个很有意思的报告, 提到了Technology Hype Cycle。”我对这两部分的理解总结为：新产品在合适的时机推出才能获取成功，此前这个产品可能经历了几个发展换代阶段。但我觉得创新是创造新产品，创新的时机肯定是领先于产品推出的时机，正如文中说的：“做前沿研究的人, 可以早于其他人很多年提出新想法, 但是这些想法一般都是在“Innovator” 那个圈子里有影响, 这些想法要等若干年才能由成功的企业家看准时机推向大众市场。”，所以我认为黄金点游戏是跟推出新产品的时机有关联而不是创新的时机。

  2. 软件创新的出路真的是“走进作坊”？邹老师在《软件工程讲义 9 创新的出路 走进作坊》中对于软件创新的出路提出了“走进作坊”的观点。原文中有这样一句话：“这些好的作坊, 都有这些核心特性: 从小事做起, 讲究质量, 信用, 对产品负责, 对工作自豪。”，我学识有限，对这篇文章笼统地理解为：创新的出路是作坊是因为好的作坊有匠人精神。感觉我的怀疑没什么依据，要说源头大概就是如原文中说的“哪里都有盗版, 哪里都有抄袭, 哪里都有竞争”，上网去搜索出路什么的大部分都是讲创新是出路，缺少实践的东西。只能说直觉告诉我走进作坊不错，但实际操作起来把它当做创新的出路真的可行吗，是不是大家一起“走进作坊”，我国软件业的创新就能搞起来了呢？

  3. 如何应对“主治医师模式”? 我读了《团队和流程》这篇博文，里面谈到了几种团队模式和软件开发模式。原文中有这样一段话：‘主治医师模式的退化: 在一些学校里, 软件工程的团队模式往往退化为“一个学生干活, 其余学生跟着打酱油。”’，即将面临软件工程实践课的组队，由于能力、性格的不同难免会形成各种团队模式。如果我有幸遇到这种模式，估计就是一打酱油的。所以一个团队如果能干活人的较少，但是为了项目能够进行下去，应该怎么做？

  4. 什么是单元测试的自动化? 读过《单元测试&回归测试》这篇博文，谈到了单元测试的自动化。原文是这样的:“另一个重要的措施是要把单元测试自动化，这样每个人都能很容易地运行它，并且可以使单元测试每天都运行。每个人都可以随时在自己的机器上运行。团队一般是在每日构建中运行单元测试的，这样每个单元测试的错误就能及时被发现并得到修改。”，虽然这次作业大概走了一遍单元测试流程，我还是想弱弱地问一句，比如VS上新建单元测试项目，编写好单元测试运行，是不是就算单元测试自动化了？

  5. 我看了第3章3.1里的“c.质量如何？”部分和“d.是否按时交付？”部分，产生了这个问题：一个软件产品质量的好坏，软件工程师们的技术水平和软件交付期限都是很重要的因素。但如何在软件交付期限内充分发挥软件工程师的水平和价值？首先是对项目的用时估计，但估计就会有偏差，那么就有可能出现一个情况：项目的前90%都是按照A级标准在开发，可是这时突然遇到一个难点，整个团队的人都没法解决，拖延了一段时间，这时考虑到交付期限，只能按照B级标准降级开发，满足基本需求的基础上尽量降低开发质量，最后呈现的结果可能就好比是科尼塞克车身即将完成后发现卡钳生产遇到困难，最后用了次级质量的卡钳去代替，结果顾客反映车子速度可以很快但是制动效果不好，安全性不足，影响了用户的体验，最终导致口碑下降，销量下滑。受按时交付的影响，团队必须在限定时间内做好产品，那么产品开发前的估计就尤为重要，完全按照B级做可能就没法发挥团队水平，无法吸引更多客户与其合作，按A级做又可能存在预估时无法估计到的困难，这实际上是一场冒险，是一个如何平衡开发水平和开发时间的问题。查了资料，大部分说法是追求交付时间内保守开发。有的项目可以先B级，然后有时间慢慢继续改进；但有的项目做不到，因为从底层开始设计就大相径庭，回溯修改极其困难。根据我的作业经历，我是按照交付时间内保守开发的路子在做，因为作业的难度和体量与实际开发项目差距颇大，很多地方量变引起质变，不好直接类推，所以我对实际开发项目的此方面问题有些许疑问。

  6. 我看了第4章4.5.3“同时，结对编程避免了‘我的代码’还是‘他的代码’的问题，使得代码的责任不属于某个人，而是属于两个人，进而属于整个团队，这样能够帮助团队成员建立集体拥有代码的意识，在一定程度上避免了个人英雄主义。”部分，产生了这个问题：文中提到，结对编程会起到互相督促，互给压力的效果。但我想可能存在一种情况：某个人与团队内编程能力最好的那个人结对编程，那么这个人会不会因为和高手搭档，就形成依赖而不是激起自己的好强心态。自己编程的时候想着反正有大佬在复审，就没有那么投入，也没有那么苛求细节，如此一来，出Bug的数量和概率肯定会上升。而且大佬的操作甚至让这个人复审不知从何下手。查了资料，有如下说法：和实力相近的人结对编程可以解决这个问题。按照我的实践经验，此举确实可以避免上述问题出现。但我又想，这好比一个班级里作业得分最高的双人组和最低的双人组，一个团队中的人实力水平差距是必然存在的，如果说按照水平两两结对编程，避免了上述情况，但此时最强的那组和最弱的那组之间的差距就会被数倍扩大，那么同一个产品的两个模块之间可能就会存在极大的质量差距，显然不是我们想要的结果，那又如何解决这个问题呢？

  7. 我看了第5章5.3.6 MVP和MBP，产生了如下问题：条件允许的情况下，MBP显然看起来比MVP更加具有吸引力，也更能一举征服用户。从我个人观点来说：MVP模式大部分是受委托进行合作的商业开发模式，而MBP则更多是创业者追求的模式。他们最大的区别在于MBP往往需要更多的时间和更好的技术团队，以及对用户需求的更精确定位。那我是否可以理解为MBP模式是MVP模式的进化和升级？MVP模式是MBP模式的跳板还是说这只是两种不同的开发模式，之间并无太多的进化关系？假设是跳板，那么就是多次MVP累计经验进行MBP，但此时或许早就过了最佳的市场抢占时期，往往都是创造性的挑战MBP产品才能形成创新，在市场中鹤立鸡群。那么它们之间的到底是否存在进化与升级关系？查了资料，并未得到一些能对我的疑问有所帮助的回答。根据我的学习实践，我的经验是：同等时间内MBP模式或者MVP模式的选择取决于个人的编程开发水平，有的同学只能完成仅满足最低需求的编程作业，但编程能力强的学生可以将编程作业做到十分完整的地步。但这情况与实际商业开发有所不同，也就是目前的实践学习经验并不能解决我的疑惑。

  8. 我看了第9章9.3中“在一个项目中，PM的具体任务是：”这一部分内容。产生了这个问题：对于PM的选择，是用更偏向市场的PM还是用更偏向技术的PM会比较好？按照书中描述，PM的任务大概是作为开发人员和用户之间的桥梁，并带领开发团队完成任务。如若是偏向市场的PM，可能在获取客户需求方面会做得更好；若是偏向技术的PM，他会更好的将客户需求转换为开发团队的具体任务。当然可以说，找两者平衡的PM，但也许事实上，既有强大的市场敏锐度又有精锐的开发技术的PM毕竟还是少数。查阅资料：大部分说看具体的项目类型以及面向的用户群体而定。我感觉这种说法过于空泛，具体如何通过判断项目类型以及用户类型来选择PM我还有疑问。

  9. 第二章P34页开始提到了PSP个人开发流程，我们这次作业也有要求用PSP表格记录自己估计将在程序的各个模块的开发上耗费的时间。但是我在估计时间的时候感觉力不从心，不知道该怎么估计，最终也和实际耗费时间相差甚大。要怎么才能更好地估计自己估计将在程序的各个模块的开发上耗费的时间呢？我目前的观点是随着自己个人能力的提升和经验的积累会对估计有所帮助。

  10. “我们是预期变化,不是期望变化”这一句话我没能理解。对于前半句中的“我们是预期变化”，我的理解是我们要未雨绸缪，通过不断提高自己的能力来应对未知的变化。但是后半句中“不是期望变化”我没看懂，这里期望的是什么变化？

  11. 书中说到：

大牛:最近业界有人总结，项目需求的生存期是18个月，就是说如果一个项目的需求是18个月前确定的，而产品还没有做出来，那几乎就可以不做了，因为需求肯定已经发生了很大变化。大家有没有注意到微软的一些成功项目的各个版本之间也是间隔18一24个月。现在软件开发的重心从桌面软件移到了互联网软件和服务,项目的版本更新就更频繁了。

“项目需求的生存期是18个月”所说的项目是否更多的适用于对那些已经投入使用的产品的更新的项目？那些未开发出来的项目，比如某款游戏的开发，我认为“18个月的生存期”应该不太能适用。

  1. 书中提到：

第十二章P266页开始，提到了在用户体验方面要不让用户犯简单的错误。书中举了飞机上的遥控器：“左上角:呼叫乘务员，右上角:取消呼叫，下方:阅读灯。可以想象,在长途飞行、照明不足的情况下，乘客很容易按错。据报道，很多乘客为了避免误按[呼叫]按钮,干脆连阅读灯也不想开了。” ；手术室中的两根输液管：“在医院手术室里，麻醉师在给病人实施麻醉的过程中会用到不同的输液药品，有两个管子一模一样，但用途截然不同,这成为不少医疗事故的问题根源所在。” 等例子。

那在软件开发中，要怎么做到尽量避免让用户犯简单的错误？又还有哪些用户犯简单的错误的例子呢？我的观点是异常处理就是一个这方面很好的例子。

  1. 书中提到：

第十六章P356页，成功的团队更能创新吗？书里提到1.成功的企业要满足股东们的巨大期望值。2.成功的公司有价值观——追逐利润。3.成功的公司有流程。4.成功的公司重视用户。5.成功的团队有老大心理。

可是我觉得成功的企业拥有更多资金、资源，这些可以给创新带来非常有利的条件。成功的企业也更容易招聘到高端人才，而人才是第一资源。有了这些条件，成功的企业应该是更有创新能力的。然而小企业创新资金不足、人才短缺的风险应该会更大，企业创新本身我觉得也是很冒险的。

在网上搜了一些观点：

大企业创新能力优势强：原因在于因为大型企业的品牌号召力、市场的拓宽能力、和人脉能力资源能力。比小型企业有更大的发展空间。故此创新的能力强。
大企业吸引的人才更多，有思想有创新的人才也就更多，但是受限于一些大企业传统的发展模式，创新程度不一定比得上某些小公司。
小型企业创新能力优势强：原因在于它与大型企业创新的不同是大企业结构和模式固定单一不易轻易改变。而小型企业反之亦然，创新价值高、模式可多样变化。

很明显众说纷纭，所以想知道现实到底是大企业还是小企业更能创新？

  1. 大多数人的思维方式是不一样的，一个问题解决也有多个解决方法，两个人结对编程过程中自己在解决问题，同时也在看对方解决问题，思维在自己和对方的解题思路中不断跳跃，这样花费的时间不会更多吗？怎样才能找到适合结对编程的搭档呢？怎么和搭在合作中达到1+1>2的效果呢？关于如何结对编程有相关的理论方法吗？比如如何达到高效合作。
  2. 书中介绍了很多开发流程的方式比如：写了再改、瀑布模型、瀑布的各种变形等。问题：一个刚组成的软件开发团队，彼此都还不是很了解，如何选择适合的开发流程呢？这几种开发方式有比较低风险的吗？如果在团队合作过程中，发现一开始的方式有问题，但内部的调动又会消耗大量的精力，这值得半途换开发流程模式吗？
  3. 文中写道“自己最喜欢的一个项目是微软学术搜索，尽管许多用户觉得它的UI不错，它仍有很多可以改进的地方，一个叫西乔的同学就给提出了下面的建议：建议采用不同的样式，将submit按钮突出，Cancel按钮样式弱化，降低用户丢失操作的可能性。”我联想到，如果存在这样希望降低用户损失（但不是很大的影响）更改界面，但是会使界面变得不美观的情况，应当如何选择？
  4. 那在实际项目中，整个团队在每个阶段的时间怎么分配才合理呢？哪个阶段的时间应该花最多的时间和精力。
  5. 团队里出现‘不做事’、‘不让别人做事’等之类的人，应该怎么办呢，是耐心的沟通交流，还是粗暴的踢出。
  6. 创新真的要顾及到一部分人的利益吗？我感到很困惑，书中提到了很多人都讨厌创新，因为这可能会影响到其他大部分人甚至自己的利益，可是，如果不创新，怎么能开发出新的市场？我觉得这样顾此失彼的做法是有待商榷的。
  7. 如何实现单元测试的自动化？这一次的作业中使用到了单元测试，可是我对单元测试还是不太了解，文中提到测试最好使用自动化，可自动化是什么呢？和自己手动测试有什么比较大的不同呢？
  8. 什么阶段最适合“效能提高”？

34页：“大家也要注意避免没有做分析就过早地进行“效能提高”，如果我们不经分析就盲目优化，也许会事倍功半。”

书中说到如果太早的进行“效能提高”，可能会导致盲目话，可我认为如果不能再最开始就进行一个完善的算法思考，最后进行提高的话不仅会增加工作量，而且会导致大规模的代码变动，这样难道会更合理吗？

  1. 是否在项目正式启动前确定代码风格？每个程序员都有属于自己的代码规范，那么在集体编程的时候，是应该按照一个统一的代码规范来编程，还是按照自己认为正确的代码规范来编程呢？
  2. 一个对算法熟悉的程序员和一个对算法一知半解的程序员差别有多大？
  3. 如何避免自己成为鹦鹉？

有些人是 鹦鹉 - 他们有漂亮的羽毛, 能说会道, 联系广泛, 能提出很多建议, 很多点子. 但是他们
不执行, 除了一些人云亦云的观点和一些关于架构的空谈之外, 他们没有其他投入. 一旦项目失败, 他们就会
飞到另一个项目中去。 他们的投入级别是 – 围观 (bystander).

  1. 遇到技术上的困难时，应该自己解决，还是应该去问别人？
  2. 不同用户需求矛盾时如何处理？对于一个程序某个功能，有的人认为是bug，影响个人使用，有的人认为这个功能不错。如何取舍呢，根据用户比例吗？
  3. 敏捷流程发生人员变动怎么办？一个团队自然会碰到离职，请假等，敏捷流程要求“冲刺”，但人员变动影响原来任务的分配，其次，缺人手后新人加入也会带来问题，给其他人带来压力，这种情况下如何“冲刺”呢?
  4. 每次软件版本更迭都需要需求分析吗？随着软件的不断发展，用户量不断增加，当这个软件越来越大后，用户好像离不开这个软件（竞争者都被干掉了）。软件的发展似乎不再需要用户提什么需求，而是软件想给用户什么功能，用户只能“自己承受”。 需求分析随着软件发展成熟后还有必要吗？现在许多app功能越来越多，偏离了最初的目的，如何看待这种情况？
  5. PM与团队平等相处是幻想还是可以实现？在产品设计过程中可能会发生许多分歧，谁也说服不了谁，这样是不是反而影响效率？表格中一个团队可能有多个PM，这些PM发生分歧又该如何解决？如果出现一个PM有了决定权，那么是不是就无法平等讨论？
  6. 测试人员在什么时候进行测试？书本上说测试人员进行测试几个模块之间的联系，具体时间如何确定呢？开发人员利用单元测试进行测试基础功能，如果测试人员也要进行测试，开发人员能否不再进行单元测试，把工作都丢给测试人员。如果测试人员等到开发后期进行测试，则可能导致整个程序改动。如何确定测试人员开始测试的时期呢？
  7. 在第五章团队中的角色和合作中提到“开发项目的时候才觉得实际情况和书上讲的都有一些出入，偏偏一些重要的出入书上没有提。我们很多人是边看asp.net的书, 边开发asp.net的项目，这相当于一边看医学书一边动手术。”在我看来这个是初期项目开发者都会遇到的问题，其实在一定程度上确实影响了自身的开发效率，那面对这样的情况应该要怎么处理呢？
  8. 在第五章的团队不同的投入中作者提到团队中有一类人为鹦鹉：“他们有漂亮的羽毛,，能说会道，联系广泛，能提出很多建议，很多点子但是他们不执行,除了一些人云亦云的观点和一些关于架构的空谈之外，他们没有其他投入，一旦项目失败, 他们就会飞到另一个项目中去。”这种类型在团队其实是很影响队员效率的，那应不应该适当的提醒她呢？或者应该怎么处理这样的情况呢？
  9. 在第九章创新方面作者提到了两种如何在一个创新性的市场上后来居上的观点，分别是“改变游戏规则”和“转换目标用户”。其实我认为“居上”最多也就是几乎齐头并进，但是还是无法超越之前的产品，这样的想法是否正确呢？对于这个观点，我觉得最好的例子就是拼多多的崛起，在淘宝已经占据了绝大部分市场份额的时候，拼多多以一个“砍一刀”的规则重新进入了大众的视野，同时商品定位比较亲民，他利用了大众心理制定的政策，果不其然，确实很成功。同时，在后续的使用过程中我们也先后发现了其他app也出现过类似的板块。这其实就正好契合作者所提到的这两个创新的办法，但是在市场上看淘宝还是大部分用户的第一选择，因为前者可以向新的创意学习，可能两者的起点就是不同，但是不可否定的是拼多多的创新确实做的很成功。
  10. 在第七章设计阶段分析中作者提到对于需求分析不应该条条框框的完成需求内的要求，但是也不可以一味追求“最大的扩展性”。所以在需求分析和设计的时候我们应该保留什么样的弹性呢？
  11. 在七章开发阶段的日常管理中作者提到“要尽量减少非开发时间，不要动不动就开“全体会议”。团队成员们自我时间管理也很重要。”这个全体会议其实是很经典的问题，感觉其实当团队积极参与度不高的时候，全体会议就显得很没有效率，但是有时候又是必要的需要告知大家，或者希望大家参与讨论，应该怎么处理呢？
  12. 事后诸葛亮会议是对整个项目的回顾，总结经验教训，但是一些公司里人员流动大，去去留留一个项目能换几茬人，那么事后诸葛亮会议还有意义吗？会不会变成甩锅大会呢？
  13. 结对编程的好处书中已经详细描述了，那结对编程的不足之处呢？结对编程在现实生活中国内的公司似乎很少采用，是有什么局限吗？
  14. 典型用户是指，按不同维度来区分用户的过程中，在每个维度中能代表目标用户的那类群体。比如，按人数多少来划分的，能代表最多用户特征的群体；按盈利来划分，能代表带来最多盈利价值特征的群体。但是典型用户的定义和删除让我觉得非常奇怪，典型用户在何种情况下需要进行删除呢？
  15. 第三章提到过早扩大化/泛化会使整个软件变得四不像最后只能让后人来完善，怎样才能避免陷入这种误区，又应该在什么阶段对软件进行扩大化/泛化，使得程序更加完善？
  16. 第四章提到结对编程使用同一机器一同完成工作，那么应该如何根据各自的特长分配两个人的任务范围以取得更高的投入产出比？
  17. 第五章中提到为解决瀑布模型的问题提出了生鱼片模型和大瀑布带着小瀑布模型，分别有什么优缺点，这两种模型分别适应与哪种开发场景？
  18. 第六章中提到Scrum/Sprint能成功实施的关键在于Scrum Master，那么应该如何判断一个人能否胜任Scrum Master的工作？
  19. 第九章介绍的PM对团队起着重要作用，但应该如何处理好与团队成员的关系，了解成员的状态，合理分配工作来提高项目的完成效率何工作质量？
  20. 面对庞大而又零碎的需求，是如何从中化繁为简，捋顺思路，将各个需求串起来已进行功能的实现的呢？
  21. 那么作为团队中的一员，如何快速的找到自己的定位，完成自己可以胜任的任务呢，并且作为初入职场的新手程序员，如何让正确而又全面的向领导展现自己能力呢？
  22. 假如作为一个个人开发者，考虑的测试情况总是有限的，有什么办法可以帮助我们拓宽自己对软件可用性测试的思维呢？
  23. 有着各自的见解，无法迅速的达到统一，所以请问在这种情况下到底应该如何达成一样的意见，团队又应该如何去沟通交流思想呢？
  24. 我有个疑问，例如现在的某手机支付软件，为了利润投加了很多影响用户观感的广告，经常在使用的时候会无奈地误触到，作为用户我感觉软件的使用不够清爽，而反观某b视频软件，在广告以及一些不影响软件主要播放功能的小功能方面安排的很好，请问作为程序员在接受了用户这样的体验反馈后会做出如何的调整呢，如何在软件收益和软件使用体验之间做出均衡呢？
  25. 书中提到：

《构建之法》3.2 软件工程师的思维误区
“不分主次，想解决所有依赖问题：想马上动手解决所有主要问题和次要问题，而不是根据现有条件找到一个足够好的方案”

疑问&思考🤔：
我们在编写代码的时候确实会遇到一个问题，但是因为代码都是有相关联性的，所以往往会牵扯出一链子的问题。那么这时候难道不是顺着这条思路去改代码吗？什么叫做根据现有条件找到一个足够好的方法呢？
就还是以作者举的小飞的例子，小飞本来要去自习，发现自行车没气去借打气筒，借打气筒要送围巾，就开始织围巾。确实这个结果偏离了最开始的计划，或许最开始小飞发现自行车没气决定走路去自习是不是作者认为的足够好的方法呢？
那么我的问题和思考归结于是不是要评估这个问题所依赖的一链子问题是不是过于复杂？对于不复杂的例子就可以马上动手顺着思路去解决，对于复杂的问题就先放着，看看有没有更快捷的方法？

  1. 阅读《构建之法》第一次知道结对编程，感觉结对编程这种形式对我来很新颖，两个人一起写一个代码工作量直接减少一半欸:)，但我觉得也有些局限。首先结对的两个人水平相差怎么样，一个人很牛一个人相对的菜。会不会导致牛人写的时候，另一个人看的时候觉得“哇，牛，这个好，写的好快，性能也好...”。等到这个人写的时候，厉害的人在旁边看的觉得这不行这不对，开始指导最后恨不得自己把键盘鼠标抢过来。那么对于结对编程的人是不是要有一个基本的水平要求？
  2. 通过对第九章的阅读了解了PM，同时知道PM需要的能力很多。我在网络上收集了一下PM需要的基本技能：
    1.研发/测试 2.运营3.设计4.市场5.职能部门6.其他技能比如word、excel、ppt等基础技能还要有思维、管理、沟通能力7.产品，熟悉高效的产品工具：Auxre、墨刀、Xmind、ProcessON7.多关注各网站和APP。多看行业报告和商业计划书，多看别人的产品。
    那么PM是由程序员逐渐去往PM培养成长起来的呢还是一开始的职业目标就向PM方向发展？比如软件工程的大学生发现对于写代码开发不怎么感冒，能不能就轻于写代码开发，而尽早去点亮作为PM的技能树呢？
  3. 书中认为测试人员测试的软件功能100%符合要求，测试人员也都按照SPEC去测试。但是如果用户恨你的软件，那么就说明是测试人员的责任。我想请问的是这里是不是把测试人员的责任看的太大，首先我认同作者的好的测试人员要做易用性测试，去站在用户的角度考虑，但是我也考虑到用户在运用软件发现有问题或者不好的地方，是不是说明这个软件的需求分析之类的做的不够好，而不是去指责测试的不到位。像易用性测试这样的更像是一个附加的测试条件，有点像之前提到的Ad hoc Test。比如之前的微信，我们很经常会用微信打开别人分享的链接，之后在链接里看到另一篇文章也不错，再打开看看，然后就在微信里面开始循环的浏览信息。这个时候突然有一条微信进来，我要去看看。结果回复完信息之后找不到之前循环浏览的网页了。这是我之前使用微信的一个痛点，但是惊喜的是后来微信增加了一个float window的功能，就解决了这个问题。请问这样的是测试的责任吗？
  4. 单元测试应该是可重复的，用随机数去单元测试不好，又提到也要用随机数出去增加测试真实性，但不是在单元测试中，那请问是在什么时候用随机数去测试呢？在这个部分我也有上网搜索，但是结果都是程序中含有随机数生成器怎么进行单元测试，并没有对于什么时候可以使用随机数去测试的解答。
  5. 一个软件如果仅仅用于一时演示而没有投入全面应用。甚至在演示之后基本就不会再继续使用了，那么这些程序在开发的过程中还有必要严格按照常规的开发流程吗？
  6. 简单说明故事是否会缺少用户体验的细节，然而如果要让故事说明得完整又细节，是否会将故事写的缺少简明性，那么要如何把握故事的细节？在之前设计用例时，我使用UML图形来分析的次数比较多，而文字内容较少，故事有哪些图形不具备的优势吗？
  7. 只把最重要的功能醒目地展示出来，的确可以让产品看起来一目了然，用户上手的难度也降低了。我的疑问是那些介于无关紧要和最重要之间的，没那么重要的功能应该放在哪里比较合适呢？
  8. 书中提到：

“在产品达到引爆点之前，不宜过早考虑变现，同时，不宜受产品现有变现模式的束缚，而要把重点放在用户满意度和用户增长率上。”

看了这句话之后，我对其中提到的“引爆点”概念的定义并不清楚。我在维基百科中，查阅到关于引爆点（Tipping Point）的定义：“系统发展到一定程度会产生飞跃性的变化，但转捩点更隐含意思于一系列大型事件、大型系统的发展，这种改变在表面或外在方面来看可能明显也不一定很明显。”查阅百科后我对“引爆点”的概念还是有些模糊。一个产品在什么时候到达引爆点，又可以通过哪些指标判断呢？

  1. 书中提到：

“在用户中招募粉丝，让粉丝有参与感并整合到市场推广中。在这一阶段要首先培养用户的忠诚度，然后再考虑品牌的知名度。”

我也十分赞同这个观点，我认为先着手用户的忠诚度可以通过粉丝的用户体验来完善产品，此外粉丝用户也能在产品发布之初缺少宣传的时候对各自的亲友宣传推荐，在产品有不足的时候及时反馈。可是在软件开发之初就可以确定自己潜在的忠实用户吗，实际市场中有什么策略可以有效地招募粉丝、培养忠实用户并提高用户忠诚度呢？

  1. 如何终止“分析麻痹”？

P52 3.2 分析麻痹:一种极端情况是想弄清楚所有细节、所有依赖关系之后再动手，心理上过于悲观,不想修复问题，出了问题都赖在相关问题上。分析太多，腿都麻了，没法起步前进，故得名“分析麻痹"( Analysis Paralysis )。

当出现一个问题的时候，我们当然会去分析导致这个问题出现的原因，而这个问题的出现也确实是存在着其他依赖问题，比如书中举的例子：木桶出现了洞需要粗绳堵，但是粗绳太长需要刀砍断······但是这些也都是真实存在，需要解决的问题。我的疑惑是，我们在分析问题的时候需要分析到哪一种程度停下来实施，才能避免“分析麻痹”？

  1. 软件工程师的职业生涯真的就会终止在35岁吗？

P55 3.3 软件工程师的职业发展 2. 工作（Job） 这些人经常会问“软件开发做到35岁以后怎么办”这样的问题。很多中国IT人士认为这个年龄是程序员的职业终点。

这个问题也是现在非常困扰我的一个职业规划方面的问题。在我上网查找的相关言论中，非常多的人都认为35岁就是一个程序员的终结，原因有很多，比如身体原因、脑力的退化以及有能力的新人的涌现等等。我的疑惑是，软件工程师的职业生涯真的就会终止在35岁吗？我们应该如何规划35岁以后的职业生涯？

  1. 用户体验和质量要怎么去权衡？

P269 12.1.6 用户体验和质量 好的用户体验当然是所有人都想要的，如果它和产品的质量有冲突，怎么办?牺牲质量去追求用户体验么,用户能接受么?

现在很多的软件都拥有数量相当多的用户，用户数量一多就会有各种各样的用户体验，有的人会觉得好，而有的人觉得不好，这样要怎么去定义“用户体验”呢？况且我认为质量不也是影响用户体验的一个因素吗？那么，在这种情况下，牺牲质量去追求用户的体验，导致了一部分用户觉得好，又有一部分觉得不好，那这样的改动还有必要吗？

  1. 怎么决定一个团队中各人负责那一功能？当一个团队接手一个项目时，是让每个人选择自己感兴趣的部分去实现，还是根据每个人的特点去分配更好？怎样去平衡这样的分工呢？

  2. 便宜、好、快这三个愿望只能满足两个，怎么办？又好又便宜的需要花时间等，又好又快的需要钱，又快又便宜的比较难用。如果让我来抉择的话，我首先会排除又快又便宜的，因为又快又便宜这个条件虽然看起来很诱人，但是做出来的东西难用，难用的东西会有人用吗？我的疑惑是，我们应该怎么在这三个愿望之间做出较好的权衡？

  3. 我看了这一段文字：
    图片
    图片
      我的问题是：教材中给的解释是说在这些科学巨人顿悟之前已经有坚实的基础了，但是顿悟和这些知识具体的联系是什么呢？
      事例资料：我试图去查了对于牛顿这个故事，也看了有的资料去讲顿悟、渐悟的关系。
      但是我还是不太懂，我的想法大概是，牛顿这样的一个思想的来源是不是由于他本身有对力的知识，就是知道世界上有力的存在，力能改变物体的状态，能让物体“动起来”之类的知识，现在发现没人动苹果，苹果却能动，说明也有一个力在牵引着它，作用于它。但我感觉这样的过程好像更像一种延申，它真的是顿悟吗？还是说所谓的“顿悟”其实就是这样延申出一个新的东西呢？

  4. 我看了这一段文字：
    图片
      我的问题是：我感觉创新面临的更多问题是在于不够创新，没有吸引力，而不是这些问题。如果是真的非常建设性的东西，是不是不太会受到这些问题呢？
      事例资料：不知道该往哪个方向找资料，搜索相关关键词基本只能看到非常笼统地说“我们要创新”“创新才有未来”之类的话。于实验室，利用先进的技术和设备在实验室中还原
      我的困惑是：好像现在更多的创新都非常容易和过去的相撞或者和别人的想法很类似，那如果真的很有意义的创新的想法是不是会获得更多人的支持呢？在编辑这段文字的时候我又想到是不是这个“创新者”除了创新的想法之外，还需要其他大量的工作去证明这个创新是有意义的，那这样究竟是一件好事还是坏事呢？

  5. 我看了这一段文字：
    图片
      我的问题是：如果一类产物是具有别样意义的东西，那么这样的产业化真的会动摇原产业吗？
      事例资料：钻石类比于水晶。现在市面上已经有大量的人造水晶，像著名品牌施华洛世奇作为轻奢的一员使用的就是人造水晶。目前为止出现在市面的有培育钻石。钻石的化学成分是碳，这在宝石中是唯一由单一元素组成的，属等轴晶系。常含有0.05%-0.2%的杂质元素，其中最重要的是N和B，他们的存在关系到钻石的类型和性质。晶体形态多呈八面体、菱形十二面体、四面体及它们的聚形。
      问题：那钻石是不是也和水晶一样，会包含不一样的矿物质，世界上没有两颗一模一样的钻石。那么人造和天然的意义是不是还是有区别。像水晶，在人造水晶越来越漂亮高阶的今天，天然水晶的市场中依旧有很多人趋之若鹜。珠宝市场的规则是不是是和批发市场有所不同呢？这样的创新是不是并不会影响这类的市场或者影响不大呢？

  6. 我看了这一段文字：
    图片
      我的问题是：这样的一个决断，是值得参考的还是只是当一个故事看看呢？
      事例：像京东当年想要转战线上，关掉了在北京的12家实体店。如今看来当然是个正确的决算，但如果这一条路错了呢？
      问题：卖掉所有的生产线，看上去是一个非常伟大而漂亮的决断，让后来的诺基亚坐到了行业头部的为止。但是如果这一战失败是不是直接死亡。所以这一部分的内容是要希望我们能坚持决断地做一件事是这个意思吗？还是一定要能选择到正确的方向。

  7. 我看了这一段文字：
    图片
      我的问题是：这个举了两个选择，一个是利润50%，一个是利润10%，那如果创新的产品没有利润，甚至一开始就倒贴，后面有可能有更高的利润，人又会去怎么选呢？

  8. 我看了这一段文字：
    图片
      我的问题是：目前为止看到“价值观坚定”而成功的栗子好像基本都是坚定站在用户的角度上考虑问题的，那有没有其他价值观成功的呢？
      事例资料：例如，为什么微信不能多任务同步操作？——就是说你看微信文章的时候来了一条消息，就必须要退出文章界面，很多人会觉得非常没有效率。而这个就是微信的产品经理在向用户传达一个小小的价值观：生活已经这么累了，那就专心做好一件事吧。
      但是我还是不太懂，我的困惑是：这好像是这个软件本身成功了这个事才无所谓。就像我同样吐槽微信为什么不能三个平台同时登陆，平板一上线电脑就会掉线。那如果这个软件改掉会不会更贴合用户，更受欢迎呢？

  9. 我看了这一段文字：
    图片
      我的问题是：现在真的效能过剩了吗？有的效能是不是必要的呢？
      事例资料：比如现在的手机的性能越来越好，按一些人的形容是已经超过了很多人的需求。比如很多父母辈的要求就只是要能顺利发消息，发文章新闻，发消息之类，现在的手机的性能很多是针对有重度游戏需要的人。
      但是好像实际上会发现这些多余的性能是有用的。除了跟内存空间相关之外，更强的性能是不是在使用时间较久之后仍不滞后，仍能使用户有与开始一样好的使用体验呢？现在的手机都在不断地提升刷新率，不也是为了用户体验的提升吗？很多肉眼不可见的地方，所谓“多余的性能”，或许并不多余呢？

  10. 我看了这一段文字：
    图片
      我的问题是：假如真的有这样的梦想，这真的应该是我们要考虑的事吗？
      事例资料：认为作坊式开发的集中体现是有组织的管理难以落地，有以下几个主要问题：
        （一）对“师傅”的依赖严重
    师傅就是骨干工程师，很多东西都是装在开发人员的脑子里面的，往往会因为一两个开发骨干走了，就造成整个团队的瘫痪，如果研发骨干一个人另谋高就，公司投资就将全部付之流水。我们看到很多团队里的“技术权威”使得老板也不敢对其“指手画脚”，否则他会“撂挑子”，事情成败取决于师傅的能力，实际上说明工作缺乏组织的有效管理，在这样的情形下，生产过程基本上是无序的、无约束的，老板作为“管理者”角色的职能几乎谈不到，甚至受师傅的摆布，除非老板是一个非常高水平的技术大牛。
        （二）老板对软件开发的过程无法介入，各层级之间也是以人为纽带的弱管理
    老板大概知道要开发个什么东西，需要什么时候交付，但具体开发过程、产品工期、产品质量老板只能问技术总监，有趣的是技术总监也是个大概齐，更多的只能问项目的负责人，虽然越接近开发工程师，越了解实际情况，但项目负责人甚至都不知道手下的工程师今天倒底是写代码了还是打游戏了，这种粗放的管理水平在今天的其他行业是很难想像的。
        （三）无文档式开发，设计都在师傅的大脑里，开发项目可持续的风险很大
      问题：那是不是其实除了文中提到的自身的很多条件和想法之外，作坊本身也是非常非常重要的呢？而在外部的人根本无法窥得内部的真实情况，应不应该冒这样的风险呢？其二，现在的年轻人比起梦想，其实更多需要的是能够生活下去，有稳定的工作和工资，是不是不应该去试错呢？

  11. 一部分人写代码时充满激情，也有一部分为了工作而勉强了事，那造成这种差异的所谓“激情”是如何产生，它来自于项目的商业价值还是个人的理想实现又或者是什么，第二类人又该如何激发自己的激情呢？

  12. 今天碰到的问题来自于昨天的风险，一个项目存在着许多的风险，其中来着环境的风险有法规、市场竞争环境、经济情况、技术大趋势等等。那么我们程序工程师在项目确定的时候考虑风险是参考当下的环境，还是凭借个人的眼光以及周遭信息更多地参考所预测的未来的环境呢？

  13. 用户体验的好坏与产品的成功息息相关，我想可以理解为用户体验至上，但是有些时候我们不得不牺牲一部分用户体验以换取性能、安全性等等，这种时候我们怎么进行取舍呢？

  14. 假设我们砍掉了一个无法实现预期的设计需求，我们为这个功能所花费的成本可以称之为“沉没成本”，那我们能不能从这个已经花费出去的“沉没成本”上吸取到什么教训。

  15. 结对编程中，两人进行角色互换，阅读对方的代码、理解对方思路时是否会浪费大量时间？

  16. 读了56~57页“专和精的关系”，我想问的是究竟该往哪个方向发展：是成为一个什么都会一点的全栈工程师，还是成为只精通某一种语言的工程师？哪个方面会更吃香？
    我自己是觉得可以成为精通一门语言的工程师比较好，把这门语言学到深，真正去理解这门语言，使用的时候就会得心应手。当然，这不意味着不要去学习其他语言、技术，只是不需要学得那么深入，会基本语法，能够使用就行，自身是需要精通一门语言的，才有底气。

  17. 读了74页的注释规范，这里说“应该只用ASCILL码，不能用中文字符”我有点不大理解？
    我的观点是认为注释的作用就是为了让其他程序员，甚至是自己看得懂代码写的是什么功能，是易读的。如果在欧美国家，用ASCII码当然没问题。但是在我们自己看来，英文注释反而大大阻碍了其可读性，我遇到英文注释，可能还需要借助翻译工具，这样就浪费了我的时间。而且写中文注释可以同英文代码更好的区分开来，哪个是注释，哪个是代码。

  18. 读了84~85页，我认识到结对编程的必要之处，那我想问如何进行有效的结对编程？若是其中一个人能力不足，或者总在偷懒，又因为项目要到时间了，另一个人只能被迫完成大部分内容，这样的结对编程反而无法带来好处，那么如何避免这种情况的出现呢？
    我自己的能想到的解决方法是，找个能力相近的有责任心的人一起结对编程。不知道还有没有更好的解决方法？

  19. 敏捷开发的一个原则是“可用的软件是衡量项目进展的主要指标”，我想问的是“可用的软件”的具体含义指的是什么？指的是仅实现功能需求的软件，但是仍存在一些bug，还是指的是无bug的软件？如何判断一个软件是可用的？有没有什么具体的标准？

  20. 读到第八章收集用户需求时，我有一个问题：软件开发时是满足大部分人所需要的需求，还是尽量满足所有用户各式各样的需求，即对小众用户的需求是否要满足？比如手机的旁白模式，这个对大多数人是用不到的，但市面上基本所有的手机都实现了这个功能，因为他对一些人来说这是非常必要的。

  21. 从事软件行业的人肯定是避免不了团队合作以及结对编程的。那么《构建之法》也在P108提到性格一定程度上会影响合作。据MBTI分析，ISTJ、INTJ以及INTP型人格才适合软件行业。但是我并不属于上面三种类型，自认为学习本专业确实还是有一些吃力的。现在不禁有点怀疑自己，能否提点一二？

  22. 书中也列举出了很多种别人“不喜欢”创新的理由，如果我的idea遭到质疑的理由是“这从来就行不通、没有人需要这些方案、在实际中根本行不通”等，我大可以像《构建之法》里面说的那样，通过考虑“对利益相关人要讲清楚‘你能从中得到什么’、创新的想法和目前流行的做法相比，有什么相对优势，能让别人清楚地看到这个区别”等方面解决问题。但是如果我的idea是因为“个人自负/嫉妒或者是面子问题”等原因被否决我又应该怎么办呢？

  23. 每当班上同学要自行组队完成老师布置的团队项目实践作业时。我发现如果同学A和C成绩较好、项目经验较丰富，而B同学成绩一般、经验不足。此时A和C会更加容易找到队友，同时他们也更加倾向于和对方组队而不是选择B作为队员。长此以往，A、C的能力、成绩、经验等等会以快于B的速度提升，那么A、C自然就能获得更多机会、成绩更好、发展更快。这个例子是不是也能证明软件工程“强者通吃”这个结论呢？那么作为处于第二名和倒数第二名的同学在这种情况下要如何“曲线救国”而迎头赶上呢？

  24. 我曾经所在的一个学习小组里，我们成员们已经有了一定的默契。A成员累计代码量最高能力最强，但有一个缺点：情商低且不自知（实话实说，没有诋毁的意思）。每当其他成员有失误时，A会毫不留情地当面说出类似于“都是因为他我们才会浪费这么多时间”这样的话语，其他成员的积极性以及自信心或多或少受到了影响。而在leader与A多次交涉无果的情况下，只有留下A或者是剔除A两个选择。我想如果调整团员，那么团队需要花时间重新建立默契；如果留下A，那团队的其他成员继续被打击。此时，leader是否有必要将A换掉？

  25. p9（第一章）中提到“软件工程师是看不到自己的源代码是如何在用户的机器上被执行的。商用软件出现了错误，工程师可以看到程序在出错的一瞬间留下的一些痕迹，但是几乎无法完整重现程序到底出现了什么问题。”，我有所疑问，在难以看出是什么错误的基础上，如果这个bug还难以复现，那么工程师该如何处理这个bug呢？根据我之前反馈bug时向一些工程师了解知道：根据bug的优先级，在上线之前对该bug进行处理，特别严重的bug，要召集项目组的成员，进行讨论分析并尽可能的复现bug。但是这仅仅只是如何找出bug，那么该如何有效的修复这些“不可见性”的bug呢？

  26. p27（第二章）写道：单元测试应该覆盖所有代码路径。所以我认为单元测试的代码覆盖率要尽可能的高，越高越好，这样就不可避免的要有很多单元测试要去完成。那么问题就来了，如果开发软件，是把这么多测试全做完，还是挑一些重要的测试来进行呢？如果只挑一些测试进行，又怕软件会存在未知的缺陷，如果全部测试都做的话那需要庞大的人力物力。我个人是觉得把全部测试都做完比较好，但是有没有其他方法既不用做所有的测试，又能防止缺陷？

  27. p47（第三章）中提到开发人员在团队中的流程，其中第六步即最后一步：“在解决方案发布出去之后，对结果负责。”，关于这个问题，我想提问：这个对结果负责是只对不好的结果负责吗？如何负责？负全责吗？这个问题目前在网上并没有明确的解答，对此我全然不知，想了解一下，希望老师们解惑。

  28. p58（第三章）中提到工程师有职业成长级别，对此我上网查找资料得知：软件工程师是一个认证考试，具体地说是从事软件职业的人员的一种职业能力的认证，通过它说明具备了工程师的资格。只有这一门认证考试，而且以后的职称级别评定是根据工作经验，个人能力以及工作结果来评的。关于这个行业我感到十分奇怪，难道没有任何数据资料或者书面材料来证明软件工程师的级别吗？还是比如说这个高级职称只在一个公司内有用，换了公司别人也只能从你简历中了解到你以前工作大概是什么情况，但是真实性有待考究，因为没有任何证明？

  29. p79（第四章）中说代码复审的正确定义是看代码是否在代码规范的框架内正确地解决了问题。查阅资料后我发现网上对于这个代码复审并没有一个很明确的定义。因此疑问：如果此时有人提出了一个新功能，那么这个新功能是否算在代码复审的过程中？我个人的第一判断是：算在代码复审的过程中。但是新功能无关代码规范，也不是为了正确解决问题，只是为了增加新功能，这与代码复审的定义矛盾。所以是我的判断错了还是定义不够准确？由于我个人理解能力有限，希望得到老师的解答。

  30. p122（第六章）敏捷流程的第四步提到了增量的软件发布，这引起了我对于生活中软件发布的联想：如果在实际的软件更新或者发布公告已经出来，但是由于各种可能的原因导致软件在截止日期没办法发布，如果DDL发布可能只是半成品，那么软件公司有两种选择：发公告说明情况并延后发布；按时发布但告诉用户缺少一些预告的功能，只能在下下个版本一起实现。如此诚信和口碑该如何选择？我个人倾向于按时发布，但是这两种选择貌似都没有什么优点，都是弊端，那么请问老师该如何选择？又或者既然两种方法都吃力不讨好，干脆选择其他途径来减少用户的不满？

  31. p160（第八章）只列举了一些利益相关者，并指出软件开发不可能一次满足所有利益相关者的要求，我的理解是对于利益相关者的需求是有优先级的，如果是那么是根据需求来确定优先级还是根据利益相关者来确定优先级？

  32. p196（第九章）有人问：如果PM也来开发，那么项目进展不是更快？答：如果这个这个舵手也开始划船，可能小船的速度会快一点，但是小船的方向、稳定性会出现问题。我的个人理解是：PM也兼做开发，那么会有利于项目进展，就好比舵手一边指挥一边划船。查阅资料也了解到不少PM也是兼做架构师、开发等等。不知道老师觉得这样是利是弊，亦或是有利有弊？

  33. p259（第十二章）提出了两点考虑：关于目标用户的考虑和用户第一次使用软件的考虑。由此我想到，比如一个用户正在使用我们的软件，旁边有人正在观察他使用软件，那么这个软件的各个界面，动画等等都有可能吸引这个旁观者成为我们的用户，虽然我们这个软件主要不是为他们设计的，那么这上面提到的可能的种种因素属于影响用户体验的因素吗？如果属于，我们需要将其放于什么位置，极其不重要的位置吗？（因为软件的主要群体不是他们，他们也还没有成为我们的用户，但是他们可能会因此成为我们的用户甚至还能吸引其他人成为我们的用户，毕竟没有人会嫌自己的用户多），该问题我无法获知实际结果，希望能得到老师的解答。

  34. p343（第十五章）讲述了如何开一个Postmortem会议（事后诸葛亮会议），这个会议显然对于参与者、已经发布的代码及以后做的项目都有好处，那么为什么不在代码没有发布之前开展这个会议，假想代码已经发布了，然后在代码发布之前解决一些问题，这样难道不是更好吗，关于一些发布后可能会出现的一些问题，我们可以先寻找一部分用户进行测试并加以解决，这难道不是两全其美吗？望解惑。

  35. 在书中的第一章节讲软件的一些背景知识，我在看到书中第15页，书里讲到什么是好的软件，似乎并没有给出一个明确的答案。那么软件开发
    的质量到底是如何衡量的呢？

  36. 书中第8章讲了需求分析，在我们着手一个项目开发设计，编码之前需要了解客户需求，怎样才能够准确了解和挖掘他们对软件的需求，引导出真实的需求，太难了，到底用户调研能不能获取到真实的用户需求，我们如何能够通过比较好的用户交流，比较全面的了解和弄清他们的需求呢？这有没有好的一套方法流程？这样就会不会在详细设计过程中又反过来讨论需求呢？

  37. 在书中291页讲到压力测试，书中说压力测试就是验证软件在超过设计负载的情况下是否能返回正常结果，不产生严重的副作用和崩溃。超负载下我们的程序到底能不能正常运行，不死机，我提出问题怎样进行压力测试怎样才是刚好？为什么很多“小”问题在加压下就会被放大？我理解的这样进行加压的测试是不是会因为内存泄露或者资源泄露，产生死锁而得不到压力测试的临界点。

  38. 讲义中提到有一些同学认为:编程从来就是一个人的活动。学校里这么教的，我们一直以来也是这么做的。两个人本来可以去做两个模块，现在一个模块两个人写是不是一种浪费（这可是两份工资哦)?首先在我学习的课程中,其实是很多实践课是有合作的,但是其实很多人在划水,但是毕竟有时候组队是难以避免的事情,就如同讲义上说的有些公司是有要求结对编程了,在大学的结课编程期间,如果有一些同学划水,但是我们为了课程的成绩,不得不要完成更多的工作量.我在知乎中看到有人说,在公司的结对编程之中,有一些同事有拖延(其实也是划水),把一个本来能几个小时能写完的代码,拖延了好几天,但是我没有查到具体的解决方案,所以想请教一下老师遇到这种情况应该怎么办?

  39. 在讲义之中提到团队成员的不同付出,猪的贡献就是全身心的付出.正常一个优秀的团队是要全面优秀,猪和鸡和鹦鹉都有,但是它也提到了一群猪全身心投入看似不错,但无论多么努力,猪没法下蛋。可是我的疑惑就是如果一群猪,都是很努力,现在软件工程这个行业,在我学习的认知中,大部分的事情其实都是只要你付出,认真查资料,在各个方面其实都可以做好,为什么一群努力的人没办法成为一个好的团队呢?

  40. 讲义中有提到用户界面那一章节中有提到一个微软学术搜索,有一个叫西乔的同学给它的界面提出了优化改进方案,将submit按钮突出,Cancel按钮样式弱化,降低用户丢失操作的可能性.前面还提到了让用户再次确认等等防止操作失误,但是我发现在我们生活中,比如我们卸载一个软件的时候,它经常弱化卸载软件,甚至多次确实,让我们在卸载的过程中造成了很大的麻烦.在用户的角度上我们肯定是希望卸载不要这么麻烦,一次次误导我们不去卸载,但是作为公司和开发人员的角度来说,肯定是希望用户不去卸载该软件,那当我们作为一个开发人员时,应该考虑用户的卸载体验,让他们不至于对该软件产生厌恶,还是考虑公司,诱导用户不去卸载呢?

  41. 在讲义中提到了一个软件工程师接到任务之后应该怎么办？说到了首先去PSP表,我认为PSP表里面的内容其实不是全然有用的,像是分析需求,设计文档这种东西,我认为是有用的,毕竟一个任务的开发首先要做好一个充足的准备,但是比如估算开发时间,特别是对于那种较大的项目,作为一个软件工程师,其实很容易在一个bug地方卡很久的,去估算这样的开发时间在我看来其实是意义不大的.

  42. 就如果我们的代码由其他同事来复审,因为有些人的算法会比较特别,不想让人知道,或者说被别人复审会不会产生代码泄露的问题,然后最后背锅的是自己呢?

  43. 学习了软件设计思想和软件工程思想的知识之后，显然并不是任何时候都要死板的按照所学的知识进行开发设计，软件思想的运用边界在哪里？何时该使用，何时不该使用？

  44. 同样是UML，我在学习完UML之后恨不得每做一个项目都画类图，这样显然不太对。个人认为编程需要软件思想的指导，但是不能死板地用所学的理论框住自己。但是对这一部分的理解还是有限，这个问题似乎有点大，我依旧无法清晰地知道自己在什么时候应该按理论要求开发，何时不要。

  45. 科班出身的软件工程师和非科班出身的有哪些区别？如何在就业市场就业压力如此大的情况下发挥科班出身的优势？

  46. 如何确定软件系统的典型用户？

  47. 如果团队成员在每日例会中迫于压力、碍于面子对自己的实际情况撒了谎，可能会打乱整个流程，该如何处理？

  48. 在阅读《构建之法》16.1.2 迷思之二：大家都喜欢创新 中的

如果使用QWERTY键盘，那么只有10%的英语单词能在手指不离开键盘中列的情况下敲出来。但是如果使用Dvorak键盘布局，你可以在键盘中列打出60%的常用单词！这样会减轻手指和相关肌肉的负担，减少劳损，同时加快打字速度。......但是，长期以来，人们已经习惯了QWERTY键盘，所谓先入为主。

我有一个问题：当前中国人最离不开的软件微信，是否正在成为中国的“QWERTY键盘”？这样的软件存在是否会打击行业创新的积极性呢？

  1. 我在读到第四章两人合作时，在了解代码复审的重要性的同时也有一些疑问?4.5.3表明现在的复审方式大致为两种，伙伴复审：程序员之间互相复审以及团队复审：多人开会复审，而这两种方式都有自身的缺陷。我的个人理解如下，伙伴复审较为贴近日常，审出bug来，较为容易让人接受，自己不会有压迫感，更不可能为此争辩自己没有错。但是这样同时也不够正式不够全面，如文中所说这样不能持久、定时的复审，毕竟没有人愿意天天帮你。但是团队复审也存在问题，比如耗时，这对于一项需要经常展开的活动来说是致命的。而且，原本审查的工作在开会进行会让开发者觉得大家***难自己，也就是所谓的面子问题。因此，我有疑问，这两种方式该如何选择。
  2. 阅读到"16-8图:高科技被炒作的规律"与"16-9图:股票泡沫的几个阶段"时我有点吃惊,因为图与我近期关注的5g、半导体、芯片etf基金k线十分相符.这些高科技产品的走势，都是经历了19年的大涨，然后迎来20年的暴跌，且19年时简直把这些捧上天了。我觉得，诚然华为公司确实是国之骄傲，但是当时它还是被过分吹捧了。毕竟，一家公司想要独抗m国这是不可能的，而且我们的芯片技术落后了人家几十年，这不知道要花多久时间去追赶。如今，它们可能正处于作者所说的迷茫期，我只能简单理解股价涨久必跌的道理，但是不明白为这些新技术会有"迷茫期"这一阶段.
    imgimg
  3. 书中提到"因为颠覆性技术的市场还不存在",并且颠覆性技术的描述为“这是一门新技术，很不稳定，经济效益也未必确定。有很多未知因素：市场有多大，用户在哪里，有哪些竞争对手，成熟的商业模式是什么。我不太认同作者“颠覆性技术的预测往往是错误的！”的观点，的确谁也没想到今后手机、汽车这些的发展会这么迅速，但是我觉得这些都是个例。我们之所以觉得预测是错的，只是因为我们公众所能了解到的信息，都是一些无行业价值的，或者本来有商业价值但是大家都知道，也就变得无价值。我查阅了资料，人工智能以及区块链钱包都属于颠覆性技术，而且目前大家普遍看好如果说专家的预测存在偏差,是否意味着如今大家认为的"人工智能 大数据"这些是风口,我们还是应持保留态度?
  4. 阅读到3.2软件工程师的职业发展，作者提到，21世纪以来，中国大陆每年招收六百万大学生，其中的百分之十是在学习各种IT相关的专业每年大致有四十万到六十万左右的“职业软件工程师”进入工作岗位.我又翻到首页看了下作者更新第三版的时候是2015年，时隔六年，我百度了一下现在的数据，据统计中国目前有六百万左右从事开发人员。而且由于如今的从业门槛低增长速度不断增加，火爆程度愈演愈烈。从我最近关注的考研情况来看，就中科大软件学院，前几年还招收调剂生，而今年据不完全统计分数400+的人数已经超过了400。网上也传出了“内卷”这个词，承然，现如今没以前那么容易在这个领域混下去了，在这样的局势下我们的未来规划应该做出如何的调整呢？
  5. 作者在书中提到“简单的说，软件的行为和用户的期望值不一样，就叫Bug，是否是Bug，取决于用户、开发者的不同角度。”，从这里我也有个疑问，用户期望跟软件开发的需求肯定会存在冲突，当我们围绕用户需求去设计开发这个软件时，需求得到了很好的满足，但是对于开发者往往达不到自己认为的标准，因为开发者觉得可以牺牲一些不必要的体验来优化性能。当这个行为与用户需求冲突时，这bug到底应该谁来背。有时我们可以引导用户取一个中间值，但是若是用户期望值跟软件优化产生极大冲突时，应当如何抉择？
  6. 书中提到：

在书中93页，作者主张在最外层，即行为和后果层给与他人反馈。作者的理由是前两层反馈难以改变，而最外层的行为和后果是可以被改正和弥补的。
此外，作者也提到三明治式的反馈是容易被人接受的。

但我认为这种方式有时不足以引起他人的重视。虽然三明治式的反馈确实让人容易接受，但也容易让别人不以为然，认为他犯的的错误只是小问题，拿过去的一次合作经历说，有些队员喜欢“划水”，队长不断地催促他们完成自己的任务，最后上交的成果并不好。如果给与他人的反馈，大多都在评论别人三种层次中的行为后果层，他或许只是这一次改正，但再次出现问题时，他还是会重蹈覆辙，所以我会考虑进一步在行为动机层上告诉他问题所在，这样会不会取得更好的效果呢？

  1. 书中提到：

在49页，作者提到了软件工程师成长的第一点，是积累软件开发相关的知识，提升技术技能。其中包括一些编程语言，设备驱动程序，内核调试器的掌握以及对某一开发平台的掌握。

但是经过了大学三年，我发现自己好像学的太少了。对设备驱动程序和开发平台没有过多的了解，太久没用的编程语言也会忘记一些知识。所以我对于第一阶段的学习还远没有结束，我也不清楚自己要掌握了哪些具体技术之后，才算完成了初级软件工程师的第一阶段，以及我需要花费大概多少时间来学习这些技能。毕竟大四面临毕业，怎样在有限的时间内让自己在软件工程的领域内掌握足够的知识？

  1. 在软件工程概论中有提到职业道德，举了一个是否可以写一个“刷课机”的程序帮助某些用户选择自己想要的课程。其实这种类型的程序在市面上有很多，比如离我们比较近的抢票软件，会根据用户的会员程度依次提高抢票成功几率，帮助某些用户抢到心仪的车票，几乎每一个抢票软件都会有这样的功能，那么这个程序合法吗？符合道德规范吗？或许每个人有不一样的见解，我对于此问题在知乎上搜到了如下解答：“在我看来并不算是违法的，换个思路看问题，如果我把抢票看成是是一个服务，然后替换，在看这个句子就会变成有些人花更多的钱享受服务，这对那些没钱的人来说是违法的吗 不能这么理解 ”，在这个博主看来，这个软件唯一的问题就是因为经济的不平衡导致售票的明显偏向。另外，我也了解到，中国铁路目前对于第三方抢票软件态度并不友好，12306正在一步步完善自身功能同时一步步封锁第三方软件。那么这些第三方抢票软件在市面上的使用是否能说明这种独占程序符合道德标准？事实上道德标准也是一个不稳定的标准，来自于每一个人的主观。那么怎么才能判断软件的可开发性是否符合当前道德？是多数服从少数下的标准吗？
  2. 第九章项目经理有一个微软的故事，讲述了不被用户要求但被开发出来的打印预览功能。那么，如果有一个正在进行的项目，PM已经归纳了用户需求，工程师发现在编程过程中某个未被要求功能未来可能会被需要，那么应该把这个功能做出来吗？PM的需求分析在后期执行过程中可以被编程者改变吗？
  3. 在讲义8稳定阶段中，有一个九条创建的bug，其中问题并不完整，似乎只是一个偶发性事件，下面又给了一个完整且可以有效解决问题的方案。虽然这样是会节省时间，但是这是专业测试人员可以做到的完整描述。bug不可能完全消失，所以如果后期软件上市后会有类似的小bug,用户的反馈极有可能是像九条一样，简单明了，或许再次打开不会有同样的bug，但那个bug确实存在，此时收到这条反馈的开发人员该怎么办呢？是等着有多次相同问题提升准确率后进行统一修改还是自己测试即使找不到那个确切的小bug?
  4. 在讲义8软件的血型中，提到软件要重构还是重写。现实中确实会有这样的事情--临近发行，发现软件的某个功能或者构建有更好的解决方法，甚至是软件可以有新的功能，那么此时是在原有基础上修改还是重新再构建一个软件？或许公司上层希望的是尽快按照既定方案发行，但工程师是否有必要在发行之前将软件尽善尽美，去增添不加也无伤大雅，加了就锦上添花的项目呢？重点是，如果真的要重构和重写，又能保证确实比之前要好吗？要以什么样的角度去看待这种问题才是我们真正需要的呢？
  5. 创新使得软件工程一步步地发展，那么创新的时机该怎么掌握呢？就像16.7提到的问题：在你创业时，有人又有了更cool的想法，你该怎么办？是继续你的工作，还是破釜沉舟重头再来？继续是否一定会成功，重头再来又会不会成功？又会不会有又一次的重头再来的机遇？人生就是选择题，人要承担自己做完选择之后的后果，那怎么选择才会不会更后悔？
  6. 在书中讲述了团队中的分工和流程，当我在看到书中提到的“要完成一个复杂的软件项目，团队的成员要在不同阶段做不同的事情”这句话事，我想到在团队开发流程中，由于每个人的性格、习惯各不相同，有人有事立马就做，有人却每次到ddl了才开始做，导致出现两极分化，这样在开发过程中就可能产生工作冲突、工作进展缓慢等问题。
    本人案例：在去年疫情期间，我和小伙伴组队参加了国际用户体验大赛，由于团队积极性没有被调动起来，大家完成任务的时间各有不同，加上大家经验不足，最后导致项目烂尾，没能完成比赛。也有可能是大家都是在家线上操作，没有参赛氛围导致的。
    那请问遇到这种情况如何协调和解决这件事情，保证团队的高度团结和团队开发的效率？
  7. 公司中团队分工可能回很明确，每个人各司其职，但是我们在做比赛项目中，可能由于时间、能力有限，无法按照流程进行开发，在任务分配时能否采取主次任务分工？或者在开发人员及技术有限的情况下，应该如何分配任务？
    例如我今年参加了服务外包创新创业大赛，小组共五人，配置为：产品、UI、前端、后端、市场各一位。但是开发时间有限，前后端开发人员压力巨大。我们使用的方式是：产品主要负责产品然后兼任ui（给ui打杂），ui主要负责ui设计然后兼任前端（给前端打杂）...。
    请问就这种方式是否合理？
  8. 这个问题是看到”竞争性“和”创新“，两个词想到的，在做需求分析时，如果遇到竞争团队也在做相关的需求分析，那么我们应该如何保证我们能够完成需求并保证我们找到的需求不被盗取？（需求被盗取可能会在问卷调查或者用户调研的过程中被盗取）
    本人案例：我之前有一个自己想到的点子，想将它实现成产品，但是在需求分析、市场调查的过程中，生怕别人看到，将这个点子偷走（毕竟目前大学生“白嫖”现象比较严重）。导致我不想在宿舍、实验室完成，最后我只好在自己空闲时间去图书馆将其完成。这种“偷偷摸摸”做需求的感觉让我这个北方人感觉很不爽。但是想法被嫖也会让我很不爽。（在此向老师道歉，本次作业的参考书籍使用了扫描版，本人只想到了学习知识、完成任务，却忽略的对正版的支持。十分抱歉！）
  9. 这个问题是我看到时间花费结合需求分析想到的，在我们做项目的过程中，需求做完后需要开发一段时间，但在开发的这段时间内，原有的需求发生了改变或者需求优先级发生了变动，此时应该怎么办？是应该停止开发重新定位需求还是应该继续开发下去？
    这个问题虽然在我这还没有发生，但是不怕一万就怕万一。对于这种情况我感觉停止开发可能会让项目时间边长，但重新做完需求的项目可能会让它更完美。但是继续开发下去貌似也是可取的，一个产品总有版本迭代。这两点让我感觉有些矛盾。
    不知道老师有何见解？
  10. 书中说结对编程让两个人所写的代码不断地处于“复审”的过程，这样可以提高设计和编码质量的过程，也能及时地发现问题和解决问题，避免把问题拖到后面的阶段。但是结对编程会降低编程效率，做项目的时候一定需要结对编程吗？
  11. 书中把团队合作分为萌芽阶段、磨合阶段、散伙阶段、规范阶段、创造阶段，团队合作中每个成员都有自己的职责，如果在后期工作阶段，有成员对分配到的任务不满，或者他不想担任这个职责，该怎么办？
  12. 现在的大部分软件都可以满足人们的日常生活需求，我们还能从哪些方面来了解用户的需求？而且要怎么知道这些需求是不是大部分人所需要的？
  13. 书中“你姥姥的遥控器”讲到了设计应该做到简洁明了，只要能让用户明白产品怎么使用就好了，但是有时候一个产品的功能就是需要较多的设计才能展现出来，这时候是要考虑用户的体验，还是要做全产品的功能呢？
  14. 书中给出了典型用户的定义方法，包括年龄、收入、生活/工作情况等等，那程序员根据这些典型用户的需求写好程序后，发现这些用户只有在特定场景才会使用到这个应用，那程序员需不需要修改程序使得用户在大部分情况都能使用？
  15. 一味追求“最大的扩展性”会有什么副作用呢？
  16. 一般在测试的时候是怎样模拟现实的环境呢？毕竟自己手动添加记录，发出请求不太现实。就算编写小工具来实现，也还要考虑正确性，总感觉除了VSTS以外，还有其他现成工具可以帮助模拟，毕竟不是所有的开发都是在VS上进行。
  17. 积极地学习者最大的特点就是积极。但有时候太积极又不好，领导者应该怎么应对太积极的初学者。很容易遇到，实际上也遇到过这样的初学者：什么都不懂，但更糟糕的是不懂得问题的重要性，有问题就一股脑问出来。其实对初学者来说，有些问题自己解决能够让他成长得更快，全部回答他的问题会影响以后他解决问题的能力。问题更具体地说，应该怎样指导初学者学习方向？应该怎样平衡“解决疑惑”和“培养自立”？
  18. 阅读第三章的时候讲re-work表示软件质量，用了一个例子是艺术家涂改作画的例子，我完全同意书中说的re-work并不能代表代码的质量。但是后面说到在一个很简单的代码上花费很多时间re-work我是存有疑惑的。艺术家经过很多遍的涂涂改改出来的一幅作品我认为是一件很好的事，因为每一次更改都代表着对上一次的否定。我认为小的代码的re-work也是必要的，不应该否定他的价值
  19. 流水例会的确是一件可耻的行为，但却让我想到了流水例会产生的原因，无非就是无事可做的时候例会还要照常召开。在团队当中的确有这样的事情发生，无事可做，每天例会，那我们要用怎样的心情去对待。其次就是我看到冲刺阶段每次报告都要一个完整的图标之类的汇总，这些图表制作不需要时间的支撑吗？如何协调时间不足的情况下还仍然要做有效的报告呢。
  20. 我不记得在哪里看过这样的话，说，有一段时间掀起了青年创业的高潮，很多年轻人纷纷涌入创业，但最后有的平步青云，有的锒铛入狱。成功的团队更能创新，因为能力已经有很好的基础，所以可以创新。但是对于那些能力基础还不存在的，是否要冒着风险去创新呢，同时，创新究竟意味着什么，是前所未有还是优化改良。
  21. 阅读第十七章有关猪，鸡，鹦鹉的故事

思考:这个故事其实还蛮有意思的，但是后续的描述的确道出现实，也不免让我惊讶。猪在故事里就是要奉献一切的那一种，而鸡就是可以贡献但不是全部，鹦鹉是语言上的掌管者，交际圈。我个人觉得我和鹦鹉很像，但故事有一个问题就是没有给出结果的衡量。猪的确是奉献一切了，但是猪的回报是多少，高回报的确值得这么做。但是事实生活中的确也有人奉献了一切，牺牲了家人，朋友(这边不是说Jolin)，但是可能他们的贡献还没有一些鹦鹉或者鸡随便一下贡献大，他们真的不值得用自己获得的白菜的钱，操着卖白玉的心吗

  1. 在现实中，也有很多人借用了别人的创新做出了更加热门的产品，或者直接使用盗版软件，比如windows系统，很多人使用的都是盗版windows。所以我们应该怎样保护自己的创新呢？
  2. 团队中的人员能力参差不齐，在一个团队中如何安排才能使每个人在团队中发挥出最大作用？
  3. 在项目合作中总是会出现个别人躺赢的情况，不管是团队项目还是结对编程，特别是作业项目，如何处理好这个情况？
  4. 代码重构和重写的区别是什么？
  5. 关于Bug，有些时候bug存在致命性，但我们又无法修复他，只能推倒重做，如何在开发过程中避免这种情况？
  6. 关于PM，在小型开发中是否需要PM？
  7. 书中提到

分析麻痹：一种极端情况是想弄清楚所有细节、所有依赖关系之后再动手，心理上过于悲观，不想修复问题，出了问题都赖在相关问题上。分析太多，腿都麻了，没法起步前进，故得名“分析麻痹”(Analysis Paralysis)。

当我看到这里时，就不太明白为什么弄清楚所有细节是极端情况？不正是因为细节处理得好，才能使程序更完善么？老话不是也说细节决定成败么？

不单单是从程序上考虑，从提高编程能力出发，不也正是因为许多细节上的考虑，才让我们的编程能力更为经验老道，得到提高么？

  1. 书中提到

理性地工作：软件开发有很多个人的、感情驱动的因素，但是一个成熟的团队成员必须从事实和数据出发，按照流程，理性地工作。很多人认为自己需要灵感和激情，才能为宏大的目标奋斗，才能成为专业人士。著名的艺术家Chuck Close说：我总觉得灵感是属于业余爱好者的。我们职业人士只是每天持续工作。今天你继续昨天的工作，明天你继续今天的工作，最终你会有所成就”。

当我看到这里时，就不太明白为什么只是完成每天的工作任务，最终就会有所成就？如果工作的内容一成不变，对编程技巧，对个人的进步无太大效果，又怎会有所成就？

按时按质按量完成所需工作量当然是必须的，但我们如果还想要提高自己的能力，竞争力，我们就不该仅仅觉得那样最后真能有所成就，而是多思考自身的能力局限，和应该努力提高的方面，并真正往其中下功夫

  1. 到目前为止我看过的关于编程的书屈指可数，在学习新技术的时候我偏向于在网络上学习，毕竟网络上的技术文章是最新的，那么，阅读经典文献的必要性在哪呢？
  2. 书中提到：

5.2.1 主治医生模式 "在一些学校里，软件工程的团队模式往往从这一模式退化为“一个学生干活，其余学生跟着打酱油”"

这种情况的确很常见，但是如果在其他学生的水平都较低，对于那个水平高的学生来说，自己完成比教会他们再与他们合作效率不是高多了吗？ 但这种模式也是合理的吧，特别是对于高年级学生来说，如果参加竞赛，对于队伍中的新生，不就应该带他们吗？

  1. 书中提到：

11.5.1 闭门造车 "小飞：我今天真失败！在办公室里坐了10个小时，但是真正能花在开发工作上的
时间可能只有3个
小时，然后我的工作进展大概只有两个小时！
阿超：那你的时间都花到哪里去了？"

对于这个问题我深有体会，在完成个人项目的过程中，我常常一坐就是一整天，对着一个bug能改一个下午，但其实只是一个很小的错误，就很容易陷入这样的迷惑中，不独处呢，很难进入状态工作，一个人呢，又会发散了思维，那我以后去公司里工作该怎么办呢

  1. 分析麻痹确实是开发的通病，想弄清楚所有细节、所有依赖关系之后再动手，心理上过于悲观,不想修复问题，出了问题都赖在相关问题上。分析太多，腿都麻了，没法起步前进。但是如果不进行细节的厘清，可能也会在之后的开发中产生问题。如何正确解决上述心理呢？
  2. 通过阅读，我了解到了“官僚模式”的软件开发的弊端。承认其模式有之弊病之处，但是在日常的生活工作中还是会有类似的开发经历。书中没有提到此模式的优点和改进，这是我的疑问。
  3. 哪些决定更利于创新，哪些决定在某种程度上阻碍了创新?创新的时机、方法？
  4. 根据p432“提问能构建知识体系”，如何提问才能更加有效呢？
  5. 根据p367图16-10技术产品发展周期，如何改良产品使产品的成熟稳定期能够更加持久？
  6. MSF模型定义了成员的角色和要职。疑问就是，成员不一定都是100%的高手，必然出现“短板”，不一定能达到质量目标，用雷达图来比喻就是图形不是正多边形。对于一个畸形的多边形，做出如何的选择才能让面积最大化，也就是目标最优化，这其中必然有取舍，如：牺牲时间，保证质量，但客户等不及；功能不完善，从而限制产品的使用方式，但很快就被市场淘汰......所以，在各种条件的约束下，怎样才做出好产品，满足需求？
  7. 对团队成员进行ABC等级划分并贴上标签的做法，我觉得有没有一种情况是：对A会A+，对C会C-呢？在中间得B因为觉得无所谓，他会变成A或是C，虽然我们可能会说得看他本人。话虽如此，但我得想法是，划分等级和贴标签的出发点是什么？是鼓励员工吗？还是在筛选员工，C淘汰，A和B留下？说到底ABC什么的确确实实会存在，但员工并不像商品那样随意拨动。我觉得程序员在社会中应该是以复数的形式存在，一个人能力如何出众，脑子都有累的时候，一个人是不可能项目开发的，从需求分析到维护都是一个人的话？谁又会进公司呢？既然这种方式各有利弊，那么划分等级对程序员来说是好是坏？
  8. 这个模型的名字挺有意思的，于是就仔细了解了一下。让我想起了我们大学里学专业课，貌似不是按照瀑布模型来的吧？从开学第一学期就在稳定阶段：学生开始写代码。可是没有在做需求分析阶段的事。这似乎很矛盾，《面向对象设计与分析》并不是入学的第一门课。假设，是第一门课的话，那么第一个学期内学生是不是都在对代码纸上谈兵呢？但又有人说，学好理论基础对敲代码不是好处更多吗？显然易见，一次瀑布模型感觉力度不够，于是多次瀑布模型才是大马哈鱼洄游模型。但是，这对普通的软件工程学生来说，我们不是成熟的大马哈鱼，洄游适合我们吗？还是说那是我们进社会的事了？（虽然我脑海里一直闪烁“优胜劣汰”
  9. 现阶段测试人员需要具备什么样的技能？对测试人员的要求和对开发人员的要求有什么不同吗？
  10. 一个软件的好坏应该更主要由什么来评价，评价标准是怎样呢？通过搜集资料发现软件的好坏得到的大多是来自于用户的评价？
posted @ 2021-04-11 10:26  Grey Zeng  阅读(396)  评论(1)  编辑  收藏  举报