博客园-Duiker's Bloghttp://www.cnblogs.com/Duiker/zh-cnSun, 06 Jul 2008 11:25:27 GMTSun, 06 Jul 2008 11:25:27 GMT60Code SOP - 4http://www.cnblogs.com/Duiker/archive/2008/07/03/1234917.htmlDuikerDuikerThu, 03 Jul 2008 08:55:00 GMThttp://www.cnblogs.com/Duiker/archive/2008/07/03/1234917.htmlhttp://www.cnblogs.com/Duiker/comments/1234917.htmlhttp://www.cnblogs.com/Duiker/archive/2008/07/03/1234917.html#Feedback0http://www.cnblogs.com/Duiker/comments/commentRss/1234917.htmlhttp://www.cnblogs.com/Duiker/services/trackbacks/1234917.html
  • 抽取函数的过程中，首先要保证程序能正常运行，这样在修改的过程中，有利于调试。
  • 函数的占位符，建议采用个性的名称。
  • 代码超长，按功能分块提取，在找共同部分进行合并。
  • 重构大型函数，应从最低层开始处理。
  • 重构过程中，要不断的讨论和演进，逐步过度到最佳的解决方案。
  • 重构过程中，要注意心理的调节，快乐良好的心态，才能保证质量和效率。
  • 多用NOT，少用FALSE。



    • [新闻]微软高管：Wii用户最终会成为Xbox 360用户]]>    Code SOP - 3http://www.cnblogs.com/Duiker/archive/2008/07/02/1234104.htmlDuikerDuikerWed, 02 Jul 2008 08:26:00 GMThttp://www.cnblogs.com/Duiker/archive/2008/07/02/1234104.htmlhttp://www.cnblogs.com/Duiker/comments/1234104.htmlhttp://www.cnblogs.com/Duiker/archive/2008/07/02/1234104.html#Feedback0http://www.cnblogs.com/Duiker/comments/commentRss/1234104.htmlhttp://www.cnblogs.com/Duiker/services/trackbacks/1234104.html
  • 代码重构后也不见得是最好的，但却是现阶段最有效的。
  • Coding的时候在IED中要注意使用书签。
  • 结对的过程中，至少每1个小时，要轮换一下。
  • 每有效工作50分钟后，要主动休息和调节10分钟。
  • 代码注释的主要作用是辅助阅读。
  • 定义数组的时候，变量名后边要加s。
  • 在SQL中定义表名，也要复数形式表示。
  • API函数尽量封装后进行复用。
  • 重构中要消灭无用的Public变量和函数。
  • 尽量不要采用类似与Temp等字样的临时变量名。
  • 要注意模块级别变量的作用域，以及复用的冲突问题。



    • [新闻]遵守YouTube案裁定 谷歌将陷入隐私指控深渊]]>    Code SOP - 2http://www.cnblogs.com/Duiker/archive/2008/07/01/1233338.htmlDuikerDuikerTue, 01 Jul 2008 08:41:00 GMThttp://www.cnblogs.com/Duiker/archive/2008/07/01/1233338.htmlhttp://www.cnblogs.com/Duiker/comments/1233338.htmlhttp://www.cnblogs.com/Duiker/archive/2008/07/01/1233338.html#Feedback0http://www.cnblogs.com/Duiker/comments/commentRss/1233338.htmlhttp://www.cnblogs.com/Duiker/services/trackbacks/1233338.html
  • 必须使用全编译方式进行调试。
  • 编码的时候要多使用快捷键。
  • 编码的过程中多用键盘，少用鼠标。
  • 重构过程中如果提取参数，要第一时间给占位函数赋值。
  • 判断字符串是否为空使用Len函数。
  • 要将编辑器的“工具-选项”中的“自动语法检测”功能取消，选中“变量声明”，网格的宽和高设为24。
  • 函数的调用层次避免超过3个层次。
  • 函数超过20行必须有注释。
  • 要优化比较条件，如短路比较。
  • 所有的变量必须声明类型。
  • 重构不停，一直前进，要着眼于全局。
  • 不要过于追求完美，适合就可以。
  • 修订过程中将关注的焦点放到修订的代码部分，不用过于分散精力。
  • 当完成阶段性工作后，要用工具进行代码的审查。
  • 调试程序中，要去掉所有的错误捕获。
  • 重构依赖于测试，特别是真实环境下的测试。
  • SQL语句要注意执行效率，特别是查询时候的效率。
  • 程序必须有统一的出口和入口。
  • 重构时要不断进行测试。
  • 重构时不要怕犯错误。
  • 重构要保证可以随时停止，随时提交。
  • 调试过程中要构建易于测试的环境。
  • 变量的类型如果是数值类型，要注意变量精度和范围，如整型和长整形。
  • 重构函数，要第一时间做好占位函数。
  • IF语句如果只有1句，则不要使用End IF。
  • 耗时的操作，UI上要给出明确的指示。
  • UI设计时，界面上的文字要用“#”进行占位。
  • 注释和代码一样重要。
  • 函数名采用Pascal命名规则，变量采用驼峰规则。
  • 函数参数如果有特殊约定，要在注释中写明。


    • [新闻]iPhone入华在即 中国手机产业生存面临考验]]>    Code SOP - 1http://www.cnblogs.com/Duiker/archive/2008/06/30/1232538.htmlDuikerDuikerMon, 30 Jun 2008 08:25:00 GMThttp://www.cnblogs.com/Duiker/archive/2008/06/30/1232538.htmlhttp://www.cnblogs.com/Duiker/comments/1232538.htmlhttp://www.cnblogs.com/Duiker/archive/2008/06/30/1232538.html#Feedback0http://www.cnblogs.com/Duiker/comments/commentRss/1232538.htmlhttp://www.cnblogs.com/Duiker/services/trackbacks/1232538.html
  • 编译参数与命令行参数不可混淆。
  • Connection的游标等设置放在Open之前。
  • 在函数和方法的命名中尽量采用Set和Get等形式。
  • 函数中的语句缩进一个Tab。
  • 所有的工程都要从Main函数开始启动。
  • 多个函数间保持一个空行。
  • 程序重构过程中优先删除废弃代码。
  • 程序重构前要删除无用引用。
  • 文件命名：frm（窗体）、m（模块）、c（类）。
  • 建议采用防御式编程。
  • 建议采用小块的紧凑函数。
  • 全局变量必须加上g前缀。
  • 函数名称要体现函数本身含义。
  • 修订中要避免注释中的错别字。
  • 函数修订过程中要保证注释同步。
  • DAL作为数据访问的抽象层次。
  • DBL作为数据的业务逻辑层次。
  • mTools作为业务的通用工具函数。
  • 尽量采用与SQL语句一致的函数命名规则，如GetStudentInfoByID等。
  • 模块级别的变量，可以采用m或者变量的类型作为前缀。
  • 模块级别的注释放在Option Explicit 之后。
  • 在VSS中使用工程文件的时候，要做到零占用。
  • 重构过程中，避免修改程序逻辑，只允许做小规模的变动，但是对错误要及时修订。
  • 变量和函数的命名尽量不采用缩写词的方式，尽量写全。
  • 调用其它模块内函数的时候，要尽量加入模块的名称。
  • 重构的时候，要从主动的调用函数入手，逐步修改被动的服务函数。
  • SQL语句关键字必须大写。
  • 在SQL查询中要注意末尾为空格的干扰查询情况。
  • 在数据库操作中，要注意返回值为空值的情况。


    • [新闻]阿里巴巴集团再向淘宝注资20亿元]]>    《硝烟中的Scrum和XP》书摘（1）http://www.cnblogs.com/Duiker/archive/2008/06/28/1231609.htmlDuikerDuikerSat, 28 Jun 2008 06:16:00 GMThttp://www.cnblogs.com/Duiker/archive/2008/06/28/1231609.htmlhttp://www.cnblogs.com/Duiker/comments/1231609.htmlhttp://www.cnblogs.com/Duiker/archive/2008/06/28/1231609.html#Feedback0http://www.cnblogs.com/Duiker/comments/commentRss/1231609.htmlhttp://www.cnblogs.com/Duiker/services/trackbacks/1231609.html
    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。



    [新闻]56被关一月 危机的是整个视频业]]>    丢一个单子可以，但是不能丢掉一个人http://www.cnblogs.com/Duiker/archive/2008/06/28/1231436.htmlDuikerDuikerFri, 27 Jun 2008 23:53:00 GMThttp://www.cnblogs.com/Duiker/archive/2008/06/28/1231436.htmlhttp://www.cnblogs.com/Duiker/comments/1231436.htmlhttp://www.cnblogs.com/Duiker/archive/2008/06/28/1231436.html#Feedback1http://www.cnblogs.com/Duiker/comments/commentRss/1231436.htmlhttp://www.cnblogs.com/Duiker/services/trackbacks/1231436.html 做软件最难熬的莫过于在临门一脚上出现问题，但是，这次我遇到了。
    很佩服竞争对手的韧劲，知道成功的希望很渺茫，但是一直在坚持，如果这次他们可以翻盘，我真的愿意为他们鼓掌。
    总结起来有几点：
    1. 飞机永远是不靠谱的，重要的事情宁可早一点走，也别指望飞机，谁知道北京会不会打雷。
    2. 团队间传递信息的时候，一定要保证明确事情的严重性，切勿含糊，不明确的需求只会误导。
    3. 加强团队间的沟通，特别是异地团队间的相互了解，这个是最最重要的。
    4. 特事特办，关键时刻切勿循规蹈矩，一定要选择最佳方案，小团队最大的优势就是敏捷，切勿陷入规矩的泥沼中。
    5. 团队的成长，建立在每一个人的责任心基础之上，共同的事业需要每一个人的全身心投入。
    6. 特殊情况，切勿忘记“探索、提议、行动、确认”，这是选择最佳路线的指针，无论如何忙乱，也一定要抓住本质，给出合理方案。
    7. 要充分相信团队，使其专注的解决问题，过度的干预，会严重影响团队的工作效率和信心。
    8. 一定要总结和反馈，不要让错误再现。
    9. 丢一个单子无所谓，但是由此造成的对团队系统的不认可，而造成对团队失去信心，是最最痛心的，无论如何不能丢掉一个人。
    10. 在每个阶段都会遇到不同的问题，只是有初级向高级发展。
    11. 没有没有问题的团队，我们需要持续的改进，让我们做的更好。



    [新闻]56被关一月 危机的是整个视频业]]>    7年http://www.cnblogs.com/Duiker/archive/2008/06/26/1230147.htmlDuikerDuikerThu, 26 Jun 2008 01:18:00 GMThttp://www.cnblogs.com/Duiker/archive/2008/06/26/1230147.htmlhttp://www.cnblogs.com/Duiker/comments/1230147.htmlhttp://www.cnblogs.com/Duiker/archive/2008/06/26/1230147.html#Feedback0http://www.cnblogs.com/Duiker/comments/commentRss/1230147.htmlhttp://www.cnblogs.com/Duiker/services/trackbacks/1230147.html
    很多人都说，IT企业能过3年就是个奇迹，现在已经7年了，其中的甘苦，只有经历过才会体会。

    现在的竞争对手，越来越重视我们，留言、诋毁、倾销和恶意竞争，也一样一样的出现了，战斗才刚刚开始。

    不知道为什么，很喜欢“血”，有点血腥味道，战斗才有意思，才能更有斗志。

    在路上，7年，我才刚刚开始。



    [新闻]李开复：中文搜索是谷歌战略核心]]>    AgileChina参会笔记http://www.cnblogs.com/Duiker/archive/2008/06/23/1228072.htmlDuikerDuikerMon, 23 Jun 2008 04:56:00 GMThttp://www.cnblogs.com/Duiker/archive/2008/06/23/1228072.htmlhttp://www.cnblogs.com/Duiker/comments/1228072.htmlhttp://www.cnblogs.com/Duiker/archive/2008/06/23/1228072.html#Feedback0http://www.cnblogs.com/Duiker/comments/commentRss/1228072.htmlhttp://www.cnblogs.com/Duiker/services/trackbacks/1228072.html
    腾讯 林松 互联网产品研发的敏捷经验分享
    1. 腾讯在敏捷上的思路是：在产品上是FDD（功能驱动开发），过程采用SCRUM，实践采用XP。
    2. 在TimeBox并没有统一的要求，主要根据产品的特点进行设计，其中比较有意思的是产品安排在周四进行发布，以避免由于周五发布造成的加班现象。
    3. 在产品的回顾阶段，通过对改进建议设置改进人的方式，避免回顾流于形式。
    4. 在站立会议方面，通过更换主持人的方式，增加趣味性，避免过于枯燥。
    5. 产品发布采用了灰度发布，降低发布的风险。
    6. 利用“与客户订婚”、“跟客户回家”的概念、眼球观测仪器等设备，准确把握需求。
    7. 利用Sale的方式，进行敏捷的推广。
    8. 利用团队比较，加大团队的热情，利用类似股票的实时面板，提高团队间的竞争。
    9. 对敏捷的改善过程是：认知、认可、实践、优化和成熟。
    10. 对敏捷的能力，也提出了A1、A2、A3等模型。
    11. 有意思的是提出了厕所文化的事情，就是Google在厕所中进行文化和技术的传播。
    ThoughtWorks 路宁 敏捷工厂之旅
    1. 清洁明亮的工厂，像医院一样
    2. 5S：Sort（有序）、Stabklize（整理）、Shine（清洁）、Standardize（标准）、Sustain（保持）
    3. 开发的环境要考虑：桌面、照明、布线、服务器、代码结构、软件配置、电脑系统
    4. 方方面面的可视化、地面上的标记、可视化控制、现场管理、强调自我管理，现场、现实、现物处理问题
    5. 迅速流动和停止流动
    6. 看板和拉动生产，Code on failed Test
    7. 交付能力，准时生产和零库存，准时生产=多交付，零库存=交付即可运行，库存量=剩余工作量
    8. 自主的工作单元，加工之后立即检测的U型工作单元=Unit
    9. 单件流，被授权的全功能小团队
    10. 全功能小团队、迭代开发、难以可视化的工作流程通过结对解决，而且要通过到处结对来解决问题，达到平衡
    11. 流动、消除浪费、到处流动
    12. 在开发活动中保证质量，全员参与的全程质量体系
    13. Andon灯=持续集成，失败立即修正
    14. 改进活动，发现和消除浪费，持续改进
    ThoughWorks QiHuiQin 德明如是说：Build Quality In
    1. 全程的质量参与
    2. 尽早进入测试
    3. 测试是全面的包括需求、设计、功能等多个方面
    4. 通过结对，达到能力的均衡
    总结：
    1. 敏捷需要尝试，需要不断的改进
    2. 全程的质量控制是质量提升的根本
    3. 利用Lean避免浪费
    4. 敏捷要根据实际情况进行应用，不可千篇一律
    5. ThoughWorks公司是一家咨询公司，因此过度的开放环境是OK的，而所有的公司都是这种开放的方式就死翘翘了
    6. 了解和学习别人的经验是我们进步的捷径
    7. 对于我而言，要持续关注XP、Scrum、Lean和GTD



    [新闻]《星际争霸2》新图：黑暗圣堂武士Zeratul]]>    不靠谱的事http://www.cnblogs.com/Duiker/archive/2008/06/19/1225111.htmlDuikerDuikerThu, 19 Jun 2008 00:16:00 GMThttp://www.cnblogs.com/Duiker/archive/2008/06/19/1225111.htmlhttp://www.cnblogs.com/Duiker/comments/1225111.htmlhttp://www.cnblogs.com/Duiker/archive/2008/06/19/1225111.html#Feedback5http://www.cnblogs.com/Duiker/comments/commentRss/1225111.htmlhttp://www.cnblogs.com/Duiker/services/trackbacks/1225111.html
    1：爱枣报目前是看不了了，要么搬家，要么关门，要么听话。

    2：饭否绑定的QQ，也不能用了，估计是腾讯发神经了。

    3：Firefox升级到3.0之后，好多插件都不能用。

    4：利用一个网络项目申报平台进行项目的申报，在生成PDF文件的时候，系统会像孙悟空的72变一样，一会这样，一会那样，让人摸不到头脑。

    总结，这个年头互联网是不靠谱的，要想靠谱就得听老大的，否则全都给你干掉，千万别相信什么免费服务，还是原始社会好。



    [新闻]FriendFeed介绍]]>    Google Developer Day 2008http://www.cnblogs.com/Duiker/archive/2008/06/17/1224122.htmlDuikerDuikerTue, 17 Jun 2008 08:45:00 GMThttp://www.cnblogs.com/Duiker/archive/2008/06/17/1224122.htmlhttp://www.cnblogs.com/Duiker/comments/1224122.htmlhttp://www.cnblogs.com/Duiker/archive/2008/06/17/1224122.html#Feedback2http://www.cnblogs.com/Duiker/comments/commentRss/1224122.htmlhttp://www.cnblogs.com/Duiker/services/trackbacks/1224122.html
    从长春去北京购买的是Z62直达的火车，由于火车票比较紧张，购买的是一张软卧，舒服是很舒服，但是价格贵了一些，车厢里边有一个老外，说话的声音很低，很恐怖。

    到北京的时间是早上6点多，直接做地铁，找到了北京国际会议中心，很好找，也很方便，路中看到了鸟巢体育馆。

    由于去的比较早，所以还没有开始注册，但是可以看出，Google的会议安排已经有点混乱的前兆了，一个Google的领导，在不断的教注册的小孩，应该做什么。

    8：00左右开始了注册，注册系统可以看出也是Google自己弄的，风格很Google，输入你的名字，底下会显示出来匹配信息，点“注册”后，就OK了，领了一个胸卡和一个文件袋，里边简单的放了一些资料，资料做的也很仓促，有不少错别字，字体的大小也是不一致。

    注册后，可以在楼道边上领取免费的食物，主要是饮料和一些小零食，很丰富。可能是由于2楼来注册的人越来越多，所以工作人员开始引导我们去3楼休息，这是一个很坏的注意，因为二楼主会场开始入场后也没有人通知在三楼的人，所以很多早到的人，反而没有得到比较号的会场位置。

    开幕式很简单，主要是李开复讲了几分钟，其中一句话我觉得很不错就是“平台的战争已经结束，互联网赢了。”，然后就不再可以见到他了，然后是一个Google的第一位女性工程师进行演讲，将这次会议所涉及的内容进行了一个总的概述，期间穿插了几个小的Demo，整体效果还不错。

    主会议结束后，开始分会场的会议，我参加的第一个是“地图API/迷你地图的应用”，讲师很负责，讲的很认真，但是内容过于浅显，大部分的时间都是在照着PPT来念，也许讲师平时的研发工作太忙，讲座的备课不够吧，听了一半，我就撤退了。

    第2场，听了一半的“机器学习”，听了一半的“谷歌网页工具包”，总的来说，讲的一般，第2个的讲师，一个劲的擦汗，紧张的不得了。

    中午简单吃了点饭，很简单，一个饭，一个果汁，两素两荤。

    根据上午的会议经验，我决定不乱跑了，直接在“云计算实现平台”这个主题里一直坚持到底，下午的会要比上午好的多，我分别听了“Google Gears 新功能介绍”、“Google  App Engine”，“使用Google  AJAX API 开发小工具及用户界面的高级技巧”和“Google与Open Source”。

    这4个Session里边，有3个是英文的课，硬着头皮听下来，意思大概能理解，最后一个Session是王永刚来讲的，就是《道法自然》的作者，口才一流，是难得的内外兼修的开发人员。

    交了反馈表之后，领了一件衣服，Lp说像老头衫。

    最后的晚餐，相当的好，吃的饱饱的做T59回家了。

    上边都是流水帐，下边聊聊感受。

    1、这次是Google第一次组织大型的开发者会议，第一届只有几百人，这次突然有2200人参加，因此组织的不到位也在所难免。
    2、这次会议的目的，的确有待商榷，整个会议的推广成分远大于技术经验的分享，似乎是面向开发者的一个技术方面的推介会，因此技术的深度很浅。
    3、参会的人员有太多的学生，好处是英语都不错，坏处是无形中降低了会议的技术质量。

    参加完这个会议后，有很多的技术方面的疑问在困惑着我，Google目前这种开放是开发，究竟会带来什么样的变革，我们如何面对？我先列一下我们可以用到的东西：

    Google AJAX APIs、Gadgets、Google Gears、Google Web Toolkit、Google App Engine、Google Data APIs、
    YouTuBe API、OpenSocial、Android、Maps API、KML等等。

    这些东西的存在，我反复看到了一个FrameWork，开发人与利用这些API，可以快速的构建新的应用，而且Google还通过Google APP Engine给你提供应用的使用容器等等，真的好像一个互联网上边的微软，但是和微软面向于操作系统的API又有很大的不同：

    1、这些API很大部分都是面向一些互联网上的具体应用。
    2、这些API都是免费的，但是到一定的限制条件会触发收费。
    3、这些API都是没有保障的。

    “云计算”这个目前火热的不得了的概念，让我感觉Google将领用目前的技术和资金的优势，将网络上各种应用绑定到Google上，使Google成为一个开发的平台，一个服务的托管商，一个广告公司，一个无线电信运营商。

    总之，“云计算”的结果是互联网上几家独大的垄断机构将出现，因此这种开放的姿态无论是竞争对手的F8挤兑的，还是本身的战略步骤，都是值得大家关注的，需要注意的是“开放绝对不等于开源”。

    相关图片：http://www.douban.com/photos/album/10429446/
    参考文章：http://www.cnblogs.com/zhubo/archive/2008/06/13/google_developer_day_2008.html


    [新闻]微软在台北发布新色鼠标产品]]>