就目前来看，我对软件的认识还停留在调代码的层次。稍微读了读《软件工程》第9版，虽说因为英文版读起来很费劲，而选择了读某中文翻译版，但还是只读了一点点。从这本书中，看到了文档在软件过程中的重要地位。
最初接触编程，是在小学的微机课上。当时在DOS系统下，用的某BASIC语言，老师也仅仅讲过一条命令：PRINT 表达式。用PRINT把算术运算的结果显示出来而已。随着时间的推移，到了大学，才学习到汇编语言和C语言。如果仅仅把C语言当玩具，倒是可以玩出很多花样，比如做个魔方的模型，用3D绘图把魔方显示在屏幕上，然后玩家用鼠标操作，任意调整方向观察魔方，把打乱的魔方还原回来。不过那仅仅是玩具，不是软件。
软件，其中一大部分，是文档。在做项目的开始，我们想得挺美，要做什么的文档都有，分析任务，照着文档，看看通信协议，有不明白的地方，或是有歧义的，查下文档，OK了。结果开始干活的时候发现，哪有文档啊？各种MCU的Data Sheet不算在文档的范畴。最多也就是个通信协议，还是个什么都没说清的通信协议，想知道这个量是要高字节在前还是低字节在前？猜去吧，协议里边绝对不告诉你。有符号无符号更不用想了，根本不可能找得到。到最后才发现，一条CAN报文里面8个字节，有4个数据A、B、C、D，都是各占俩字节，其中A和B是高字节在前，C和D是低字节在前；同时，同样是高字节在前的A和B，数据A是有符号整数，数据B是无符号整数；C则是浮点数，报文里面要放大100倍之后取整，按照有符号数添，D也是浮点数，却是使用放大倍数和偏移量，修整到无符号整形。同样都是EB 90这么两个字节，解析出来确是完全不同的4个数。
好了，我们自己写文档吧。拿来模板，在上面改吧。发现，不去写代码，就不知道该写些什么。最后，文档和代码完全对应不上。就这样，其他人在这个版本上添加功能的时候，一直在重犯我们犯过的错。我们不怕犯错误，千锤百炼之后，对于曾经研究过的部件，一旦发现错误，我们可以根据现象，大致猜到错误发生在什么地方。但是，我们不会想去把这个思路整理成文档。虽然我们的绩效里面有“典型案例”这么一项，但这个是硬指标，导致我们只是为了交差，而写些无关紧要的东西进去。真正值得分享的，真正希望推广的，是不会写进去的。就算想写，区区一千字的指标是写不清楚的，写太多的话，提交绩效时，会没有时间去整理绩效里面其他部分。
我们的那强大的OA系统，上面有我们提交的所有典型案例，每篇文章有谁读过，都是有记录的。但是，几乎所有的典型案例，阅读的人就那么两三个。当然，我们使用的OA系统本身，对浏览器的支持不好，也有一定的关系。甚至其中的文档不支持在linux系统下的在线阅读，即便在Windows系统下，在各种主流的浏览器中，文档都显示不出来，显示的就是一灰框，想下载也下载不下来，运气好下载下来，也是文件已损坏，重下几遍都是已损坏。
结果，前辈们的心血我们浪费掉了，我们的积累后辈们也得不到。我们的现状，还是跟试用期时一模一样。
我们从各种渠道得知了Linux系统的存在，于是打算去学习Linux相关的知识。深受微软影响，对Linux只可远观，就算学会了使用gcc之类的工具进行Linux的代码编译，直到现在也只是在虚拟机里面，偶尔敲敲用用而已。我倒是曾经在一个硬盘分区中装了个基于Linux的Debian系统，但是玩坏了不知道如何恢复，后来就删了。
我们还只是把软件当成敲代码而已。希望提高文档编写的能力，能够成为软件开发的正规军。