Duiker's Blog

7月12日晚上坐火车去大连，火车很不错是直达的，但是空调很冷，LP早上2：30就醒了，我这个人属于没心没肺的，快到6：00才起来。火车站接车的MM长得太一般，讲解的也一般，一个劲的忽悠我们参观一个大连最高的楼，呵呵，她的阴谋没有得逞，来到了星海公园附近的一家饭店，吃了出游的第一顿早餐，很烂。

 

星海广场还是老样子，滨海路还不错，景色很酷，导游又开始推销鳗鱼和珍珠鲍，还是没人响应。到达老虎滩后，一部分人去了极地海洋馆，另一部分去了鸟语林，我属于后一部分，呵呵。鸟语林门票35，很一般，鹦鹉的表演还不错。

 

中午吃饭的时候LP说网上介绍的王子饭店相当好，如果团餐在这吃就爽了，结果团餐真的是在王子饭店，但是，菜是相当的烂，比猪食强不了多少。吃晚饭，导游自然安排购物了，全团加在一起买了不到100块的东西，BS导游。

 

下午去了一趟傅家庄海滩，忽悠LP坐了一次快艇，把她吓了够呛，50块一个人还是感觉有些贵，海边的螃蟹不多，也不会抓，有个小MM抓了几个。

 

晚餐后，导游4点多就把我们扔到了码头，自己回家爽去了，再次BS导游，8：40登上了渤海银珠号，前往烟台，船上还可以，只是东北人多了，自然麻烦不少，好险干一仗。

 

半夜 2：30到达了烟台，由于办了延住，4：30起床上了岸，坐车去威海，在威海码头吃了点早餐，登船去刘公岛，刘公岛真的没什么意思，只是比2002年来的时候要气派了不少，中午吃饭后，导游拉我们去买菜刀，说来好笑，160块一套的菜刀，全团竟然买了4把。

 

然后坐车去蓬莱，看了八仙渡海口，看了蓬莱阁，没什么大意思，累得不得了，晚上结伴找个地方吃了点海鲜，虾爬子还不错，只是花盖蟹很一般，但是的确便宜，虽然这个时候封海，但是在海边吃点海鲜还是不错的。

 

早上起床后做了一上午的车到达曲阜，这一天很不舒服，一个是在蓬莱让蚊子给折磨了，还有就是拉肚，估计是海鲜不是很干净，到了曲阜显示看孔老夫子的墓，然后是他的庙，最好是他的家，这就是三孔。看了之后不服不行，孔子真牛呀，最牛的不是他的学问，而是他的商业才华，整个曲阜我咋就没感觉到一丁点儒家的气氛呢，可能是因为看了那个像皇帝一样的孔子像吧，哎，出名就是好。

 

晚上到达了泰安，无话，早上起来后，上了泰山，爽，尤其是十八盘，登泰山没有感觉到险，只是感觉到过瘾和累，在天街吃了煎饼卷大葱和25块一碗的拉面，真TM黑。

 

下山，导游拉着我们喝茶、买特产和买木鱼石，晚上我们去了银座超市，价格和导游领的地方价格差近一倍，乖乖。

 

回济南，看趵突泉，坐车回长春。

 

20号在南岭看了一场，中国国奥和澳大利亚国奥的足球赛，1：0，赢了骂人也是舒坦，到了现场才感觉最喜欢的竟然是董方卓和周海滨，踢得的确不赖，对得起80块的门票了。

 

OK，到此为止，我的无目的闲游结束了，调整，彻底的调整，从7月12日到20日的修养生息，现在又加满油回来了。

 

写这个随笔的时候，直接把分类勾到了“心情”上，这一周一直处于一个比较焦虑和烦躁的状态中，工作的效率很差，精神头也不是很足，为什么会这样呢？

1. 也许是很久没有回家，想童童了。
2. 也许是纷杂的事务，让我失去了专注的目标。
3. 也许是过大的压力，让我有些茫然。
4. 也许是什么，还说不清楚。
   

是该调整一下了，回家，看老婆孩喽。

PS：

