玄猫的窝

立秋++++

hanguofeng — Mon, 09 Aug 2010 23:55:26 +0800

立秋前一天，六月廿七。

十点多从公司回家，到家发现忘记带钥匙，于是厚着脸皮，叫棍子跑来开车带我去公司取钥匙，事毕，棍子说，明天立秋了，吃点肥肉，贴秋膘。

这件事我颇不以为然，身上的膘，还可以撑过很多个秋天。

而这个秋天，就这样到来了。

出生和死亡，都是会让人哭泣的事情，我们为迎接一个生命而惊喜，又为送别一个生命，而悲伤。天地不仁，以万物为刍狗。

不知道已经持续了多少个日夜，每每早晨打开网站看新闻，总是悲剧占据了头条，时不时还有黑体、黑字的加强版悲剧。贼老天，能不能淡定点？

每到秋天，总是会唤醒我记忆中这样的场景：军训中，在深山中秋天的傍晚，嗅着充满了树叶气息的空气，看蚊子的嘴穿透汗浸湿的衣服。感觉军训带给我们的，是恍如隔世的另一种宁静。恍如隔世没有什么不好，有的时候，真想给自己再创造一些恍如隔世的机会，总是跳出这个坑，才有机会看到坑里的自己。

今天，先到这里吧，我累了。

随机内容

夏·恐惧·变化·解耦

hanguofeng — Tue, 27 Jul 2010 00:37:12 +0800

今年的夏天我是怎么过的？

埋头在代码里解决问题、重构。淹的喘不过气来。终究在这个湿热的夏天，闷病了。

去年的夏天我是怎么过的？

奔波在学校和公司之间，和老师bargain论文，和dra bargain需求，和棍子bargain设计。

前年的夏天我是怎么过的？

蜗居在六里桥，享受刚工作的快感。

再之前呢？也许……我已经忘却。

最近半年总是很多变化，从年初的记忆日搬家、到过完年回来的众多离别、到五月份的杭州之游，再到入职百度。

从写程序的角度来看，没有比写永远不会经历变化的代码更无聊的事情了。写代码的快感就在应对变化，从需求的变化，到负载的变化。

在程序上害怕变化的原因莫过于耦合。你认为B是一个A，于是你让B继承了A，但实际上明天出现了变化，B不再是A了，问题来了吧。人生何尝不是如此。《波若波罗密心经》有云：“心无挂碍，无挂碍故，无有恐怖”，我们的恐惧总是来源于“挂碍”，挂碍难道不是依赖么。

我所习惯的应对变化的方法，则是解耦，如果B不和A耦合的那么强，也许事情会好办很多，你所挂碍的东西，不是那么具体，也会变得好很多。

现在的人，满足底层需求都是很容易的，所谓的忧愁，却偏偏是不厌其烦的要满足自己的高层需求，总是将“自我实现”继承了“钱”、“地位”，但实际上，你需要的是一个高层需求提供者，这个提供者就是更真实的你，有的时候，这个提供者提供的是钱，有的时候，是地位，还有的时候，是快乐，是幸福，是感动，是付出。别直接把高层需求假设为某个东西嘛。其实啊，钱、地位和开心、幸福在这个层次上都是平行的，实现同一个接口的东西，这个接口是自我实现。那么，这些东西，是否可以继承自一个基类，是一类东西的抽象呢？我现在还没有想明白，所以，不急，不急。慢工出细活，慢慢干。

淡定哥是我，我是淡定哥。

回想过去的几个月，有很多东西都被配给了需求提供者，提供者输出的东西，也在频繁变化，不想加那么多switch…case，太费脑子，让他自己感应环境，自己适配吧。

我好像得了很严重的职业病，之前发生过看到 season in the sun，念成session in the sun的故事，今天又在一篇普通的，没有作为“Code Life”的博客里面，用技术原理描述生活了，哎。

好了，淡定，也许你又要说，看不懂，好高深，淡定啦，以后，会懂的。

随机内容

LazyLoad Girl On Marriage

