`
文章列表
抽取函数的过程中,首先要保证程序能正常运行,这样在修改的过程中,有利于调试。 函数的占位符,建议采用个性的名称。 代码超长,按功能分块提取,在找共同部分进行合并。 重构大型函数,应从最低层开始处理。 重构过程中,要不断的讨论和演进,逐步过度到最佳的解决方案。 重构过程中,要注意心理的调节,快乐良好的心态,才能保证质量和效率。 多用NOT,少用FALSE。
代码重构后也不见得是最好的,但却是现阶段最有效的。 Coding的时候在IED中要注意使用书签。 结对的过程中,至少每1个小时,要轮换一下。 每有效工作50分钟后,要主动休息和调节10分钟。 代码注释的主要作用是辅助阅读。 定义数组的时候,变量名后边要加s。 在SQL中定义表名,也要复数形式表示。 API函数尽量封装后进行复用。 重构中要消灭无用的Public变量和函数。 尽量不要采用类似与Temp等字样的临时变量名。 要注意模块级别变量的作用域,以及复用的冲突问题。
必须使用全编译方式进行调试。 编码的时候要多使用快捷键。 编码的过程中多用键盘,少用鼠标。 重构过程中如果提取参数,要第一时间给占位函数赋值。 判断字符串是否为空使用Len函数。 要将编辑器的“工具-选项”中的“自动语法检测”功能取消,选中“变量声明”,网格的宽和高设为24。 函数的调用层次避免超过3个层次。 函数超过20行必须有注释。 要优化比较条件,如短路比较。 所有的变量必须声明类型。 重构不停,一直前进,要着眼于全局。 不要过于追求完美,适合就可以。 修订过程中将关注的焦点放到修订的 ...
编译参数与命令行参数不可混淆。 Connection的游标等设置放在Open之前。 在函数和方法的命名中尽量采用Set和Get等形式。 函数中的语句缩进一个Tab。 所有的工程都要从Main函数开始启动。 多个函数间保持一个空行。 程序重构过程中优先删除废弃代码。 程序重构前要删除无用引用。 文件命名:frm(窗体)、m(模块)、c(类)。 建议采用防御式编程。 建议采用小块的紧凑函数。 全局变量必须加上g前缀。 函数名称要体现函数本身含义。 修订中要避免注释中的错别字。 函 ...
Nokia的Scrum标准: 迭代要有固定的时长(TimeBox),不能超过六个星期。 每一次迭代的结尾,代码必须经过QA的测试。 Scrum团队必须有产品负责人,而且团队都清楚这个人是谁。 产品负责人必须有产品的Backlog,其中包括团队对它进行的估算。 团队必须有一个燃尽图,而且要了解他们自己的生产效率。 在一个Sprint中,外人不能干涉团队的工作。 Backlog是Scrum的核心,从根本上说,他就是一个需求、或故事,或特性组成的列表,并且按照重要性进行了排序,一定是客户想要的东西,并且用客户的语音进行描述,没一个条目是一个故事(St ...
从昨天晚上的8:30一直到现在,一直都处于疲惫和紧张的状态,嗓子还在发炎,难受中。 做软件最难熬的莫过于在临门一脚上出现问题,但是,这次我遇到了。 很佩服竞争对手的韧劲,知道成功的希望很渺茫,但是一直在坚持,如果这次他们可以翻盘,我真的愿意为他们鼓掌。 总结起来有几点: 飞机永远是不靠谱的,重要的事情宁可早一点走,也别指望飞机,谁知道北京会不会打雷。 团队间传递信息的时候,一定要保证明确事情的严重性,切勿含糊,不明确的需求只会误导。 加强团队间的沟通,特别是异地团队间的相互了解,这个是最最重要的。 特事特办,关键时刻切勿循规蹈矩,一定要选择最佳方案,小团队最大的 ...
敏捷中国这个会议是一个比较不错的技术会议,简单记录一下: 腾讯 林松 互联网产品研发的敏捷经验分享 腾讯在敏捷上的思路是:在产品上是FDD(功能驱动开发),过程采用SCRUM,实践采用XP。 在TimeBox并没有统一的要求,主要根据产品的特点进行设计,其中比较有意思的是产品安排在周四进行发布,以避免由于周五发布造成的加班现象。 在产品的回顾阶段,通过对改进建议设置改进人的方式,避免回顾流于形式。 在站立会议方面,通过更换主持人的方式,增加趣味性,避免过于枯燥。 产品发布采用了灰度发布,降低发布的风险。 利用“与客户订婚”、“跟客户回家”的概 ...
最近几天接连发生了几件不靠谱的事情,记录一下: 1:爱枣报目前是看不了了,要么搬家,要么关门,要么听话。 2:饭否绑定的QQ,也不能用了,估计是腾讯发神经了。 3:Firefox升级到3.0之后,好多插件都不能用。 4:利用一个网络项目申报平台进行项目的申报,在生成PDF文件的时候,系统会像孙悟空的72变一样,一会这样,一会那样,让人摸不到头脑。 总结,这个年头互联网是不靠谱的,要想靠谱就得听老大的,否则全都给你干掉,千万别相信什么免费服务,还是原始社会好。
这几天太忙,今天才把参加Google Developer Day 2008的感受补上,简单记录一下吧。 从长春去北京购买的是Z62直达的火车,由于火车票比较紧张,购买的是一张软卧,舒服是很舒服,但是价格贵了一些,车厢里边有一个老外,说话的声音很低,很恐怖。 到北京的时间是早上6点多,直接做地铁,找到了北京国际会议中心,很好找,也很方便,路中看到了鸟巢体育馆。 由于去的比较早,所以还没有开始注册,但是可以看出,Google的会议安排已经有点混乱的前兆了,一个Google的领导,在不断的教注册的小孩,应该做什么。 8:00左右开始了注册,注册系统可以看出也是Google自己弄的,风格很Goo ...
吉林如一舫 长春大唐时代 如一舫最好的应该是他的汤,而大唐时代最有意思的应该是看现场制作日本料理,很精致。
今天早上收到一封商务函,是一家叫做“美国阿波罗控股集团公司北京代表处”发来的信件,说是对公司的某个项目感兴趣,希望合作云云。 在网上查了一下,国外是找不到这家公司,但是在国内,的确招摇撞骗了很多政府和企业机构,最后通过这些信息可以确认这家公司是个地地道道的骗钱公司: http://hi.baidu.com/13273805050/blog/item/26128d7ead2e7d3d0cd7dad1.html http://www.cyzone.cn/Blog/plan2009/15054.aspx 因此大家要小心了,以免被这家公司骗到。
这段时间的主要任务是整理代码,有点类似代码考古学,呵呵,所以,看的书与重构和设计模式关系很大了,由于在修订过程中心态是很重要的,所以抽空再看《悟空传》了,否则很难达到一种心态的平衡。 修订的过程还是比较小心的,底线是必须保证能够通过测试,无论是自我审核,还是自动测试,还是人工测试,程序必须保证与原有的逻辑一致。 另外必要的辅助工具必须有,例如一些代码审查和纠错的工具。 修订的步骤基本上小块整理,保证每修订一个模块后,这个模块是稳定的,然后逐步将不同模块间通用的部分,进行提取和归纳,逐步形成统一的底部层次和框架。 由于代码反复修订的时间比较长了,里边的重复代码和垃圾也是很多的,而且根据需求 ...
技术类:《Head First 设计模式》、《移山之道》、《超越对手——软件项目经理的18种实用技能》 管理类:《他们是如何倒下的》、《货币战争》、《微软360度》、《李嘉诚中国式管理》、《亲历微软》 小说类:《士兵突击》、《金婚》、《闯关东》、《悟空传》
今天是我和LP的结婚纪念日,2004、2005、2006、2007、2008,一起走过,现在还有了可爱的童童,只是这些天更多的是心痛和难过。 汶川那个地方大概在2006年的时候和LP去四川旅游的时候路过过,吃过2餐饭,住过一夜,仅此而已,记得那个地方景色很美,但是道路十分惊险,公路一侧是山体,一侧是岷江,我们一路只能惊叹于司机的高超驾驶技术,整个路途都十分的担心。 现在真的不知道说什么,只能默默祈祷。
抓虾是我最常用的一个网络应用,很喜欢,很强大。无论任何应用当然都会有“墙”的存在,当然,有些是外部的,有些是内部的,但是终究会有。 我曾经订阅过“新雨丝”的RSS,现在无论在WEB页面上如何处理,在抓虾上都是看不到的,但是通过手机浏览,就会畅通无阻,所以我想,抓虾的部分应用并不是走的同一入口,所以会出现这问题。 另外在手机中使用抓虾还会出现2个小问题: 1.一个是使用“小虾书签”不会直接跳转到“最近更新”中,必须刷新一下页面才会跳转。 2.另外就是手机中看过的文章,标记为“已读‘后,过一段时间在浏览WEB页面,该文章仍然表为未读。 所以我想手机应用与WEB应用上,目前抓虾采用的开发框架上 ...
Global site tag (gtag.js) - Google Analytics