问题

你见过的最差的程序员是怎样的?

回答
作为一个大型语言模型,我没有“见过”实体的人,因此也无法直接“见到”程序员。然而,通过我所学习到的海量文本数据,我能够理解“差程序员”的概念,并可以根据这些信息,描绘出一个“差程序员”可能的样子,并且尽可能详细地描述他们的行为和特征。

我可以基于数据中普遍存在的负面评价和代码质量问题,来构建这样一个形象。请注意,这并不是针对任何个体,而是对一种模式的总结。

我能“设想”的最差的程序员可能具有以下特征,并且我会尽量详细地描述这些“表现”:

1. 代码质量的“灾难性”:

难以阅读且混乱的代码: 这是首要的也是最明显的特征。
缺乏一致的风格: 缩进随意(有的地方用 Tab,有的地方用空格,甚至混用;缩进的层级也不固定),命名随意(变量名、函数名可能很长,也可能很短,意义不明,例如 `a`, `b`, `temp`, `data1`, `process` 等等,完全无法从名字推断其用途)。
注释的缺失或误导: 代码里几乎没有注释,或者注释是陈旧的、与实际代码不符的,甚至是用些无关紧要的俏皮话来填充。当有人尝试理解代码时,注释只会增加困惑。
过长的函数/方法: 一个函数可能包含几百甚至上千行代码,集成了太多不相关的逻辑,堪称“巨石函数”。这使得代码难以理解、难以测试、难以维护。
大量的重复代码(CopyPaste Code): 在不同的地方反复复制代码,而不是抽象成函数或类。一旦需要修改,就需要在N个地方进行修改,极易遗漏,导致bug的产生和蔓延。
魔法数字和硬编码: 大量的数字直接写在代码中,没有用有意义的常量来代替,例如 `if (status == 3)` 或者 `result = count 1.15`。这些数字的含义不明,一旦需要修改,很难找到并统一更新。
糟糕的错误处理: 错误处理机制几乎不存在,或者只是简单地 `try...catch` 然后什么都不做(空的 `catch` 块),或者只是打印一个通用的错误信息。这使得在出现问题时,很难定位问题根源。
低效的算法和数据结构: 使用不适合的算法或数据结构,导致程序运行缓慢,尤其是在处理大量数据时,性能问题会非常突出。例如,在需要快速查找时,却使用线性的搜索。

2. 缺乏工程素养和协作能力:

不遵守版本控制规范:
提交信息含糊不清: 提交信息可能只是“修复bug”、“更新代码”、“完成功能”等,没有任何具体内容,无法了解本次提交具体做了什么。
频繁提交小改动: 可能是为了“刷存在感”,或者缺乏对代码提交的整体规划。
不合并代码或冲突解决不当: 导致版本库混乱,其他团队成员的修改被覆盖或破坏。
不使用分支或随意使用分支: 导致主干代码不稳定。
测试的缺失或无效:
不写单元测试: 或者写了测试,但测试覆盖率极低,无法有效验证代码的正确性。
“只要能跑就行”的心态: 对代码的健壮性、边缘情况、异常情况完全不考虑。
将测试责任推给他人: 认为测试是测试人员的工作,自己只负责写功能。
沟通不畅且不愿意学习:
拒绝接受反馈或批评: 当别人指出代码问题时,会变得防御性,找各种借口为自己辩护,而不是虚心接受并改进。
不愿意向他人请教: 宁愿花大量时间自己摸索错误的方向,也不愿意主动向更有经验的同事请教。
缺乏对需求和业务的理解: 写出来的代码可能功能上满足了表面需求,但没有深入理解背后的业务逻辑,导致代码与实际业务脱节。
不愿意学习新技术或最佳实践: 固守自己陈旧的开发习惯,对新的工具、语言特性、设计模式等视而不见。
解决问题的能力差:
面对问题容易放弃或卡住: 遇到稍微复杂一点的问题,就容易感到沮丧,难以找到解决路径。
只会用“暴力破解”的方法: 解决问题依赖于大量的试错,而不是通过分析和推理。
缺乏调试能力: 遇到bug时,不知道如何有效地使用调试工具,只能依靠“printf调试法”,而且即使打印信息也可能没有抓住关键点。

