所感所悟

元月初九祭技术情节～

乾坤一笑 — Sat, 10 Feb 2007 00:23:00 GMT

满怀踌躇志
遍吃现实苦
孙子无遗策
谋臣非君主

软件开发的“佛脚”

乾坤一笑 — Thu, 22 Jun 2006 15:45:00 GMT

独木不成林。一个项目组有1～2个高手，也很难保证整个项目组的成功。一般来说，水平越高，负责的任务往往也就越多越重，要他们在工作之余挤时间指导其他成员、像检查作业一样的检查其他人的代码是不现实的。而等到问题真正出现了再去解决、规避、重构代码，早已经为时已晚了。代码紊乱程度就像熵一样只会增加不会少的，如果不在早期阻止代码往不良方向发展，代码就会越来越烂，最终导致产品的可靠性没有保证。因此，项目成功的关键因素之一就是要缩小项目组成员间的“贫富”差距，水平越相近，价值观就越统一，也就越容易实施管理策略，制定的规则就越容易被所有成员认同。对此，我的建议是，把培训重点放在帮助中下技术水平的成员提高基础技能、构架认识、全局观、软件工程理念上；而对于水平较高的成员，适当地规范其开发过程中的行为，略加引导就可以了。项目组地平均水平提高了，整个项目组的开发能力就上去了。

以往我推荐的书都是纯粹提高技术能力的，并不能有效的提高其全局观、软件工程理念。不可否认的是，每个项目组都会存在这样一些“高手”，他们debug能力很强，但是缺不愿遵守编码规范、不认同流程规范；他们把重点放在技巧编码方面，而从来没考虑文档和代码是写给别人看的，也从来没有担心过孤立的代码会增加后期维护的成本和移交工作的成本。他们是属于瘸着腿跑也比一般人跑的快的人。（所以，瘸也就不用治了，他们是这么认为的。有的甚至根本不觉的自己瘸，只觉的自己跑的快）我的看法是：这种人的代码杀伤力往往比低手还大。因为低手往往按部就班的编码，不敢挑战流程，低手也往往得不到编写核心代码的任务，所以低手的代码对整个工程造不成大的伤害。相反，编码意识如果不好，技术水平越高，其代码的危害就越大。编码不仅要提高技术水平，也好同时提高培养编码意识和大局观。

我曾极力向初涉软件开发的同事推荐下面三本书，收到了很好的效果：
《C程序设计语言(The C Programming Language)》Brain W.Kernighan & Dennis M.Ritchie 著徐宝文李平译
《Joel说软件(Joel on Software)》Joel Spolsky 著谭明金王平译
《程序设计实践(The Practice of Programming)》Brain WKernighan & Rob Pike著裘宗燕译

三本都是价格不贵的小薄书，很容易看完。（为什么这么说？看过C++ Primer的都有体会，真是又厚又贵）第一本能够使读者达到胜任C开发工作的水平，一本小书容纳了语言、算法、模式、代码风格艺术的精华。第二本，以散文随笔的方式介绍了软件工程的思想，介绍了软件开发的理念，能够使读者的编码品德、设计品味提高。第三本，分别介绍了代码风格、算法、接口设计、排错方法、测试、性能优化、可移植性等诸多软件实践，作者水平极高，写的深入浅出，令人反复阅读反复受益。

这三本书组成了一个开发人员必备要素的铁三角。相信细细品味于小书的字里行间，思维就越来越受教于世界顶级的大牛，悟性、能力、修养都会不断提高。我衷心的希望初涉软件开发领域的朋友们能从这三本书入手，从白纸开始就写好每一个字。找工作或者搞突击时，临事抱抱佛脚，也不失为一种快速溶入优秀开发团队的捷径。

-------------
乾坤一笑写于2006年06月22日转载请标明出处和原文链接

赌侠的经验

乾坤一笑 — Tue, 20 Jun 2006 00:50:00 GMT

昨晚看了《中华赌侠》，古天乐饰演的阿酷提及了自己的赌博经验：“偶尔赌一次可以靠运气，长期赌只有靠技术了”。由此偶想到做项目不也是如此？靠蛮力、靠冲劲儿硬拚，获得项目的成功那只是小概率事件，要想任务不延期、质量有保证必须依赖于(统计学)规律而不是能力。郎咸平也说过中国的厨师水平高，但是出不了麦当劳这种连锁店，也是这个原因。大厨的能力不能复制，所以分店总店不是一个味。大厨一走，饭店就散架。麦当劳虽然味道不算好吃，但是全世界都一个味道，一个品质。所以吃的放心、安心。

