随笔分类 - 《这就是软件工程师》
笔记整理；摘抄
摘要：什么是X-Y问题 X-Y问题就是有人想解决问题X，他觉得Y可能是解决X的方法但不知道Y怎么做；在我们的工作中，需求方给出的来的是Y，而软件工程师不知道需要解决的X是什么。 我理解的X-Y问题是没有找到问题的本质，而在错误的解决方案上浪费时间 避免X-Y问题 遇事目标要明确，多探究问题的本质 下面引用
阅读全文
摘要：互为磨刀石 互相挑毛病。前提是双方都非常信任彼此，因为搞软件大多容易沉浸在自己的问题里，又不太善于做高情商的表达。一遇到沟通问题，一句话说不好就会引发误会。 有了信任的伙伴，你就不再需要费时间去想如何表述问题，无需猜测、有话直说，就算无意间说了不太客气的话，对方也能理解并接受。 互为回音壁 很多时候
阅读全文
摘要：读代码是一种有益的精进方式，类似与阅读和写作，从范文得以借鉴 读代码的过程中，值得重点关注的部分 被反复使用的代码 穿越时间的代码 如果一段代码被使用了很久都没有被淘汰，说明它设计思路很棒，建议关注最旧的部分，可以推敲设计的核心思想 好调试的代码 大概率是因为写代码的人准备好了基础工具，要看看别人早
阅读全文
摘要：分解的目的： 简化问题的复杂度 分解任务的好处 任务分解能帮你理清楚解决问题的思路 子任务完成后，发给评审，有问题的话评审也会很快给你回馈，那么接下来要写的子任务就能避免面同样的问题——小步试错。 怎么分解： 抓住重点，去掉不必要的东西，留下必须要做的，找到任务的主干 按单一职责原则对任务拆解，罗列
阅读全文
摘要：如果修复某个Bug花了很长时间，这时候就要问问自己为什么，怎么做才吸取经验教训，在类似的问题上不再出问题，以及采用的方法，使用的工具是否还有改进的地方； 当所有问题都解决之后，一定要梳理下从最初找Bug到最后改Bug的整个过程 定位Bug 模拟Bug场景：想想什么样的代码才能导致该Bug 二分法：代
阅读全文
摘要：测试 测试工作比较考验全面思考的能力 常见的分类 白盒：清楚内部的东西以及内部是如何运作的 黑盒：不考虑程序内部结构和特性通过输入输出测试 单元测试：白盒测试 主要对基本功能（单元模块）进行测试，只测某个小零件，离问题最近，所以解决问题的成本低； 功能测试：黑盒测试 每个零件都能工作，但不能说明组装
阅读全文
摘要：避免重复原则：相似的代码要想办法抽取出来，达到用这一段代码解决多个问题的目的 单一职责原则：一个类或模块应只有一个职责；例如我要造一辆车，A工厂，只负责生产车轮；B厂，只生产座椅；C厂，只生产发动机；每个人只负责生产一个部件，而我要做的就是把不同的部件组装而已。 高内聚、低耦合原则： 让一个模块做到
阅读全文
摘要：公司/平台选择 优先选择走在未来航道上的那些 快速发展 的公司 确认所选公司是否是一家以技术驱动，以技术文化为主导的公司 新人进入公司后要注意 一般的开发流程是：需求分析➡️设计➡️编码➡️测试 新人进入公司后要注意（新人一般要做的是执行层面的任务）： 应养成良好的工作习惯 培养自己的执行能力，脚踏
阅读全文
摘要：不存在年龄的坎，只存在能力的坎（乐观来讲是这样的） 其实所有行业都是如此，只是软件工程师这一行的容错率会比较低，到了岁数就干不下去了，而在其他行业还能混得下去 35岁是一个接过重担的年纪，因为更大的人可能就慢慢退休了，年轻人这时候也还没成长起来，社会一定会把重担交给30~40岁这群人，若没接住一会掉
阅读全文
摘要：新手：前调执行力，按照方法一步步做，确保每一步不会出错就行 进阶：强调设计能力，对上级提出的要求/任务 进行抽象、拆解（任务的拆解很有技术含量），并独立设计解决方案 高手：需要融汇贯通的的能力——架构师（把技术的演进、需求的变化、系统的发展等多个维度综合起来考虑） 大神：沉淀方法，成为某个方面的权威
阅读全文
摘要：从发展阶段来看，国内的互联网公司大多都处于原始积累阶段，大家都是 你有什么功能，我也要有，本质上就是抄来抄去；这就导致然后大家都拼命扩军、拼命提速，进入一种低维度的竞争状态。 那么这种局面应该如何打破呢？ 如果发明出来更高级的“武器”，就能打破这一局面，那么就算再快也没用（我觉得发明更高级的武器就意
阅读全文
