时间紧迫症

时间紧迫症

  -- 时间紧迫的恐惧感

 昨夜至今天（20130421）我深刻反省自己，并勇敢地认识到：近几日得了时间紧迫症，内心反复触发起恐惧感。缘由来自最近工作的项目，一个对先前设计方案不断优化与改进的项目，这是之前出自我手的一个分享文件的设计方案（程序）。这段时间（10 天左右）关于项目优化的细节占据着我思维的大部分（80%），除了工作时间几乎占用全部之外，早晨睡醒脑子里第一件事情就是它或者说它把我从睡梦中叫醒，午休时候同样如此，晚上睡觉前最后一件事考虑的事情同样也是关乎方案的优化细节。

这些日子，优化细节不断从思绪中涌出，而且我总能很快付诸行动去编码、测试、观察性能、改动继续编码（反复）……如此反复的情况正是不断尝试调优的过程。这些日子，我的精力如此旺盛，在前面的日子丝毫不感疲倦……终于在昨天下午我深感累了，这种感觉似的来的异常快速，快速的令我不得不去反思回味前面的过程……其实，我应该更加理性一下，有些时候过于投入容易出现无法自拔的境地。

至此，项目的调优效果明显已达到原来预期的效果（甚至有点惊喜），至少可以满足领导们现在的期望了。因为所采用的优化方案不会对原来的设计结构大动干戈，而且经测试验证其效果理想，这样我们可以松了好几口气，可以暂缓下来去做其他比较紧急的另一个事情了，按理说现在我应该内心放缓轻松下来，不必为此事而费神了。但是，对于源源不断涌现出来的优化细节，我却抑制不住放缓不下来而是内心莫名紧迫起来恨不得立刻付诸行动去尝试……还有其他的工作事务安排所以容不得我去放纵。所以，后面这几天我的内心常常自我矛盾。最后深深发现自己累了，在网上搜索了解到“时间紧迫症”，与我的情况最相近了。

最后，我想简单地总结一句表达我想说的：由于最近工作的项目在不断地调优过程：思考、编码、测试、验证、改进、思考、编码……如此反复，导致近几日内心默默产生一种紧迫感，即一旦有思绪恨不得一蹴而就，立马付诸行动得以理想的优化结果，竟然一段时间乐此不疲精力旺盛。与如此情况最相近的就是时间紧迫症。累了，今日深刻自省，已放缓过来。

关于时间紧迫症，从网上捞到的定义（参考互动百科的时间紧迫症 ）：

  时间综合症是指人们对时间的反应过于关注而产生的情绪波动、生理变化现象。时下，快节奏的现代生活，使都市白领感到时间越来越不够用，对事业的专注使人对紧迫的时间感到焦躁不安、紧张过度，这样会引发心率加快、血压升高、呼吸急促等症状。

咳咳……如上这些的表达都是为了尝试另我放松下来，我歇息歇息，满血再战！

记于20130421（完）

成功的老板都善于讲故事

成功的老板都善于讲故事
 -- 20130221 听Big boss 说价值观

刚好（20130221）今天是我第一天上班，中午就恰逢老板CEO（还有看看公司的CEO付总）请蜘蛛网兄弟们吃饭，前面说是老板与我们互相交流，而事后看来其实不如说是大家听他（们）讲故事，灌输一些价值观给我们，在此谈不上洗脑，毕竟老板说的那些事情我们相对比较认可的，而且也有类似娱乐新闻的趣味故事，笼统的回想回想，掐指算算聊到的话题，有：

1，聊自组网应用前景。嵌入在快传、手雷提供组网与数据传输服务，搭建平台。具体应用于文件分享、游戏平台等。

2，小团队作战能力精悍，反应敏捷效果突出。举了个例子几年前迅雷对手网际快车的第一作者（侯延堂），当时单枪匹马可以把软件设计的很好，但是后来交手给了十多人的团队反而没把握好方向了，慢慢做得不行了（落后了）。

3，迅雷也一直努力站在用户的利益。老板做迅雷牵扯的利益要面对股东、ZF、还有网民（用户）。老板技术出身一直崇尚技术但毕竟也是位商人，在当年中国环境办公司做生意必须学会与ZF妥协，要做好迅雷最终面对的是用户所以一直放用户利益至上。需要在股东与ZF面前争夺用户的利益。

4，在国内的互联网公司，老板最佩服的公司是阿里巴巴，在IT业界电商方面它不仅把技术、服务做得第一，还给中国提供了无数就业机会与商机。

5，在当今中国经商不得不与官员打交道，需要懂很多门道，还有老板风趣说趣事比如，有时某位官员觉得迅雷不听话想找茬，最后迅雷常常先找到了他的上司，这样就安然无事了。

6，迅雷碰到最多的官司关于版权问题……常常很难与好莱坞那边谈拢合作起来，可恶的美国人表面很斯文实际上都是很强势的（老板在美国生活了十年时间深有体会）。迅雷与好莱坞那边有过几次官司谈判，结果都不是很愉快。最后迅雷找到了好莱坞的爸爸（默多克）作为靠山，通过华人邓文迪（默多克第？任妻子）加盟了迅雷股东，这会迅雷在谈判上就有了足够的底气了。

7，老板说到自己一段不孝子的故事。2011年迅雷在香港、美国路演筹备上市（虽然最终未果），其年迈的父亲也一直跟随之儿子，但老父一直有个吐痰的习惯，当时在路演过程儿子正因此（不良）习惯而在父亲身上感到过羞愧……事后老板认真反省过，羞愧自己不孝，更应该体谅老父年老。日后要努力做好孝子。

记于20130221（完）

另一种“荒野求生”

另一种的“荒野求生”
  源自知乎的一个话题（问题）。

• 话题：

五年编程经验，跳槽到新公司后，月薪 6000 元，但工作内容就是写注释，写了一年注释，这种情况在编程行业普遍吗？

我有五年的编程经验，其中一年是实习，其余四年在一家小公司做外包。由于我不习惯公司整天把我外派到别的公司做技术，于是我就跳了槽。
现在这家公司是一家所谓的大企业，已上市，技术团队几百人，公司名字就不说了。月薪6000元，我上一份工作月薪是4500元。
但工作内容就是给代码写中文注释，整天就是跟//打交道，写了一年注释。
我另一个同事更离谱，整天看代码然后用txt文档记录可能出错的地方，别说开发，他一年多都没配过ide。就算他找出错给总监，总监也不理，测试那组几十个人，也轮不到他，他找到的人家早就找到了。
现在这份工作总的来说，能看到别人写的非常牛X的代码，很多非常牛X的算法，但没有办法参与到开发过程中去，该不该跳槽？首先我承认我技术不如别人，但同样拿6000的很多人都在做开发。

