予沁安-CSDN博客

原创我技术作文的方向

反观如今的博客也好，技术文章也好，多是某一方面的技术细节,我个人不太喜欢这个方向,觉得意义不大。这些确实都是知识,我也十分尊重和感谢这些作者的贡献，因为我碰到问题也经常搜索这样的技术文章而得到了帮助。可是，这与软件公司的实际工作总有个巨大的鸿沟，经常也看到很多人也类似的困惑，看了众多技术文章后，依然迷茫?更有人把这些困惑诉诸于文字。商业软件注重的是技能,是所有技能的大整合，而不是技术点的罗

2012-07-25 04:34:42 1073 4

原创领域驱动(DDD)实战---月份类YearMonth

Net中有一个DateTime结构类，涉及时间和日期，这个类大量使用。可是，他的名称已经显著的表明他是表达某个具体的时刻。当我们不需要每天的具体时间时，如：我的程序逻辑仅仅需要年月（发工资的周期？），这个DateTime显得有些累赘，甚至不合用。一般人们解决的方式，仍然使用DateTime而从数据上，设置hour,mintue等等为0。然而，这与DDD的理念相背，名称有与含义有偏差，另外，数

2013-05-22 12:15:06 952

原创重构之重与敏捷之轻---身份证号重构回顾

寻找重构的案例重构的案例不好选取,我们自己实际的项目当然有不少重构的情况,却不适合作为文章阐述出来。并不是因为保密的考量,而是业务本身的内容太复杂。当然，这个复杂是相对的,对短短一篇文章来说,那怕是最小一部分的业务逻辑拿出来,也显容量不够。而且,过多的阐述业务逻辑,导致喧宾夺主,掩盖了重构的注意力。所以,要选取一个大家都熟悉的东西,身份证号恰恰中了我第一个要求。即然是重构,必然要有个原始的

2013-05-10 04:58:20 984

原创它山之玉可以重构：身份证号（第四天）

可以说,到了今天,我才真正能开始做我想要的重构/改进。之前，只是补充测试，调整了一下结构。是的，非常的缓慢，这居然被称为“敏捷”!? 你说奇怪不奇怪?还好，这种节奏适合我这种大龄青年，合用就好，关它是风花还是雪月。==》测试覆盖上一次漏掉了最重要的异步，测试覆盖:本以为会秀一个漂亮的100%覆盖率的测试出来，人算不如天算，居然有一个方法是75%！（本文版权属于

2013-05-02 06:05:40 1221 2

原创它山之玉可以重构：身份证号码解析、验证工具（第二天）

又是一个清新的早晨, 开始我们新的测试之旅.2 - 第二个测试, 从身份号取到正确的性别信息.==>很简单,依葫芦画瓢, 容易的写出第二个测试. ==>很惊奇,居然没有过? 却不知, 测试的旅途中,Failed是常态. ==>好吧, 看看错误在哪?在取性别代码时,作了验证,而且是全套. 为什么取地址时却不验证呢? 这个不一致性来源于---不是测试

2012-12-21 09:22:47 703

原创代码整洁之道------它山之玉可以重构：身份证号码解析、验证工具（第一天）

首先感谢原作者的代码: 《面向对象的15位、18位中国大陆身份证号码解析、验证工具》. 如果有版权问题，敬请告知。原代码给了我很好的起点，是的，这些代码都是玉，我在这只是再琢磨琢磨。即使如此，重构的过程依然很繁琐，文章也许会很长，每一次的重构都需要把全部代码显示一遍。知易行难, 重构是个动态过程, 不那么容易呈现出来,需要点耐心，慢慢看啊。1 - 转化为C#

2012-12-18 09:09:30 4079 16

原创百般武艺为哪般, 业务域是核心

"业务域,是软件的核心价值所在。"项目经理和架构师: 敌人还是朋友无论是买成型的软件产品,还是出资开发项目,客户投资的是软件的业务价值。项目经理直接为这个目标负责,尽量少的成本,尽量短的时间,生产出高业务价值的软件产品。架构师则是跨越单个项目,长期为这个目标负责。项目经理与架构师是天生的敌人,短期看这是对的,长期来看,他们是真正的朋友,是战略朋友

2012-12-13 06:06:20 917

