文章摘要1
2.1.2中提出“单元测试必须和代码一起进行版本维护。如果不是这样，过了一阵，代码和单元测试就会出现不一致，程序员要花时间来确认哪些是程序出现的错误，哪些是由于单元测试滞后造成的错误。这样就失去了单元测试的意义，同时又给大家增加了负担。如此折腾多次以后，大家就会觉得维护单元测试费时又费力”
问题提出
单元测试的维护应当以什么标准进行迭代？如果是需求改变，那么如何覆盖改变的需求影响到的单元测试的全体呢？
资料调查
当需求发生变化时，单元测试也需要进行相应的更新和新增。这需要开发团队对需求变化的影响进行评估，并相应地修改和新增测试用例。同时，也需要确保测试用例的全面性和有效性，以覆盖所有可能的变化和异常情况。
有时候需求变化后接口测试人员不知道或者过了很久才知道，也有时候需求变化很小却很大程度影响了测试框架
个人看法
需要保持信息的时效性，更新需求后应及时让测试人员知道
在保证时效性的基础上下放工作到各个部门，分别在不同层次、不同部门更新测试用例
接口测试人员可以将测试按照测试泛化性进行分级，泛化程度较高的应保证灵活性，修改更多发生在泛化度低、专门针对需求的测试
文章摘要2
4.3.4中提出"不要在构造函数中做复杂的操作，简单初始化所有数据成员即可构造函数不应该返回错误(事实上也无法返回)。把可能出错的操作放到 HrInit() 或23FInit() 中。"
问题提出
构造函数中应当对传入的参数进行参数检验吧？如果参数不符合要求，是不是应该抛出异常呢？
资料调查
构造函数中抛出异常，会导致析构函数不能被调用，但对象本身已申请到的内存资源会被系统释放（已申请到资源的内部成员变量会被系统依次逆序调用其析构函数）。
因为析构函数不能被调用，所以可能会造成内存泄露或系统资源未被释放。
构造函数中可以抛出异常，但必须保证在构造函数抛出异常之前，把系统资源释放掉，防止内存泄露。
在函数体内构造函数抛出异常将释放已经构造的成员对象，直接执行其析构函数
#include <iostream>using namespace std;class C {int m;public:C(){cout<<"in C constructor"<<endl;}~C(){cout<<"in C destructor"<<endl;}};class A {public:A(){cout<<"in A constructor"<<endl;}~A(){cout<<"in A destructor"<<endl;}};class B:public A {public:C c;char* resource;B() {resource=new char[100];cout<<"in B constructor"<<endl;throw -1;}~B() {cout<<"in B destructor"<<endl;delete[] resource;}};int main() {try {B b;}catch(int) {cout<<"catched"<<endl;}}/* outputin A constructorin C constructorin B constructorin C destructorin A destructorcatched*/
可以看到成员对象被释放，但是b中构造函数如果申请了内存则没有调用析构函数以释放，导致内存泄漏
个人看法
更好的做法应当是添加一个构造器函数，首先进行参数检验，通过了再将参数传入构造函数，不通过则提示用户重新输入参数
智能指针管理内存资源，其生命周期和资源绑定，自动释放内存。问题仍是被构造函数的析构函数没有调用
文章摘要3
6.4.1中提出对于极限编程的下表
问题提出
上文中提出的“计划没有变化快”解决方案是“那就别做详细的设计、做频繁的增量开发、重构和频繁地发布”是否过于极限？频繁的重构带来的工作量可能大于设计的工作量，还会导致代码的可扩展性不强
资料调查
过于频繁的重构可能会导致代码的可读性和可维护性降低，因为频繁的修改会增加代码的复杂度和难度，使得代码难以理解和修改。
重构和发布的过程也会增加额外的工作量和风险，因为每次重构和发布都可能会引入新的问题和bug，需要额外的测试和验证工作。
个人看法
应当根据具体项目需求确定是否采用这种极限的开发方式，如果项目变化较频繁，设计所用时间甚至赶不上市场变化的节奏，那么可能可以采用这种设计方案
其余时候都应当遵循设计优先的原则，保证充分的单元测试、版本控制以保证更新迭代过程中的可迭代性
文章摘要4
9.5中提出风险管理的最高境界：“第四层次:把问题变为机会( Opportunity）从关注风险的负面影响转化为关注风险能否带来正面的机会。例如:一个开发 PC 桌面办公软件的团队，没有多少份额，预计到移动设备的大量发展可能会对 PC 造成冲击，自己的产品在 PC 端发展前景更不好。于是提前布局，加强针对移动设备的开发特别是不同设备之间的同步功能。经过一段时间的努力，反而在移动和 PC 端都有很大收获。”
问题提出
这里提出的场景似乎很理想，现实往往是各级市场都偏向饱和，PM应当如何挖掘市场潜力、看到可行的努力方向呢？
资料调查
市场挖掘是产品经理工作中的一环，市场调研的方式有：
用户访谈和调查
竞品分析
数据分析
行业报告和趋势分析
个人看法
市场挖掘需要对市场和用户进行深入的了解和分析。在现实中，市场往往饱和，但是也可能存在一些细分市场或者需求点，产品经理应当善于发现和挖掘这些机会点，找到自身产品的差异化竞争点，并加强对产品的特色功能开发和推广，提高产品在市场上的竞争力。
（我自己不能解决的问题）
文章摘要5
12.2中提出“倘若认知阻力大，学习曲线就会比较陡;但是经过学习和练习，如果用户适应了新的认知模式，工作效率便会有较大的提高。 ...... 需要指出的是，软件工程师往往以熟练掌握认知阻力大的工具而自豪(例如命令行操作、VIEmacs 等编辑器 )，这对于工程师的工作是有帮助的;但是大多数用户的心理是要躲避认知阻力。IT 产品的用户，有些是喜欢高科技的，喜欢尝试新的交互方式和体验;大部分还是依赖于传统和系统提供的指令来交互，他们希望IT 系统升级之后，还是熟悉的界面，东西还是在老地方。当UX 设计师决定把亿万用户熟悉的交互方式(例如 PC 的“开始”按钮 )颠覆的时候，他们为这些用户考虑了么? 技术团队的成员大多是熟悉科技的男性，而产品的用户则男女老少、各行各业都有，如何为广大用户设计呢 7 ?”
问题提出
为什么软件工程师往往以掌握认知阻力大的工具而自豪？或者说真正影响软件工程师选择一款软件的核心驱动力是什么？
资料调查
软件工程师并不总是倾向于掌握认知阻力大的工具，如vscode因为其简洁易用而被选择
存在这种心理的工程师，往往也认为：掌握复杂工具是技能水平的体现，这可以让他们在职业发展中更有竞争力。
个人看法
软件工程师更多看重效率，如果任务需求较为频繁，人们更愿意花费时间学习工具、进而提升生产力水平
此外的场景中，如任务不够频繁、追求简洁易用的程序员，更多追求的仍是认知曲线较平缓的开发工具
如果觉得《《构建之法：现代软件工程》阅读提问》对你有帮助，请点赞、收藏，并留下你的观点哦！
