十年编程路，这些观点我变了又没变
十年编程路，这些观点我变了又没变
在软件开发这个瞬息万变的领域，十年时光足以让一个开发者历经无数项目，积累丰富经验，也会让最初的观点发生诸多改变。今天，就让我们一同走进一位资深开发者的十年，看看他在软件开发的世界里，哪些观念发生了转变，又有哪些始终坚守。
十年间，那些 “变” 了的观念
简单并非与生俱来，而是持续努力的成果
曾经，或许会天真地认为简单的代码和设计是自然而然的。但在十年的摸爬滚打后发现，保持简单是一件极具挑战性的事。每一个简洁高效的系统背后，都离不开开发者持续不断的打磨与优化。在项目推进过程中，需求不断变化，技术也在持续更新，要在复杂的环境中让代码保持简单易懂、易于维护，需要时刻保持敏锐的洞察力，不断审视和重构代码，这绝非易事。
管理或理解复杂性并无值得骄傲之处
以前可能觉得能够驾驭复杂的代码和架构是一种能力的体现，甚至会为此感到自豪。但现在明白，复杂性往往意味着更多的潜在风险和维护成本。真正优秀的开发者，不是去炫耀自己能处理多么复杂的系统，而是想办法降低系统的复杂性，让代码更易于理解和维护。如果陷入对复杂性的盲目追求，可能会忽略项目的核心价值，让开发过程变得艰难且充满隐患。
强类型语言在经验参差不齐的团队中至关重要
对于经验水平不一的团队来说，强类型语言的优势就凸显出来了。在弱类型语言环境下，代码的灵活性可能会导致一些潜在的错误在运行时才暴露出来，这对于经验不足的开发者来说很难排查和修复。而强类型语言能够在编译阶段就发现许多类型相关的错误，降低错误发生的概率，提升代码的稳定性和可维护性。它就像是团队协作中的一道防线，即使有人犯错，也能及时被发现，避免错误在代码库中蔓延。
Java，因 “无聊” 而伟大
曾经对 Java 可能存在一些误解，觉得它相对保守、缺乏一些新兴语言的 “酷炫” 特性。但如今却认为 Java 是一门出色的语言，恰恰是因为它的 “无聊”。Java 拥有稳定的生态系统、丰富的类库以及严格的语法规范，这使得开发人员能够专注于业务逻辑的实现。在大型项目中，这种稳定性和规范性尤为重要，它可以减少很多因语言特性带来的不确定性，让开发过程更加可控。
REPL（交互式解释器）：探索有用，设计无力
REPL 在探索新技术、快速验证想法时非常实用，能够即时看到代码的执行结果，方便进行试验和学习。但在系统设计阶段，它的作用就大打折扣了。设计一个完整的软件系统需要全面的规划和架构设计，REPL 的即时性和临时性无法满足这种系统性的需求。在设计时，需要考虑模块之间的交互、系统的扩展性等诸多因素，这些都不是 REPL 能够轻易解决的。
多数编程工作应在敲代码之前完成
过去可能认为编程就是写代码，但现在意识到，在真正开始编写代码之前，还有很多重要的工作要做。需求分析、系统设计、架构规划等前期工作，对于项目的成功起着决定性作用。只有在充分理解需求、设计好合理的架构之后，编写代码才会更加顺畅高效。如果前期准备不充分，后期可能会频繁返工，导致项目进度延误、成本增加。
前端开发：从热爱到 “噩梦”
曾经或许对前端开发充满热情，但如今却觉得它宛如一个卡夫卡式的 “噩梦世界”。前端技术更新换代极快，各种框架、库层出不穷，开发人员需要不断学习新的技术和规范。而且，前端开发要兼顾不同浏览器的兼容性、复杂的用户交互需求等，这些都让前端开发变得异常复杂和繁琐，曾经的那份热爱也在这种复杂的环境中逐渐消磨。
优雅，并非真实可用的衡量标准
在软件开发中，“优雅” 这个词常被提及，但它其实很难被量化和定义。过去可能会追求代码的优雅，认为优雅的代码就是好代码。但在实际项目中发现，过于追求优雅可能会导致代码复杂难懂，增加维护成本。在很多情况下，能够高效解决问题、满足需求的代码才是好代码，而不是单纯追求形式上的优雅。
优秀的管理价值无可估量
在职业生涯的大部分时间里，可能没有真正见识到优秀的管理是什么样的。但当遇到一位出色的管理者时才明白，好的管理能够合理分配资源、协调团队成员的工作、为项目指明正确的方向，让整个团队的效率大幅提升。优秀的管理者就像团队的 “定海神针”，在他们的带领下，团队成员能够充分发挥自己的优势，共同为项目的成功努力。
DynamoDB：特定场景下的好选择
DynamoDB 并非适用于所有场景，但如果项目的工作负载与它的特性相匹配，那它就是一个不错的数据库选择。例如，对于一些需要高并发读写、对扩展性要求较高的应用，DynamoDB 能够提供很好的支持。它的灵活架构和强大的性能，在这些特定场景下能够发挥出巨大的优势。但如果项目需求与它的特点不相符，强行使用可能会带来很多问题。
拥抱对象与函数式编程的优势
曾经可能会盲目追捧某种编程范式，比如过度推崇函数式编程而忽视了对象的优势。但现在认识到，对象在封装数据和行为方面有着独特的能力，它能够很好地模拟现实世界中的事物和操作。而函数式编程在处理数据变换、保持代码的纯洁性等方面表现出色。在实际开发中，应该根据具体的需求和场景，灵活运用不同的编程范式，而不是盲目地坚守某一种。
十年沉淀，途中形成的新观点
工程的本质是沟通
软件开发不仅仅是编写代码，更多的是人与人之间的沟通协作。与团队成员、产品经理、客户等各方进行有效的沟通，才能准确理解需求，避免误解和返工。良好的沟通可以确保项目方向正确，团队成员之间配合默契，提高开发效率。如果沟通不畅，可能会导致开发出来的产品与需求不符，浪费大量的时间和精力。
别在 Java 中过度使用单子（Monad）
在 Java 中，单子虽然是一种强大的函数式编程工具，但过度使用会让代码变得晦涩难懂。Java 本身的语法和编程风格更倾向于面向对象编程，过度引入单子会让代码风格变得混乱，增加其他开发者理解和维护代码的难度。除非有非常明确的需求和场景，否则不建议在 Java 中过度使用单子。
别轻视任何技术难题
如果觉得某个技术问题很简单，那往往是因为还没有真正理解它。在软件开发中，很多看似简单的问题背后可能隐藏着复杂的原理和潜在的风险。在面对问题时，不能掉以轻心，要深入研究和思考，确保真正掌握了问题的本质，避免因为轻敌而导致后续出现更多的问题。
给予年轻开发者成长空间
年轻开发者充满活力和创造力，应该给予他们足够的空间去探索和尝试，允许他们犯错。在错误中，他们能够快速成长，积累宝贵的经验。作为经验丰富的开发者，应该扮演好引导者的角色，帮助他们从错误中学习，而不是一味地批评指责。
投资软技能，收获立竿见影
在软件开发领域，软技能同样重要。积极提升沟通、团队协作、问题解决等软技能，能够在工作中立即看到回报。良好的软技能可以帮助开发者更好地与团队成员合作，提高工作效率，解决项目中遇到的各种问题。例如，有效的沟通可以避免很多不必要的冲突和误解，让项目进展更加顺利。
应用开发与库开发的差异
在一般的应用开发中，不需要过度追求抽象。很多时候，根据实际需求编写简单直接的代码就足够了。因为应用开发更注重解决具体的业务问题，过度抽象可能会增加代码的复杂性，降低开发效率。而在库开发中，抽象则是关键。通过抽象，可以提取出通用的功能和算法，提高代码的复用性，让其他开发者能够方便地使用库来解决类似的问题。
ORM（对象关系映射）并非万能
在各种编程语言和实现中，ORM 虽然在一定程度上简化了数据库操作，但它也带来了很多问题。ORM 会隐藏底层的 SQL 操作，使得开发人员难以优化数据库性能。而且，ORM 在处理复杂查询和事务时，可能会出现一些意想不到的问题。在很多情况下，直接编写 SQL 语句反而更加灵活高效，能够更好地满足项目的需求。
函数式编程的 “烦恼”
函数式编程本身是一种强大的编程范式，但部分函数式编程人员过度强调其理念，使得在实际开发中，一些代码变得过于复杂和难以理解。在追求函数式编程的纯洁性和优雅性时，有时会忽略项目的实际需求和其他开发者的感受。在使用函数式编程时，应该在保持其优势的同时，也要考虑代码的可读性和可维护性。
Serverless 的隐患
从长远来看，过度依赖 Serverless Functions 可能会带来很多问题。虽然 Serverless 在初期能够快速搭建应用，降低开发成本，但随着项目的发展，可能会面临供应商锁定、成本不可控等问题。而且，Serverless 架构在某些场景下的性能和稳定性也有待考验，在选择技术架构时，需要充分考虑这些潜在的风险。
类型即对世界的断言
类型在编程中起着重要的作用，它可以看作是我们对程序中数据和操作的一种断言。通过明确的类型定义，可以让代码更加清晰易懂，减少错误的发生。同时，类型系统也有助于代码的维护和扩展，当代码规模变大时，类型能够帮助开发者更好地理解和管理代码。
分布式锁：依旧棘手的难题
尽管技术在不断发展，但分布式锁的实现仍然充满挑战。在分布式系统中，由于网络延迟、节点故障等因素，实现一个可靠的分布式锁并不容易。不同的分布式锁实现方式都有其优缺点，在实际应用中，需要根据具体的场景和需求选择合适的方案，并且要充分考虑各种可能出现的问题。
正式建模与分析不可或缺
正式建模和分析是软件开发中一项至关重要的技能。通过建立精确的模型，可以更好地理解系统的行为和性能，提前发现潜在的问题。在设计复杂系统时，正式建模和分析能够帮助开发者做出更合理的决策，提高系统的质量和可靠性。
集成测试的关键：隔离性
在一套好的集成测试中，隔离性是最重要的属性。隔离性可以确保每个测试用例之间相互独立，不会因为其他测试用例的执行而受到影响。这样可以更准确地定位问题，提高测试的可靠性和有效性。如果集成测试缺乏隔离性，可能会导致测试结果不准确，无法及时发现和解决问题。
珍视热爱编程工艺的人
在软件开发行业中，真正热爱编程工艺、追求代码质量的人并不多。对于这些人，应该给予珍视和支持。同时，对于那些不太关注编程工艺的人，也应该以理解的态度去对待，根据他们的实际情况，引导他们提高代码质量，共同推动项目的发展。
渐进式、依赖类型语言的前景
渐进式、依赖类型语言结合了动态类型语言的灵活性和静态类型语言的安全性，为开发者提供了更多的选择。在未来的软件开发中，这种类型的语言有望得到更广泛的应用，因为它能够更好地适应不同的开发场景和需求，提高开发效率和代码质量。
测试代码：注释多多益善
在测试代码中，添加再多的注释都不为过。测试代码的目的是验证功能的正确性，而清晰的注释可以让其他开发者更容易理解测试的意图和逻辑。当项目规模变大，测试代码变得复杂时，注释能够帮助开发者快速定位问题，提高测试代码的可维护性。
始终不变的坚持
莫为代码风格等琐事纠结
在开发过程中，有些人会过分纠结于代码风格、代码检查规则等琐碎的事情。在作者看来，这些固然重要，但与项目的整体架构、功能实现等重要方面相比，它们的优先级应该靠后。开发者应该把更多的精力放在解决核心问题、提高代码质量和项目的整体价值上，而不是在这些细枝末节上浪费过多的时间和精力。
代码覆盖率≠代码质量
很多人认为代码覆盖率越高，代码质量就越好，但实际上并非如此。在很多情况下，代码覆盖率与代码质量甚至呈反比关系。高代码覆盖率可能只是表面现象，代码可能存在很多潜在的问题，比如逻辑错误、性能问题等。代码质量应该从多个维度来衡量，包括代码的可读性、可维护性、功能正确性等，而不仅仅是代码覆盖率。
单体架构仍有优势
单体架构曾经是主流的架构模式，随着微服务的兴起，它受到了一些质疑。但实际上，单体架构仍然有很多优点。它的开发和部署相对简单，易于维护和测试。对于一些规模较小、业务逻辑相对简单的项目来说，单体架构是一个不错的选择。而且，即使是大型项目，在某些阶段，单体架构也能发挥出它的优势。
RDBMS（关系型数据库管理系统）的地位难以撼动
经过几十年的研究和改进，RDBMS 已经非常成熟和稳定。它在数据的一致性、事务处理、复杂查询等方面具有很大的优势。虽然现在有很多新兴的数据库技术，但在大多数情况下，RDBMS 仍然是项目的首选。除非项目有特殊的需求，否则很难找到比 RDBMS 更合适的替代方案。
微服务架构需谨慎抉择
微服务架构在近年来得到了广泛的应用，但并不是所有项目都适合采用微服务架构。很多项目在没有充分评估自身需求和实际情况的前提下，盲目采用微服务架构，结果导致系统变得复杂难以维护，增加了开发和运维的成本。在选择微服务架构时，需要有充分的理由和规划，确保它能够为项目带来真正的价值。
别盲目追求 “可扩展性”
大多数项目，即使是在 AWS 这样的云计算环境下，其实并不需要过度追求 “可扩展性”。很多项目为了追求所谓的 “可扩展性”，在架构设计和技术选型上花费了大量的时间和精力，结果却发现这些扩展性根本用不上，反而增加了项目的复杂性和成本。项目应该根据实际需求来设计架构，避免盲目跟风，过度追求一些不切实际的目标。
部分项目经理 “可有可无”
在作者看来，大部分项目经理在项目中并没有发挥出应有的作用。很多项目经理缺乏专业的技术知识，无法有效地协调技术团队的工作，甚至可能因为不合理的决策和管理方式，导致项目效率低下。如果这些项目经理消失，项目的效率可能不会受到影响，甚至可能会有所提升。虽然这个观点有些极端，但也反映出在项目管理领域，确实存在一些需要改进的地方。
十年的软件开发历程，让这位资深开发者对很多技术和理念有了新的认识。这些变化和坚持，不仅是他个人的经验总结，也为广大开发者提供了宝贵的参考。在不断变化的技术浪潮中，我们都在持续探索和成长，或许再过五年、十年，我们的观点又会发生新的变化。但无论如何，保持开放的心态，不断学习和反思，才能在软件开发的道路上走得更远。你在软件开发过程中有哪些观点发生了改变呢？欢迎在评论区分享你的经历和看法。
本文原文来自CSDN