• 一楼：

从描述看，这是一家“荒野求生”型公司。这样的公司特点是，新员工被仍在一个荒岛上自生自灭，优胜劣汰之后，剩下几个“幸存者”都是技术和性格非常强悍的人。
这类公司挑战员工的有：
1. 目标感，不告诉你什么时候来救你。你必须对长期在岛上生活做充分的准备。一个明确的目标使得你不至于放弃求生的希望——我要学习什么样的技术；
2. 发现食物的能力，没有现成的吃得给你，你必须把各种野菜变成食物充饥。
3. 竞争意识， 食物少或者没有食物，大家必须靠抢夺食物为生。你必须要主动的解决项目中暴露的问题，而不能等待它 assign 给你。
这样的公司不是适合所有的人。但一旦你挺过来了， winner 的感觉会伴随你以后的工作。

• 二楼：

我觉得你对自己的定位有问题，说白了只能说你是个合格的员工，公司叫你写注释你就只写注释？
如果你以这种思维跳槽，你到其他公司也不会有大的发展，我觉得你在这岗位上应该突破自己的职责做出些贡献。
比如现在的岗位
@梁涛说的：“要是你把所有的代码和注释画成流程图”，那公司肯定把你奉为牛人；
另外你通过看代码可以了解这个产品和系统最核心的东西，也许你可以发现缺陷，提供改进方案；也许你可以从某个方面设计出优化系统的办法；公司一定会给你更合适的岗位；

你还可以通过看代码了解代码编写者的能力和缺点，在你对每个人了解后很适合在以后提出好的意见，也很可能获得提升走上管理岗位；
......
太多了，努力吧，哥们；

（其他评论）……

• 我的评论：

看了楼主的问题，还有楼上诸位的一些评论！我也在此说几句吧，希望可以给楼主一些好的意见！

均同意一楼和二楼的意见，小总结一下：
1, “荒野求生存”，你需要更加主动给自己想主意啊，把事情（理清代码逻辑，不单单是添加注释）做全面、精彩了！挺过来了那么你的“生存能力”必然很大提升！
2, 明确你的定位，@yaocoder就举出了几个方面颇好！
还有，一些我的感触：
a. 楼主现在的公司环境还算比较宽松啊，可以分配给你这么一闲差。既然这样，好像更有空间给自己充电啊！
b. 都五年的编程经验了，你一定可以有更好的发展的，完全不局限于此！加油。

刚好，昨晚在微博转发了这么一条：
#管理者说#无论你从事哪一行，你都不只是别人的员工——你还是自己的职业生涯的员工。——曾任英特尔公司董事长安迪·格鲁夫（Andrew S·Grove）

补充一下：

不要单单局限于当下的简单工作（任务），尽量发挥自己的主观能动性吧，适当有点危机感，营造另一种“荒野求生”吧。何况现在自己还很年轻，对自己允许苛刻一些，不枉少年！

有的人会说，“人生不必太累了，何必呢？“ 哼，苛刻不代表就累了，真的。恰恰很多人也这么说，“每当回忆过去最美好的时候，都是那些吃苦的日子。”

PS. 知乎源地址在这里。

（完）

几条工作备忘

几条工作备忘

  -- 与工作效率有关

• 如何逃避项目延期厄运呢？

眼见身边故事的总结，个人鄙见：

1. 项目前期尽量安排紧凑，都给老子动起来；

2. 管理者对项目天天做到把控，安排各进度，能清楚手下都在忙啥；

3. 积极调动每人主动性，参与一些项目把控任务；

4. 友好善待每位手下，难但尽量做好。

至少，我所在项目没延期，而隔壁项目则严重延期了（一月）！话说回来还是我们的TL管理有方，虽说其要求比较苛刻了！

• 如何给自己提高工作积极性与成就感呢？

1. 坚持总结、撰写技术资料，博文发布分享更好；

2. 根据近期项目经验积累，整理成文积累下来；

3. 对从事方向的前沿技术或产品保持关注；

4. 乐于与身边同事彼此技术交流或产品意识或新奇古怪；

5. 不忘定期如半年或三月，为自己争取加薪升职机会。

会议讨论过程遇到有人闹情绪激动怎么办？1迅速告诉自己他只是就事论事；2他的性格决定如此，每人都有自己的个性可以理解；3他的激动表示其认真投入与执著值得肯定、甚至仰慕；4此时我需要表现更加镇静，思路清晰，否则考虑暂停继续交锋式的探讨交流；5引以为戒，有话好好说最好了！

• 如何把握好与上司相处呢？（转）

与上司相处九原则:

1.当上司讲话的时候，排除紧张意念，专心聆听；

2.有所选择地向上司报告；

3.讲点战术，不要直接否定上司建议；

4.解决好自己分内问题；5.维护上司形象；

6.积极工作；

7.信守诺言，若你承诺的一项工作没兑现，他就会怀疑你是否守信用；

8.了解你的上司；

9.关系要适度。@世界经理人网站

• 如何设计良好的接口？

如何设计良好的接口，让多模块间的交互行为看似完美又简洁？

这种解决办法在哪里，有这种银弹的吗？没有！我想永远都没有答案，具体问题看情况具体分析，最多只能说银弹值得去追求！甚至，在糟糕的情况如项目危急紧急时候，哪管什么银弹不银弹的，只要能保证模块间交互没问题就万事大吉了，即使它有着千疮百孔，银弹最多那也是后事（追求）。被A逼迫着的情况，B还要求着要银弹，C怎么办？继续追求银弹？

PS. 到此有点儿吐槽的味儿了~！哈哈:D 

• 如何算是过于强调结构设计呢？

1. 项目需求还未明确就不断追求模块化与系统架构；

2. 仅为直观的结构而调整架构而无从编码与实用性考虑；

3. 项目开发时间与人力资源均紧张情况下追求完美架构与标准文档化；

4. 用理论的一些名词强加定义不同的结构部分。

遇到困难时你的第一反应呢？

 “遇到困难学会逆向思维。”道理简单，可惜很多人当时都懵住了，完全不知所错，甚至越走越难！

  “把图片倒过来看看吧！你会发现很快乐！有时候把事情倒过来想就不一样了！转给我的朋友们。遇到困难学会逆向思维，也许会柳暗花明。。。”

（完）

做技术，做深做透，不急不躁！

做技术，做深做透，不急不躁！

===

故事从这里说起，先引用RTX内容如下：

---------------------------

