今天开一个装13的话题~
起因是前几天，有一个老同学发了条朋友圈，提到他当年写c程序养成的扣KB的习惯一直都在。（翻译一下，就是想尽一切办法节省内存，一个字节一个字节地扣）
这位老同学是经常活在我的谈资里面活古董，资历绝对够，当年卖过光碟、徒手反编译写过小卫星的操作系统、有幸跟他还一起改过BBS、Mud源代码，他当老师的时候比苍井空还早一些。
背景渲染完毕，说正事~所谓上一代程序员，自然是跟如今90后、00后这一代来比较，并不是说更早的那一代程序员，那是源码写在纸带的那一代。
上一代程序员坚持的是高效、节约内存、节约磁盘I/O、节约屏幕输出、节约一切能节约的东西。甚至可以为了节省几个字节，重新调整struct的定义顺序...
但这种坚持在如今CPU过剩，内存都上T的时代，经常被人嗤之以鼻：有这个时间可以抄好多个py、php、js脚本了，废这个事干嘛呢？只要能按时交付一个可以跑起来的东西，老板基本是不会去追究跑的到底如何的。这在如今的天朝IT圈早就是不成文的共识了。憋上半年甚至一年，去认真打磨出来一个系统这种事，如今也只有老家伙才会干。比如，之前开源了一套物联网DB系统源码的那家伙。
本来想也说点别人的例子，鉴于同一件事，不同人理解可能截然相反，为了避免给其他人带来困扰，索性只讲几个自己做过的小事，现在看应该就是所谓的执念~
有个项目，因为需要几种常见图片对格式做解码，嫌开源的图片、视频处理库太庞大，各种用不到的特性一大堆，最要命的是各种溢出太多，不放心直接使用。索性举刀，从几套开源库里抽出来了JPEG、TIFF、BMP、GIF等几个格式的解码代码，重新做了一个小巧的解码库。为了搞定市面上见过的所有溢出和常见的图片编码错误不崩溃，拿了几百万图片做测试。自然，这套系统在我不维护那个项目以后被人改成了著名的能直接溢出拿root权限那套开源破烂。至于后来，在线发个图片就开shell的事情大规模流行后，我每天做的事，就是转一圈喜滋滋地催他们排期，更换成无漏洞的库。
后来跟几个刚毕业的小伙子说，你们要用这个那个功能，那就自己抽出来呗，没必要继承那么大一套垃圾进去，遂被白眼...
还有个项目，需要在线缓存一些常用数据，我竟然要求方案设计成cache不准使用超过100MB内存，并且准实时地在硬盘做cache数据的灾难恢复机制。如果一定要超过100MB，也不是不允许，先得给我计算一下到底为啥会超，当时开发此项目的只有一个人表示认同这个要求。
还有个项目，为了节省每次数据处理周期能少几秒，扔掉了python写的全套东西，换回C实现了核心逻辑，一比较，效率提升100倍。因为好奇py到底有多慢，还用perl又写了一遍，仍然有10倍提升，果断彻底抛弃py。后来，还要求在线系统不得使用py，遭白眼无数。
另有个项目，因为需要处理的数据规模庞大，每小时都要以T来计算，跟一个70后的强兄弟一起商量半天，最终决定把现网所有服务器每块硬盘做成无raid的方式。当时，那破服务器每台有12块-16块硬盘。按规矩做事的运维自然坚决不同意，最后没办法，只好自己动手悄悄搞定。敢这样做，是因为数据基本上处理周期只有几次，需要优先保证快速写入，处理完后即使整盘挂掉的数据损失也可以承受。而那批服务器有200多台，最多的时候超过300台，而且是别人都不愿意用的老旧机型，是旧型号机械硬盘。
又有个项目，核心代码只有几千行，自己花了1个多月憋出来的，全程基本无锁，上线后在我手上维护跑了有5年，基本没崩溃过。后来我换岗位，项目自然换人维护，中间听说被改过几次，但都无法在线上稳定跑，会出现各种意想不到的崩溃，最后结论是无法修改扩充，得彻底换掉。算起来总共跑在线上差不多有10年。其实，原因很简单，在数据处理阶段，可以引起逻辑死锁和冲突崩溃的情况都被干掉了，后来接手的人只是不愿意去了解这些而已，自然也就改不出来。再后来，我招了一个b程序员，在另一个项目上重新重写了这部分算法，在保证准确率的前提下、效率又提升了接近10倍。
还有个好玩的，因为不喜欢标准MD5特别容易就被撞库撞出来，但又无法拒绝MD5的快速，索性找到并改了一个用的人非常少的非标的MD5库。
在非常流行Java实现AI算法的时候，凑热闹，写过一套基于Java的AI处理系统，跑起来的时候发现不崩溃，但系统慢的要死，各种资源都直接红线卡死。认真研究了一下，最后结论是Java的GC垃圾回收系统有问题，经常是等到该GC的时候系统已经无法响应了，死循环。这个问题当年一直无法解决，最后直接放弃Java，遇到大数据量的情况时，严禁使用Java去处理，这个要求也是持续n年频繁被白眼，直到py流行开才没人提Java了，哈哈哈~
要说个人最坚持的东西，那肯定得讲这个：每年招人的时候，明知90-00后这一波已经基本没人听说过Perl，还是会问懂不懂Perl...
(图片来自sogou，图侵删)
