一个程序员的成长之路(辛酸史)

一个程序员的成长之路(辛酸史)

从业两年，前一年拼命撸代码，不断学习新的技术，也算是进入了程序员的行列了。后一年由于机缘巧合，接手了一个被别人遗弃但自己的老板看好的项目，从半路开始项目的开发和维护，调试的时间远远超过了开发时间。接触到的新技术少了，但项目总体开发进度、联调等方面的问题遇到的多了，也有了点感触，借此机会抒发一下。
加入程序员的行列
本人小硕一枚，毕业于西部某城市，机械电子工程专业。机械不是我热爱的领域，所以偏向于电子，研究生期间捣鼓了点单片机、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现象选择使用恰当的调试工具定位问题。
问题定位了，问自己为什么会出现这样的问题。是设计导致的还是编码造成的？
理解了问题出现的真正原因，才能从根本上解决问题。
一个问题解决了，要记得总结经验教训。此处不要小看了坚持的力量，平时注意总结素材，日后必会感谢自己。
还有一个问题，如果所有的方法手段都用了，问题还是解决不了，又该怎么办呢？求助。永远记住，你不是一个人在战斗。你还有同事、朋友和上级。
几乎没有一个项目是由孤立的一个人完成的。项目联调决定了一个大系统能否正常运转的关键。项目联调需要各个项目方的人员互相配合，这也涉及到了人与人之间的沟通交流问题。毕竟，系统出了问题，互相推诿是非常常见的现象，这也是人之本性。

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

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

接手半截子项目
这个项目辗转了2个部门，无人愿意推动，最终得到了我部门领导的重视，决定启动。

启动之初，也遇到了一些阻力，其中之一就是我的项目经理。我负责对项目的技术进行梳理总结，并向他汇报。项目使用了java、erlang和c三种编程语言开发，各个模块之间使用TCP/IP通信，由oracle数据库存储数据。

使我们担心的并不是项目的复杂度，而是时间节点和项目使用的技术。项目组之前未接触过类似项目，并且从未涉及过java和数据库，至于erlang是什么就更没人知道了。但老大就是老大，拍板了说做，还语重心长地安慰我们说：“不会的你们可以学习呀！”

说做就做。别看哭穷的时候说的真切地真跟无论无何也做不了一样，实际干的时候立马也得有方案。

首先深入梳理掌握项目功能模块划分、模块关系和目前具备的功能
总结汇总有待开发的功能，及开发这些功能需要使用的技术
任务分配到个人，明确调试时间节点和目标
开干！
项目初期的调试是痛苦的，没有外援，只能靠自己。于是，我便开始了对着书看代码的日子。《erlang程序设计》大概是erlang里的权威著作，只得慢慢地啃。但这里还是想吐槽一句，erlang与c语言的差异还真是大啊！

就这样摸索着过了一个月，终于把erlang模块的实现流程梳理了开来。调试时遇到的错误也大概知道是什么原因了，项目也算有了希望和眉目。好在前期java模块不需要修改太多东西，算是坚持了下来。

后期，有2个新员工加入到项目中来，他们是做java的，前端java实现的用户操作模块就交给他们了。于是，我就一边深入理解项目的背景和协议，一边有计划地进行新协议的开发。

3个人一起进行协作，使得压力减经了不少。我们也有了时间可以讨论项目的背景和需求，并细致研究项目的技术细节，考虑可扩展生和可维护性。在开发erlang的过程中，我们充分利用了代码的利用和移植，使得项目开发效率大大提高。

项目的3个模块之间的内部联调也是很重要的一部分，由于代码开发中较少考虑对外部接口的调试输出，定位问题时消耗了大量的时间。这也促使着我们对代码进行深入思考和重构，以提高项目的可维护性。

但总体结果仍是喜人的，项目顺利完成了既定的目标，完成了第一阶段的开发、调试和测试工作，当然，这要感谢项目组所有同事的付出。

项目目前仍在紧锣密鼓地进行中。

探寻出路
十多年的管理工作经历，让我可以非常确定地告诉你，被重视的员工，职场上发展的好的人，通常不是那些唯唯诺诺、只会点头说是、埋头执行的，而是那些能陈述自己主张、提出好的意见，并让对方接受的人。

不知道这话是哪位说的了，但感觉很有道理。公司需要的是能够为公司创造价值和利润的人，而公司的管理者也是人，做事的也是人，所以，归根结底，仍然是人与人之间沟通交流的问题。公司领导需要的是能够创造最大利润价值的人，而不是一个只是按照指令动作的机器。

夯实自己的技术能力，加深对专业业务的理解和实现的认知，做到独立思考，对于一个事件，要能形成自己的看法和认知
拓宽自己的视界，不局限于自己专业领域的圈子。主动接触身边各个领域里的牛人，保持开放学习的心态
要主动输出，通过博客、专栏、公众号等方式总结、思考、评论，梳理自己思维，也要积极理解每日的新世界

最后想跟大家说下,我们公司再组件一个程序员的圈子,可以交流,讲段子,学习技术,互相探讨,有兴趣的小伙伴可以加我们公司客服小妹妹的微信,单身,可撩,可咸可甜.