摘掉耳机，它让我无法冷静地思考。
题目当然是参考了张震岳的《爱之初体验》啦，忽然想起了他，复出时随便翻唱了曲《再见》就再度火了。这点让我有点无法理解。不过他唱得还是蛮不错的。
前面都是些题外话。
入职已是一月有余了，是时候总结下这段时间的学习了。
在大学里，我主要是和Dreamer,Lin一起帮学校做点项目的，这些项目基本属于OA系统。学校的项目特喜欢搞重复开发，哪怕是已有前人已经完成了项目的大半部分，大多数接手者也是一切推倒重来。这其中的原因我想开发技术不一是其一，当然更多的情况是软件开发流程的混乱，甚至可以说是毫无规范可言。所以，有时候一个系统可能都没设计完毕就急匆匆地进入了编码阶段，到最后系统算是开发完了，也能运行了。但是此时，客户（一般是高校老师）很可能会提出些变化的需求，这时候动大手术是不大可能了，只能是在现有的系统上修修补补，到最后做出来的东西自己看得都有些惨不忍睹。这样1.0的完成往往可能只是痛苦的开始，这时候在客户的不断抱怨下，你终于忍无可忍了，开发一个2.0的欲望越来越强烈。当然有些人可能看过一些软件工程方面的书，里面提到了开发2.0版本可能产生的后果。我便是如此，没有按奈住冲动，毕业了都还留在学校为其做了个2.0版。（当然这其中还有别的原因，就不想再提了。）
在大学做项目时，开发技术和开发环境的可选性比较大。这个也是造成大学项目的重新开发率较高的原因之一。不像是在企业，开发环境的选择得考虑很多情况。在大学哪管这么多，往往是受某些个偏好的主导。盗版的也好，开源的也罢，看那个顺眼就用哪个。从这个方面看，在大学做点小项目还是挺舒服的。现在在公司就不能这样了，只能是自己去学习去适应公司的开发环境，使用什么工具开发都是由不得自己的。当然，这个是很有必要的，没有统一哪有规范。我认为，这点也算是团队开发的一个基石吧。
前不久才接触到公司产品的Code，课堂培训很久了，一见Code就有种久违的感觉，虽然这些Code并不是很亲切。倒不是因为语言本身的问题，而是我只能窥见一角，毫无全局感。（目无全牛？hah!高考成语的魔鬼训练令我牢记这用法是错误的。不过我倒希望能达到如此境界。）这确实令我有些茫然。当时就隐隐感觉到这Code要看懂不仅需要些时日，还得配合着深入学习些别的东西。比如RTOS或者Protocol相关的东西吧，我也不能很确定。这些可能就是一些程序员所谓的“内功”吧。
初入行还有一个感受就是技术知识获取途径的狭窄。以前在大学里面，因为用的都是时下流行并且较为成熟的开发技术，学习途径相当地广，无论是看传统的纸质书籍还是网络文档，一般都能找到解决问题的方法。如果要快速开发，要找到一套类似的源代码似乎也不是很难。为此，我以前还自我总结了一套学习新技术的方法，而且那时候我还能很骄傲的说，“学会一门新技术并将其用于实际项目我可能只要一个月甚或更短”。现在看来觉得那时确实有些轻狂。嵌入式要达到这种学习效率似乎有些困难。Code有很多方式，我不想每天机械式地搬照工作指令，而是想知其所以然。如果已经有一个模块，你每天的工作只是在这个模块上稍作修改，而全然不觉其他模块是做什么的话，这样的工作我倒期盼有一天能让计算机取代他们的职位。但是我又想到，现在很多公司不正是大量招收这样的“人才”吗？我现在还不敢说我不是这类人，因为我现在能力也只能在这个范围之内。但我希望自己能修成一位优秀程序员才具备的“内功”，而非一个即将被机器人取代的“人才”。我现在觉得嵌入式的学习道路确实有些艰辛，我手头的资料又十分有限，Protocol这样标准的东西还好说，基本就是K掉Stevens那几本大作和一些RFC了。但是好像一般涉及到嵌入式系统的公司都拥有一套自我知识产权的Platform，公司的大部分产品研发都基于这个Platform。我现在所在的公司也是如此，虽然说这些嵌入式的Platform在功能上有些相似之处，但是某些特定领域的东西实现起来还是会有所不通的。如果该公司没有做好文档工作，就会给新手上路带来很多困难。此时很多技术就只能靠真人（此真人非彼真人）传授。这些特定的问题还无法从网络上找到解决方法，因为这时可能会牵涉到一些保密条例的限制。一般就只好向公司的大虾们求救了。这点我现在所在公司还好，虽然文档并不是很齐全，但是真人们还是很热心也很有耐心地帮我解答的。
再谈谈现在的开发环境吧，嵌入式的开发环境并没有以前开发应用软件那么方便，以前经常抱怨Java的开发环境配置起来怎么就没有M$那套东西那么畅快呢？现在看来那时候有个Eclipse已经是大幸了。现在我们公司的编码环境倒还可以，用的是Source Insight，这个东西用起来还是挺不错的，个人认为比起EditPlus要强上百倍。但是调试程序简直就是噩梦了，特别对我们这些新手来说。前段时间我给原有Code开刀，按照教程按部就班地添加了一些自己的Code。由于很久没写Code，再加上自己写Code的粗放，还有没注意到Code的添加注意事项，犯了不少错误。犯错要改啊，但是得先知错。断点是没法设置的，（听老大说也能，但是得用到ICE此类高深的工具，公司一般都没人去用）只能是靠经典的Printf调试大法。而且在Build Code时，还得使用独立的编译器，然后在Console里面敲入指令，Build的时候屏幕飞速闪过一串串黑底白字，看起来也很有当年高中我在文曲星CC800上List QBasic程序源码的感觉，甚为爽快。当然还是公司的Code Build起来更为壮观，全部Build完得10分钟左右，闪过的Warnning还是不少的。一旦出现错误，这些错误信息也是罗列在这一堆编译信息中，这时候就得费点神了，还得靠肉眼晶晶从那堆编译信息抓出错误信息，然后再经过肉脑处理手工转到Code的出错的那一行。真是麻烦！而以前的IDE一般只要简单惬意地双击错误信息便能直接定位到。经历N次修改，重Build。终于算是Build过了。这时候就能把生成的BIN刷到Device的内存中，因为嵌入式所使用的语言原因，很容易出现内存存取问题。而一般的Device对内存分配得甚为紧密，稍有不甚，就有可能把某些指针乱彪到不该去的地方，这样崩溃可能性极大。一旦当掉，就得用另外一套工具来分析程序的函数调用关系，找出引起崩溃的函数也并不容易，经过两三种工具交替使用，再经历两三次信息人工对校，找出真凶。这时候又得改Code了，改完再Build，再刷。如此反复……
以上的情况算是还好啦，但是经过前段时间台湾总部老大的培训，我还略有神会到“你无法保证支撑你开发的环境是否有误”这一经验之谈。这个环境可能主要指两个方面，一个是你所依赖或者调用的函数库。这种情况还比较好说，因为自己也是写Code的，多少能有所了解。测试的时候也相对有把握一些。但是另一个方面可能是硬件设计或者硬体本身就有瑕疵。这时候你要是对底层的硬件一无所知的话，你就得多多留意了，说不准调试了几个星期，到头来发现是芯片提供商提供的芯片有瑕疵，所以在工作中必须要持一种怀疑的态度，当然，怀疑也要有怀疑的本钱。一位真正优秀的嵌入式程序员最好能软硬皆通。（崇拜HQ老大）。当然，这段所叙的一些事情我还没有亲身经历，只是为了给以后的自己提个醒。
这个星期一直都有些茫然，也可能是一些懒惰的情绪开始滋生，当然也可能是自己在刻意追求些什么，一周来并没有很努力地学习新东西。明天就是下一周的开始了。希望自己能够调整好继续前进。
相关日志
没有评论