longshen 17:04:08
刚刚测试了下motorola电信定制版，创建软AP问题。
主要是其WifiConfiguration比其他多出 wifi_ap_gateway、dhcp_start_addr、dhcp_end_addr 三个字段。
需要用reflect进行设置，否则会导致motorola重启。
设置这三个字段后，motorola可以创建软AP，正常通信了。

team leader 17:04:31
好的，幸苦了

team leader  17:04:44
以后我们技术，就参考快牙和快传吧。
技术这东西，还是努力做深做透彻，不要急于做结论。
有个学习和深入的过程。

junkunhuang 17:05:46
嗯，我当时没做深入进去。

===

今天，在工作上遇到一件尴尬的事情，不妨在此讲述故事并做小小的总结一番，与大家分享。虽说当时让我有点儿找不着台阶下的感觉，TL说的那些多少是落在我份上的，但我不得不承认先前我没保持足够的好奇心与专注把功能做深下去做好。

数月（2-3月）前，繁忙于无线项目开发工作，团队人员稀少（加上Team Leader共5位），分工明确且任务繁多。干活如打仗似的一场续一场的

……

当时我负责做Android系统的Wifi热点功能主要包括创建于关闭热点，得到的解决方案除了那台MOTO电信定制机（系统），都可以在其他机器上正常完成功能。开发时间仓促，当时与TL沟通后，最后就索性判断，若系统为电信定制则认为不支持该功能（创建Wifi热点）。

……

过了数月，突然发现某一流行的应用竟在那台MOTO系统上顺利创建热点，完成数据传输。那一定是我们的程序做的不完善，遇到的问题没有给予解决。

继而TL与longshen就该问题讨论起……在longshen同学很给力地进一步“追踪”尝试之下，最终顺利找到了电信定制（android）系统的私有窍门。

再然后我便知道了这事情，当时甚为尴尬，像犯了过错似的。我想最好把这件事情当是一课，记录下来提醒日后自己做事严谨，同时分享大家！

===

最早的时候，或许保持足够的好奇心与专注继续探究问题下去，那么只要一两小时的事情，问题便得以解决！不会有今日之尴尬，早知今日何必当初，所以谨记：做技术，需做深做透彻，且不急着做结论！稍作修剪作为文章标题：做技术，做深做透，不急不躁！

感谢你们，我的团队，我的战友们，我的TL！

（完）

艰难项目（二）

• 艰难项目（二）
• 故事（段子）篇

---

• 段子一

2012-10-12 Google+ 上的一条微博，如下：

“唉！领导疯了，进度疯了，任务疯了，我疯了，工作疯了，生活疯了！我的状态没了。威总是幸福的孩子！”

PS. 以下内容，从（引用）TL说过的话说起，算是些不经意的言辞吧脱口而出的，其实没啥不必太过在意，在此就只是讲故事罢了，不如说剧情需要吧。

• 段子二

时间是晚上十点钟左右，大家还在公司工作着，也差不多一日的工作安排（任务）接近尾声了，TL说道“差不多了，大家早点回了吧，早点休息。”

     -- 都TM晚上十点多了，还早点呀，有没有搞错啊。

听了TL说了几次，总觉得怪怪的，后面干脆回复了，“都这时候了，还早点啊。”哈哈，TL想想下却是有些不着调了。其实，跟TL一直关系很好，这么回复他一下，不碍事的。

• 段子三

国庆节假，提前三天（10-05）到了公司上班，没有加班费一说，最后只能是后面工作事情不多了争取调休回来吧。接着就是连日连夜加班两天，晚上都是到了十点回家的。原来期待着10-07最后一天的假期可以休息一下，结果TL看着项目进度不够排期还是很紧，“照现在的项目进度，我们明天继续加班！”。怪不得，长假一回来TL就跟大家打了预防针，打了鸡血（其他没啥鸡血），后面我们有硬仗要打，希望大家努力做好工作同时又照顾好身体！

连续三天加班，然后第四天直接工作日上班了，再连续六天的上班，苦逼倒了，明天是最后一天的！哎呦呀，现在看来这“后面”到底啥时候是个头啊！闷头继续努力吧，兄弟们共勉。

• 段子四

“最近公司很重视无线项目，公司四处调人往无线事业做项目，看得出倾力在做这个事情。努力做好这个项目（无线组网），大家都会有好处的。”

唉，听着这样的话，也照这样想只自我安慰了！不然箭在弦上不得不发，就是这种感觉了，别无他法！加油吧。虽然如上说的，听着有着那么忽悠人的感觉！我们已经苦逼很久了，连续的加班至晚上十点之后，这样的日子将近三月了，苦逼艹！

• 段子五

“辛酸史”是这样的：

     2012-08-13 开始从事无线组网的研究与开发，首先从Android的Wifi-Direct（Wifi P2P）入手，同时研究智能手机的超声波传输数据。我们为了尽快做出一个比较理想的Demo，希望可以得到CEO以及其他领导们的看重与支持，顺利加入基础研发中心项目并领取津贴。项目组加上TL一共五人，为了这个目标奋战了一个月多。如何奋战呢，这期间多得是会议讨论与头脑风暴，然后各种编码各种尝试。从刚入门Android开发起，三天时间就开始项目开发了（虽说是已有了Java基础）。每天天晚上加班至十点半，没有周末，仅休息一天（虽说后面可调休回来）。

     接着，2012-09-10（周一） 在基础研发中心的月报告会议中，我们的Demo演示和TL的PPT演讲均顺利，并得到老板的鼓掌（认同）。当时心想既然CEO认同了，那目标有望实现了，顺利领取加入基础研发中心项目并领取津贴。

     然后，万万没想到的结果就在之后第三天（周三）TL接到上层领导通知，要求我们团队直接调往无线事业部参与无线项目的开发工作。这样情况，那个目标就只是泡影了，与津贴无缘。而且是CEO发号施令，要TL搬到他的办公室，我们必须再次搏一把努力一回，正所谓”箭在弦上不得不发“，别无他法。引用同事的一句话，“距离心脏最近的血液就越是新鲜。” 要明白，这是用来打鸡血的~！要吧，兄弟们，继续努力，后面的机会更多，面包有的，金子银子也会有的！

     ……

（完）

艰难项目（一）

• 艰难项目（一）
• 谈谈艰难项目中团队协作的项目管理感悟

---

