把记账 App 拆成三块。
计算机基础 · 小纸条
选一章打印。双面打印(按长边翻页)后沿虚线剪开,每张卡片正面题目、背面答案。
一个"工具类"里放了日期处理和网络请求,问题在哪?
怎么判断耦合高不高?
这和函数的参数返回值是一个道理吗?
存储换成另一种数据库,业务代码该不该改?
一个类既算价格又发邮件,违反了什么?
为什么改老代码风险大?
为什么说"不是必须用"?
什么时候需要它?
单例的坏处是什么?
参考答案(家长):内聚太低,两件事没关系,该拆开。
参考答案(家长):如数据存储、业务逻辑、界面显示。
参考答案(家长):是,函数签名就是最小的接口。
参考答案(家长):看改一处要跟着改几处,越多耦合越高。
参考答案(家长):单一职责,价格规则和邮件模板变化的原因不同。
参考答案(家长):不该,说明中间需要一层存储接口。
参考答案(家长):硬套模式会让简单问题变复杂。
参考答案(家长):可能碰坏已经在正常工作的部分。
参考答案(家长):难测试、隐藏依赖、并发时要小心。
参考答案(家长):创建逻辑复杂、或者要根据条件创建不同类型时。
这和你学过的什么很像?
排序规则可切换,适合用它吗?
判断该不该用模式的标准是什么?
检查你的代码有没有这五样。
给一段长函数做一次"提取函数"。
为什么不全用端到端测试?
一个"有时通过有时失败"的测试有什么害处?
先写测试的好处是什么?
为什么覆盖率能骗人?
为什么越早发现越省事?
参考答案(家长):适合,每种规则一个策略。
参考答案(家长):像 Scratch 里的广播消息。
参考答案(家长):有就是重构的机会。
参考答案(家长):不用它是不是真的会带来麻烦。
参考答案(家长):太慢、太脆弱,出错时也难定位到具体原因。
参考答案(家长):把独立的一段抽出来起个好名字。
参考答案(家长):接口设计更合理,也保证了一定有测试。
参考答案(家长):会让人不再信任测试,最后干脆忽略它。
参考答案(家长):改动少容易定位,隔久了要在一堆改动里找。
参考答案(家长):跑过但没检查结果,覆盖率照样很高。
频繁小发布比一次大发布好在哪?
环境不一致通常差在哪?
为什么密码尤其不能写进代码?
日志该记什么?
为什么不全开?
只有日志够不够?
这和狼来了的故事像在哪?
请求变慢了先看哪个?
为什么"以后小心点"不是有效措施?
这五个问题为什么关键?
参考答案(家长):语言版本、依赖库版本、系统配置、编码设置。
参考答案(家长):每次改动小、风险低、出问题容易定位和回退。
参考答案(家长):关键操作、异常、以及排查需要的上下文。
参考答案(家长):代码会被提交和分享,密码会跟着泄露。
参考答案(家长):不够,日志是事后查,监控是事中发现。
参考答案(家长):量太大、影响性能、真正的问题反而找不到。
参考答案(家长):先看监控确认范围,再用追踪定位具体环节。
参考答案(家长):假警报多了,真出事没人当回事。
参考答案(家长):它们决定了架构该往哪个方向做。
参考答案(家长):靠人小心不可靠,要靠机制:加检查、加测试、加限制。