许多开发人员根据他们过去的经验不断分享提示和技巧。
这些提示和技巧提高了我们的生产力并使我们变得聪明。
但作为成熟的开发者,我们也应该知道,开发者分享的所有建议都是行不通的。
我们应该始终将事实与虚构分开。
在这里,我分享了四个流行的编程技巧,与它们的受欢迎程度相反,它们并没有带来预期的结果。
1. 学习新技术和语言
程序员被告知要不断学习新事物。
平庸的开发人员不断建议其他人学习新技术和新语言。
这些开发人员与其他开发人员在线或离线交互时。 他们唯一的建议是“不断学习新事物。 最终,你将成为一名聪明的开发人员。”
我们,开发人员,到处都被告知我们应该跟上技术世界正在发生的事情。 我们被要求阅读有关最新技术发明的博客和时事通讯。
我不同意这个建议。 以不同的方式投入时间对我们来说会更好。
如果您在一家为其他公司生产产品的公司工作,您就会知道这些公司在未来几年内不会使用新技术来生产产品。 相反,他们将使用一些拥有适当支持和国际社区的旧技术。
那么我们为什么要浪费时间深入研究新技术呢?
如果我必须重写上面的 BS 提示。 我的建议是“不断学习新事物。 你将成为另一个平庸的开发者。”
你应该做什么?
而不是把时间浪费在新技术和语言上。
你能做的就是花时间了解现有的系统。
现有系统所教给您的知识远远多于任何新技术。
新技术的另一个问题是你不知道什么时候会使用它。 你绝对可以用它来构建一个副项目,但它不会有任何好处。
作为程序员,我们不想浪费时间做一些人类不会使用的事情。
现在,如果您构建一个可供其他人使用的副项目,您就必须对该产品进行营销。 这是另一场战斗。
如果您花时间质疑现有系统,您会学到更多。 如果您开始质疑为什么在现有系统中选择特定的设计模式,您将提高对整个系统的理解。
通过质疑现有系统而不是学习新语言,您将成为更好的开发人员。
2.“不要重复自己”是废话
不要重复自己。
不要重复自己。
不要重复自己。
不要重复自己。
不要重复自己。
我不知道我们程序员听过多少次这样的建议了。
至少一百万次。
我们在阅读书籍、博客和观看教程后都了解到,不重复自己肯定有一些好处。
代码重用就是其中之一。 当你保持模块化设计时,干原则将确保有许多重用代码组件。 这样,我们开发人员就可以一次又一次地使用代码。
另一个好处是可维护性。 当我们开发人员需要对代码进行任何更改时,我们只需在一处进行更改,而不是在多个地方进行更改。
我对“不重复自己”原则的看法是,我们被要求在任何地方都遵循它。 是的,使用 DRY 有一些优点,但到处使用它就太多了。
大多数代码审查者都希望代码是枯燥的,你甚至不能在这一点上与他们争论。 在某些情况下,不遵循干燥是合理的。
让我们举一个这样的例子
def calculate_something(a, b):
# Complex calculation logic
result = ...
return result
上面名为calculate_something 的函数根据两个输入值a 和b 计算某些内容。
现在您需要在代码库中的两个地方使用结果。
在这两种情况下,输入值和要使用的结果都会略有不同。
这里的代码可以有两个方向。 我们可以引入一个新函数,也可以选择复制代码以保持简单。
第一个案例
我们将在这里引入一个新函数,以确保我们提取通用逻辑。
def calculate_something(a, b):
# Complex calculation logic
result = ...
return result
def process(a, b):
# Common data processing logic
result = calculate_something(a, b)
def process_something_1():
# Some data processing logic
a = ...
b = ...
process(a, b)
def process_something_2():
# Different data processing logic
a = ...
b = ...
process(a, b)
为了避免重复,我们引入了一个名为 process 的新函数。 代码变得难以阅读。
第二种情况
在这种情况下,我们将重复一遍。
def calculate_something(a, b):
result = ...
return result
def process_something_1():
# Some data processing logic
a = ...
b = ...
result = calculate_something(a, b)
def process_something_2():
# Different data processing logic
a = ...
b = ...
result = calculate_something(a, b)
在上面的代码中,计算逻辑被重复了。
上面的代码违反了DRY原则,但是我们的代码很简单。
我的论点
现在,如果我们的函数 process_something_1 和 process_something_2 没有随着时间的推移而变得复杂。
违反干燥原则总是更好。
而不是给出“不要重复自己”的建议。
我们应该给出这样的建议:“不要重复自己,直到它使代码库变得复杂为止。 为简单起见而优化。”
3.“不要破坏东西”
平庸的开发者不断告诉自己:
“我不被允许破坏任何东西。 如果我破坏了任何东西并且代码库发生了任何不好的事情。 我会被解雇”。
通过告诉自己这一点,这些开发人员会让他们的工作变得无聊且乏味。
作为开发人员,我们的工作是不断在代码库中进行更改,以使软件更加健壮。 当我们开始担心我们可能会破坏某些东西时。 我们变得害怕做出改变,最终我们的生产力下降。
在更改哪怕一行代码之前,一些开发人员都会担心此后可能会出现其他问题。
在进行了几行代码更改后,他们开始祈祷,因为他们不希望任何不相关的功能被破坏。
作为一名开发人员,如果您遇到在进行一些更改后出现问题的情况。 然后你需要修复整个代码库。 您不想使用这样的代码库。
如果你继续使用这样的代码库,整体质量将会下降,你未来队友的日子也会变得艰难。
你该怎么办?
而不是仅仅因为某些东西会损坏而害怕做出任何改变。
进行所需的更改。
如果出现问题,您可以稍后修复。 如果截止日期临近并且由于您的更改而导致某些内容被破坏。
你需要向管理层请求更多时间。 这不是你的错误,代码库从一开始就更糟糕。
现在你必须完成你的工作和数百个其他程序员的工作来解决某些问题。 你需要更多时间。
只是不要害怕,也不要编写平庸的代码。
4.“重写一切”
这个编程建议不是任何程序员给出的。
这是任何程序员都会给自己的一条建议。
每次我们开始与新的代码库交互时,我们的大脑都会对我们说“重写一切”。
我不知道我的大脑向我建议了多少次。
你该怎么办?
首先,不要尝试重写一切。
重写代码并不能保证您不会面临与以前的开发人员相同的挑战。
告诉你的大脑“闭嘴”。 当它建议你重写所有内容时,不要听它。
相反,如果您必须对代码库进行更改,则需要首先了解代码库的不同部分及其测试方式。
您需要了解代码库,以便检查不同组件如何相互交互以及它们具有哪些功能。
当您检查代码库和所有测试时,您将能够了解代码库的结构以及测试方式。
一旦理解了代码和测试,您就可以轻松地进行更改,并且不会引入新的问题。
我们举个例子
假设您必须重组网站的代码库,以允许人们发布他们的想法并稍后进行编辑。
整个代码库看起来很混乱并且难以维护。
你的大脑不希望你浏览混乱的代码库。 它建议您按照自己的风格重写所有内容。
但正如我们之前讨论的,您不会重写所有内容。
您应该查看允许人们创建、发布和编辑消息的文件,而不是重写。 一旦您浏览了这些文件并能够理解事情是如何工作的。
你必须做第二步。 现在您必须查看为代码编写的测试。 如果有测试可以确保帖子正确加载并且编辑成功,那么您应该看一下。
一旦你经历了所有这些。 您可以通过将相关功能分组到不同的文件中来开始重组过程。 这样你就可以使代码变得干净。
现在,当您在代码库中进行更改时,您需要确保旧的测试用例仍然通过。 否则,你必须假设发生了不好的事情。
因此,仅查看代码库并理解它而不是仅仅重写它有很多好处。
概括
不要只关注新事物。
如果这能让你的代码库变得简单,就重复一遍。
爱上破坏事物。
不要试图重写整个事情。 只是不要这样做。