1. 《马云点评创业》已经看了一半。
2. 昨天这边暴雨，9：00左右就睡着了，结果半夜寝室里边闯来一个醉鬼，扰了老子清梦，我还以为是打酱油的，酒真TM的壮熊人胆。
3. 早上公司附件的农行和建行，都是人，看来10块钱的号召力真大，不知道哪个公司能用这个10块钱发奖金。

周末的时候，紧急处理了一件事情，因为一个客户说，听到一些消息，目前有人在卖软件的破解，他问是否可以有办法处理掉，否则很棘手。
我们接到通知后，还在臆测，到底是哪个环节出了问题，我们很迷茫，因为，对方也没有拿到破解，只是听说了，最后的决定是我们去现场，看一下。
到达现场后，通过一些技术手段，查到了用户的使用方式，也知道了对方的破解方法，马上讨论了一个技术方案，从下午4：00接到通知，到晚上8：00封堵上漏洞，我个人感觉效率蛮高，团队的配合也十分默契的。
事情也许到此就结束了，但是这件事情，我在考虑一件事情，就是这么一个简单的破解，就有可能将整个软件毁掉，我之前对软件的盗版和破解，应该是处于一个与我无关，或者隔岸观火的状态，当这件事发生在自己的身边时，才知道这对一个软件公司有多致命。
我之前总是强调软件的品质要好，编写的要帅，用起来要方便，对客户要提供近乎苛求的服务，但是如果一个软件失去了它的公正性，用户可以通过一些小技巧达到欺骗的目的，那么我想，这个软件就完蛋了。
看看现在的游戏公司，估计对作弊和外挂的现象，初期是不会太在意，但是一旦到一定的规模，我想，这个就会爆发，继而产生一个灾难。
开源是一个好事情，但是有些东西真正的公布了，我想，与之对应的“反”作用力也会出现，对待软件到底是“开”还是“闭”，真的要根据软件本身的性质来说，走极端是最没意思的事情。
废话了半天，就是说，评价一个软件的重要指标就是安全性和公正性，一定要重视这点，因为在和朋友聊天的时候，知道了一些很“酷”的事情，做短信的，留个接口可以免费发短信，做机动车违章的，可以让自己的车不缴费，等等。
在调查的过程中，深深的理解，破解一个软件和留后门的最终目的，还是“钱”，这个是驱动破解和盗版的最终目的，无利不起早，另外有些时候也是无奈，因为一个破解的人，后边往往有一个更大的利益集团，这个是不可触碰的。

1. 在重构过程中发现重大错误或改变，要立刻通知其它部门做好协调工作，并做好记录。
2. 在Scrum中的每周例会，要做好任务评估、沟通和目标明确的任务。
3. 在Scrum中的每天晨会主要的任务是沟通、交流，以及评估任务的完成情况。
4. 无论任何会议，都要坚持PDCA的原则，就是计划、执行、检查和调整。
5. 在重构过程中，可以修改规矩，但是不允许破坏规矩。
6. 每天的例会都由当天的主程序员发起。
7. 每天的主程序员都要在下班前领取新的任务。
8. 对任务的评估要集体评估，而不是臆测，或者强制。
9. 任务的评估不要过分保守，也不要过于冒险，有一定挑战性的任务才是做好的任务。
10. 重构的过程是时间驱动的，而不是任务驱动的，随时可以结束。
    

1. 抽取函数的过程中，首先要保证程序能正常运行，这样在修改的过程中，有利于调试。
2. 函数的占位符，建议采用个性的名称。
3. 代码超长，按功能分块提取，在找共同部分进行合并。
4. 重构大型函数，应从最低层开始处理。
5. 重构过程中，要不断的讨论和演进，逐步过度到最佳的解决方案。
6. 重构过程中，要注意心理的调节，快乐良好的心态，才能保证质量和效率。
7. 多用NOT，少用FALSE。
   