一个黄飞鸿救不了中国，一个软件高手也救不了团队。假如让你领导一个团队，要确保产品的交付能力，你会怎么办？靠拚？靠冲劲？靠加班？偶想还不如老老实实的按规律办事，把cmm、6δ引进进来，踏踏实实的做事。这一点，韩、日的企业十几年前就认识到并做到了，中国的企业还没有认识到，认识到的也是在空喊，不喊的也没落实到位。要想进世界500强，单单靠廉价成本做为核心竞争力是玩不转的。

-------------
乾坤一笑写于2006年06月20日转载请标明出处和原文链接

猪八戒喝汤

乾坤一笑 — Tue, 06 Jun 2006 15:34:00 GMT

猪八戒嘴馋，脑子里成天想的就是吃。这天闲来无事，就自己煮汤喝。要说起煮汤，猪八戒还真是此中好手，他煮的汤菜叶飘香、不油不腻、清润爽口……想想都流口水。可是今天八戒有点失手：眼见着汤已经煮好了，八戒舀起一勺来，一尝，味道有点淡。嗯，加把盐。八戒举起汤勺再一尝，味道还是淡。再加些盐，八戒再一尝，还是淡。哎，真是活见鬼了不是，半袋子盐撒了进去，竟依然淡然无味。这时候孙猴子来了。“师兄，你来尝尝这汤，真是见鬼了……” 猴子舀起一勺汤一尝，一口吐掉，“靠！你想把卖盐的打死啊？”原来汤咸的已经不能喝了。这到底怎么回事？说来真是可笑，原来八戒虽然加盐若干次，可是每次尝的却仍然是最初舀起的那勺汤。

《猪八戒喝汤》的笑话是偶小时候看小人书时看到的笑话，记忆颇深。现在工作时每每犯了同样的错误，偶总是一声叹息“哎，猪八戒喝汤！” 比方说，修改了个函数，怎么编译都没有效果，最后一看原来是写到另一个工程的代码里了。再比方说，改了N遍，查了N遍，代码一点错误都没有，手机还是重启，最后发现原来烧到手机上的还是老的镜像文件。:) 这种例子真是数不胜数啊。

相信大家都犯过“猪八戒喝汤”的错误。所以，当偶们长时间解决问题都没进展的时候，不妨放松一下，出去抽根烟，或者晚上去打打羽毛球——或许你就会猛然发现：原来没舀新汤！真是山穷水尽疑无路，柳暗花明又一村。

-------------
乾坤一笑写于2006年06月06日转载请标明出处和原文链接

回顾"夜读自励"诗有感

乾坤一笑 — Thu, 04 May 2006 15:45:00 GMT

书山无路劈荆棘，学海茫茫浮木舟！
皇天厚赐我才庸，唯有搏命与天挣。
不尽人世坎坷路，岂有繁华幸福驻？
满怀壮志闯江湖，不立威名不归梓。 
    ——夜读自励 FreeDebug
             于2004年 元月4日夜

上述小诗是偶04年初春节前夕（也就是猴去鸡来的那一刻）所写的一首诗，感慨大学的荒废、对人生道路的迷茫和困惑。诗写罢之后偶就辞职南下，来到了传说中豪杰辈出的上海滩(现在更应该叫做大上海^_^)。今天与HateMath闲聊校园生活，忽然想到此诗，google了一下，竟被数人引用为签名档。顺口胡捻的小诗能得到大家的认可偶心中自然是欣喜，再次品味诗文，却又感到无限的辛酸与苦涩。

诗的第一句“书山无路劈荆棘，学海茫茫浮木舟！”是说偶无明师之路，独自摸索，苦读书而无所获。古人诗云“纸上得来终觉浅，决知此事要躬行”可以算是对此困惑的答案了。第二句“皇天厚赐我才庸，唯有搏命与天挣。”是说偶虽有心上进，但却天资驽钝，虽努力进取，但收获不大，自己不免悲观。华罗庚华老师的“勤能补拙是良训，一分辛苦一分才”回答了这句疑问。第三句第四句“不尽人世坎坷路，岂有繁华幸福驻？满怀壮志闯江湖，不立威名不归梓。”自己给自己打气，使偶能保持“黄沙百战穿金甲，不破楼兰终不还”的心志。感谢初来上海时上海VCKBASE朋友给偶的鼓励，尤其是才来上海、囊中羞涩、食不果腹而又找不到工作时，LindaXu 姊姊对偶的鼓励“每天睡觉前对自己说100句'唵吗呢嘛咪吽!Show me the money!!'”——这中西结合的咒语可真有效啊，人确实是需要精神依靠的。^_^