• 前奏
• 2012-08-13 开始从事无线组网的研究与开发，至今（2012-10-18）已两个多月，整个项目组成员（加上TL共五人）为了项目还一直在奋战，周末若单休已很奢侈了，恰逢国庆长假而提前三天（2012-10-5）回到公司报到继续加班，然后不休息继续开始正常的工作日上班至周六（2012-10-13），连续上班九天下来。两月多上班的晚上几乎都是十点后下班的。后头想想，我们都是被狠狠打了一把一把鸡血的，而无怨无悔。“路漫漫其修远兮，吾将上下而求索。”
• 这样的高强度的工作压力与十分紧凑的项目进度，结合同事间团队协作以及项目管理者（TL）的项目推荐工作，在此仅做尽可能简单的工作总结。其实不该叫工作总结，工作感悟会比较贴切一些。详情如下，开始吧。
• 情节
• 额，该如何形容上面说的最近艰难的项目呢，想想：

几个形容词：

紧张，紧凑，高压，努力，艰难，浮躁，激动，发泄，不满，体谅，坚持，……

几个名词：

领导，项目，进度，任务，排期，版本，文档，方案，会议，团队，情绪，Demo，夜晚 ……

几个动词：

赶，计划，推进，讨论，争议，加班，编码，调试，连调，解Bug，重构，协调 ……

• 感悟
• 额，艰难的项目开发中，得有几点感悟，说说：

1. 模块清晰，分工明确。

     尽快对项目的开发与测试工作进行模块划分。

     这些划分就是服务于后续项目工作给同事们的分工，需保证项目具有持续、并行的进展。

2. 严格把控项目进度。     

     该点最为重要，项目管理者需要明确分配任务，并知道每位同事现在手上的任务及进度情况。做好项目推进工作，若意外出现了滞后部分需及时协调过来。

3. 营造紧张而顺畅的讨论范围。

     紧张，问题讨论紧凑，针对性强，尽快解决。顺畅，讨论过程彼此理性对待问题，保持和气。

     会议或讨论时候需控制好各自的情绪，免得伤了和气。否则难免影响到大家的士气。

     都是同一条船上战斗的，和气很重要。伤了和气，很容易削弱团队士气，打击同事的积极性，影响大家协同工作，难免会滞后项目进度。种种坏处在此就不多描述了，你我想想便知！

     这里，我与TL有过几次的情绪冲突，事后想想其实没必要。还好，俩人都是性情中人，除了上下级的同事关系也是好朋友，乃良师益友。

4. 领导与下属关系融洽。

     最好，保持与同事们的沟通。有障碍则尽快化解，可能有时领导需委身妥协，有时下属需多多谅解领导。

（待续）……

高管VP会议什么样子！

高管VP会议什么样子！

     -- 公司VP会议初体验心得.20120828.AM

---

20120828的上午，已经是一个难忘的时间了，一次至今难得的体验经历，虽然这种经历不是令人所爱的。

经历情绪波折，百感交集（夸张了点:D），欲知详情，且听下文描述 ……

简单的故事情节如下：

     由于项目工作需要，有幸跟着Team Leader一起到公司高管会议报告项目进展与Demo演示。而我们其他兄弟几个仅是赶场旁听，就坐在后面的一排的角落位置。

     公司大老板对于报告表示了不满，提出了几点批评与建议。直接的说其情况就是我们几个兄弟在后面看着TL在上面挨着老板的批评，场面挺尴尬的，我们在会后都有些佩服TL可以这样挺过来呢，不容易了啊！我们心里当然都很不爽不开心啊，毕竟这段时间确实努力地辛苦地付出。可能方向错误的原因吧。大老板与TL之间其实还隔着两三层的组织关系呢，领导的想法与我们的行动达不到一致。

     其实，这过程我心里有些紧张的，有这样的假设，上面TL若是我，我将什么个情况 …… 负责的心情啊。

     由于PPT报告结果不理想（糟糕的），所以我们没有做Demo演示，拿不出台面有两个原因：

          1. Demo程序过于简单，演示效果不明显。

          2. Demo的功能点与CEO & VP们的期望不一致。

     最后，总结几点关于CEO以及VP们对于项目报告的期望点在哪里，包括：

          1. 功能新颖的Demo演示。个人觉得这里可以不必太追求程序稳定。

          2. 配合简洁的（加漂亮的）PPT演说。功能点说明清晰，可借鉴乔布斯的产品发布演示视频。

          3. 搜集罗列说明下业界相关的产品情况与技术进展。

          4. 尽量不要展望（画饼），要低调。不过，可私下与CEO交流。

          5. 涉及到开发实现的东西，一律不必在PPT或会议提及。

     作为基础研发的项目，老邹（CEO）强调要基于未来一年两年之内的产品发展方向，而非从事当前产品研发，但可从现有产品中存在的问题，难以一时填补的问题摄取出发点，着眼于未来一两年时间。

     有幸见识到公司CEO主持会议的风范。但也总听说起他一贯的霸气，有点‘独裁’的说辞，其他的较多的旁听的份儿。小辈子的我们，确实可以从中学习到很多东西。以上描述到的这些心得总结，算是其中一小部分。

     后续努力，同事们再接再厉吧！

--

     20120910.PM 续

     “今天下午在项目汇报研讨会上，我们的项目汇报进展顺利，接近满意效果。能拿出来演示的基本都顺利在DEMO演示效果表现出来，而且我们TL演讲效果良好，所以整个项目汇报效果比较良好。至少我们这么觉得，包括身边的其他开发同事以及HR同事。”

（完）

Android开发笔记（二）

Android开发笔记（二）

    -- Android开发网上资料搜集（部分）

---

最近，刚开始从事Android程序开发，由于之前（大学时期）就已经掌握了或多或少的Java开发基础，包括Java语言基础与开发环境（Eclipse，NetBeans等），所以，在短期入门Android开发难度不大。但是，要想做好当然不容易的，需要一段时间的磨练，学习android开发资料以及实践经验的积累。

以上的背景说明大概描述过了，那说说这篇笔记的内容吧。内容就是针对这段时间（10 days+）从网上搜集到的相关资源的整理，主要涉及android开发的网络通信，多线程，消息处理等。足够的简单内容，可惜的是暂时没有属于自己的东西可拿出来的分享。毕竟，还是刚入门不久的Android小生一枚。待日后功力足矣再言，亦可。

--- Android开发网上资料搜集（部分）  --
Android UI学习 - 对话框 (AlertDialog & ProgressDialog)
http://android.blog.51cto.com/268543/333769/

Android程序完全退出的三种方法
http://blog.csdn.net/gumanren/article/details/6199789

Android中的异步IO-Select模型
http://blog.csdn.net/magoboy/article/details/7588460

GPS定位基本原理浅析
http://www.cnblogs.com/magicboy110/archive/2010/12/09/1901669.html

Android 中文件类型与MIME的匹配表
http://www.cnblogs.com/hibraincol/archive/2010/09/16/1828502.html