1. 代码重构后也不见得是最好的，但却是现阶段最有效的。
2. Coding的时候在IED中要注意使用书签。
3. 结对的过程中，至少每1个小时，要轮换一下。
4. 每有效工作50分钟后，要主动休息和调节10分钟。
5. 代码注释的主要作用是辅助阅读。
6. 定义数组的时候，变量名后边要加s。
7. 在SQL中定义表名，也要复数形式表示。
8. API函数尽量封装后进行复用。
9. 重构中要消灭无用的Public变量和函数。
10. 尽量不要采用类似与Temp等字样的临时变量名。
11. 要注意模块级别变量的作用域，以及复用的冲突问题。
    

1. 必须使用全编译方式进行调试。
2. 编码的时候要多使用快捷键。
3. 编码的过程中多用键盘，少用鼠标。
4. 重构过程中如果提取参数，要第一时间给占位函数赋值。
5. 判断字符串是否为空使用Len函数。
6. 要将编辑器的“工具-选项”中的“自动语法检测”功能取消，选中“变量声明”，网格的宽和高设为24。
7. 函数的调用层次避免超过3个层次。
8. 函数超过20行必须有注释。
9. 要优化比较条件，如短路比较。
10. 所有的变量必须声明类型。
11. 重构不停，一直前进，要着眼于全局。
12. 不要过于追求完美，适合就可以。
13. 修订过程中将关注的焦点放到修订的代码部分，不用过于分散精力。
14. 当完成阶段性工作后，要用工具进行代码的审查。
15. 调试程序中，要去掉所有的错误捕获。
16. 重构依赖于测试，特别是真实环境下的测试。
17. SQL语句要注意执行效率，特别是查询时候的效率。
18. 程序必须有统一的出口和入口。
19. 重构时要不断进行测试。
20. 重构时不要怕犯错误。
21. 重构要保证可以随时停止，随时提交。
    
22. 调试过程中要构建易于测试的环境。
23. 变量的类型如果是数值类型，要注意变量精度和范围，如整型和长整形。
24. 重构函数，要第一时间做好占位函数。
25. IF语句如果只有1句，则不要使用End IF。
26. 耗时的操作，UI上要给出明确的指示。
27. UI设计时，界面上的文字要用“#”进行占位。
28. 注释和代码一样重要。
29. 函数名采用Pascal命名规则，变量采用驼峰规则。
30. 函数参数如果有特殊约定，要在注释中写明。
    

1. 编译参数与命令行参数不可混淆。
2. Connection的游标等设置放在Open之前。
3. 在函数和方法的命名中尽量采用Set和Get等形式。
4. 函数中的语句缩进一个Tab。
5. 所有的工程都要从Main函数开始启动。
6. 多个函数间保持一个空行。
7. 程序重构过程中优先删除废弃代码。
8. 程序重构前要删除无用引用。
9. 文件命名：frm（窗体）、m（模块）、c（类）。
10. 建议采用防御式编程。
11. 建议采用小块的紧凑函数。
12. 全局变量必须加上g前缀。
13. 函数名称要体现函数本身含义。
14. 修订中要避免注释中的错别字。
15. 函数修订过程中要保证注释同步。
16. DAL作为数据访问的抽象层次。
17. DBL作为数据的业务逻辑层次。
18. mTools作为业务的通用工具函数。
19. 尽量采用与SQL语句一致的函数命名规则，如GetStudentInfoByID等。
20. 模块级别的变量，可以采用m或者变量的类型作为前缀。
21. 模块级别的注释放在Option Explicit 之后。
22. 在VSS中使用工程文件的时候，要做到零占用。
23. 重构过程中，避免修改程序逻辑，只允许做小规模的变动，但是对错误要及时修订。
24. 变量和函数的命名尽量不采用缩写词的方式，尽量写全。
25. 调用其它模块内函数的时候，要尽量加入模块的名称。
26. 重构的时候，要从主动的调用函数入手，逐步修改被动的服务函数。
27. SQL语句关键字必须大写。
28. 在SQL查询中要注意末尾为空格的干扰查询情况。
29. 在数据库操作中，要注意返回值为空值的情况。
    

Nokia的Scrum标准：

1. 迭代要有固定的时长（TimeBox），不能超过六个星期。
2. 每一次迭代的结尾，代码必须经过QA的测试。
3. Scrum团队必须有产品负责人，而且团队都清楚这个人是谁。
4. 产品负责人必须有产品的Backlog，其中包括团队对它进行的估算。
5. 团队必须有一个燃尽图，而且要了解他们自己的生产效率。
6. 在一个Sprint中，外人不能干涉团队的工作。

