【程序员成长之路】

 

背景

 

从业两年，前一年拼命撸代码，不断学习新的技术，也算是进入了程序员的行列了。后一年由于机缘巧合，接手了一个被别人遗弃但自己的老板看好的项目，从半路开始项目的开发和维护，调试的时间远远超过了开发时间。接触到的新技术少了，但项目总体开发进度、联调等方面的问题遇到的多了，也有了点感触，借此机会抒发一下。

 

这个名字起的有点大了。曾经看过写程序员成长之路的文章，总结的很全很到位，受到过不少启发。但本文只是想要记录一下个人工作上的经历和感悟，简陋错误之处请读者朋友不吝赐教。

 

 

加入程序员的行列

 

本人小硕一枚，毕业于西部某城市，机械电子工程专业。机械不是我热爱的领域，所以偏向于电子，研究生期间捣鼓了点单片机、dsp什么的，参与了AGV的设计和开发，画过电路图，也写过一点代码。毕业找工作的时候我还是比较倾向于硬件设计的，毕竟没有系统地学习过软件相关的课程。

 

但正所谓是有心栽花花不活，无心栽柳柳成荫，做硬件的公司给的offer不太想去，想去的城市却没有硬件的岗位。于是，脑子一短路，就答应了面试时命题硬件的题目的公司里做软件。就这样，我只身一人来到了北京，从事嵌入式软件开发的工作。

 

以前的编程都是给单片机的，基本都是在windows下的IDE里做的，像keil/IAR/CCS什么的，当然也做过VS里的c/c++/c#。而公司里的项目都是linux下的嵌入式c开发，所以当来公司里的时间是痛并快乐着，痛的是两眼一抹黑，linux系统从来没接触过，命令需要从头学起，快乐的是学习新知识进入新领域时的兴奋感，每天上完一天班，都可以掌握几个新命令，很有满足感。

 

和我同期入职的还有一个人，他是自动化专业的，对软件也是没有太深的了解，我们算是半斤八两（也许这也是国企的好处的，招聘的人员还是有充足的时间学习提升的）。刚入职时还挺忙的，由我们两人共同开发一个演示程序，功能很简单：一个客户机，一个服务器，用户在客户机上发送带有密级标识的文件，由该应用程序决定文件是否能够发送，若可以，则发送到服务器，否则丢弃该文件并提示用户失败原因。演示程序使用命令行方式运行，文件的密级标识、加解密方式等都需要自己设计。

 

从此，我就开始了码农之路。

技术提升之路

 

一个很简单的应用程序，涉及到c语言最基本的命令行、文件操作、加解密模式、客户端-服务端通信等。c语言我们都是熟悉的，通过这个小程序，我们学习了liunx操作系统的使用，主要是掌握基本命令行的使用。

 

除此之外，还需要各种工具的支撑：

 

• gerrit代码审查

• git代码管理

• gitlab项目开发管理

• vim/slickedit/sourceInsight

• secureCRT/ssh

 

学习新知识的感受是快乐的，特别是那些掌握了就感觉自己的天空更亮了一点的那种。但面对未知的领域，有时也会感到前途漫漫，步履维艰。这种感觉来自于我独自一人承担一个项目模块的开发的时候，项目涉及到了toml配置文件使用、多线程、进程间通信等。通过这个小项目，我也明白了一点：

 

在做项目的过程中，学习新知识的速度是最快的。

 

或许这也是为什么在学校的学习中要考试的原因吧。如果没有考试，学习似乎也就没有了目的（毕竟能看到长远目的的人数不多，即使看到了能坚持学习的更少了），漫无目的地做事情的效率和结果可想而知。这也正如电影《私人定制》里的一个理念：

 

在需要使用的时候，缺什么就恶补什么。

 

不得不承认，这恶补的效果是立竿见影的。项目驱动式学习，或者说是结果导向式学习使我受益匪浅。

 

项目开发永远只是一个完整项目中的一部分。抛开项目需求分析、方案设计、谈价格、签合同不考虑，项目自测试、项目联调、项目评审、项目验收，甚至后续的维护、升级，都是一个项目生命周期需要考虑的事情。

 

从一个开发人员的角度来看，代码编写和代码测试或许是最考虑技术能力的地方。编写代码，实现需要的功能。但，实现的是开发者认为需要的功能，而且是开发者自认为实现了这些功能。这里就存在着一些问题：

 

开发者实现了自己认为需要的功能，这些功能是项目需求中的功能吗？

开发者自己认为实现了需要的功能，这些功能真的实现了吗？

第一个问题涉及到对项目需求的理解。很多人认为程序员是不容易理解别人并被别人理解的一个群体，这个评价不算过分。在实际的开发中，不要说文档需求，即使是两个人面对面地交流，也会有误解的时候。

 

对于一般的交流，误解的成本不是太高，但作为一个程序员，我认为如果等到程序代码都码完了才发现自己理解的需求与实际不一致，就会造成效率和时间的损失，因为这意味着前期的功都是无用功，可以用事倍功半来形容。

 

这还是对个人的损失，对项目、对公司而言，损失就更大了。项目进度受到影响，这个时候加班就不要抱怨什么了。所以，我觉得，在拿到一个项目时，花一些时间理解项目需求是很有必要的。遇到不明白不理解的地方就要及时询问，及时沟通，解决疑虑。

 

至少，在没有完全理解和确认项目需求之前，不要急着写代码。毕竟，写代码的工作并不是很难。难的是在理解项目需求之后的构思。这个构思的过程就是软件设计，包括架构设计、功能模块设计、流程设计，甚至再细分到项目工程文件设计、函数模块设计、函数名称等等。构思不怕细，越细致越好，构思好了写代码的效率也会大大提升，达到事半功倍的效果。

 

第二个问题涉及到测试和联调。测试又可以分为开发者自测试和专门的测试小组进行测试。自测试包括开发过程中的单元测试、添加程序输出测试。程序中难免会有各种各样的bug，调试解决bug的过程是最考验一个人分析、定位、解决问题能力的地方。

 

• 对调试工具的掌握情况。bug出来了，现象是大家都能看到的。根据bug现象选择使用恰当的调试工具定位问题。

 

• 问题定位了，问自己为什么会出现这样的问题。是设计导致的还是编码造成的？

 

• 理解了问题出现的真正原因，才能从根本上解决问题。

   

• 一个问题解决了，要记得总结经验教训。此处不要小看了坚持的力量，平时注意总结素材，日后必会感谢自己。

   

• 还有一个问题，如果所有的方法手段都用了，问题还是解决不了，又该怎么办呢？求助。永远记住，你不是一个人在战斗。你还有同事、朋友和上级。

 

几乎没有一个项目是由孤立的一个人完成的。项目联调决定了一个大系统能否正常运转的关键。项目联调需要各个项目方的人员互相配合，这也涉及到了人与人之间的沟通交流问题。毕竟，系统出了问题，互相推诿是非常常见的现象，这也是人之本性。

 

在联调的过程中，最能体现出一个人冷静思考、技术沉淀和影响力。出现了问题，就要去解决，但解决问题之前，往往会有个小会讨论一下，可能会是谁家的问题。这个时候需要的就是冷静思考、逻辑思维并有理有力有切阐述自己观点，说服别人是最重要的，特别是有各个单位的领导在场的时候。这样的描述让我想起了在《逻辑思维》中听到的职场说服力：

 

表达观点、提出建议，跟各方有效沟通，让别人接受你的主张，是职场上非常重要的能力。