其实以前也有类似的想法，但是决定写这篇文章是由下面一件事情引起的。

引子

同事自已造轮子要实现一个rtmp协议，在调试过程由于有一个问题有没有解决，影响团队的联调，对于他造主动造轮子，我是不支持的。重复实现一个完整的rtmp协议，会走很多坑的，需要花费较多的时间，而开源的librtmp已经实现完整的rtmp协议功能，我决定将librtmp协议移植到现在系统。

接着就自己开始干，了解librtmp实现，动手写一个利用librtmp支持epoll的rtmpserver。 在调试过程出现rtmp握手失败的问题，初看定位无果的情况下，我修改了makefile，生成调试的符号表，同时打开调试开关。这些弄好之后，试了一下，没有我期待的符号表与调试信息。

于是我怀疑自己对makefile是否正确。重新学习makefile与编译的一些知识还是无果，觉得makefile修改是正确的。这时候灵光一现，看看进程加载的是哪些lib

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

(gdb) info sharedlibrary 
From                To                  Syms Read   Shared Object Library
0x0000003a74600b00  0x0000003a746198db  Yes (*)     /lib64/ld-linux-x86-64.so.2
0x00007ffff7dd57e0  0x00007ffff7de4358  Yes (*)     /usr/local/lib/librtmp.so.1  #加载的librtmp库
0x0000003c39a18340  0x0000003c39a53558  Yes (*)     /usr/lib64/libssl.so.10
0x0000003c39669cc0  0x0000003c3975dbe8  Yes (*)     /usr/lib64/libcrypto.so.10
0x0000003a76602120  0x0000003a7660d3a8  Yes (*)     /lib64/libz.so.1
0x0000003a74a1ea20  0x0000003a74b3f76c  Yes (*)     /lib64/libc.so.6
0x0000003a8260ac30  0x0000003a82638728  Yes (*)     /lib64/libgssapi_krb5.so.2
0x0000003a8161b430  0x0000003a81694a78  Yes (*)     /lib64/libkrb5.so.3
0x0000003a806013f0  0x0000003a80601fc8  Yes (*)     /lib64/libcom_err.so.2
0x0000003a812043d0  0x0000003a8121d5a8  Yes (*)     /lib64/libk5crypto.so.3
0x0000003a74e00de0  0x0000003a74e01998  Yes (*)     /lib64/libdl.so.2
0x0000003a80a02a40  0x0000003a80a080c8  Yes (*)     /lib64/libkrb5support.so.0
0x0000003a80e00bf0  0x0000003a80e011d8  Yes (*)     /lib64/libkeyutils.so.1
0x0000003a76a03930  0x0000003a76a12938  Yes (*)     /lib64/libresolv.so.2
0x0000003a75205660  0x0000003a75210eb8  Yes (*)     /lib64/libpthread.so.0
0x0000003a76205850  0x0000003a76215cc8  Yes (*)     /lib64/libselinux.so.1
(*): Shared library is missing debugging information.
(gdb)

看到上面的一幕，犯了这样的错误：改对了代码，却没有更新lib

反思

在现实的开发过程中常常碰到下面的情行：

场景1： “我修改了代码，代码也改好，怎么还是这样的？”

场景2： “在我的环境下，测试ok，怎么在你的环境就不行了呢？”

场景3： “前几天运行都ok的，怎么现在不对了？”

场景4： “以前上线都没事，这次同样的操作却没有成功”

场景5： “原来从业务角度出发，可以设计，确实不要那么麻烦”

以上这些问题，很大一部分因素我们只考虑到代码本身而已，还没有考虑代码的深层次问题，也没有考虑代码与业务的关联，在实际系统中很多问题一部分原因也是因为深层上没有了解代码的本质或者没有吃透业务对代码的要求。

代码是核心，但不仅仅是代码，还有下面几个方面需要考虑：

  1. 代码的本质
  2. 测试验证
  3. 系统设计
  4. 业务需求
  5. 部署需求
  6. 监控需求
  7. 升级问题
  8. 团队合作
  9. 安全问题

对此，个人大胆划分四个层次：

  1. 码农，以码为主，停留在代码上，关注代码与算法（如果有足够的天赋研究像人工智能这样的顶级算法，请继续深入研究）

  2. 工程师，以解决具体业务为主，代码作为业务的实现，关注的业务与需求，能够实现技术持续性满足小范围内的业务需求

  3. 架构师，考虑上述各个方面，从需求，设计，实现，部署，演进等各个阶段满足具体一个产品的技术需求，除此之外，主动思考技术对业务的发展的支撑

  4. 技术总监，CXO，创始人，这一层次就不YY了

后记

需要强调的一点：作为程序员写好代码是第一要务，本文强调写好代码的基础上，要从深度与广度角度思考代码与审视代码，这样让自己不停留在代码层面，让自己不仅能技术上取得进步，更能让技术上的进步转化为业务上的价值

自己接下来的重点，除了继续提高自已技术能力，另一个重点加强对业务的学习与研究，用技术更快，更好地满足业务需求

(PS：起了标题，希望后面能够有更深的感悟，写得更具体一些)