Backlog是Scrum的核心，从根本上说，他就是一个需求、或故事，或特性组成的列表，并且按照重要性进行了排序，一定是客户想要的东西，并且用客户的语音进行描述，没一个条目是一个故事（Story），建议每个故事包含这些字段：

1. ID（统一标示）
2. Name（名称）
3. Imp（重要程度）
4. Est（初始估算）
5. How to demo（如何做演示）
6. Notes（其它）

每一个故事有3+1个变量（范围、重要性、估算）+质量，无论如何不能在质量上让步。

质量分为内部质量和外部质量：

1. 外部质量是用户可以感知的，如运行缓慢，让人迷糊的界面等。
2. 内部质量一般指用户看不见的原素，它对系统的可维护性有深远的影响，如系统设计的一致性、测试覆盖率、代码可读性等。

记住，在松散的沙滩上永远不能建立起精美的楼阁，经验证明牺牲内部质量是一个糟糕透顶的想法，现在省下来的一点时间，接下来的日子，你就要一直为它付出代价。

在Scrum中一切事情都是有时间盒的，到时必须交货。

“这个Sprint让大家不太好过，但是我们应该看到它的正面影响，整个团队从中获益匪浅，下个迭代会议会更有效率。”

学会按照时间盒安排工作，学会制定各种合乎情理的时间盒，这对sprint会议的长度同样有效。

典型的Sprint时间表，每一个小时休息10分钟：

1. 30分钟的总体介绍，概括产品的Backlog。
2. 20分钟的时间估算。
3. 1个小时的Story选择，计算生产率。
4. 1个小时的站立会议安排和将故事拆分为任务。

比较理想的一个Sprint长度为3个星期，（目前公司每日的Build版本，发布到测试部进行测试，应该是一个自动化测试的过程，而人工测试的应该是每个月发布的正常版本）

半死不活的目标比什么都没有强。

在Sprint中包含多少个故事由团队决定，而不是产品的负责人或其它人，但是产品负责人要对sprint中放入哪些Story产生影响。

自动生成故事卡的脚本下载地址：http://blog.crisp.se/henrikkniberg/2007/12/18/1197973740000.html

计划指派的点数：0、1/2、1、2、3、5、8、13、20、40、100、？、Coffee。

从昨天晚上的8：30一直到现在，一直都处于疲惫和紧张的状态，嗓子还在发炎，难受中。
做软件最难熬的莫过于在临门一脚上出现问题，但是，这次我遇到了。
很佩服竞争对手的韧劲，知道成功的希望很渺茫，但是一直在坚持，如果这次他们可以翻盘，我真的愿意为他们鼓掌。
总结起来有几点：

1. 飞机永远是不靠谱的，重要的事情宁可早一点走，也别指望飞机，谁知道北京会不会打雷。
2. 团队间传递信息的时候，一定要保证明确事情的严重性，切勿含糊，不明确的需求只会误导。
3. 加强团队间的沟通，特别是异地团队间的相互了解，这个是最最重要的。
4. 特事特办，关键时刻切勿循规蹈矩，一定要选择最佳方案，小团队最大的优势就是敏捷，切勿陷入规矩的泥沼中。
5. 团队的成长，建立在每一个人的责任心基础之上，共同的事业需要每一个人的全身心投入。
6. 特殊情况，切勿忘记“探索、提议、行动、确认”，这是选择最佳路线的指针，无论如何忙乱，也一定要抓住本质，给出合理方案。
7. 要充分相信团队，使其专注的解决问题，过度的干预，会严重影响团队的工作效率和信心。
8. 一定要总结和反馈，不要让错误再现。
9. 丢一个单子无所谓，但是由此造成的对团队系统的不认可，而造成对团队失去信心，是最最痛心的，无论如何不能丢掉一个人。
10. 在每个阶段都会遇到不同的问题，只是有初级向高级发展。
11. 没有没有问题的团队，我们需要持续的改进，让我们做的更好。