由于最近晚上一直没有"加班"，所以CSDN也很久没有去逛了。今晚本来是要正式加次班的，但是又是翻翻网页听听歌这样过去了。
CSDN上的C和C++专家们又吵起来了，技术方面的争论还是挺有意思的，起码比时下的一堆愤青胡乱骂街要好得多，至少我们能从中学到点东西。一般这样的争论是没有所谓正确的结论的，能留下也就是些长久的思考。
因为现在学嵌入式，所以只用C。我这人一般做什么就往这方面的好处想，最近看这些用C写的Code实在有点恶心了，虽说入职前曾买了本《UNIX编程艺术》来陶冶下我的C灵，但是都被最近看的这些东西给埋没了。于是还得继续端正，当然不会诋毁C++，我只是在努力感会C之美。
前往CSDN查看这次争吵实况！
这个月公司厂庆，运动会因而冠名为“厂庆运动会”。
在大学久不运动的我，这周基本是每晚运动。搬用黄健翔的节目来说就是“天天运动会”。
能在公司进行体育活动还是挺多的，我也是样样都来（形体室除外）。但是由于本人先天天赋不佳，后天努力欠缺，运动水平一直稳定在中等偏下水准。虽说拿不了奖，但是当个板凳选手还是问题不大的。运动嘛，自己玩玩，陪别人乐乐而已，不一定非要参加比赛不可。（纯粹自我安慰。。）
在公司玩足球最逗。听同寝室的老人才哥说，原先公司建厂时有设计足球场的，但是由于预算时少了点投资，没有将足球场用工程车压实，致使草皮松垮塌陷，踢了一两次就没有人再去踢了。后来这这足球场就成了一块只可观玩的草坪了。但是RD毕竟是RD，有限的资源也能做出最好的调配。于是有人提议将篮球场使用时间分时间片轮转，分出球场足球和篮球使用时间，最终获得大家的一致赞同。比较搞的是踢足球没有球门，他们便以篮球铁架脚及适当拓展范围为门，正中即为射门。一伙人轮流玩着5V5的足球也是不亦悦乎。
这几天一直在看Code，遇到些移位计算。诸如计算“1<<24”之类。本人在这方面从来都是比较懒惰的，加上那时看Code已是身心疲惫，就花了点时间做了个移位计算器，虽然功能简单，而且基本没有做容错处理，但足以应付目前的需要了。
这个版本就算是1.0，如有需求，日后改进。
SST主要功能：
使用请注意：
数字和操作符之间必须以空格隔开。
例如:1 << 24
部门老大终于决定这个月中旬集体出游了。各小组充分调度RD人的程式大脑，终于搜寻出以下N种备选方案：
怎么就没有人提提去某个江南小镇逛逛？大概是老人们已经逛腻了，算了，有这些地方已经够满意了。在部门大会上经过集体表决，最后目标锁定在“浙西大峡谷”！听说此地有山有水有漂流，而后还有同事提议说要弄些帐篷在室外野营，Woo…真有想法，I like it!工作后第一次旅行，期待ing!
拥抱
歌手：五月天 专辑：听不到你
脱下长日的假面奔向梦幻的疆界
南瓜马车的午夜 换上童话的玻璃鞋
让我享受这感觉 我是孤傲的蔷薇
让我品尝这滋味 纷乱世界的不了解
昨天太近明天太远 默默聆听那黑夜
晚风吻尽荷花叶 任我醉倒在池边
等你清楚看见我的美 月光晒干眼泪
那一个人爱我
将我的手紧握
抱紧我吻我喔爱~~~别走*
隐藏自己的疲倦 表达自己的狼狈
放纵自己的狂野 找寻自己的明天
向你要求的誓言 就算是你的谎言
我需要爱的慰借 就算那爱已如潮水
repeat*
那一个人爱我
将我的手紧握
抱紧我吻我喔爱~~~别走
抱紧我吻我喔爱~~~别走
抱紧我吻我喔爱~~~
已经是一首老歌了
但最近又把它挖出来
听了一遍又一遍
太喜欢这词
以至一印落纸
边走边唱
摘掉耳机，它让我无法冷静地思考。
题目当然是参考了张震岳的《爱之初体验》啦，忽然想起了他，复出时随便翻唱了曲《再见》就再度火了。这点让我有点无法理解。不过他唱得还是蛮不错的。
前面都是些题外话。
入职已是一月有余了，是时候总结下这段时间的学习了。
在大学里，我主要是和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老大）。当然，这段所叙的一些事情我还没有亲身经历，只是为了给以后的自己提个醒。
这个星期一直都有些茫然，也可能是一些懒惰的情绪开始滋生，当然也可能是自己在刻意追求些什么，一周来并没有很努力地学习新东西。明天就是下一周的开始了。希望自己能够调整好继续前进。
![""]("http://www.sunky.net/images/download.gif")
点击下载此文件