构建之法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点：【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。