左耳听风 - 成长中的问题「读书打卡 day 06」

你好！我是 Java 工程师蔡姬，此蔡姬非彼菜鸡！很高兴和大家一起共读陈皓老师的《左耳听风》一书，并在这里分享自己的感悟。

我的读书打卡将会分为两部分——笔记 + 打卡。

• 笔记部分，我会整理在读书过程中感悟比较深的内容，和你一起分享。

• 打卡部分，我会就一个点阐述个人的思考。

话不多说，让我们开始吧！

笔记

• 好的技术应该支持用更少的成本获得更好的产品。良性的成长也符合这一规律，用尽可能少的时间、实践和试错成本，获取尽可能完善和强大的技术能力。

选广度还是深度

• 选择源于目标。

• 广度是深度的副产品，只要深入探究，自然会拥有广度。

• 只要不是浅尝辄止，鱼和熊掌可以兼得。

如何保证工程进度

• 在开始实施前，先仔细思考解决方案，这有助于确保进度。

• 解决方案是自己拍脑袋想出来？还是借鉴“最佳实践”或前人经验呢？

• 在做技术决策时，是否能找到数据来支持决策？“这样做可能会更好”或“用户应该会喜欢”这类猜测可能带来错误的假设。

• 尽量将长线任务拆分为能在一周内完成的多个子任务，因为越容易实现的任务越能调动执行力。

如何良性地工作

• 计算机专业不是一门让人仅为了谋生而存在的专业。

• 你不需要特别出类拔萃，但只要你学到的技能比较扎实，就足以通过很多公司的面试。

如何跟上技术迭代

• 技术更新的速度越来越快，紧跟技术前进的步伐这件事的难度就越来越大。此时，或许可以选择另辟蹊径，关注不怎么变化的部分，比如基础知识。原因是虽然很多基础知识多年来都没有太大变化，但是它们同样重要，甚至变得更加重要。可见，在变化中找到不变的东西很重要。

• 什么是不变的东西呢？计算机基础知识、操作系统的原理、编程范式、算法和数据结构，等等。

• 想跟上技术迭代的速度，技术的交流也很重要。

技术人的创业赛道

• 很多人想找创业的新路子，就是所谓的蓝海。对此，我的建议是一定要选择红海。因为红海一般是大公司竞争的领域，大公司激烈竞争，说明该领域的资本较多。事实上，“教育”用户的成本远高于做产品的成本。如果你的新产品是用户从来没有用过的东西，你就必须通过“烧钱”来改变用户的习惯，而这通常只有大公司才能做到。

• 较为成熟的一种创业方式就是锚定大公司挣钱的领域。

• 懂技术的人只需要做一件事，那就是把技术的成本降低。

• 用户从来不会拒绝廉价的产品，哪怕产品的性能、指标不尽如人意。只要产品有成本优势，总能找到合适的场景。

• 要关注用户的黏性，其中一种方式就是，让用户在弃用产品时必须付出较高的沉没成本。

• 我个人认为，协作型软件会是一个盈利的方向，Adobe 的单机版软件未来可能会被在线版的协作软件代替。

• 尽管个人很难写如此复杂的软件，但是可以为某些厂商的应用市场写插件。应用市场天生就有流量，只要你的插件定位不太偏，是很容易赚到钱的。

算法面试之弊

• 你的思维习惯于依赖某个标准答案，但是标准答案会阻止你思考，从而使你的思维固化下来。

• 性能等非功能性需求有可能不是最重要的。在解答算法题时，我们太注重算法的时间和空间复杂度了，想要在时间和空间方面找到最优解。受这个思维影响，我们只会机械地思考算法内部的性能，而忽略了算法外部的性能。

• 当谈到性能时，通常每个人都会问：请求量有多大？如果请求量为 m 次，则使用 O(n) 复杂度算法的最终复杂度为 O(n * m)，这一点学术派永远想不到。

做技术工作的基本修养

• 在技术上精耕细作的确可以降本增效。

• 直到今天，我们正在把人变成“机器”，而机器正在努力通过 AI 技术变成“人”。

• 一定要去做可以让自己与众不同的事情。

• 比起公司，我更看重职业和行业。

如何选择技术

• 选择一项技术，以确定自己未来的发展方向，要考虑几个条件：

• 这项技术是否已被大公司使用？大公司是否投入了时间和金钱来支持这项技术？

• 这项技术是否有“杀手级应用”？也就是说，用它开发的某个产品是否出类拔萃？

• 这项技术的社区是否有热度？不管它是开源还是闭源技术，其所在社区的发展态势如何？