hanguofeng — Wed, 14 Jul 2010 00:57:36 +0800

 class Boy
    {
        private string _name;
        private Girl _girl;
        public Boy(string name,Girl girl)
        {
            this._name = name;
            this._girl = girl;
        }
 
        public void Marriage()
        {
            string girl_name = this._girl.GetName();
            string boy_name = this._name;
            this._marriage(boy_name, girl_name);
 
        }
        private void _marriage(string boy_name, string girl_name)
        { 
            //other codes
        }
    }
 
    class Girl
    {
        private int _id;
        private string _name=null;
        public Girl(int id)
        {
            this._id = id;
        }
 
        public string GetName()
        { 
            if(null==this._name)
            {
                this._name = this._get_name_from_store(this._id);
 
            }
            return this._name;
        }
 
        private string _get_name_from_store(int id)
        {
            string rtn = "";
            //other codes
            return rtn;
        }
    }

延迟加载，不是一种设计模式，而是一种思维。当一个对象的若干属性值位于数据库或其他远程存储中，且不会被立即访问时，没有必要一开始创建对象就从远程存储读取，而是在被调用的时候，才进行读取，读取后，可以考虑放入私有变量，作为一个缓存机制，但是需要考虑当后端数据存储更新时，类实例存在脏数据的问题。
延迟加载在某些场合，可以提高系统性能。

随机内容

听小韩聊PHP项目开发(3)–切分你的系统

hanguofeng — Mon, 12 Jul 2010 20:04:09 +0800

【写在前面的话：看看本文的时间，最后一次保存是去年的八月份，想想，还是先发表一下，然后待续，老规矩，在本文完成之前请不要转载。】

你是一个有控制欲的人么？你希望把控你的项目么？那么，切分他们吧。

1、为什么要切分你的项目

我们是邪恶的 -.-。我们希望把控我们的项目，所以，我们需要切分它。

想像一下，你有一个生日蛋糕，你想吃掉它，那么，按照惯例，作为寿星的你，应该先切分它，什么？你还要点蜡烛？OMG，你要在吹蜡烛时喷口水在蛋糕上吗？你的口味好重。

切分代码，大体上来说，在控制进度、应对变化、简化逻辑、代码复用、分工协作等方面，都有相当的好处。

1.1、控制进度

首先来说控制进度，当你开始开发一个大型站点时（当然，更多的时候是“你们”），作为项目经理的你来讲，你需要时不时的应对来自你的上级或者你的客户的询问–“小韩，做了多少了，还有多久能做完啊”。这个时候，你总不能说，“哦，我做了一些了，还有一段时间能做完。”

你的领导希望听到的是，系统一共有x个模块，我做完了x个，剩下x个模块，难度有些大，可能还需要x天的时间，等所有模块都完成了，再整体整合测试一下，就OK了。这样回答，我想你的表现会让你的领导觉得，你是一个思路清晰，能够把控的项目管理人员。这里再容我跑题一下，一般认为，管理职能分为“计划、组织、协调、控制”等。其中“计划”则首先依赖于对项目的切分，如果不能切分项目，则无从进行计划。

1.2、应对变化

我们都知道，项目，尤其是软件项目是多变的，这种变化可能来自于前期沟通的不完善，也可能来自于随着时间的发展，客户或软件使用者的需求随之发展而发生变化。如果项目中所有的部分都是互相缠绕的，那么则牵一发而动全身，你甚至无法对一个简单的变量名进行改变，而使得系统的其他部分不受到干扰。然而此时，如果对系统进行划分，将其分为若干层次、若干模块，层次与层次、模块与模块之间通过既定协议（如接口）进行通讯，则可以将原有的整体复杂系统切分为若干个子系统、子模块、子程序，各程序只要保持其输入、输出不变，则其内部的代码可以方便的更改而不怕会影响到外部。

我举个例子来讲，你可能用以下代码处理用户的登录以及其登录会话的持久化（Session）。

//登录代码
if($success_login) //假设$success_login为上一步判断用户名密码正确与否的标记
{
  $_SESSION['user_name'] = $user_name;
  $_SESSION['password'] = $password;
}