时过境迁，已经两年。再回首往事，真感慨万千。在看自己的职业生涯，缓缓的按照自己设想走上了轨道。从数据库到嵌入式再到手机，从SWE(Software Engineer)到SE(System Engineer)，路是自己一步一步走出来的——前途不明朗，世道多变化——此时此刻，唯一能做的，就是练好内功，以不变应万变，才能仗剑闯江湖。

-------------
乾坤一笑写于2006年05月04日转载请标明出处和原文链接

装双光驱的难点

乾坤一笑 — Sun, 16 Apr 2006 14:30:00 GMT

以当今的Windows软件(还有DVD、MEPG等多媒体)发展趋势，就是有两块200GB的硬盘，恐怕也撑不了多久的。经过反复盘算，终于下定决心，今天投资买一块DVD刻录机。我买的是先锋111CH DVD-RW，黑色面板，与原来那块先锋黑旋风吸盘式DVD-ROM放在一起非常和谐。

拿回来后，难题出现了，很难安装上！

首先是数据线太短。111CH用的是80线的数据线，黑旋风用的是40线的数据线，还有一块120GB的迈拓硬盘用的是80线的数据线。另外，为了避免线的冲突，我又另买了一根80线的数据线。拿回来后发现，我买的80线的数据线和原来的80线的数据线从主板到第一个设备的距离都太短，不足以接上两个光驱。我尝试把光驱挂为硬盘的从盘，跳线后又都认不出来（需要检测3～4分钟才认出来），怪怪！

我想，还是把光驱接在一起保险些吧。于是去小区外面的电脑配件店又拿了一根超长型的80线的数据线，终于把两个光驱接在了一起。但是依旧需要很久时间才认出来啊？我明明把跳线跳好了，一个主，一个从。

经过一番尝试，找到了问题的原因之所在。如果把数据线插主板那头记为0，把中间的一节记为1，把离主板最远的插头记为2，那么存在这样的关系：1处的设备要跳线为slave，2处的设备要跳线为master。如果该数据线上只接了一个设备，则1和2处无论是跳为slave还是master都无所谓。

这就是偶的一点心得和体会，欢迎批评指正！

-------------
乾坤一笑写于2006年04月16日转载请标明出处和原文链接

搬家，搬家～

乾坤一笑 — Sat, 01 Apr 2006 12:48:00 GMT

搬到世纪公园后面拉，小区门口就是2号线地铁口。看来今后去浦西玩方便多了。在浦东关了一年，终于敖出头了。～

PS:在blog左边加了个“Mail to me”，大家点点看哈～ :)

把Blog转向嵌入式开发方向

乾坤一笑 — Thu, 16 Mar 2006 15:44:00 GMT

转眼间做了一年手机了，对X公司的解决方案，无论是套片特性、器件特性，还是驱动、软件构架都有了相当程度的了解。突然间想买块板子自己玩个小project，移植一套操作系统跑跑，自己写写驱动玩。上ARM论坛一看(工作太忙，以前从未看过)，真让人寒心！国内的ARM论坛中的帖子大体上分为如下几类：
1) 广告贴。米粒大的公司都在论坛四处流放广告，声称买xxxx芯片的开发板，声称超值，但是不敢标价。（本小利薄，骗一个算一个，坑得大多都是学生娃）
2) 成品发布贴。宣布我做了××一款方案，要的举手。实际看看，一点有用的信息都没有，无非是个成品展示。（或许在吸引猎头？）
3) 赚钱yy贴生成偶有××公司的源码(不是免费的)，要的与我联系，多少多少钱？（老天，你又不是代理，盗人家的版卖钱，这主意亏你想的出来。）
4) 拉人贴。××论坛是交流的好地方，网址如何如何。×× QQ群，欢迎加入，如何如何。（一般不会有人关注，大站交流尚不成火候，况乎小站？）
5) 小本经营贴。某某DIY的开发板，半卖半送，付送全部资料。（国内正规的开发板的价钱已经是国外的1/10了，质量都难说，何况这种自制的？还不如自己申请个样片，layout一块来）
6) 小弟求学贴。经常是编译不过，跑不起来，或×××引脚不会飞线，冰天雪地裸奔跪求倒立跳楼的问答案。（结果是没人理，估计也是没空理。）
9) 招聘求职贴。××公司招嵌入式工程师，简历寄至××mail box等等。（水平低的不愿招，水平高的想招不愿给人家高薪。人家水平高的没准也想自己独立门户）

