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

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

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

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

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 的代码，更是那些因为糟糕的编码习惯、缺乏工程素养和负面工作态度，导致其代码难以维护、容易出错，并最终拖累团队整体效率和项目进度的人。

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

当时写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个数组，每次随机取一个，修改好返回，于是第二次调用时不会返回同样的数组。

你可真是个小机机鬼啊！

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

纯从业务来说，这些代码是满足他们当下的业务需求的。但是该技术总监躺在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倍的价格采购，据说也出自该技术总监与采购部门负责人合谋。

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

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

你见过出身最奇特的程序员是什么样的？

你见过最差的算法工程师能差到什么程度？

你见过最丑的猫丑到什么程度了？

你见过最挑食的人达到什么程度？

武汉一女大学生手握 6 篇 SCI，斩获 200 万元奖学金，你见过最努力的人努力到什么程度？

你见过的混得最差的公务员是什么样的？

你见过的最美的图书馆什么样子？

你见过的最丑的函数曲线图形是什么？

你见过的最美的手办是什么样的？

你见过的最美的情书是怎样的？

你见过的最美的女性照片是哪张？

你见过的最好的中医是什么水平？

你见过的最大的课题组有多大？

你见过的最美的翻译（汉译英）是什么？

你见过的最好的软文是哪一篇？

请问你见过的最强的公式是什么？

你见过的最好看的/最奇特的中国地图是什么样的？

你见过的最阴暗的事是什么？

你见过的最叹为观止的营销是什么？