用 managedQuery() 时需要注意的一个陷阱
http://blog.csdn.net/quaful/article/details/6976768

android中handlerthread通知机制
http://www.liuxuchao.com/show-13-2-3.html

Android Handler机制
http://blog.csdn.net/stonecao/article/details/6417364

Android的消息机制，用Android线程间通信的Message机制，Android中Handler的使用方法——在子线程中更新界面，handler机制
http://www.cnblogs.com/-OYK/archive/2011/08/03/2126657.html

Android异步处理一：使用Thread+Handler实现非UI线程更新UI界面
http://blog.csdn.net/mylzc/article/details/6736988

android_获取音乐文件信息
http://wenku.baidu.com/view/332ca36048d7c1c708a1454b.html

在Android 中调用选择图片、视频、添加音频、录音、拍摄视频、拍照等其他的功能
http://blog.csdn.net/geolo/article/details/6557860

Android Permission大全1.0最终版本
http://www.builder.com.cn/2008/0925/1152080.shtml

Android开发中获取本机Mac地址和IP地址的方法 （存在问题需改进）
http://blog.csdn.net/sulanyan29/article/details/7349612

Android的窗口机制分析-事件处理
http://www.linuxidc.com/Linux/2011-11/47721.htm

Android 对话框(Dialog)大全 建立你自己的对话框
http://www.cnblogs.com/salam/archive/2010/11/15/1877512.html

android Uri获取真实路径转换成File的方法
http://fzlihui.iteye.com/blog/1098043

android Toast大全（五种情形）建立属于你自己的Toast
http://www.cnblogs.com/salam/archive/2010/11/10/1873654.html

Android Handler机制
http://blog.csdn.net/stonecao/article/details/6417364

android的socket与udp广播
http://www.eoeandroid.com/thread-23413-1-1.html

【Android】Socket编程 TCP和UDP实现
http://hi.baidu.com/lphack/item/39bf110e5a118c3ef3eafcad、

Android数据存储（总结篇）
http://www.moandroid.com/?p=319

Thread和Looper以及Handler和Message详解 Android开发必读
http://www.android123.com.cn/androidkaifa/422.html

Android下如何调试程序？
http://www.moandroid.com/?p=339

Android DDMS如何使用？
http://www.moandroid.com/?p=638

android消息推送-XMPP
http://blog.csdn.net/sulanyan29/article/details/7451663

[Android算法] 【eoeAndroid索引】史上最牛最全android开发知识汇总
http://www.eoeandroid.com/thread-168008-1-1.html

加密（混淆）APK安装包防止反编译。
http://topic.csdn.net/u/20120816/18/65c5fd07-ae0c-41a9-9a46-c4faec76cd79.html?62827

--- Android开发网上资料搜集（部分）  --

后续若有时间再针对性地整理一下最近的学习心得或其他值得推荐的学习资料吧。根据网上搜索Android开发相关资料的情况，总体感觉Android开发还是比较活跃的。

最后，在此感觉一些同事、朋友提供的帮助，如@SmallArcher ，@wangzhichao等。

（完）

如何提高工作会议效率

如何提高工作会议效率

---

（#工作效率# 笔记：20120820 ） 

鉴于最近繁忙的工作，基本上每天一次工作会议讨论，其中深度热度都保持在良好的范围。差不多这样的会议：5-6人讨论会议，每次会议总结一份会议记录结果与TODO LIST，明确分工情况，每次会议内容开始于上次会议的结果与TODO LIST。大概流程如下：

a. 回顾上次会议TODO LIST的解决情况。

b. 各自发言提出遇到的新旧问题，一起讨论解决方案。

c. 下一步工作任务的确定与分工。

d. 会议记录并总结。

这段时间的会议参与让自己对于这方面有些额外（除工作内容）的体会，而且感觉不错不妨尝试将心得描述出来。

……

就关于“如何提高工作会议效率”该话题，在此简单地总结关键的几点：

1，确定会议主题可包括若干主题，但不求多。

     开会之前就需要有人去确定会议的主题或是上次会议遗留下来的TODO LIST。

2，彼此讨论需要意见鲜明，此时沟通无需含蓄遮掩。

     越是含蓄，或是表达不清，那么使问题容易复杂化。若没想到把问题表达情况，那请你继续思考。

3，必需有人具权威地控制讨论范围，避免跑题。

     多人的会议讨论，容易扩大了问题讨论范围，或多种解决方案无法让问题有着落，或多方持有不同观点等等……此时需要权威人的拍板。

4，白板画笔必备，且需有人做过程记录并会后总结。

     白板与画笔可以是思维表现的载体，彼此快速沟通的催化剂。可能这样形容不够贴切，但差不多就那意思了。会议记录与总结目的就是提取会议要点，让会议内容延续下去如推进工作进展，落实会议结果。

5，适当控制讨论情绪，激动也行但不得积怨。

     希望通过会议上面的讨论，从侧面上可以增进同事间彼此的沟通与理解。

其实，实际工作中各人情况存在或多或少的差异，所以以上这些当然不是教条，只是一种工作方面的心得感悟，甚至是一时的。

附一条，昨晚的微博，如下：

睡前吐点不快，以好睡觉：哎，忙活一天，加班就不说了，都是边敲代码边思考琢磨边讨论再敲代码...这样的头脑风暴，甚可惜的是折腾到十点半还没出来满意的结果，只能明天赶早继续，还有，更好的彼此协作很重要，需进一步改进。祝晚上睡好别满脑浑沌着，明天事半功倍！好久没这状态了，亦好亦不好。

（完）

一个设计漏洞引发的故事

一个设计漏洞引发的故事

     -- 根据链接URL的字段值判断采用的下载调度策略

---

讲故事吧，想说明一个漏洞案例是具体如何被触成的而已。引以为鉴！

“秦人不暇自哀，而后人哀之；后人哀之而不鉴之，亦使后人而复哀后人也”

==

2010年，为了节省会员CDN带宽与服务器压力，在客户端程序针对会员CDN的连接，做了流量优化的下载调度策略（保证速度的前提下尽量少去CDN请求下载数据），以达到目的。

PS. 会员CDN即XL公司自己架设的服务器专门提供给迅雷会员加速下载的。

诶，好不容易做了一套效果勉强还行（？）的策略，成了。就这样！那时候我才刚刚接手下载调度模块，显然策略的设计者不是我，而是跨部门A的某同事，但是后面我就一直充当其维护者。

题外话：由于某下载调度老前辈升职去了其他部门A结果就顺着带下载调度模块过去，而我当时任务就是尽快熟悉下载调度并拿回来下载调度模块……