• 是否有其他人为这项技术做出贡献？其他软件是否与其兼容？对于该技术，是否有标准委员会？

• K8s 是必须要学的。因为你学的不是这个软件，而是其运维范式和方法。K8s 的运维思路和 Spring Cloud 有很多相似之处，有其不变的设计模式和方法论，不容易过时。

• 在拿时间和精力投资一项技术前，需要做大量的调研工作。

• 计算机原本用来处理输入和输出，从文本、图片到视频，输出的形式越来越高级。而 AR、VR 作为更高级的输出形式，有可能会符合用户的最新需求。更高级的输出对更大的算力、带宽和数据量有要求，而由于计算机硬件要处理的数据量越来越大，正好在持续提升算力、带宽和存储能力，二者不谋而合，可见 AR、VR 有前景。如果有招聘职位数量和大公司资金投入等数据作为支持，得到的结论会更加准确。

ChatGPT 的峥嵘未来

• 在试用了一段时间后，我对它有了如下认识：

• ChatGPT 不是基于事实的，而是基于语言模型的。

• ChatGPT 并不能保证内容正确，只能呈现精彩的回答套路。

• ChatGPT 是一个语言模型，如果得不到足够的数据和信息，它基本上只能胡编乱造。

• 所有于信息或文本处理相关的软件应用和服务都将因 ChatGPT 而重生，这将是新一轮的技术革命。

• 与 ChatGPT 需要成长一样，程序员也应该厚积薄发。成长难免遇到问题，但解决这些问题既是成长的原因，也是成长的结果。可以说，它就是成长本身。

打卡：如何在完成工作产出的同时持续成长？

软件工程师的工作内容包括但不限于沟通需求、设计方案、编写代码、测试代码、部署上线等。

在我看来，在完成工作产出的同时持续成长，需要保持对每个环节精益求精的态度。

• 沟通需求：在沟通需求时，我会问自己一些问题：

• 我是否真正了解需求背后的用户故事？

• 需求是否合理？

• 需求是否是长期的？

• 有没有更深层次的需求？

通过对这些问题的思考和沟通，我能获得更完整的业务视角，也能逐步建立更深的业务思考。

• 设计方案：在设计方案时，我也会问自己一些问题：

• 方案是短期的还是长期的？

• 方案是某个业务场景通用的还是只能解决特定分支问题的？

• 方案是否是可扩展的？

虽然很多时候，我们会因为时间紧、任务重、资源紧张等这样那样的原因，而倾向于使用临时方案。但我认为，我们起码需要思考长期方案是怎样的。只会设计短期方案的软件工程师，不是好的软件工程师。使用临时方案“救火”固然重要，但更好的方式是通过良好的长期设计防患于未然。

• 编写代码：在编写代码的过程中，我同样会问自己一些问题：

• 代码的可读性、可复用性、可维护性以及可测试性怎么样？

• 代码的风格是否统一？

• 代码是否具备完整的单元测试？

• 是否使用了经过验证的最佳实践？

• 代码对异常情况和边缘案例的处理如何？

• 代码是否存在可能的性能瓶颈？

代码质量是一个软件工程师的名片。在完成工作产出的过程中，追求高质量的代码输出是每一个软件工程师应该做的。

• 测试代码：在测试代码的过程中，我仍然会问自己一些问题：

• 代码表现是否符合业务的功能要求？

• 测试是否覆盖了边缘案例？

• 是否需要进行性能测试？性能基准是怎样的？

测试代码的过程和编写代码的过程同样重要，二者的面向角度不一样。编写代码的过程，思考更多的方向是“人”；测试代码的过程，思考更多的方向是“机器”。为了保证你提交的代码的质量，每一次提交代码的动作之前，都要进行严格的测试。一句话，“不要相信自己的代码！”

• 部署上线：在部署上线的过程中，也有一些比较通用的问题：

• 部署过程是否自动化？

• 如何提升部署效率？

• 部署上线是否有完整的 SOP？

• 是否有部署失败的回滚方案？

• 部署过程是否会对服务上下游造成影响？

唯有不断地思考，才能不断地提高。

经常听有人说，“我所做的工作就是增删改查，没什么成长可言”。我对此观点并不认同。在我看来，再简单的业务，只要是公司的线上服务，就会有很多需要考虑的点，这些点就是成长的机会。

只要在每个节点精益求精，注入思考，就能在完成工作产出的同时持续成长。

以上便是今日份的笔记和打卡内容。欢迎你在评论区留言，我们一起探讨，共同进步。

我是 Java 工程师蔡姬，期待和伙伴们有更多交流和思维碰撞，明天见！