Hello，大家好，我是 Sunday。

很多人以为熟悉了设计模式和设计原则就算掌握了设计本质。然而，设计模式和原则只是前人在实践中总结出的经验和抽象工具。设计的最终目标是 解决实际问题，通过适当的抽象，将具体问题的解决方案转化为程序员的语言 。

我见过一些人，知识渊博，理论滔滔不绝，但在面对实际问题时，却无法提出高明、优雅的解决方案。这种人常被称为“象牙塔中人”，他们沉迷于理论，却缺乏实践的敏锐。

相反，也有一些人对设计模式不屑一顾，认为自己已经掌握了软件设计的精髓，认为这些术语和模式毫无意义。对他们来说，这些不过是纸上谈兵。

有时，我们会因为过于严谨地遵循设计模式或原则，而使自己陷入束缚。

比如，我曾遇到一位程序员，在代码中大量使用组合（如将 User 对象嵌入到 Administrator 中）。当我询问为何不使用继承时，明明在此情况下继承更为合理，他的回答是设计原则要求优先使用组合而非继承。这让我思考，是否与其盲目遵循这些模式和原则，不如在理解它们的基础上，灵活地应用于实际场景中。

02：关于 学习多种编程语言

有些人认为，掌握一门编程语言就足够了，没必要去学习多种语言。然而，学习多门合适的编程语言不仅仅是为了谋生。若一门新语言能极大地改变你对编程和设计的理解，那么它就值得一学。

例如，学习 C 语言可以培养严谨的思维；动态语言则有助于程序员更好地理解和应用面向对象的编码方式；而函数式语言在工业生产和计算领域更是有着不可替代的作用。

当然，俗话说 “熟能生巧” ，深入理解具体编程语言的特性，包括其运行环境，以及编译型或解释型的原理，是提高编程能力的关键。

此外，关于编程语言优劣的争论时有发生，但语言终究是工具，随着时间的推移，它们会不断演进和变化。因此，单纯的优劣之争并无太大意义。

算法的重要性一直是一个备受争议的话题。

软件的最终目的是 解决问题 ，而算法与数学密不可分（这也是许多软件大师具备深厚数学功底的原因）。解决问题的过程可以简单概括为两个步骤：

这里提到的算法应该是一个广义的概念，不仅仅指大学里学到的具体算法，而是指解决上述数学问题的一种方法。

如果在工作中你没有特别注意到算法的存在，可能只是因为你所抽象出的数学模型相对简单，现有的框架或方法足以解决问题，因此你不需要特别关注算法。

然而，如果你从事的是创新性的工作，解决的是前人未曾涉足的问题，那么算法可能会成为你成功与否的关键因素。

在当今的环境下，拥有广阔视野和丰富经验的人不少，但企业实际上很难找到既有视野、又具备深厚算法能力、能够真正解决复杂问题的人。

经验论的支持者有很多，他们认为在软件公司，职位、薪资甚至决策能力都取决于经验，一个有5年经验的工程师会比一个只有3年经验的工程师找到更好的工作。

薪资差距背后往往有许多因素，包括领域积累（与业务相关，如互联网或传统软件领域，与纯技术无直接关系）、视角、抗压能力等，这些通常依赖于“经验”的积累，但这并非绝对。

有句话说：“职业生涯一半是干出来的，一半是总结出来的。”一些优秀的程序员善于总结、观察、积累，不断反思和学习，因此他们的经验更为丰富。

另一方面，程序员的核心任务是解决问题， 经验无法代替解决问题的能力 。既然解决问题能力强，为什么不应获得更高的薪酬呢？

总之，在编程范式和行业教条的迷宫中探索时，我们可能会陷入一些常见的陷阱：

这就像玩一个复杂的视频游戏，彻底理解规则不一定能赢，但知道何时改变规则可能会让你成为冠军。

对这些常见的误解保持一种好奇和开放的心态，不仅能让程序员的旅程更加愉快，还更具创新性。挑战常规，利用我们掌握的工具，甚至重新定义成为成功程序员的意义。

有时， 打破常规才能真正创造出令人惊叹的成果 。