当时，百思不得其解，优化策略其中的一奇怪逻辑：判断该资源来自于会员CDN根据其URL是否包含某字段值。 如：

若下载资源对应的URL包含关键字段为"xxx.vip.xxx"，则任务该资源为会员CDN，即参与资源流量优化调度策略。

不明白为啥这么做，我也问过相关同事（跨部门），得到的说法只是设计简单实用。

好吧，程序就在那持续的跑着，没问题。

====

2011年，刚好另一部门B的其他下载产品同样需要做流量优化。该部门的某同事偷偷在其他同事那边打听到了上面描述的”奇怪逻辑“。然后，他就在其产品的下载任务URL上面增加了关键字段"xxx.vip.xxx"。唉，恰到好处确实可行。我估计，该同事当时肯定偷着乐到了。（其实我是事后2012最近才知道这事情的。）

好吧，程序就在那持续的跑着，没关系。

====

2012年，（上面提到的）另一部门B发现那套优化策略已不适用，存在不合理地方，主要由于其产品演变包括用户数剧增，产品特性变化等。既然不适用了那么就需要找人继续优化了。找谁，找其他部门因为他们不持有该策略的研发（downloadlib），正是我现在所在的部门。

经多方面讨论，决定使用已有的那套优化策略服务部门B的CDN，为节省器服务器带宽。这样的决定，说明了我们都不知晓“2011那段故事”。

直到我们完成了功能的开发设计，在做程序连调时候无意间在LOG上发现存在怪异情况，即使没有新加的逻辑，程序也已经在为部门B的CDN资源做流量优化了啊。

……在此省去很多气愤与无奈的表达……

最后，召集大家一起讨论，说清具体事实情况，才知晓了“2011那段故事”。

其实，那套流量优化策略不仅在为部门A的会员CDN服务着，还默默地为部门B的CDN服务着。

好吧，程序就在那持续的跑着，没关系。

====

显然，那奇怪逻辑就是一个设计漏洞。很容易被外者利用以触发原本不该走到的逻辑。还好上面说的外者是自家的兄弟部门。

若是外面其他公司的CDN知道该漏洞，并加以利用了，那么我们不就白白为他人做了巨大的省钱活儿了吗！

所以，需尽快改正回来！

（完）

谈谈团队建设

谈谈团队建设

     -- 有感于XL下载库团队

---

最近半年时间下来，在某些方面（团队良好建设方面）隐隐觉得总有或多或少有些体会与感悟，（题外话：有时疲惫的时候脑子装东西多，容易浑起来就慢慢担心过了就忘了，所以就想找个办法帮忙记录下来，此时笔记倒是一项良好的辅助记忆的解决手段。）所以，就此写一篇小小总结博文记录之，希望可以积累下来。

不妨，挑选一些重点（细节）讨论分享吧，尽量保持简洁，罗列下面几点：

1. 氛围活跃

     需要营造良好的相互学习与技术交流的氛围。

     最好每个成员都有自己的专长，能够整理出属于自己独特的知识与大家分享，这样做同时可以让大家在心理上建议一种平等，因为程序员们是相对骄傲的一类群体。可以每周（每月长了点）定期组织一次由某成员发起的具有针对某主题的分享、交流、讨论会议。

2. 存在权威

需要一个权威成员，不管是来自技术还是管理层面都可行，只要能够在多成员间存在争议时拍板做最终决定。

     引用几句有点意思的话，某权威同事说，“就这样决定了，服从就是绩效。”，哈够强悍吧，显然他既涉及技术也是管理人员。

3. 共同爱好

     团队需要有一个共同的业余爱好，交流融洽。

     比如午休时间玩玩三国杀，或每周一次的篮球运动或游泳或其他运动、娱乐项目。这种活动对于团队的默契以及成员间的友好作用不凡。

     让同事们除了在工作中协同合作，还在生活玩的项目上协作吧，收获乐趣的过程中就释放了工作中的压力与疲惫，同时收获友情！下班时间，同事们可以互相调侃，玩笑，聊聊生活趣事，尽量不必谈及工作的事情。

4. 良性发展

     整个团队需要有良好的发展与支持（物质与精神上）。

     作为团队的Leader（TL @jieouy），必须（应该）尽力去为下面的同事们争取各种福利，包括升职加薪机会，工作与学习资源，还有团队活动经费等。这点对于TL而言，很重要不仅大大提高其在兄弟们心中的分量，而且之后兄弟们一定是更愿意尽心尽力去做事。

5. 能力拓展

     培养团队成员们都具有一定的产品与项目管理意识，最好都有尝试去做好的机会。

     该点也是为了同事们都有更好的发展，不必疑问说“有些人不合适做产品或项目管理呢“。不好意思我想说的是，不管是产品或是项目管理涉及的范围都是多方面的，只要你用心去发现去做，正常人都会从中获益的。这样的结果，大家都有一定成就感在其中，可以有提高团队凝聚力，尤其在与其他团队PK某竞争时候。

6. ……

   （待续，再想想应该还有不少点可以加以总结，但暂时未想到更好的，就先占坑放着吧。）

注：以上内容可认为纯属笔者YY的结果。

最后，感谢所在团队的同事们，感谢欧爷@jieouy！

（完）

谈谈内存越界读写的危险

谈谈内存越界读写的危险
  -- 记某一次低级而糟糕的程序犯错。

---

# 故事
这是发生在上周的事情了。当时就有想法，要写篇文章以表示‘铭记’。

想必，这个话题对于C/C++程序员一定很熟悉，都有过或多或少，或轻微或严重（惨痛）的经历吧。

最近正在开发的项目，正在内部开发人员自己测试阶段，突然爆出好多的程序崩溃，大概估摸了下这些崩溃的规律如下：

     1，程序崩溃不确定性但必崩，只要你多操作几次，或重启程序再来试试。
     2，这些崩溃基本都不一样，（从堆栈看来）分散在不同的几个模块；
     3，分析程序崩溃堆栈看到崩溃在正常的代码上（显然不可能），亦看不出错误代码地方了。
     4，由于有辅助程序可在程序崩溃时候帮助自动抓取程序堆栈。但是有时程序崩溃无堆栈或堆栈数据无效。
……

最后，辛苦地安分地回头好好Review最近提交的代码，（……由于这几次提交改动均无法自己做到完整的测试保证，只能自己简单的功能程序和代码Review……），涉及的代码量较大，所以花了不少时间才找到了错误所在，有地方内存越界读写了。虽然找到了错误并很快纠正过来了，但是那样的低级错误让吾情何以堪？也正是为了纪念这么一‘尴尬’，我才想整理一篇博文表示‘罪过’。前车之鉴，后车之师。