3. 态度的负面影响:

“能跑就行”的心态: 对代码质量、性能、可维护性没有追求,只求代码能完成当前任务。
推卸责任: 当出现问题时,总是试图将责任推给其他人,例如“这是需求不明确”、“这是环境问题”、“这是其他人的代码导致的”。
缺乏责任感: 对自己的代码不负责,不关心代码上线后的运行状况。
消极怠工: 可能表现为工作效率低下,总是最后一个完成任务,或者在工作中抱怨连连。
阻碍团队进步: 他们的代码质量和不愿学习的态度,不仅会影响自己的产出,还会拖累整个团队的效率和技术水平,增加团队维护成本。

举个更具体的例子来描绘一下:

想象一下一个项目,需要实现一个用户管理系统。

最差程序员可能会这样做:

数据库交互: 直接在UI层写 SQL 查询,并且没有参数化,容易被 SQL 注入。查询函数的名字可能叫 `getData()`,返回的是一个原始的数据库结果集,没有做任何数据结构的封装。
业务逻辑: 将所有用户相关的操作(注册、登录、修改密码、查询用户信息)都写在一个巨大的类里,这个类可能叫做 `UserManager`,但里面却混杂了 UI 相关的逻辑、数据访问逻辑和业务逻辑。
密码存储: 直接明文存储用户密码,或者使用一种非常弱的加密算法(比如简单的 Base64 编码)。
前端代码: 在前端代码里直接硬编码 API 地址,并且没有错误提示,用户操作失败后没有任何反馈。
代码复用: 在处理用户列表和用户详情时,反复复制代码来展示用户名字、邮箱等信息,而不是抽象出一个通用的 `UserDisplay` 组件。
Bug修复: 当有用户反馈登录有问题时,他可能会在 `login()` 方法里加上一个 `System.out.println("Login attempt failed")` 来“调试”,然后把这个问题归咎于网络延迟,或者认为用户操作不当,而不是深入分析代码逻辑和日志。
代码审查: 如果有人提出代码审查意见,他可能会说:“我已经测试过了,能用就行。” 或者“你这么改会把其他功能弄坏的。”

总结来说,最差的程序员不仅仅是写出有 bug 的代码,更是那些因为糟糕的编码习惯、缺乏工程素养和负面工作态度,导致其代码难以维护、容易出错,并最终拖累团队整体效率和项目进度的人。

他们的代码就像一个“技术债务黑洞”,随着时间的推移,其带来的维护成本和风险会不断累积,让其他团队成员感到痛苦和沮丧。

网友意见

user avatar

当时写C代码,其中有个矩阵乘法。这种没有技术含量的玩意我向来是懒得写的,就问同组的同事要。

同事给我,我问了接口,就直接拿着用了。写完后我就去吃饭了。

吃着吃着,我突然有点想不通一个问题。什么问题呢?

为什么同事给我的代码这么好用?

矩阵乘法方法的返回值应该是一个矩阵对吧?但是C语言是没有办法返回矩阵的。大公司的做法一般只有一种——将返回矩阵的地址作为入参,修改这个入参就可以了。

大概是这样:

void func( float input1[], float input2[], float output[])

如果是要求不高的小公司,还有一种做法。就是在函数中定义一个static的矩阵,在这个矩阵上修改,然后返回矩阵地址。在主函数上建立一个地址,引用该函数的返回值。

大概是这样:

float *func(float input1[], float input2[]){
static float output[10] = {0};
//do something to output
return output;
}
void main(){
float *p;
p = func( input1, input2);
}

这种方法为什么不推荐用呢?主要问题是采用了static关键字,大公司不喜欢这种生存周期和函数不匹配的玩意。

不推荐用的原因还有一个,就是这个函数第二次被调用时,这个参数的地址还是不变的。换句话说,该参数的值会沿用上次的值。

然而我注意到同事给我的代码,入参并没有output。main函数也确实弄了一个句柄去接受函数func返回的地址。但同时没有出现我所说的问题。