汗！全然没有技术交流的成分。或许嵌入式领域之所以待遇好就是藏私藏的厉害，中国科技落后于西方不能说不跟这种自私关键有关。不过也难怪，温饱都达不到的工程师，怎么能不染铜臭气呢？

我也摆脱不了这种俗套，想买板子，想用功能强的，又不想多花钱，郁闷那。哎，不说了，周六去看看S2C44B0X和S2C4510B，看看那个性价比高又承受的起，买一个先。玩玩Bootloader想必是够用了。:)下一步准备把Blog的写作方向全面转向嵌入式开发，边练边写，分享一下我做嵌入式驱动的经验。有同行的朋友请留个mail，业余时间交流下。拜师的就算了，偶也是低手，业余时间又不多，就不收徒弟了。:) 不过有问题请在Blog帖子下面留言(千万别写到私人留言里，几个月也不看一次)写出来，就是我回答不出来也会有高手解答的。

过马路，左右看

乾坤一笑 — Sun, 05 Feb 2006 11:51:00 GMT

小时候，大人们总是教导小孩子“过马路，左右看”。我年纪小不懂得为什么，但是由于大人们唠叨得遍数太多，以至于都深深印在脑海里，成为了潜意识。每每过马路的时候，不由自主得左右看看。长大以后，渐渐的喜欢考虑问题，凡事问个为什么：为什么是“过马路，左右看”而不是“过马路，右左看”？有朋友告诉我说那是因为中国话的习惯就是左右、男女、老幼之类的说，就像“决一雌雄”不叫作“决一公母”一样只是个习惯而已。可是，我觉得习惯是养成的，如果天天说“过马路，右左看”说多了，反倒这么说比较习惯——这也说不准那～ :)

其实，仔细想想，“过马路，左右看”是个很有道理的话。中国的车辆都是靠右行驶，所以过马路的时候前一半的过程（就是从路始边走到路中间的过程）总是车辆从我们左边开过来，而后一半的过程（从路中间到路右边的过程）总是车辆从右边开向左边。

于是，这个俗语就教导我们先看左边再看右边，甚至可以说走前一半的时候可以只看左边，走后一半的时候可以只看右边。如果把口诀反过来做，就做了无用功；如果没有这个口诀，没准过马路时头会摇的跟一个波浪鼓似的。（注1）。

中国人做事很讲究总结一个口诀，内功讲究心法，练刀有刀谱，练剑有剑诀，甚至书圣王曦之还写了个什么书诀（我忘了多少招了，那个兄弟提示下）。再比如《西游记》中说孙悟空过火焰山的时候把毛都烤糊了，于是左手捏了个避火诀冲了下去。这说明口诀很有用，本领大如孙大圣都用的上：虽然你不知道他是怎么来的，但是照着口诀做就没错——老祖宗已经验证过了才总结成口诀传下来。

其实软件开发的时候也有很多口诀，即便是不明白道理，但是照着做，总没错。如果不照着做，没准还真就捅了篓子，或者在代码中埋下了一时难以出现的隐患。下面就举一个C中的应用口诀的例子（C++我不懂，就不献丑拉。～）

比如，有个口诀叫做“定义宏常量或宏公式的时候，一定要加圆括号”，有很多人就不理解，于是他们就不加，结果就出了类似于如下的问题：

#define NUM_A  100
#define NUM_B   25 * 2
#define int_div(a, b) a / b

float c;
c = int_div(NUM_B, NUM_A); //作者原意是  50/100,实际结果是 25 * 2 / 100, 结果没错
c = int_div(NUM_A, NUM_B); //作者原意是 100/50,实际结果是 100 / 25 * 2，结果错了。

试想，如果我们就按照口诀来操作：

#define NUM_A (100) 
#define NUM_B (25 * 2)
#define int_div(a, b) ( (a) / (b) )

又怎么会出错呢？

再举个例子，比如有个口诀叫做“头文件里面只声明不定义”。如果不照这个口诀操作，也会出问题。比如：

//a.h
int max(int a, int b)
{
    return a>b?a:b;
}