个人觉得，上面总结的规律四点不妨可作为“内存越界读写”这样错误的表象。若以后还是遇见这样情况，不如先怀疑怀疑你的内存被越界读写了，赶紧回头仔细Review代码吧，相信你已很快顺利找到错误地方……

# 示例

下面内容就简单描述一下如何导致程序乱蹦，即越界“乱踩”内存了！示例代码如下：

struct A {
     ...
};
struct B {
     ...
     A a;
     ...
};
// 错误程序如下：
void some_func(struct B* b_ptr) {
     ...
     memset(&(b_ptr->a), 0, sizeof(*b_ptr)); // Error: memory overwrite.
     ...
}
// 修正程序如下：
void some_func(struct B* b_ptr) {
     ...
     memset(&(b_ptr->a), 0, sizeof(b_ptr->a));    // 1. ok
     // memset(&(b_ptr->a), 0, sizeof(struct A)); // 2. or else, also well.
     ...
}

果然吧，错误的程序那么低级，So stupid，而找到了错误修正程序那么简单的！程序就恢复正常了。

我想当时写程序脑子犯晕了吧。好了，不再多说了。还是我以前的那么句话，“以后写程序时候头脑得时刻保持精神点，否则后果有你好受的。”

# 借鉴

最后顺便引用一段关于内存越界的描述吧，延伸看看，想想。

--

对Memory overwrite 和memory corruption有什么好办法哪？常见的，就是设置CPU的breakpoint，也就是对某一地址的写操作，dump出stack，然后找是哪个模块写坏的。或者可以把整个page设置成只读，在操作系统层面检查，然后dump。这些对只读的变量或者page还还用，但是对可读写的变量又该怎么办哪？如何区分合法的读写和非法的读写？
对于非法的读写，也有在语言层次进行控制的，比如c++/java/c#等面向对象的语言，就有对对象的保护。但是这些语言并没有排除全局变量，也就是说，在语言层次的控制并不彻底。基于语言的静态检查是个好办法，但是对大规模代码，检查也需要时间和精力。任何经过仔细review的代码都是好代码，但是，有哪些公司能够坚持严格的代码review哪？
对于第三方和legacy的代码，review也基本是不现实的，但是静态检查是第一道防线，一定要坚持。
在操作系统层面，没有对象的概念，导致在操作系统层面没法保护。或者说，操作系统层面的保护代价太大了。我觉得还是操作系统的设计思想没有体现保护，隔离的要求，传统操作系统在这方面，做的很不够。
新的操作系统应该能够在更细粒度上做到隔离，保护，但是性能，通信等等又如何解决？

引用自这里。

-- 

还有，在stackoverflow上面关于内存越界的一段讨论，这里。

（完）

删接口，哥以后惹不起了。

# 删接口，哥以后惹不起了。 
     -- 越是稳定的产品项目，其接口越不予改动。

---

# 背景

今天遇到一件比较尴尬的工作上事情，虽然有些后悔，但也没有啥不好意思的。所以就想在此描述聊聊，吐吐内心里的小小“憋屈”。

其实，只是涉及一个小小的程序改动，不过故事倒是不短。那开始讲起……

最近工作上都挺忙的，事情多需要经常多线程切换操作，这边事情那边事情的：

负责日常项目管理事务（项目计划安排，组织开会讨论等），负责版本控制安排（版本统一编译，提测，配合打包等），负责项目开发工作，负责配合测试的工作（撰写需求、设计文档，梳理、解释、讨论设计逻辑等），负责解决问题（包括测试发现的问题，关注崩溃系统问题，用户反馈诡异问题等）。

（故事背景，当是讲故事前奏预热吧☺）

# 故事

前一阵子，某项目涉及一个接口的修改，而该接口为异步返回结果，描述如下：

原来，调用者不需要关心其返回结果。一个简单接口可以满足，

int set_xxx_func ( ... );

现在，新的需求决定调用者要关心其返回结果，调用之后调用者需要以轮循的方式查询结果。此时需要两个接口得以满足：

int submit_set_xxx_func ( ... );

int query_set_xxx_func ( ... );

PS. 至于这里为啥是轮循方式查询？在这里不是重点不需关心☺，具体的系统设计决定了这样的形式吧，不过当然是callback机制的效率高于一筹了！不再多说了，否则离题了。

说到这里还没有说到重点呢，改接口。后来因这样的新需求决定如上描述修改了该接口。记得在过（讨论）详细设计方案时候，开发测试四人（包括YJ，JL，SY还有我）都提到了是否保留原来接口set_xxx_func的问题，讨论中确认了已经没有其他产品，其他模块在使用该接口了，而且差不多已一年的时间没有使用到了吧，最后大家均同意了去掉该接口吧，直接上新的接口吧。因为该接口的模块一直都是跟着另一接口层模块DK一起发布的（该点是问题的所在），只要保证到时DK模块一块更新新的接口就万事大吉了。

好吧，那就果断去掉吧，我当然乐意了。作为开发人员，我已经难受很久那些“无用久已”的接口了，看着就觉得接口资源浪费在那儿，一个dll导出了四百多接口不少了吧，而且也碍着程序猿们查看代码啊。注意，这里带着当初一时比较重的个人感情色彩。汗。。

修改过程，与DK模块一并更新了新的接口设计，后面也完成了开发与测试，提测顺利完毕了。没出啥接口方面的问题，就不再关心了，以为没事就放心了。

差不多过了三周的时间吧。突然在今天下午，兄弟部门某同事突然报了一个问题到了欧爷（My TL）那边，转给了我。查了原因，他竟然使用了旧版的DK模块，Check不到老接口set_xxx_func了，囧，然后程序刻意做就地崩溃下来了。

这时，欧爷大怒了（可能夸张了点，其实情况还好吧）。痛批，“ Too simple，too stupid！，你们怎能去掉老接口呢，甚低级错误也“。

虽然某同事使用接口不当，但崩溃这种不良情况确实发生了，我有点愣住了，必须无条件承认自己过错了。奇怪，当初我们四人咋都同意了如此做法了呢。即使留着旧接口吧，也不崩溃。回想揣摩一下，”该接口的模块一直都是跟着另一接口层模块DK一起发布的“ 其实，这只是一条”一直以来都这样“的常识判断，而不是某确定的发布方案。

# 结果

情况还好，产品版本未发布，还在测试改错阶段。尽快恢复老接口，修补该问题即可。

越是稳定的产品项目，其接口越不予改动。

……

好吧，故事就讲到此吧。

所以，删接口，哥以后惹不起了。谨记！

晚安好梦。

（完）