而使用如下代码判断是否登录

if(isset($_SESSION['user_name']))
{
  //do something
}

那么假设有一天，你想使用username作为保存用户名的Session变量名称，则你需要找出所有形如$_SESSION['user_name']的代码，并修改，一旦有遗漏，你的程序将会出现难以查找的bug。

这就是因为在代码中，把用户登录会话的部分耦合在了全部的系统当中。实际上，你应该专门有一个管理用户登录会话的模块，比如叫做SessionManager，你的代码则可能变为这样：

/**
* 设定登录会话
*/
if($success_login) //假设$success_login为上一步判断用户名密码正确与否的标记
{
 SessionManager::SetLoginUser($user);
}
 
/**
* 判断登录状态
*/
if(SessionManager::IsLogined())
{
 //do something
}

这样，你在系统中，无需过度关注用户会话保存的具体实现，只要去调用SessionManager这个管理器的相关方法就可以了，而一旦发生前面提到的变化，你可以在SessionManager的内部完成此修改，而不会将这个问题渲染到全部代码。

1.3、简化逻辑

也许大部分普通的Web站点并没有复杂的逻辑，但是，随着网络世界越来越精彩，Web站点也会逐渐面临处理复杂逻辑的任务。一旦你面临复杂的系统，其中可能难倒你的，大部分不会是技术问题，而是逻辑问题，我们应当承认我们人类中的大部分，思维的稳定性和思维长度，都是有限的，我举个例子来说，在下棋的时候，在头脑中演算下一步应该如何走，对手针对你的下一步如何走这样的逻辑，没有经过一定锻炼的人，是不可能演算很多步的。对于系统逻辑来说也是一样的，同时考虑过多的问题，以及这些问题之间的关系，会让你无法承受，然而此时将一个大的、复杂的问题切分为若干小问题，在同一时刻只关注一个小问题，则可以让自己轻松快乐的去进行程序的编写。再举个例子，比如我们要写一个MSN的客户端，那么实际上是有很多问题要考虑的，你的程序如何与服务器通讯，如何构造和发送数据，如何接受和处理数据，如何将数据显示在界面上……so many，这个时候你可以将你的系统切分为若干的模块，有的模块去处理网络通讯，有的去处理数据包的解析和构造，有的去处理界面显示，有的去处理各种事件的调度，等等等等，在各个模块中，你还可以进一步划分，直到单个类遵循单一职责原则，而一个模块间各个类都是聚合的……等等等等，这里有很多方法和技巧，我们稍后会详细讨论。

1.4、代码复用

代码复用的一个重要基础是分割变化与不变的部分，并分别进行编程。还以我们上面的MSN客户端的例子来说，其处理网络通讯的模块，在其他的程序中是不是也可以使用呢？答案是肯定的，但是……这要求你能够良好设计这个模块，权衡其边界，以使其具有普适性。这种基础类的实现，不应当关联具体项目的问题，比如说最简单的，你的方法名，不应当叫做send_msn_request，而只是send_request，这只是一个很简单的例子，但是却说明了，你要考虑你系统中的某些聚合功能，是不是可以在其他项目中使用的，如果是，请将其切分出来，并撰写并非是与当前项目紧密耦合的代码，你可以使用一个适配器将其配接到当前项目中，而不是将其直接为当前项目撰写。

关于代码复用的内容，您还可以查看http://www.ibm.com/developerworks/cn/java/reuse/获得更多信息。

1.5、分工协作

