buhui912的专栏

在做这个deadline扩展功能开发时，明白了其实软件开发重要的还是需求分析。如果开始仔细分析好式样，能够和客户及项目经理协商好，简化式样的处理，尽量不做复杂的式样，那么后期的开发就能保证了做的比较好了。所以在项目经理向日方客户汇报式样分析结果之前，要先看看项目经理的式样分析结果写的咋样，这样好提些意见。一旦得到客户确认后，就不能再改式样了吧 同时项目进度预测也很重要。如果是做产品的，能关系到

1：工程师首先想到的是解决问题，而不是学习知识。工程师解决问题的方式：   那次SPEC编译失败，是因为你禁用了二进制接口宏；   这次/var目录空间不足的解决方法：背景（你明明删除了LOG子目录下的messages文件，但还是显示/VAR/目录剩余空间为0）  方法：仅仅重启一下/ETC/INIT.D/SYSLOG服务就行了，根本不用再上网搜什么资料。2 转义字符方面的东西

HPC组给我带来了一笔宝贵的有关C语言开发大型软件的技术财富，下面是这些点滴财富记忆1 指针和指向指针的指针两个不同类型变量的命名  if ((ret = set_execunit2pcc(job_p, job_p->jrset, &recvjob_p->execunit.rsv_vn)) 中间这个多个&的错误避免办法：以后注意指针变量尽量写成：char * str_p，不要写成

HPC项目组工作内容：按照富士通作业管理软件FD式样书的要求，协助日方工程师开发出具有可提交，管理和调度作业的高性能服务器软件（23万行代码/7人）。该软件运行在富士通PC集群上，可高效地为用户提交的作业分配资源。开发工具：C语言，GCC工具链，GNU make, source insight及SVN版本管理工具 开发环境：RHEL操作系统和富士通PC集群 （集群由6400个物

从网上找的单元测试评论：什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从老纳的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指

GCC警告选项对我们及时找出代码中BUG，改善代码品质很有帮助。听说高手们对每个警告选项都很熟悉，能灵活运用各个警告选项来分门别类地过滤代码中的BUG信息。1../SRC/libpjmacl/pjmacl_jaccmd.c:1661: 警告: dereferencing type-punned pointer will break strict-aliasing rulespjma

uclinux ethernt FM3芯片的移植这个移植是把uclinux下面的本来支持stm32芯片的代码修修改改让它支持FM3芯片。移植开发环境搭建：开始我们隔壁项目组做uclinux相关的，我们把它们的工作正常的uclinux版本拿过来。在里面找到stm32相关的代码，开始这个版本的uclinux是配着uboot去执行的，是标准的嵌入式linux执行流程，必须有uboot去引导。而我

去年被调到了嵌入式组，终于和以前研究生阶段搞的开发经历一致了。但以前用的是ADS工具，还有用linux平台上的交叉编译工具链，还有看linux 2.4内核的驱动代码。现在搞起对日了。日本人不爱用linux，凡事总是搞出自己的一套。现在用的ut-kernel, 开发工具则有RVDS,DS-5，MTK和IAR， 硬件调试器有Dstream， Realview ICE。现在对应的是富士通半导体

CM3系列处理器优势：功耗低。延长了电池的寿命——这简直就是便携式设备的命门（如无线网络应用）实时性好。采用了很前卫甚至革命性的设计理念，使它能极速地响应中断，而且响应中断所需的周期数是确定的。代码密度得到很大改善（应用thumb指令？）。一方面力挺大型应用程序，另一方面为低成本设计而省吃俭用。降低成本还有一招，就是使基础代码在所有系统中都可以重用，至少要方便移植。CM3的内

1：关于新创建的task在执行函数时，怎样得到它的两个参数：stacd和exinf在函数knl_setup_stacd中，还有权威指南P142.就是说执行函数写成：void task_test(INT stacd, VP exinf)和void task_test(INT stacd)都行2：函数tk_rcv_mbf_impl中 QueInsert(&knl_ctxtsk->t

PJM 软件数据结构方面组织的还是不错的；typedef struct PjmsPktHeader {    int msgcode;                /*!    int errcode;                /*!    int16_t rscunit_id;         /*!    int16_t reserved[3];        /*

PETA软件的内存管理工具让我明白了原来C语言中的指针使用确实也这么多值得学习的地方。NQS组的工作得到最大收获就是重新认识了指针这个东西。当然了，写个小程序当然不用理睬指针了。但是做大型软件开发时，尤其是C语言，我觉得还得多用指针，巧用指针。在提高效率的同时，也得改进软件质量。指针运用不当，会导致很多内存错误。而且有些内存错误出现地方不固定，很难排错。所以开发大型软件时，需要自己也做个内

今天忽然明白了什么，呵呵面对一项任务开发，你是倾向于开始先在SD阶段就把结构设计的如何好，质量设计的如何强壮，能应付各种突发的情况，还是倾向于开始时，先做出个简单能满足基本功能的原型，再在原型上做些代码或者架构上的调整和质量改进。今天我知道了应该采用第二种方法，企业级开发应该采用第二种方法。你做的在面对-n nodeid[,...]选项有关的式样处理时，如果真是日方让你既满足PCC式样

最近两天调了一个BUG，本来想着是什么重大BUG的，原来还是个比较幼稚的BUG。这主要是因为自己对版本管理控制不熟悉，不够重视，才导致花了很长时间调BUG。还得花花时间学习下版本控制对开发软件的重要性。

一个人的开发毕竟和多个人的团队开发不一样所以两方面的东西不可少：表达：1：倾听别人说话2：自己说了.............3：写一些文档动手:1：操作各种软件工具的能力，比如SVN，souce_insight的能力2：灵活解决问题的思路当你是搞工程而不是搞理论时，当你是搞低端开发时，这两方面的能力就尤为突出了。自己在这两方面都不强，学校期间毕竟没有

转孟岩老师的话：           基础软件开发崇尚的是自由、直接、透明、简单、高效，要像匕首一样锋利，像战士一样勇猛，像农夫一样朴实，反对繁琐华丽的设计，反对架床迭屋的层层抽象，反对复杂的结构和不必要的灵活性。而Java社群多年来形成的设计风格与此格格不入，甚至可以说是对立的。Java在意识形态上是要面向企业应用软件的开发，所以特别强调架构，强调设计模式，强调标准，强调规规矩矩，强调高姿态

今天我忘记了统计抽取CASE表的测试项目了，里面有些CASE其实现在还是可以测的。但是这个测试任务，我最近忘了，主要是因为最近要干的事情比较多，扩展机能开发比较费时。     以后要做个未作事件和正做事件备忘录，以便提醒自己哪些事重要，需要先做，哪些事由于时间长了，忘记做了，那些事不重要，后作。基础功能开发测试先做，扩展机能开发测试后做，扩展机能开发不能占用基础功能的CT测试。     测

日本人的企业呆着最大的感受就是—规范，想象不到的规范 日本人的规范用到硬件上，做出了高质量的产品。但是软件上，日本人做的并不怎么好。 日式代码的风格文档式代码—风格一：     日本人很爱写文档，应该是酷爱写文档。代码设计思维跟他们写文档一个样。不怎么讲究灵活巧妙的设计思路。写文档时，是什么功能一条一条地列出来实现。     写代码也是这，讲究复杂的功能就应该分解，分解成一块一

用C语言开发是比较费时费脑的时，怎么才减少工作量，高效舒服地开发不得不需要考虑下首先代码要符合编码规范，大公司都有自己的一套编码规范。富士通的编码规范不得不佩服一下，确实很详细，很能避免开发时所出现的错误编码规范适合团队式开发，编码规范从深层次上说是一个团队的开发方言，就像家乡的方言一样，你要了解家乡文化，必须得了解方言。编码规范制定的科学详细点有助于代码的清晰可读，代码的调试编译错误避免

2011/12/20       目前我是致力于软件服务业方面的工作，虽然不是做产品开发的。但是自己的角色定位也得摆脱过多技术化色彩。       我是做软件服务的，全心全意为日本客户服务，争取让客户多发单，让我们做，改进工作质量，让客户看到我们的实力。       技术说到底都只是个工具，我要站在更高一级的角度来看待我的工作。       软件服务业也有很多值得学习提高的地方。虽

总的开发基调：选成熟稳定的，简单易想的，利于快速开发的开发基调，反之不怎么好。企业级开发总的来说，是追求进度的，有点保守的，为了追求进度，总是复用前期项目的代码，不管前期代码做的如何。优点是：毕竟前期代码都经过工业级测试了，已经变得成熟稳定了；你自己如果新实现个代码函数，leader 一般情况下不愿意采用，怕有风险不稳定，关键是组内开发基调要保持一致，团队规范协作胜于个人独自表现。