原创这也是C#代码吗 --- 代码阅读性进阶：测试文档化

没有太多的罗嗦，代码本身已经足够。如果，要添几个标签的话就是：中文化,流畅性接口(Fluent Interface),ＡＰＩ.只有几点补充说明：1。这都是真实可运行的代码，请看测试状态: 点击Login as guest2。测试使用Machine Specification, 重点是Establish部分。 3。仅仅使用于集成测试（用户故事）；不建议业务领域和单元测试使用

2012-07-21 00:18:24 5393 51

原创深入浅出裸测之道---单元测试的单元化

摘要: 依赖注入DI很大程度的帮助解耦层与层之间的依赖关系，使得测试单元化。当我们的注意力转移到业务域时，情景有了悄悄的改变。业务域中,类与类之间有更多更复杂的依赖关系。相比之下，三层之间反而简单。本文一步一步介绍，对于业务域的单元测试，如何从传统nUnit测试走到最高境界。三层架构之解耦和单元测试业务域的简单案例---构造器赋值传统nUnit测试示例坏味道？---重构的提出

2012-05-21 14:03:24 1377 2

原创三层架构，够不够---DDD眼中的三层（附C#源代码实现）

软件复杂度的根本，来源于思维的复杂度。三层架构从DDD看三层DDD的三层实现详细架构看代码业务域（Domain）持久层（数据层）测试和使用的例子完整代码下载得心应手武器库:Fluent nHibernatenUnitGit （GitHub) 本文所涉及使用的工具, 见前文: 我的.Net武器库 -

2012-05-18 23:28:09 2328 5

原创我的.Net武器库

工欲善其事，必先利其器。N多年前微软官网曾发了.Net下必备的十种工具，N多年过去了，世异时移，很多东西都已经变化了，那个列表也似乎陈旧了。而且，该文也只是对十种工具独立的介绍，显得有些罗列的感觉，是不是每个工具都是同等重要，工具与工具之间是否有联系？等等，阐述得并不明确。这里，我想从另一个角崖，重新归纳一个更新的更实际的武器库。更新，是因为有很多最近几年才出来的工具/框架库，更实际，

2012-04-05 04:35:41 1250 2

原创逃脱Asp.Net MVC框架/枷锁,使用Razor视图引擎

此文应该算Razor引擎浅析的续篇，或者说浅析是此文的前传。为什么要这么做？1. Asp.Net MVC 其实也不是太好 2. 我有自己的敏捷Web框架, 仍然想用Razor引擎 3. 动态编译很有意思，这也是将来的一个趋势，如果有人有兴趣，我倒是很想写写这方面的内容. 可是也有这些想法的人并不多，找来找去，这方面的资料和论述极其之少。与其临渊羡鱼，不如退而结网。

2012-03-28 12:37:27 1447 2

原创 html从魔鬼拼图到行云流水

虽然Html不是和互联网同时诞生，但如今它们的紧密关系，让人几乎一忽略了这段历史。Html有如此强的生命力力，应用如此之广，自从W3C宣布H已死之后，却又在别处开了花，Html 5的发展却又反过来，逼得W3C接受又继续发展。然后，自Html设计之出，就主要针对静态内容的表现，这也注定其天生缺陷。互联网已从起初的内容表现，发展到应用的平台，在应用程度领域上已经足以与桌面程序抗衡一一你还在用F

2012-03-28 04:55:40 1416 2

原创 Html从魔鬼拼图到行云流水之二

所幸，业界一直致力变革。先期CSS 1，2，3，Javascript特别是JQuery，分别贡献于样式和行为的分离，这些都是碎片组成部分。因而，HTML可以只关注于内容及其结构，纯粹化的很重要一部分。这里不作详敘，因为网络上有太多的文章和论敘，尽管很多的网站建设，连这些技术都没应用好。这里，我只想讲讲后CSS，jQuery时代的故事。那怕只作内容的呈现，仍有很多的机会产生碎片。不变的

2012-03-28 04:52:49 963

原创 html从魔鬼拼图到行云流水之一