//main.c
#include "a.h"
#include "a.h" //include 两遍后就会重复定义max()，结果出重复定义的错。

int main()
{
	return 0;
}

你肯能会说，我在.h里面加点料儿，保证它不重复定义,比如：

//a.h
#ifndef _A_H_
#define _A_H_

int max(int a, int b)
{
    return a>b?a:b;
}

#endif //_A_H_

Okey，现在上面那个case确实搞定了（注2）。但是下面这个就又不行了：

//a.h
#ifndef _A_H_
#define _A_H_

int max(int a, int b)
{
    return a>b?a:b;
}
#endif //_A_H_

//b.h
#ifndef _B_H_
#define _B_H_
void foo();
#endif //_B_H_

//b.c
#include "a.h"
void foo()
{
    max(100, 200);
}

//c.h
#ifndef _C_H_
#define _C_H_
void bar();
#endif //_C_H_

//c.c
#include "a.h"
void bar ()
{
    max(300, 400);
}

//main.c
#include "b.h"
#include "c.h"
int main()
{
    foo();
    bar();
	return 0;
}

分开编译b.c、c.c和main.c都还可以通过，但是最后一link就玩儿完，因为max()被定义了两遍。所以如果max()的定义放在a.c文件里，而在a.h中只写max()的声明就不会有这个问题了。（注3）

综上所述，我想说的是：如果能通透理解口诀的含义那是最好（达到了心中有剑、见招拆招的境界，每招虽无口诀的形但是却暗含了口诀的神），如果不能通透理解，不妨先照着口诀做，而不是总跟前人总结口诀对着干，真是“不听老人言，吃亏在眼前”。做的多了，也就慢慢悟了，可以细细琢磨口诀的真正含义，总结口诀应用的场景，从而达到避开“听了老人言，吃亏在后面”的境界了！：p 这就是否定之否定么？我瞎说的。^_^

注1：
后来我想到：英国的车是靠左边开的，会不会他们教小孩子的口诀是：when going across the road, look right then left! :p
注2：
这里用了“头文件里面要加guard宏”的口诀，所以避免了一个问题！:p
注3：
后来释雪提出来，可以在.h中定义的函数加个inline来搞定。这个例子举的不好，我只是觉得函数定义和声明的概念比变量定义和声明的概念容易描述清楚才举这个例子。其实对于出“函数定义写在.h中”的错还真不多见；不过把数组定义和初始化写在.h文件中可真就屡见不鲜了，有时候还真是让人头疼的狠。
-------------
乾坤一笑写于2006年02月05日转载请标明出处和原文链接

当前手机开发领域中c和java的地位

乾坤一笑 — Sat, 21 Jan 2006 21:31:00 GMT

源于和pAnic在七猫的《C++的衰落和JAVA、C#的崛起》的评论中的讨论。我觉得自己总结的不错，以后可以再回头看看，看看想法有没有变化：

>>> pAnic的发言：
>>>我有一点不明白，就是手机等开发，市场上净是java的产品，按理说这应该是嵌入式开发，C应当有相当市场份额的。。
>>>而且Java开发的GUI和游戏，运行效率实在有点不敢恭维，经常连屏幕刷新都看得到--b
--------

我的解释如下：

1)手机开发，平台全是C；MMI绝大多数也是C做的，或者是用其他工具设计然后再generate成C代码，然后用C编译器编译。原因很简单，由于手机市场竞争极为残酷，要拼价格战就要降成本，要降成本ARM就要用低端的，现在芯片套片也逐渐向All-In-One方面发展，所以...
如果纯粹用java开发，不用别人打击他，他自己就跨了。

2)对于协议栈部分，更是非C不可。这个部分的性能治标都是ms级的，那个用户也无法忍受拨个电话好几秒都不通。

3)手机上的java是趋势，目前来看不可取代，但java主要用作增值服务，比如游戏、二次开发接口等。因为java的可移植性的优势不仅仅在目标发布阶段，在开发阶段更具有优势。如果用C的话程序必须要进行目标单板上的验证（集成测试？不太确定），但是java完全可以在windows上开发好，然后直接down在手机上用就Okey了。

4)目前手机上的单板调试工具比起windows和linux软件开发的调试手段来说及其落后，基本上都是依赖最原始的trace、assert、或者注释代码行等手段来调试。这也是用C开发比较慢的原因。至于驱动程序就更不用说了，是没法模拟的。