分工协作首先要求在“工”上有的可分，现代生产是要求详细分工，流水线方式作业的，试想，哪怕一个简单的MP3，有做芯片的机器，有开发嵌入式系统的工程师，还有利用模具生产的合作工厂，最后将各个部分拼接起来，成为你手中那个会发声、可以控制的小玩意。程序开发也是一样的。每一个系统，无论简单复杂，总是由若干个子系统组成的，这些子系统通常是功能内聚的，并通过某些特定方式与其他子系统进行协作。简单说，你所看到的这个WordPress的系统，有文章的子模块、有分类/Tag的子模块，那么我们是否可以让两个人分别去开发文章的子模块和分类/Tag的子模块呢，答案是肯定的，合作者首先坐在一起，定义各自的系统边界，开发分类/Tag子模块的工程师无需了解文章是由标题、内容，甚至图片组成的，他只了解，需要给特定的文章（通过文章的id来作为关键标记），进行分类，或者标记Tag，同理，开发文章子模块的工程师也无需了解Tag和分类的区别，只需要做他的文章模块的CURD就可以了，彼此之间不需要了解太多，是增强系统稳定性，在变化时可以敏捷修改而不担心影响其他部分的重要方式。这可以降低系统的开发和修改成本，工程师之间不必担心进行了重复的工作，因为子系统边界已经确定，每个人需要做什么是非常清晰的，同时，他们不必担心他们所完成的功能如何被调用，因为这些调用规则在切分系统时就明确了。他们也不必考虑其他子系统是否会影响他的系统，包括其他子系统的bug或者修改，因为各子系统是高内聚、低耦合的，子系统的具体实现方式不会过多影响其他系统。

2、如何切分你的系统

切分系统是一种艺术而不是一种技术。从不同的角度看某个物体，你会得到不同的投影，一个正方形的投影，那么其原物体一定是正方体吗，当然未必。从不同的角度看待系统，就会有不同的切分方式。而我们要做的就是，试图从各个角度来看待系统，避免盲人摸象，最终选择一种权衡的、折衷的，对于系统的发展方向最契合的方式来切分。不同的程序员有不同的切分习惯，而我们也无法武断的去说一定要按照某种方式切分。毕竟，我们不是为了切分系统而切分，而是要达成某种目的，这些目的我在上面笼统的谈过，比如说，针对分工协作，如果团队中程序员的水平有一定差距，那么可以将相对内核的复杂部分切出来，交由有经验的程序员来完成，即时它可能在其他方面并不能达到你的目的。

切分系统有几种角度，让我们由浅入深的聊一聊。

2.1、横向切分

对于系统的切分，横向切分是最常见的，例如MVC模式：MVC（Model-View-Controller，模型—视图—控制器模式）用于表示一种软件架构模式。它把软件系统分为三个基本部分：模型（Model），视图（View）和控制器（Controller）。

这种切分方式主要考虑了系统是由几个层次来完成的，各个层次之间的功能是内聚的，比如在MVC中，Model层负责数据交互，它永远不必理解数据在界面上是如何展示的，同理，View层也不必理解数据是从MySQL数据库还是SQL Server甚至是文件中的哪个取出的。

这种层次的划分，可以将系统功能划分为几个大部分，这几个大部分相对独立，然而又通过行为/数据被粘合在一起，从而使得其中某个部分发生变化时，其他部分不至于那么敏感，比如，网站的界面是会频繁改版的，然而你会发现，几乎大部分情况都是，界面上的元素摆放发生了变化，但是数据本身并没有任何变化，那么我们只需要改变View层就可以了，你的C和M层的代码一点都不用改动。

另一个名词叫做“三层架构”，实际上和MVC类似，也有人将MVC直接成为三层架构。其代表是微软的示例程序PetShop（架构详细分析看这里）。其将系统大致分为DAL（Data Access Level，数据访问层）、BLL（Bussines Logic Level，业务逻辑层）以及界面表示层。