虽然Html不是和互联网同时诞生，但如今它们的紧密关系，让人几乎一忽略了这段历史。Html有如此强的生命力力，应用如此之广，自从W3C宣布H已死之后，却又在别处开了花，Html 5的发展却又反过来，逼得W3C接受又继续发展。然后，自Html设计之出，就主要针对静态内容的表现，这也注定其天生缺陷。互联网已从起初的内容表现，发展到应用的平台，在应用程度领域上已经足以与桌面程序抗衡一一你还在用F

2012-03-28 04:51:44 876

原创 Razor视图引擎浅析

从Web Form开始，视图的机制其实就没改变过，动态编译视图脚本。所不同的是，Razor就仅仅是模板，没在嵌入与网站等相关的东西，应该是SRP的一个体现。可惜，这种功能分离仍做得不彻底，MVC中，Razor与其他部分的整合仍比较多，路径的寻找等功能的嵌入，使得它不容易单独拿出来使用。当然，这也是微软的一贯风格，整体使用性能优先。视图引擎浅析模板是其最主要的功能，但是另一个次功

2012-03-28 04:10:59 1244

考试系统架构经历了三个阶段： 一、大部分都基于Jean-Paul S. Boodhoo提供的Front Controller 实现，主要核心是基本抛弃Web Form，实现了一个轻量级的MVC架构。 二、考分查询实现。Http://ES.skight.com 在上面架构的基础上，加入Repository层，实现从文本提出数据，在内存缓冲。经过几次实际流量的测试和改进，现在的性能基本达到每个查询耗时20ms 。因此，反推理论最高查询流量可达50次/秒或18万次/小时

2011-05-27 04:39:00 879 6

原创 Web应用架构:错误统一处理, 和事务统一处理

因为前期,重点放在业务分析上,这两块一直认真思考过,觉得很简单.一开始只是找了一个nHibernate的示例, 就决定把Session的Open和Close和事务(Transaction)的Commit, 放在HttpModule中处理. 算是Session per Request的模式.之后,继续加入错误处理的PlugIn, 做了一个HttpHandler的Decorater, 在所有其他HttpHandler的最外层. (我使用的是自己实现的FrontController来处理页面). 这样一来, 任何

2010-07-15 05:16:00 636

原创 Server.Transfer 与 Server.Execute

近期在做一个Web的项目. 即不用WebForm也不用MVC, 走了第三条路,做自己的一个框架用FrontControll. 可是,HTML模版这一块太大,仍然使用Asp.net的解析. 使用aspx文件做模版. 开始,使用Server.Transfer来装载模版文件( 类似Server.Transfer("my template.aspx") ). 一切都没有问题, 效果很好, 速度也快, 过程中我也反过来看了Asp.netWeb Page类实现,

2010-07-14 00:49:00 585

原创时间的尺度和任务的粒度 -- SCRUM 1

时间的尺度:小时(1~2小时),天(0.5~3天), 星期(1~2星期), 月(1~3月),年.仅仅使用以上的时间尺度来衡量任务. 比如, 说1个任务需要量10个小时是没有意义的, 要折算成天,如2天.同样,说这个用户故事要20天完成,不如说要1个月. 尺度的恰当使用,会对项目管理很有帮助. 组织好开发的节奏.任务的粒度: 目前为止,在我的实际应用当中, 开发人员个人的工作过程中最基本的任务单位以1小时为宜, 这也是上面最小的时间尺度.这不一定是项目分配任务, 多数情况应该是开发人员的分解任务.

2010-07-08 00:03:00 1204

原创思维的禁锢大脑的绳锁

在心理学上有个有名的故事，就是一只大象，在它小时候被一根细细的绳拴在一根小小的桩上，只是它那时没有力气挣断，于是它试了又试，最终不得不放弃。等它成年后，仍然一个小小的桩、一根细细的绳就能缚住它，它已习惯不再挣扎

2010-07-01 00:16:00 918

原创 SCRUM + Agile(Iteration) + Pattern

SCRUM是项目(公司)的层面. Agile是软件开发流程(的层面). Pattern是技术层面. Pattern只是一个有代表性的词而已, 其实涵盖更多与技术有关的东西. 比如光是Pattern就有Design Pattern, Architect Pattern. 其他技术性的东西: 面向接口编程, 合同编程(Design by Contract), DDD(Domain Driven Development), TDD(Test

2010-07-01 00:09:00 744

卓越之行