前言 由于最近工作重心的转移,原来和几个同事一起开发的项目也已经上线了,而新项目就是在现有的项目基础上进行优化延伸扩展.打个比方,现在已经上线的项目行政案件的Web管理网站(代码还没那么多相比较即将要做的刑事案件吧),而新项目是刑事案件的Web管理网站,之后行政和刑事这两个网站是要合并的.前段时间也和同事以及上司的讨论结果就是新建一套项目,考虑将原有系统各种组件进行重新封装.优化.提升扩展,然后先开发刑事案件的网站,待刑事案件开发完毕将原有项目按照刑事案件的思路重新整合. 最近刚开始进行查看老代…

2014-05-16 09:08 by Jeff Li 前言 系列文章:[传送门] 下个星期度过这几天的奋战,会抓紧java的进阶学习.听过一句话,大哥说过,你一个月前的代码去看下,慘不忍睹是吧.确实,人和代码一样都在成长,都在变好其中.有时候仅仅是实现功能的编程,长进不了呀. 博客提供的优点就能够交流,讨论的学习方法你们应该知道. 在这里,我会陆陆续续的进行对<编写高质量代码改善java程序的151个建议>看法,希望大家点击交流. 正文 看这本书原因   1.项目做的仅仅是实现功能,然而没有…

原文:编写高质量代码改善C#程序的157个建议[1-3] 前言 本文主要来学习记录前三个建议. 建议1.正确操作字符串 建议2.使用默认转型方法 建议3.区别对待强制转换与as和is 其中有很多需要理解的东西,有些地方可能理解的不太到位,还望指正. 建议1.正确操作字符串 字符串应该是所有编程语言中使用最频繁的一种基础数据类型.如果使用不慎,我们就会为一次字符串的操作所带来的额外性能开销而付出代价.本条建议将从两个方面来探讨如何规避这类性能开销: 1.确保尽量少的装箱 2.避免分配额外的内存空间…

最近读了陆敏技写的一本书<<编写高质量代码  改善C#程序的157个建议>>书写的很好.我还看了他的博客http://www.cnblogs.com/luminji . 前面部分选择什么,该怎么用我没有怎么消化.看了他写的一篇关于自动化测试的工具,能够录下人的操作,然后可以在多台机器上调用,因为是windows开发的,我没有亲手实验,先记录在这里,以后要用可以找,"Code UI Automation" 文中大量都是通过对比IL代码,来区分哪个方案更好.我在看&…

建议157:从写第一个界面开始,就进行自动化测试 如果说单元测试是白盒测试,那么自动化测试就是黑盒测试.黑盒测试要求捕捉界面上的控件句柄,并对其进行编码,以达到模拟人工操作的目的.具体的自动化测试请学习Code UI Automation,这里不再介绍. 转自:<编写高质量代码改善C#程序的157个建议>陆敏技 到此,<编写高质量代码改善C#程序的157个建议>的笔记已经全部完成. 转载请注明出处: 作者:JesseLZJ出处:http://jesselzj.cnblogs.com…

建议156:利用特性为应用程序提供多个版本 基于如下理由,需要为应用程序提供多个版本: 应用程序有体验版和完整功能版. 应用程序在迭代过程中需要屏蔽一些不成熟的功能. 假设我们的应用程序共有两类功能:第一类功能属于单机版,而第二类的完整版还提供了在线功能.那么,在功能上,需要定制两个属性“ONLINE”和“OFFLINE”.在体验版中,我们只开放“OFFLINE”功能.要实现此目的,不应该提供两套应用程序,而应该通过最小设置.为一个应用程序输出两个发布版本.这一切,可以通过.NET中的特性(At…

建议155:随生产代码一起提交单元测试代码 首先提出一个问题:我们害怕修改代码吗?是否曾经无数次面对乱糟糟的代码,下决心进行重构,然后在一个月后的某个周一,却收到来自测试版的报告:新的版本,没有之前的版本稳定,性能也更差了,Bug似乎也变多了.也就是说,重构的代码看上去质量更高了,可实际测试结果却不如人意. 几乎每个程序员都因为此类问题纠结过.我们要修改的代码也许来自某些不负责任或经验欠佳的程序员,也许这些代码是自己一年前写的,但是看上去已经惨不忍睹.我们想要修改这些代码,却担心重构出别的问题.…

建议154:不要过度设计,在敏捷中体会重构的乐趣 有时候,我们不得不随时更改软件的设计: 如果项目是针对某个大型机构的,不同级别的软件使用者,会提出不同的需求,或者随着关键岗位人员的更替,需求也会随个人意志有所变更. 如果竞争对手增加了新需求,我们也不得不为正在研发的新产品调整设计方案. 刚开始的架构太糟糕了,这可能源于设计经验的不足或者架构师的不负责任. 以上分别从外部和内部描述了必须修改需求和设计的几种场景.也就是说,在软件开发过程中,变化几乎总会发生. 为了捕捉需求上的不断变化,软件开发必…

建议153:若抛出异常,则必须要注释 有一种必须加注释的场景,即使异常.如果API抛出异常,则必须给出注释.调用者必须通过注释才能知道如何处理那些专有的异常.通常,即便良好的命名也不可能告诉我们方法会抛出那些异常,在这种情况下,使用注释是最好的手段. /// <summary> /// 注释 /// </summary> /// <param name="value">输入参数注释</param> /// <returns>返…

建议152:最少,甚至是不要注释 以往,我们在代码中不写上几行注释,就会被认为是钟不负责任的态度.现在,这种观点正在改变.试想,如果我们所有的命名全部采用有意义的单词或词组,注释还有多少存在的价值. 即便再详细的注释也不能优化糟糕的代码.并且注释往往不会随着代码的重构自动更新,有时候我们可能会在修改代码后忘记更新那段用来表达最初意图的文字了.所以,尽量抛弃注释吧,除非我们觉得只有良好的代码逻辑和命名仍旧不足以表达意图. 当然,有些注释可能不得不加,如一些版权信息.另外,如果我们正在开发公共API…