上一页 1 2 3 4 5 6 7 8 9 ··· 14 下一页
2015年8月26日
敏捷软件开发：原则、模式与实践——第4章　测试
摘要： 第4章　测试 编写单元测试是进行验证，更是进行设计。同样，它更是在编写文档。编写单元测试终结了许多反馈循环，尤其是功能验证方面的反馈循环。4.1 测试驱动开发 假设我们遵循如下3条简单规则： （1）除非编写了一个不能通过的单元测试，否则不编写任何产品代码。 （2）只要编写正好导致测试不通过... 阅读全文
posted @ 2015-08-26 18:02 JesseLZJ 阅读(552) 评论(0) 推荐(0) 编辑
敏捷软件开发：原则、模式与实践——第3章　计划
摘要： 第3章　计划3.1 初始探索 在项目开始时，开发人员会和客户商讨一下关于新系统的情况，以确定出所有真正重要的信息。然而，他们不会试图去确定所有的特性。随着项目的进展，客户会不断的发现新的特性。特性发现的过程会一直持续到项目完成。 当识别出一个特性时，会把它分解成一个或者多个用户故事，并把这些用户... 阅读全文
posted @ 2015-08-26 16:20 JesseLZJ 阅读(485) 评论(0) 推荐(0) 编辑
敏捷软件开发：原则、模式与实践——第2章　极限编程概述
摘要： 第2章　极限编程概述作为开发人员，我们应该记住，XP并非唯一选择。--Pete McBreen，软件技术专家在第1章中，我们概述了有关敏捷软件开发方法方面的内容，但它没有确切地告诉我们去做些什么；其中给出了一些泛泛的陈述和目标，却没有给出实际的指导方法。本章要改变这种状况。2.1 极限编程实践2.1... 阅读全文
posted @ 2015-08-26 11:54 JesseLZJ 阅读(974) 评论(0) 推荐(0) 编辑
2015年8月25日
敏捷软件开发：原则、模式与实践——第1章　敏捷实践
摘要： 第1章　敏捷实践敏捷软件开发宣言：人和交互 重于 过程和工具可以工作的软件 重于 面面俱到的文档客户合作 重于 合同谈判随时应对变化 重于 遵循计划虽然右项也有其价值，但左项更加重要。1.人和交互重于过程和工具 人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就算是使用好的... 阅读全文
posted @ 2015-08-25 15:12 JesseLZJ 阅读(2669) 评论(0) 推荐(0) 编辑
2015年8月24日
编写高质量代码改善C#程序的157个建议——建议157：从写第一个界面开始，就进行自动化测试
摘要： 建议157：从写第一个界面开始，就进行自动化测试如果说单元测试是白盒测试，那么自动化测试就是黑盒测试。黑盒测试要求捕捉界面上的控件句柄，并对其进行编码，以达到模拟人工操作的目的。具体的自动化测试请学习Code UI Automation，这里不再介绍。转自：《编写高质量代码改善C#程序的157个建议... 阅读全文
posted @ 2015-08-24 19:09 JesseLZJ 阅读(620) 评论(0) 推荐(1) 编辑
编写高质量代码改善C#程序的157个建议——建议156：利用特性为应用程序提供多个版本
摘要： 建议156：利用特性为应用程序提供多个版本基于如下理由，需要为应用程序提供多个版本：应用程序有体验版和完整功能版。应用程序在迭代过程中需要屏蔽一些不成熟的功能。假设我们的应用程序共有两类功能：第一类功能属于单机版，而第二类的完整版还提供了在线功能。那么，在功能上，需要定制两个属性“ONLINE”和“... 阅读全文
posted @ 2015-08-24 18:45 JesseLZJ 阅读(428) 评论(0) 推荐(1) 编辑
编写高质量代码改善C#程序的157个建议——建议155：随生产代码一起提交单元测试代码
摘要： 建议155：随生产代码一起提交单元测试代码首先提出一个问题：我们害怕修改代码吗？是否曾经无数次面对乱糟糟的代码，下决心进行重构，然后在一个月后的某个周一，却收到来自测试版的报告：新的版本，没有之前的版本稳定，性能也更差了，Bug似乎也变多了。也就是说，重构的代码看上去质量更高了，可实际测试结果却不如... 阅读全文
posted @ 2015-08-24 18:11 JesseLZJ 阅读(394) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议154：不要过度设计，在敏捷中体会重构的乐趣
摘要： 建议154：不要过度设计，在敏捷中体会重构的乐趣有时候，我们不得不随时更改软件的设计：如果项目是针对某个大型机构的，不同级别的软件使用者，会提出不同的需求，或者随着关键岗位人员的更替，需求也会随个人意志有所变更。如果竞争对手增加了新需求，我们也不得不为正在研发的新产品调整设计方案。刚开始的架构太糟糕... 阅读全文
posted @ 2015-08-24 15:23 JesseLZJ 阅读(472) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议153：若抛出异常，则必须要注释
摘要： 建议153：若抛出异常，则必须要注释有一种必须加注释的场景，即使异常。如果API抛出异常，则必须给出注释。调用者必须通过注释才能知道如何处理那些专有的异常。通常，即便良好的命名也不可能告诉我们方法会抛出那些异常，在这种情况下，使用注释是最好的手段。 /// /// 注释... 阅读全文
posted @ 2015-08-24 08:53 JesseLZJ 阅读(452) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议152：最少，甚至是不要注释
摘要： 建议152：最少，甚至是不要注释以往，我们在代码中不写上几行注释，就会被认为是钟不负责任的态度。现在，这种观点正在改变。试想，如果我们所有的命名全部采用有意义的单词或词组，注释还有多少存在的价值。即便再详细的注释也不能优化糟糕的代码。并且注释往往不会随着代码的重构自动更新，有时候我们可能会在修改代码... 阅读全文
posted @ 2015-08-24 08:41 JesseLZJ 阅读(407) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议151：使用事件访问器替换公开的事件成员变量
摘要： 建议151：使用事件访问器替换公开的事件成员变量事件访问器包含两部分内容：添加访问器和删除访问器。如果涉及公开的事件字段，应该始终使用事件访问器。代码如下所示： class SampleClass { EventHandlerList events = new EventH... 阅读全文
posted @ 2015-08-24 08:28 JesseLZJ 阅读(321) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议150：使用匿名方法、Lambda表达式代替方法
摘要： 建议150：使用匿名方法、Lambda表达式代替方法方法体如果过小（如小于3行），专门为此定义一个方法就会显得过于繁琐。比如： static void SampeMethod() { List list=new List(){"Mike","Rose... 阅读全文
posted @ 2015-08-24 08:16 JesseLZJ 阅读(537) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议149：使用表驱动法避免过长的if和switch分支
摘要： 建议149：使用表驱动法避免过长的if和switch分支随着代码变得复杂，我们很容易被过长的if和switch分支困扰。一个类枚举类型Week如下： enum Week { Monday, Tuesday, Wednesday, T... 阅读全文
posted @ 2015-08-24 07:55 JesseLZJ 阅读(818) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议148：不重复代码
摘要： 建议148：不重复代码如果发现重复的代码，则意味着我们需要整顿一下，在继续前进。重复的代码让我们的软件行为不一致。举例来说，如果存在两处相同的加密代码。结果在某一天，我们发现加密代码有个小Bug，然后修改了它，却又忘记了角落里的某处存在着一份相同的代码，那么这个Bug就会隐藏起来。让我们重现这个例子... 阅读全文
posted @ 2015-08-24 00:58 JesseLZJ 阅读(530) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议147：重构多个相关属性为一个类
摘要： 建议147：重构多个相关属性为一个类若存在多个相关属性，就应该考虑是否将其重构为一个类。查看如下类： class Person { public string Address { get; set; } public string ZipCode { get;... 阅读全文
posted @ 2015-08-24 00:44 JesseLZJ 阅读(346) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议146：只对外公布必要的操作
摘要： 建议146：只对外公布必要的操作那些没有必要公开的方法和属性要声明成private。如果需要公开的方法和属性超过9个，在VS默认的设置下，就需要滚屏才能显示在Intellisense中，如图：SampleClass类： class SampleClass { private... 阅读全文
posted @ 2015-08-24 00:36 JesseLZJ 阅读(352) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议145：避免过长的方法和过长的类
摘要： 建议145：避免过长的方法和过长的类如果违反“一个方法只做一件事”及类型的“单一职责原则”，往往会产生过长的方法和过长的类。如果方法过长，意味着可以站在更高的层次上重构出若干更小的方法。以行数作为指标，有人建议一个方法不要超过10行，有人建议不要超过30行。当然，这没有唯一标准。在我看了，一个方法在... 阅读全文
posted @ 2015-08-24 00:19 JesseLZJ 阅读(512) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议144：一个方法只做一件事
摘要： 建议144：一个方法只做一件事“单一职责原则”（SRP）要求每一个类型只负责一件事情。我们将此概念扩展到方法上，就变成了：一个方法只做一件事。回顾上一建议的代码，LocalInit和RemoteInit方法是两件事情，但是在同一抽象层次上，在类型这个层次对外又可以将其归并为“初始化”这一件事情上。所... 阅读全文
posted @ 2015-08-24 00:11 JesseLZJ 阅读(404) 评论(0) 推荐(0) 编辑
2015年8月23日
编写高质量代码改善C#程序的157个建议——建议143：方法抽象级别应在同一层次
摘要： 建议143：方法抽象级别应在同一层次看下面代码： class SampleClass { public void Init() { //本地初始化代码1 //本地初始化代码2 RemoteIni... 阅读全文
posted @ 2015-08-23 23:41 JesseLZJ 阅读(378) 评论(0) 推荐(0) 编辑
编写高质量代码改善C#程序的157个建议——建议142：总是提供有意义的命名
摘要： 建议142：总是提供有意义的命名除非有特殊原型，否则永远不要为自己的代码提供无意义的命名。害怕需要过长的命名才能提供足够的意义？不要怕，其实我们更介意的是在代码的时候出现一个iTemp。int i 这样的命名只能出现在循环中（如for循环），除此之外，我们找不到任何理由在代码的其他地方出现这样的无意... 阅读全文
posted @ 2015-08-23 23:03 JesseLZJ 阅读(386) 评论(0) 推荐(0) 编辑
上一页 1 2 3 4 5 6 7 8 9 ··· 14 下一页