你见过的最差的程序员是怎样的？-duidaima 堆代码

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

发布于 3天前
 3 热度

 0 评论

科叼
2 粉丝 217 篇博客

我见过的最差程序员，差到让整个团队崩溃

作为一名在嵌入式领域摸爬滚打近十年的老兵，我见过太多奇葩程序员了。但要说最差的，非"赵工"莫属。

初见赵工

那是我从机械调剂到电子部门的第二年，公司接了个重要项目，需要开发一款基于STM32的工业控制系统。领导从总部借来一位"资深嵌入式专家"——赵工。

初见赵工时，他西装革履，一副成功人士模样。"我做过BAT核心项目，对单片机开发了如指掌"，他面试时的豪言壮语，让领导对他寄予厚望。

"独特"的编码风格

接手项目的第一周，赵工就展示了他的"实力"：

void Do_Something(void)
{
    u8 a;
    u8 b;
    u8 c;
    u8 i;
    u8 j;
    u8 k;
    a=1;
    b=2;
    if(a==1)
    {
        for(i=0;i<10;i++)
        {
            if(b==2)
            {
                k = i + 1;
                //do something here
            }
        }
    }
}

没错，这就是他的编码风格——变量命名全是单字母，没有注释，缩进混乱，函数名毫无意义。当我问他这些变量代表什么意思时，他瞪了我一眼："代码就是写给机器看的，能运行就行，哪那么多讲究？"

"高效"的调试方法

赵工的调试方法更是"高效"。有一次系统死机，排查原因时，他直接往代码里塞了几十个printf：

printf("here1\n");
if(temp > 50) {
    printf("here2\n");
    control_valve();
    printf("here3\n");
}
printf("here4\n");

任何正常程序员都会使用条件断点或日志系统，但他偏要用这种原始方法。更可怕的是，调试完成后，这些垃圾代码常常被他忘记删除，留在生产代码中。

"革命性"的存储管理

记得有次他在处理EEPROM存储时，创造了这样的"杰作"：

// 存储用户配置
void save_config(void)
{
    // 直接从0地址开始写，不管有没有其他数据
    EEPROM_Write(0, (uint8_t*)&global_config, sizeof(global_config));
}

// 加载配置
void load_config(void)
{
    // 没有任何校验，直接读取
    EEPROM_Read(0, (uint8_t*)&global_config, sizeof(global_config));
}

没有地址规划，没有数据校验，没有版本管理。当我提醒他这会导致数据混乱时，他不以为然："又不是大型系统，用不着那么复杂。"

结果可想而知，产品一上线，用户配置经常莫名其妙丢失或混乱。

远离坑货机会

技术大厂，前端-后端-测试，新一线和一二线城市等地均有机-会，感兴趣可以试试。待遇和稳定性都不错~

"高级"的内存管理

在一个需要处理大量传感器数据的模块中，他写出了这样的代码：

void process_sensor_data(void)
{
    // 每次分配固定大小，用完不释放
    uint8_t *buffer = malloc(1024);
    
    // 处理数据...
    
    // 没有free操作
}

这个函数每分钟会被调用几十次，内存泄漏严重。当系统运行几小时后必然崩溃。我指出这个问题时，他竟然说："单片机会自动回收内存的，不用担心。"

我当时就懵了，这种基础常识都不懂，他是怎么通过面试的？

"创新"的版本控制

提到版本控制，赵工也有独到见解。公司用Git管理代码，他却坚持用自己的方式：

从不写commit信息，或者就写个"update"
本地修改后直接push到master分支
代码出问题了，就复制整个项目文件夹重命名为"project_backup_0415"

有一次他把整个主分支代码弄坏了，急得团队其他成员直冒冷汗。当问他为什么不用分支开发时，他理直气壮："那太麻烦了，我一个人开发用不着那些东西。"

"高超"的团队协作

赵工的团队协作能力堪称一绝。记得有次我接手他的一个模块进行扩展，打开代码后惊呆了：

// 神秘函数
void xyz(void)
{
    u16 m = get_value();
    if(m > 30)
    {
        op();
    }
    else if(m <= 30 && m > 20)
    {
        op2();
    }
    else
    {
        if(flag)
        {
            op3();
        }
    }
}

完全看不懂这函数是干什么的！没有文档，没有注释，变量名全是缩写，函数名毫无意义。我只好硬着头皮找他问。

他却说："代码写出来就是给机器看的，你看不懂是你水平问题。再说了，这是我的核心竞争力，如果写得太清楚，公司还要我干嘛？"

这种"核心竞争力"理论让我哭笑不得。在我看来，真正的核心竞争力是创造价值的能力，而不是制造混乱的能力。

灾难的项目结局

最后这个项目如何收场？你们猜到了。

原定三个月的项目拖了半年，客户不断投诉系统不稳定。在一次重要演示中，系统当场崩溃，客户大怒。公司损失了一个重要客户，也赔了一大笔违约金。

赵工却毫不愧疚，反而抱怨环境问题："肯定是测试环境不对，我本地运行得好好的。"

最终，他被公司礼貌地送回了总部，项目由我和另外两位同事重构。我们花了两个月才把这烂摊子收拾干净。

反思：什么造就了"最差程序员"

回想这段经历，我总结赵工这类"最差程序员"的特质：

技术傲慢：自以为是，不接受批评，拒绝学习新知识
基础薄弱：缺乏编程基本素养，连最基础的内存管理、代码规范都不遵守
自私封闭：视代码为个人财产，故意设置理解障碍
责任推卸：问题永远是别人的，从不反思自己
短视功利：只关心眼前能跑，不考虑长期维护

这种程序员不仅技术差，更可怕的是态度差。他们像一颗定时炸弹，迟早会给团队和产品带来灾难。

与之对比：什么是好程序员

我27岁进入世界500强外企时，遇到一位让我敬佩的技术主管李工。他的代码风格截然不同：

/**
 * @brief 处理温度传感器数据并控制阀门
 * @param temperature 当前温度值(摄氏度)
 * @return 操作是否成功
 * @note 当温度超过临界值时，会自动关闭阀门
 */
bool processTempAndControlValve(float temperature)
{
    // 安全检查
    if (!isSensorValid(SENSOR_TEMP)) {
        logError("Temperature sensor not valid!");
        return false;
    }
    
    // 温度过高，关闭阀门
    if (temperature > CRITICAL_TEMP_THRESHOLD) {
        logWarning("Critical temperature detected: %.2f°C", temperature);
        return closeValve(VALVE_MAIN);
    }
    
    // 正常温度范围
    return true;
}

他的代码：