20120615 / Junkun Huang.

下载与上传速度计算的总结

下载与上传速度计算的总结

     -- 从良好的用户体验出发，速度计算乃一门艺术活儿。

---

# 背景说明

首先，背景说明一下，这里要探讨的速度涉及到两部分，一个下载速度，一个上传速度。

前段时间从事的一个项目开发，正好涉及到计算速度，要求在界面提供有速度的显示。刚开始认为要显示速度应该很简单的逻辑，计算公式如下：
download_speed = download_bytes / tick_time_count;
upload_speed = upload_bytes / tick_time_count;

照此，若要计算每秒的即时速度，只需获取每秒的流量差值结果即可，足够简单吧☺。

# 情况描述

但是，我们上面涉及的问题很单纯，忽略了产品设计细节上的很多东西，复杂的元素。
有必要先说明清楚我们产品的在统计速度方面，大致流程是怎么设计的，如下：

--
为了方便描述逻辑，在此先定义我们产品的两进程p1和p2，说明，p1负责具体的下载逻辑，p2负责下载展示与用户交互。

-- 1，p1进程实时更新流量统计值download_bytes，upload_bytes 。

     在系统应用层，毕竟下载与上传逻辑都是在p1进程直接处理，足以做到实时更新，提供准确信息。
  
2，p2与p1的通信均为异步-轮循机制。所以p2投递异步请求获取流量统计值，然后轮循尝试获取结果。
     两进程通信是单方面，只有p2向p1投递请求，而p2获取请求结果需要以定时轮循方式得以获取。
  
3，p2获到统计值download_bytes，upload_bytes ，与上次获取的流量统计值download_bytes’，upload_bytes ‘相比得到差值

 diff_download_bytes，diff_upload_bytes 。

4，p2同时取得p1返回流量时的时间戳tick_time_count，与上次的时间戳tick_time_count‘，相比得到差值diff_tick_time_count。

5， 差值与时间代入以上速度计算公式，最后得到速度值。

     download_speed = diff_download_bytes / diff_tick_time_count;

     upload_speed = diff_upload_bytes / diff_tick_time_count;

6，界面显示的速度值为6秒的平均速度，作为平滑效果的处理。
# 问题剖析

那么，产品上面具体的复杂细节在哪里？个人的总结可能不太全面，描述如下：

1，统计流量的地方与显示速度地方不在同一进程。
     p1负责流量统计而不涉及具体的速度计算，该点主要从逻辑分层方面考虑，一个属于功能逻辑，一个属于具体的业务逻辑。
     p2可以周期从p1获取流量统计值，根据具体场合计算所需的速度。

2，两进程通信为异步交互，存在堵塞导致延迟。
     由于下载与上传涉及逻辑诸多，p1进程需要处理的请求可能很多很多，导致p2获取流量的请求等到一段时间才得以处理返回，出现延迟现象。这样，请求时刻与计算速度的时刻出现较大的时差。
     其实，第二点是由第一点而引起的。
    

# 歇后语

像以上的情况，要想进程间的尽量同步（准确）显示速度，的确是一件考验的事情啊。

如同事振振所说的，”公司单独安排一同事负责这方面工作的研究，设计好速度显示的用户体验，也不为过。”

所以，从良好的用户体验出发，速度计算乃一门艺术活儿。

项目推进总结

项目推进总结

     -- 2012-04项目管理工作总结

作为项目开发人员，版本技术负责人以及项目管理负责人，最近这几天我深深发现当这三者结合在一起，各种忙，”需要Hold住不准凌乱了“。

话句话，你要是没有不错的耐心与应变能力，那过程和结果都一个结局，惨！

当然，而至于开发能力、技术问题解决能力和沟通协调能力以及项目推进能力这些都是必需的，毕竟自己已经历过两年多的工作实战与学习。前面提及的那些能力嘛，虽说也还未那种杠杠的水准啦，但至少已达到可稳步发展的水准了吧。

在此就个人观点而言，想总结几点关于项目管理方面的需注意地方：

1. 若出现项目问题，尽快联系到所有相关人员一起讨论。问题才可能最快变得明朗。

 而具体组织讨论视情况而定，网络交流（如RTX或QQ群）或面对面聚会。记住，讲究效率第一。

2. 只要是讨论，就要有人负责记录过程要点以及结论，很多时候他就是负责人自己。讨论完后最好（必须）以邮件发送大家告知，且可考虑抄送给你的领导。

3. 在讨论过程中，若一时未能确定问题所在或确认具体情况，需指定一位合理人员负责尽快（明确时间点）给予答复。

4. 周期定时地询问工作人员，跟进大家各自负责工作的进度。好处这几点：

 a 清楚各方面的进展情况，利于及时做调整或更新计划。

 b 让大家都有着一定的紧迫感，这是好事，但需要注意询问情况的态度。

 c 甚至利于与大家进一步沟通，增进彼此好感。

……

（未完待续）

好吧，暂且仅简单描述这么多。

明天继续，加油。有时间再续。更多的意义在于，作为笔记给自己总结。

晚安！

我与下载库调度某一段代码的故事

纯属工作杂谈，放放松！

---

我与下载库调度某一段代码的故事

标题很戏剧性，有抢眼之嫌疑，但初衷完全是想让我放放松自己心情，避免边描述边心情太激动了。那开始讲述这么段简单的故事吧。

一年多前，我刚来下载库接触到调度器的其中一段代码，很辛苦啃了一段代码，好“心酸”的感觉啊，啥叫“肉牛满面”哭笑不得就是那种感觉了没错，当时也没敢没好意思抱怨太多……这段代码有将近四百行，各种诡异逻辑都包含在一个函数里头……一年多之后，就最近段时间重新翻查到了这段代码，真是想骂娘了都。

说真的，倘若你没有清醒的头脑和富有耐心，想必你是看不下懂不了其中的逻辑！冰山一角，简单贴一段看看：

简单罗列上面代码包含的糟糕点：

1. 函数参数迭代器传引用。

2. 滥用while循环，根本不需要；while，if，return，break各种乱。

3. 函数内部修改外部的迭代器引用。

4. 定义无必要的的变量new_map_pos增加函数逻辑的复杂性。

……

算了，后面还有三百多行代码，哥不想继续说了，不然伤神的是自己。

其实，这只是冰山一角！My god.

冰山一角

PS.

最后庆幸，我已经针对该函数，整理好了一份文档，准备放到svn上与有需要的同事分享。

同时希望的是，同事可帮忙发现其中包含理解上或表述上存在错误的地方，欢迎指正！

唉，感慨一点，对于程序猿们，需要的是耐心与毅力啊，最重要的了。