但是，我窃以为，仅有MVC是不够的。在MVC中，Model层的功能实际上是可以再分为数据逻辑和业务逻辑两个层次，即更倾向于三层架构。业务逻辑层可以复用多个数据逻辑层，这在仅有Model层的系统中是难以做到的，同时，业务逻辑是可能发生频繁变更的，此时简单的数据逻辑并没有发生任何变化，不需要花代价和承担风险进行修改。我举个例子来说，我们要设计一个用户系统，该系统有注册、登录、修改信息等功能，此时，我们可以根据需求制定出一个业务逻辑层，你可以将其叫做LogicOperation/UserOperation层（下文简称UserOper），在该层中切合需求进行功能的设计，即Login、Regist、ModifyInfo，那么，我们是否在这个层次中就开始撰写关于数据库操作的代码呢，答案是否定的，因为你会发现，在Login功能中，你需要去查询用户名是否存在这样的信息，在Regist中，你同样会查询该信息，此时，你应该继续抽象出一个功能相对原子化的数据操作层，即DataManager/UserManager，在UserManager中，实现标准的CURD（Create、Update、Read、Delete）功能，以及某些可能用到的其他功能，但是这些方法应该是原子化的，可以由UserOper组合调用，例如在Regist中，可能通过UserManager的IsAccountExist方法查询用户名是否存在，然后用CreateUser方法建立用户，而在Login中，首先通过IsAccountExist方法查询用户名是否存在，然后用ReadUserByAccount方法来获得用户信息，并继而比对密码，等等，你会发现，LogicOperation层是对DataManager层方法的组合调用，而其组合方式就是具体的业务逻辑。

2.2、纵向切分

2.3、混合切分

2.4、切分粒度

3、切分案例

3.1、一个CMS系统的切分

3.2、一个博客系统的切分

3.3、一个校内网APP程序的切分

4、切分作业

Singleton.Lover

hanguofeng — Tue, 01 Dec 2009 21:17:21 +0800

    class Lover
    {
        private static Lover _instance;
        private static readonly object _locker = new object();
        public static Lover getInstance()
        {
            if (null == Lover._instance)
            {
                lock (Lover._locker)
                {
                    if (null == Lover._instance)
                    {
                        Lover._instance = new Lover();
                    }
                }
            }
 
            return Lover._instance;
        }
    }

单例模式（单件模式、Singleton）是一种为方便管理类的实例的数量的设计模式，属于建造型模式。当然，这个数量一般是1。单例模式可以使得在生存期内，所有使用类实例的场合，都使用相同的类实例，从而保证在某些应用场景下，所操作的数据是你需要操作的那一份，同时有一个副作用的方便就是不再需要记住所使用的是哪个类实例。

顺便发一个小笑话：

如何加一个条件让查询：

SELECT * FROM 女人 WHERE will_love_me=true

不返回空记录集呢

答案是…

SELECT * FROM 女人 WHERE will_love_me=true OR 1=1

好吧，这很冷。。。

QQREADER0EAE6F8FD43BDC7F

随机内容

北京·冬·有雪

hanguofeng — Tue, 10 Nov 2009 00:29:11 +0800

今年的气候不太正常，11月刚露出半个脸庞，就蒙上了轻纱，天会突然变得阴暗，然后雪就降了下来。

今天晚上，又是这样的，只是，天蒙蒙有些橙色，树都被妆成了圣诞节的样子。

我希望今天是一场梦，我希望，这一年，是一场梦。

然而，不是的。

ade，dota战友，ade，加班总是没蓝的同事，ade，东来顺，ade，很多次被用记号笔画过的白板，ade，glass floor，ade，220，ade，2007。

and,never,forget,those days in dream.

随机内容

parseInt bug in firefox 3.5.2

hanguofeng — Sun, 06 Sep 2009 10:25:37 +0800

来，先让我们看下面的JS代码：

  for(var i=0;i &lt; 1000;i++)
  {
        var result = parseInt(-15.02);
	document.write( result );
	document.write( '' );
  }

你觉得他会输出什么？一串的-15？恩，也许在其他浏览器中是这样的，但是据我的测试，在Firefox 3.5.2里面，只有开始的几个是-15，其他都是-16，而且-15的个数不一定，有时是3个，有时又会出现4个。

那么，怎么解决呢，将其改为：

parseInt(-15.02,10);

即可

English version for foreign friends:

Ok,let’s get to the codes below:

  for(var i=0;i &lt; 1000;i++)
  {
        var result = parseInt(-15.02);
	document.write( result );
	document.write( '' );
  }

What do you think it will output?Rows of -15?It might be in other browsers except Firefox 3.5.2 according to my test.In Firefox 3.5.2,only the begins are -15,others are -16,and the number of -15 is varying at different time,sometime 3 and sometimes maybe 4.