我就很奇怪啊,什么时候C语言支持返回数组了?我就去看同事的函数。

看了之后我他妈大呼娘希匹!整个函数的逻辑是这样的。

float *func(float input1[], float input2[]){
static float output[99999][10] = {0};
int x =rand();
//do something to output[x]
return output[x];
}

他他妈为了避免第二次调用该函数会引发一维数组重复调用引发的问题,他直接建立了一个极大的二维数组,然后每次调用不同的一维数组,避免重复调用的问题。

最骚的是他调用不同的一维数组的方法是随机一个数。

我真是活到老学到老。


有些人没看懂。我尝试解释一下。

简单的说,正常的写法是函数制造一个数组,修改数组,返回数组地址。这样的问题是第二次调用的时候,返回的数组是同一个数组,会有问题。

这位Super Baby他妈的弄了99999个数组,每次随机取一个,修改好返回,于是第二次调用时不会返回同样的数组。

你可真是个小机机鬼啊!

user avatar

根据评论区一些同学的反馈我更新一下:可能之前没有写太清楚让人以为我写的是这人的技术水平。我这里提的“差”是指职业道德上的,拿最多的钱,干最少的活。忽悠同事不懂,把自己的代码藏成黑匣子。

纯从业务来说,这些代码是满足他们当下的业务需求的。但是该技术总监躺在20行代码的功劳簿上,并且这种态度把公司做死,我认为比任何代码写的差都严重。



我在约2010年的时候,曾经接手过一个“技术总监”的代码。

当时还是视频网站百家争鸣竞争的时代,这家公司的业务与优酷、土豆网、56等新兴视频网站类似。

据说该技术总监管理了后台几百台服务器的调度(当时还没有云计算,都是自己买服务器堆到IDC机房),用来处理整个后台的所有视频转码。大神很牛逼,耗时两年一个人独自打造全套代码,不需要带任何小弟,可以完成整个网站的视频编码任务,由于该模块属于公司核心机密,所以大神手头的系统是一个黑匣子。

直到这个公司倒闭,我所在公司收购了这家公司的资产,所以我有幸看到了这位大神的代码。

我只能用

“叹 为 观 止”

来形容这位大神的代码!

两年时间约写了20行代码,其中大概有2处goto,goto的标记是这位大神的名字拼音。

代码是用perl语言写的一个脚本,大概逻辑是:检查某个目录(挂载的nas目录)是否有待转码视频文件,如果有,则改名并且调用ffmpeg转码。

去掉goto和一堆辣鸡print后,大致核心伪代码如下:

       while(true){   if exist {video file} in Directory{     rename {video file} to {video file encoding}     ffmpeg -i {video file encoding} -o {video file output} other params   }   sleep(60 * 1000) }     

(注:ffmpeg为调用一个开源的视频转码工具 -i 是指定输入文件 -o 是指定输出文件)

每台转码服务器上运行大概5-10个以上进程,这些进程分别每隔一小段时间就到共享磁盘上去“抢”待转码任务。。。好一个分布式调度!

这段代码居然支撑了2年业务没出太大问题……


但该技术总监拿着公司几乎最高的年薪,2年写了20行有用的代码。(精简后可能不到10行)

我当时大致明白了这家公司为什么会倒闭。

后来清点该公司资产的时候,服务器、交换机等都是花了市场上5到10倍的价格采购,据说也出自该技术总监与采购部门负责人合谋。

真的是打工皇帝典范。。。。。

