共计 1079 个字符,预计需要花费 3 分钟才能阅读完成。
前言
每位开发人员在本人的职业生涯、学习经验中,都会出一些坏习惯,本文将列举开发人员常犯的坏习惯。心愿大家可能意识和扭转这些坏习惯。
不遵循我的项目标准
每个公司都会定义一套代码标准、代码格局标准、提交标准等,然而有些开发人员就是不遵循相干的 标准,命名不标准、魔鬼数字、提交代码笼罩别人代码等问题常常产生,如果大家可能遵循相干标准,这些问题都能够防止。
用简单 SQL 语句来解决问题
程序员在开发性能时,总想着是否能用一条 SQL 语句来实现这个性能,于是实现的 SQL 语句写的非常复杂,蕴含各种子查问嵌套,函数转换等。这样的 SQL 语句一旦呈现了性能问题,很难进行相干优化。
短少全局把控思维,只关注某一块业务
新增新性能只关注某一小块业务,不思考零碎整体的扩展性,其余模块曾经有相干的实现了,却又反复实现,导致反复代码重大。批改性能不思考对其余模块的影响。
函数简单简短, 逻辑凌乱
一个函数几百行,简单函数不做拆分,导致代码变得越来月臃肿,最初谁也不敢动。函数还是要遵循设计模式的繁多职责,一个函数只做一件事件。如果函数逻辑的确简单,须要进行拆分,保障逻辑清晰。
不足被动思考,拿来主义
实现相干性能,先网上百度一下,拷贝相干的代码,可能运行胜利认为高枕无忧。到了生产却呈现了各种各样的问题,因为网上的 demo 程序和理论我的项目的在场景应用上有区别,尤其是相干的参数配置,肯定要弄清楚具体的含意,不同场景下,设置参数的值不同。
外围业务逻辑, 短少相干日志和正文
很多外围的业务逻辑实现,整个办法简直没看到相干正文和日志打印,除了本人能看懂代码逻辑,其他人基本看不懂。一旦生产出了问题,找不到无效的日志输入,问题根本无法定位。
批改代码,短少必要测试
很多人都会存在幸运心里,认为只是改了一个变量或者只批改一行代码,不必自测了应该没有问题,殊不知就是因为改一行代码导致了重大的 bug。所以批改代码肯定要进行自测。
需要没理清,间接写代码
很多程序员在接到需要后,不怎么思考就开始写代码,写着写着发现自己的了解与理论的需要有偏差,造成无意义返工。所以须要多花些工夫梳理需要,整顿相干思路,能躲避很多不合理的问题。
探讨问题,表白没有逻辑、没有重点
探讨问题不交代背景,上来就说本人的计划,他人听得云里雾里,让你从头形容你又讲不明。须要学会沟通和表白,能力进行无效的沟通和单干。
不能从谬误中吸取教训
作为一位开发人员,你会犯很多谬误,这不可避免也没什么大不了的。但如果你总是犯同样的谬误,不能从中吸取教训,那态度就呈现问题了。
总结
对于这些坏习惯,你是否中招了,大家应该尽早躲避这些坏习惯,成为一名优良的程序员。