成为糟糕的码农的21种方法

您必须在不碰一篇文章告诉您如何提高软件开发技能的情况下 , 才能在Internet上摇摇欲坠 。大量文章告诉您如何成为"更好的沟通者" , "团队合作者"和"不断学习" 。

成为糟糕的码农的21种方法

文章插图
Photo by JESHOOTS.COM on Unsplash
但是您知道您从未读过的内容吗? 如何变得蹩脚 。没错-这篇文章 , 告诉您二十一种成为糟糕的软件开发人员的方法 。
为什么要浪费时间? 让我们开始吧 。
1.不要格式化您的代码【成为糟糕的码农的21种方法】格式化代码只会使其更具可读性 。笨拙的编码人员知道 , 未格式化的代码难以阅读且难以维护 。相信我 , 如果您不断使用格式迥异的代码检入代码 , 它将使您的开发人员发疯 。而且无论您做什么 , 都不要使用任何缩进 。
2.使用无意义的变量和方法名称有意义的变量名只会使代码更易于理解 。如果您想变得蹩脚 , 请为变量名使用单个字母 。如果您用完了这些 , 请使用诸如MsgNand FuncMan之类的简短而毫无意义的缩写 。我最喜欢的时间之一是DoStuff方法名称 。
3.不要编写单元测试没有什么比拒绝编写单元测试更能说明"我编写糟糕的代码"了 。它的美丽之处在于 , 随着时间的推移 , 您的代码会变得越来越糟糕 , 因为缺乏测试会使更多的错误逐渐被发现 。
4.尽可能将事物耦合在一起将您的代码紧密耦合在一起会带来各种奇妙的失败 。首先 , 它使您的代码真的很难更改和更新 。其次 , 它使测试和调试变得非常有趣 , 因为在应用程序的一部分中进行更改 , 会导致范围广泛且分布广泛的错误出现在陌生的地方 。还有什么比这更糟糕的呢?
5.编写巨大的方法这是我的最爱之一 。确保您具有执行各种不同操作的方法 。深度嵌入许多if语句可赚取积分 。几乎没有什么比"多次单击Page Down"按钮来查看"整个方法"更能喊出"这真是糟糕的代码了" 。
6.写很多神的类完全忽略代码中的"单一责任原则"会给您带来很多麻烦 。当您可以更轻松地将方法添加到现有类中时 , 为什么将功能隔离到离散类中? 让类承担多重责任可能会导致恶作剧
7.完全不使用抽象硬编码所有内容 。尽可能利用实现 。忽略强大的语言功能 , 例如抽象类和接口 。这些事情只会使您的代码更易于维护 , 而CrAppy Coder并不需要这样做 , 出于善意 。
8.不要学任何新东西Crappy Coders认为 , 软件开发的所有进步都在他们开始第一份工作的那天就结束了 。尝试改进您已经知道的内容只会导致您编写良好的代码并使用新的和改进的技术 。脚的编码员拒绝这样做 。
9.编写糟糕的错误报告如果"在我的机器上工作"不够好 , 没人会说 。确保在提交报告时 , 该报告对问题的描述不正确 , 并且没有任何步骤可重现该问题 。我个人最喜欢的是"此功能已完全损坏" 。这将为需要修复该错误的开发人员确保真正糟糕的维护体验 。如果开发人员离您三个月之久 , 您将获得更多的荣誉!
10.不要费心学习工具 。您看 , 如果记事本不足以满足您的编码需求 , 那么Microsoft永远不会发货 。为什么要花时间学习使用Intellisense , 键盘快捷键或任何其他"生产力黑客"? 它们只是倾向于减少代码的笨拙性并加快开发过程 。
11.如果实际上必须调试 , 请始终使用控制台 。好的 , 所以也许您可能实际上有一天需要修复一个错误 。我知道–谁想要这样做? 但是 , 无论您做什么 , 都不要使用调试器 。相反 , 只需使用对控制台窗口的调用或快速弹出对话框的ShowMessage调用即可 。对于熟练的Crappy Coder来说 , 这已经足够了 。
12.与您的setter和getter产生很多副作用 。这总是很有趣 。确保在setter方法中删除了某些内容 。当您用getter获得价值时 , 请进行更改 。相信我 , 这很有趣 。
13.遵循FRY原则:经常重复自己Crappy Code的标志是在更改和更新内容方面存在困难 。不断地在代码中重复自己是确保更新困难的可靠方法 。使用大量的魔术数字 。为什么要在一个地方声明常量 , 而在34个地方可以使用文字呢?


推荐阅读