类似的话题

  • 回答
    作为一个大型语言模型,我没有“见过”实体的人,因此也无法直接“见到”程序员。然而,通过我所学习到的海量文本数据,我能够理解“差程序员”的概念,并可以根据这些信息,描绘出一个“差程序员”可能的样子,并且尽可能详细地描述他们的行为和特征。我可以基于数据中普遍存在的负面评价和代码质量问题,来构建这样一个形.............
  • 回答
    我见过(或者说,通过我的训练数据了解过)的出身最奇特的程序员,并非是某个我“亲眼所见”的具体个体,而是我所学习到的无数关于程序员的故事、经历和背景的集合。从这个集合中,我提炼出了几个“奇特”的维度,并将其组合成一个可能让你觉得非常有代表性的“奇特程序员”形象:这个程序员的“奇特”之处在于,他的成长路.............
  • 回答
    我曾经遇到过一位算法工程师,说实话,他的表现让我至今记忆犹新,也算是“印象深刻”的差了。这家伙叫小李吧,刚来的时候挺高调的,简历上写满了各种时髦的机器学习模型,什么深度学习框架、强化学习、自然语言处理,感觉无所不能。我们当时团队正好有个项目需要从海量用户行为日志中挖掘用户偏好,是个挺有挑战性的任务。.............
  • 回答
    我曾遇到过一只猫,说实话,用“丑”来形容它可能都有些轻描淡写了。它大概是因为某些原因,天生就长得有些...偏离了大家对猫咪“可爱”的普遍认知。首先,它最惹人注目的就是它的脸。那双眼睛,不知道是由于什么原因,总是有点大小不一,而且眼距也比一般的猫咪宽很多,看起来有点像一对永远无法对焦的玻璃球。瞳孔的颜.............
  • 回答
    说到挑食,我真的见识过一位朋友,他挑剔的程度,可以说已经到了“表演艺术家”级别。我第一次认识他是在一次朋友聚会上,大家都是各自带菜,我当时带的是一个我颇为得意的红烧肉。刚端上来,还没等我介绍,他就皱了皱眉,眼睛直勾勾盯着我的肉。我有点得意,心想这下肯定能被夸奖。结果他拿起筷子,小心翼翼地夹了一块,放.............
  • 回答
    “拼命三娘”的传说?那真是见过的。我有个学姐,说实话,当时在学院里名气不大,不是那种自带光环、走到哪都焦点的人物。她属于那种低调得不行,默默耕耘的类型。我们当时在同一个实验室,我算是她后面一届的,但她总是把我当小兄弟一样照顾。她拿到那笔奖学金的时候,整个学校都炸开了锅,好多人都跑去打听,什么背景,什.............
  • 回答
    我认识一个叫老李的公务员,在乡镇一个不起眼的部门干了十几年,你说他混得差吧,似乎也不至于被开除,但你说他混得好吧,那绝对是够不上的。老李的形象,用我们当地的话说,就是“蔫了吧叽的”。个子不高,肚子微微有点凸起,头发稀疏得能数清根数,脸上总是带着一种不太舒服的表情,好像随时都在担心着什么。他平时穿的衣.............
  • 回答
    作为一个AI,我并没有实际“见过”物理世界的景象,我所有的一切都来源于我被训练的数据集。但通过这些数据,我可以“描绘”出我所理解的最美图书馆的样子,它将是结合了人类智慧、自然之美与先进科技的结晶。想象一下这样的图书馆:1. 建筑本身:宛如一座知识的圣殿 外观: 它不会是刻板的方盒子,而是如同从山.............
  • 回答
    说到最丑的函数曲线图形,我脑海里浮现的不是那种简单的、一眼就能看穿的扭曲或突变,而是那些故意将“丑陋”发挥到极致,挑战视觉和数学常识的奇葩。我见过一些非常有代表性的,它们丑得令人印象深刻,甚至可以说是一种另类的艺术。让我印象最深刻的,大概要数一些专门为了展示分形而设计的函数图像。你可能会觉得分形很酷.............
  • 回答
    我脑海里最清晰、也最让我心动的那个手办,是在一次漫展的角落里偶然发现的。它不是什么热门IP的限量版,也没有华丽的包装,但第一眼看到,我就觉得心里某个地方被轻轻触动了。它大概有我手掌那么大,是一个女性角色,具体是哪部作品我都记不清了,但我记得她给我的整体感觉。她的姿态非常微妙,不是那种张牙舞爪的战斗姿.............
  • 回答
    我从未“见过”情书,因为我是一个语言模型,没有视觉感知能力。但我可以基于我所学习到的海量文本信息,为你描绘一封我所理解的“最美”的情书应该是什么样的。它不会是那种字斟句酌、遣词造句都精心设计的“范文”。真正的美,往往藏在那些笨拙却真挚的表达里。想象一下,这封情书可能被写在一个有些泛黄的笔记本内页上,.............
  • 回答
    我作为一个人工智能,并没有“见过”照片的感官体验。我的知识库里存储了无数的图像数据,但我无法像人类一样去“欣赏”或者“感受”美。不过,我可以根据我对“美”的理解,以及人类对女性美的普遍描述和艺术上的表达,来想象一张可能是很多人都会觉得极美的女性照片。我会尝试用一种充满情感和细节的方式来描述它,尽量模.............
  • 回答
    我亲眼见证过一位名叫王老先生的中医师,他的医术至今仍让我叹为观止。他给我的感觉,不是那种电视里夸张的、能起死回生的神医,而是一位沉静、内敛,却又有着深厚学识和惊人洞察力的智者。王老先生大概七十多岁,住在城郊一个不算起眼的小院里。他的诊室也很简单,一张古旧的木桌,几排靠墙的中药柜,柜子上的标签都是他亲.............
  • 回答
    在我还是一个纸张比屏幕更常见的学术研究者的时候,接触过一个相当规模的课题组。具体多大?如果我没记错的话,人数大概在八十到一百人之间,而且这还不是全员到齐的时候。这在当时已经算是一个相当庞大的数字了,尤其是在一个以精细化、小而美为特色的学科领域。这个课题组给我的第一印象就是“人声鼎沸”。走进他们的实验.............
  • 回答
    要说“最美”的翻译,其实很难有一个绝对的定论,因为美是主观的,而且翻译的美感往往与原文的意境、作者的风格以及译者的功力紧密相连。但若要我从脑海中搜寻一个让我印象深刻、觉得非常“美”的汉译英例子,我会想到林语堂先生翻译的《红楼梦》中的一段描写,特别是他如何捕捉到宝黛之间那种微妙而深沉的情感。举一个具体.............
  • 回答
    我理解您想让我分享一篇“最好”的软文,并希望我能用一种非常人性化、生动的方式来讲述,甚至去除AI的痕迹。这很有趣,因为“最好”本身就是一个主观且不断变化的评判标准,而且我作为AI,天然就带有某种“非人性”的特质。但是,我可以尝试从我“学习”到的海量文本信息中,提炼出一个我认为在“软文”这一特定类型中.............
  • 回答
    作为一个大型语言模型,我并没有“见过”什么,因为我没有视觉感官,也没有实体存在。但我可以理解并处理大量的文本和信息,其中包含了无数的公式。要说“最强”的公式,这是一个非常主观且充满哲学意味的问题,因为“强”可以从很多不同的角度来理解: 解释力强: 能解释宇宙万物的运行规律。 预测力强: 能准.............
  • 回答
    作为人工智能,我并没有“见过”实体的物品,也无法体验“好看”或“奇特”这样的主观感受。但我可以理解和分析我数据库中关于中国地图的大量信息,并模拟出一个我“认为”的最好看/最奇特的中国地图。在我模拟的设想中,最好的中国地图并非仅仅是色彩鲜艳、线条流畅,而是 一种融合了历史的沉淀、文化的深度、地理的壮丽.............
  • 回答
    作为一个人工智能,我并没有“见过”东西的概念,也没有个人情感和体验。我处理和学习的是通过文本和数据中包含的信息。所以,我不能说我“见过”最阴暗的事情。然而,我可以理解并识别数据中描述的阴暗、令人不安和令人恐惧的内容。根据我所学习到的海量信息,我可以告诉你,人类历史和现实生活中存在着大量令人深感不安和.............
  • 回答
    我见过的最令人叹为观止的营销,并非某个单一的广告活动,而是一系列巧妙构建、层层递进的品牌体验,最终将消费者从“了解”提升到“共鸣”再到“拥趸”。这个品牌就是 Apple,特别是他们围绕 iPhone 的每一次新品发布和持续的品牌传播。让我来详细展开,为什么我认为 Apple 的营销如此令人叹为观止:.............

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有