Then,codes following will works:

parseInt(-15.02,10);

随机内容

听小韩聊PHP项目开发(2)–观察你的项目

hanguofeng — Sun, 28 Jun 2009 13:42:06 +0800

Hello，时隔半年，我终于继续了 =.=

1、为什么要观察你的项目–需求的重要性。

俗话说，磨刀不误砍柴工，当开始一个项目时，我希望你就像在街上看到了美女，你要先好好打量打量，然后再思考，“啊，我怎么去问她的电话呢~”

So,same as our projects.

当开始一个项目时，你应当首先审视的是项目的需求，要注意了，除非是你自己为自己闲着没事做的东西，其他的项目，都是为别人做的，怎么理解呢，我的意思是说，你项目的目的就是满足别人的需求。软件实际上是一种商品。所谓商品，就是商品是为交换而生产（或用于交换）的对他人或社会有用的劳动产品[百度百科]。请注意“对他人或社会有用”，这就是在讲，我们所编写的软件是为了满足需求而存在的，如果不能满足需求，哪怕你用了再高的技术，软件做的再漂亮，运行效率再高，都不能被称之为一款合格的软件。

为什么突然要扯这么远呢，是因为，我曾经和很多人一样，在做开发的时候，开始的时候无时不刻的都在想，这个东西有什么技术创新点，什么地方的效率会很低，应该解决，后来我听到了一句话，叫做“过早优化是万恶之源（premature optimization is the root of all evil–Donald Knuth）”，可能的确有那样一些项目，他们要求很高的效率，或者，该项目的需求者一直在询问你关于效率的问题，但是无论如何，在你什么都没有的时候，你就什么都不能做，就像你并没有一个女儿，你却时刻想着如何去打扮她一样毫无意义。

请记住，我们所编写的软件，它的第一要务是满足需求，当然，运行效率、界面美化可能是需求的一部分（非功能性需求，我们稍后会谈到），但是请将其作为需求考虑，而不是贯穿软件的全部。

关于需求，这里有一幅漫画，来源未知（提示：你可以点击图片放大）：

另外还有此图片的中文版：http://picasaweb.google.com/lh/photo/ZK59I5p5-jfsc7kl213htQ?feat=directlink

2、我要观察到什么–什么是需求

“需求是产品必须完成的事以及必须具备的品质。需求存在的原因要么是该类型的产品要求一定的功能和品质，要么是客户希望需求成为交付的产品的一部分。”

–《掌握需求过程》ISBN:9787115159830

从上面的漫画中，可以很有趣的发现，由于沟通方式，对目标的理解差异和技术水平的不同，都会让需求在传递中发生变化，这种变化有时可能是致命的，我们人类在沟通时多采用语言，然而语言，尤其是口头语言，极易发生变化。因此，就需要大家对需求有一个统一的认识，什么是需求，需求应该包括哪些内容，不应该包括哪些内容，应该如何去分析需求。

本节引言中的话，严格来讲不是对需求的定义，让我们来看IEEE软件工程标准词汇表(1997年)中“需求”的定义：

(1)用户解决问题或达到目标所需的条件或权能(Capability)。

