|
|
|
[indent,全文共1755字，预计学习时长6分钟
[/indent,图源：pixabay
面临无数抉择是程序员工作的常态，有时候我们明知道一些决定没什么好处，但还是会做出这些错误的决定。
造成程序员们明知故犯的原因多种多样：追寻刺激，或只是犯懒诚然，有时候我们会享受做坏事的乐趣。但是有一件事可以确定，下面提到的这些事情，实在不应该太频繁地做。
快刀斩乱麻式的解决方案
有时候明知道自己选择的并非最佳方案，但最终还是选择了该方案，因为它很快速，这能为修复其他问题预留出了更多的时间。这个逻辑听起来似乎没毛病是吗？
在一定时间内解决某个特定问题会让人心情愉悦，但是运行代码只占工作非常小的一部分。快刀斩乱麻式的解放方案会给后续工作带来更严重的缺陷，这些缺陷则会导致更多的技术债务。
回想一下自己曾经的那些粗制滥造的代码，无论何时你都应该意识到那些所谓的“解决方案”可以让整个团队遭受毁灭性打击。
你可能会说，在某些情况下，它们确实有用（例如在代码寿命短的情况下）。但是，当需要长期运行代码的时候，这种快速但并不彻底的修复方式会反咬你一口，别再说什么“我稍后会处理”这种连小孩子都不信的鬼话了。
裕度设计
图源：pixabay
大部分开发人员选择运行某个设计模式是没什么特殊原因的，仅因为看到了可以运行设计模式的机会，但这并不意味着你可以随意处理。
这就是典型的裕度设计，你要做的就是在代码库中增加更多的技术深度。裕度设计往往发生在开发人员还没有遇到很大挑战的时候。一旦出现了裕度设计的苗头，他们就开始寻找挑战了。
另一种导致裕度设计的原因是我们总是设想添加的某段代码，觉得它总会在以后派上用场。这段附加代码虽然被添加进去了，但可能从未发挥过作用。裕度设计是解决不存在的问题的代码，这也许是对它最恰当的解释了。
闷声犯大错
这种事对新手开发者来说十分常见，也时不时会发生在资深开发人员身上。但是，与新手开发人员不同的是，他们往往是在故意犯错。
当面对大量让人焦头烂额的问题而截止期限马上来临的时候，你已经没有时间一一解决这些将流入漏洞跟踪器的问题了。为了避免被某些通知打扰，有时你会选择任其发生，反倒是把精力集中在剩余任务上。
大部分情况下，闷声犯大错并非有意为之，而是因为缺乏经验或不了解低级代码的内容。你可以想一想什么情况下会闷声犯错，例如，由于无处报告而导致创建日志文件失败。可以的话，最好不要这样做。
一拖再拖
拖延是普遍现象。当开发人员陷入困境或“无法进入项目”时，他们往往会选择拖延。这会导致你完全淹没在无尽的工作中，以至于无法完成任何事情。
如果你不想因无尽的拖延而浪费时间，将工作任务分成不同的小任务会帮助你前进。但如果这种方法也不管用的话，那你可能就要稍微休息一下了，让大脑得到充分的放松。只有行动才会战胜拖延。
从头再来
图源：pixabay
开发人员总会时不时遇到要重新从头开始构建事物的情况。开发人员也喜欢这种构建方式，因为这是帮助其真正理解各项环节的最佳方式。
我们享受着从头再来的过程，但这种快乐不会经常造访。由于时间紧迫，必须要在截止时间之前完成目标。所以，我们不推荐推倒重来的方式，那样太浪费时间。有时候时间成本是合理的，但有时候是无法衡量的。
对有些任务来说，它们至关重要，如果失败就会造成严重后果。这时候，把一切推倒重来就不是最佳选择。
编写错误的提交信息
很多开发人员在编写提交信息时都栽过跟头，尽管他们也明白这些错误从长远来看会造成不好的影响。我们理解为什么大家不愿花时间好好编写提交消息。你已经花了好几天修复好了某个功能，现在终于可以提交最终版本了，当然越早完成越好。
但是，花时间好好编写提交消息很关键。从这些消息中，我们能得到已更改的内容和相关原因等有用信息。当真的出现问题时，修订历史记录是快速查出确切原因的重要渠道。
图源：pixabay
总而言之，这不是些好习惯，那些故意为之的程序员很可能是为自己找好了借口，但趁早摆脱这些坏习惯才是问题的最终解决之道。
留言点赞关注
我们一起分享AI学习与发展的干货
如转载，请后台留言，遵守转载规范 |
|
发表于 2020-7-13 11:39:19