(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明

软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

简单来说，需求就是说明你软件将要满足的用户需要，需求是你软件的功能列表，这里的功能可能包括看得见的功能和看不见的功能。同时需要注意实际用户（用户是重要的需求分析参与者，难以想象一个只有开发者而没有用户参与的需求分析，所得出的是什么）可能对需求的理解有误，有时他们甚至不了解活无法向你描述出他的需求，也有时，他会“啰啰嗦嗦”的向你讲一堆不是需求的东西。

同时，需求还包括非功能的部分，例如，“单次搜索查询必须在0.1秒内完成”、“用户传输文件的速度不应低于其网络最高可用带宽的50%”，这些内容并非软件的功能性要求，但是实际上是软件的使用者使用软件体验、感受的重要感受点甚至是其是否能完成功能性需求的制约。

3、我没有马王爷的第三只眼–那么我如何分析需求呢

哦，这很麻烦，是的，好吧，我们退一步，作为开发人员，你可以让你的产品经理去和客户打交道，但是你必须和你的产品经理打交道，同时，你还必须和你的代码打交道。

与产品经理打交道和与代码打交道是两码事，八杆子打不到一块，你不能和产品经理讲if(xxx) {} ，也不能去问你的代码，这里是让用户操作的，还是你丫自动操作的。

在与产品人员打交道时，你有责任用他们的语言来描述问题，这并不是单纯为了对方能够听懂你说什么，更重要的是，这会大大减少你们在交流沟通中的误解。所以，熟知你所在的行业，熟悉他们的业务，如果你要开发财务系统，请去阅读财会相关书籍，如果你要开发ERP系统，请去和工人师傅、基层管理人员多聊聊，在拓展你领域的同时，也会让你对你的编程思想有新的看法。

在与代码打交道的时候，你需要是一个好的建筑师，你应当构建严谨、运行健壮、可扩展性强的代码，这要求你在充分理解需求的情况下，看到需求的发展方向以及需求中可能发生变动的情况，甚至你需要和产品经理、客户去沟通，提出你的想法，当你问道“我觉得这里这样做的话，系统可能存在不稳定的因素，如果怎么怎么样做，不仅系统稳定了，您的操作也会更方便”，客户恍然大悟，你又减轻了工作量，何乐不为呢。

在理解需求、分析系统时，我建议你首先这样做：

将系统中存在的活动者都列出来，然后依次列出他们的操作功能和反应。

比如，一个简单的文章系统，我们可能这样去描述它

普通用户：注册、登录、找回密码、修改个人信息、查看类别、查看文章、查看某个类别下的文章、输入关键字搜索文章、发表评论、当别人发表对自己评论的回复时收到邮件。
管理员：查看用户信息、CURD（Create-Update-Read-Delete）类别、CURD文章

在上面的需求描述中，涉及了两个活动者，分别是“普通用户”和“管理员”，同时两个活动者都有若干功能，其中“普通用户”的“当别人发表对自己评论的回复时收到邮件”实际上不是用户的主动操作，而是用户对某个操作的反应，需要注意的是，这样的信息也需要在需求分析中体现。

需求分析可以体现为UML用例图，其好处是更直观，同时由于是统一化的表达，更有助于沟通，其他程序员可以更方便的理解你的意思，而不容易出现理解误差。

关于UML用例图方面的内容，可以到http://hi.baidu.com/jyangstu/blog/item/5d2f89131ef270c6c3fd7833.html查看一份简介。

我的需求方法实际上是用例图的一个超级简版，这个方法不能体现活动者与活动者、用例与用例（就是活动者所做的那些事情）之间的关系，一般适用于小型项目或大中型项目的模块级需求分析，对大中型项目的整体需求分析，实际上是一个非常复杂、有机结合的多个过程的系统，以后有机会我们再探讨。

北海公园游记

hanguofeng — Tue, 03 Mar 2009 01:48:25 +0800

周六晚上决定出去逛一下，毕竟的确有一段时间没有出去玩了，自己的、或者公司、学校的事总是一件接着一件，it’s OK。

周日起来，洗了衣服，再慢慢等它们变干的时候，已经是下午两点多了，匆忙查了路线，又步行一段距离，到了北土城坐奥运2，没有想到会在鼓楼附近堵了将近20分钟。到达北海公园的时候，已经是三点多了 -。-逛公园的貌似很少有这个时间的吧。

想去北海公园，主要是因为从小的时候就一直在听“海面倒映着美丽的白塔，四面环绕着绿树红墙”，可是来北京这么久，还一直没有去亲眼目睹下这美丽的白塔。

到了公园，买票进了大门，豁然开朗的是一片蓝蓝的。。。湖。很多人站在湖边，举起手机、相机狂派，于是我慢慢从很囧的“修水管”的工具包里面掏出相机，挂在脖子上，然后慢慢靠上河边的围栏，开拍。

蓝的逼人眼的湖面上，波光荡漾，倒映着一座白塔，水中的白塔和天上的白塔相映成趣，仿佛一个可以对折的世界。

然后随着人群，漫步过桥。

过桥后，俨然是另一番景象，一座亭子中，一些老人在欢乐的歌唱着，他们自己吹拉弹唱，吸引了很多游客，看着一曲结束后，他们脸上会心的笑容，我感受到，这才是平和的和谐社会。

一曲终了，依依不舍的再往前漫步，就到了永安寺，永安寺是一座黄庙。穿过永安寺的后门，便来到了一列台阶前。

拾阶而上，到了白塔，近看白塔，威仪壮观。

被白塔震撼后，慢慢下山，便来到了太液池旁，事实上，才看到了真正的北海全貌，夕阳下的白海，显得格外静逸，一抹夕阳洒在水面上，波光粼粼的阳光的碎片让人沉迷。

夕阳的水面上，归巢的水鸟自在游弋，如果看到这一幕，我想你的心境会不自主的平静下来，在这片喧嚣的都市，竟然有如此宁静的一片桃源。

想想最近的生活，很多忙碌，却有很多的进步，然而却总是缺少坐下来静静思考的时间，人，是需要经常思考的，不是吗。我的朋友们，不要为你们现在的忙碌而抱怨，不要为你们现在的迷惘而失落，生活本如此，既然未来是光明的，那么我们为什么还要低头沉浸在自己的影子中呢。

反思之我（们）需要什么样的IT书

hanguofeng — Sun, 22 Feb 2009 23:02:09 +0800

他们没有关注的需求

发现现在除了JSP和.Net之外，例如php、ruby之类的，还有js，甚至css、html，都没有人讲过在企业化开发的时候，这些东西应该遵循什么样的模式，达到高可用性和对需求变动的敏捷性。

PHP、ruby、JS可能还好一些，但是CSS和HTML这些的可重用性，和对需求变动的敏捷性，讲的太少啊了，单纯说可用性、语义性，都是针对单个来讲的，而没有谈到比如说淘宝、搜狐这样的大型网站，他的CSS和页面如何重用，这应该是一个不小的话题。

按照柱子哥的思路做东西，就发现我以前从来没有这么做过事情，也没有网上的教程或者书籍告诉过我，基本上都是在讲，一个人的时候怎么开发，也没有过多考虑需求变动导致的影响。
我相信随着当前互联网形式的进一步推动，人们会逐渐重视这些方面，同时这样一些东西可以把原来二把刀的程序员，培养成可以胜任企业开发的人员，给大型网站或者大型公司做开发，也解决了很多实际的问题

如何让读者理解

单纯告诉你去如何做，和没有告诉是一样的，因为每个人都希望固守自己之前的方式，除非你明确指出了它的缺点，并让他实际感受到他固有方式的不便和新方法给他带来的实惠。这恐怕真的得用例子来带来共鸣。

玄猫的窝

立秋++++

随机内容

夏·恐惧·变化·解耦

随机内容

LazyLoad Girl On Marriage

随机内容

听小韩聊PHP项目开发(3)–切分你的系统

1、为什么要切分你的项目

1.1、控制进度

1.2、应对变化

1.3、简化逻辑

1.4、代码复用

1.5、分工协作

2、如何切分你的系统

2.1、横向切分

2.2、纵向切分

2.3、混合切分

2.4、切分粒度

3、切分案例

3.1、一个CMS系统的切分

3.2、一个博客系统的切分

3.3、一个校内网APP程序的切分

4、切分作业

相关内容

Singleton.Lover

随机内容

北京·冬·有雪

随机内容

parseInt bug in firefox 3.5.2

随机内容

听小韩聊PHP项目开发(2)–观察你的项目

1、为什么要观察你的项目–需求的重要性。

2、我要观察到什么–什么是需求

3、我没有马王爷的第三只眼–那么我如何分析需求呢

相关内容

北海公园游记

相关内容

反思之我（们）需要什么样的IT书

随机内容