现在感觉自己废话很多。 有些自觉经典，但却没有记录下来，可惜。

最近感觉数据结构应该教授些精髓的东西而不是去教应该怎样编程，或者讨论这段程序到底是干什么的。

现在问些数据结构的东西。大家看看能不能答上来…

1为什么顺序表比二叉树的查询速度慢？

2到底什么是栈，什么是队列，什么是树，什么是图，什么是堆？

3用数组到底能做些什么事？

4链表在哪些方面优于数组？

5为什么快速排序比冒泡等低等排序快？

6在现实生活（计算机世界）中用到了那些数据结构？

7如果碰到一个棘手的问题（如路由算法）你能不能想到可能要用到什么样的数据结构解决？

没有答上以上问题没有关系，因为还可以学习。。。。。。

在C#的后台代码中写入

1
2
3

this.ClientScript.RegisterStartupScript(  typeof  (Page),  "JavaScript",  "<script>window.close('StateChangeApply.aspx','','left=0,top=0,scrollbars=yes,width=600,height=500')</script>" );  

可以防止页面变化

在删除一条记录时有可能遇到一条记录已经被关联外键，那就应该将它其中的一个字段单独拿出来做标记，在程序中判断是否被删除，否则就真正的删除它。

使用try{}catch(){}方法。如果首次删除不成功，系统就会抛出异常，然后转到catch中，在其中的程序段中将其中的一个字段单独来做标记。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public  bool  DeleteDevInfo(String  deviceID)  {  


    bool  delete  =  false  ;  

    try  {  

        try  {  

            delete  =  SQLHelper.ExecuteCommon(CommandType.Text, DELETE +  DEVICE_ID +deviceID,  null  );  
        }  catch  (Exception e)  {  

            return  SQLHelper.ExecuteCommon(CommandType.Text, UPDATE_DEVICEID +DEVICE_ID + deviceID,  null  );  
        }  

        return  delete;  

    }  catch  (Exception e)  {  
        throw  new  Exception("删除设备台账时失败!");  
    }  

}

这里的SQLHelp类似于petShop中的Uility层中的SQLHelp，封装了底层于数据库的交互

不要在后台代码里的Respose.write();中写javascript脚本，这样有可能会影响页面显示的效果。

使用GridView，在其中添加模版列，在html中写入：

1
2
3
4
5

<asp:TemplateField  HeaderText  ="修改">  
<itemtemplate>  
<a  href="#"  onclick='<%#string.Format("GotoModifyDevice({0})",Eval("deviceID")) %>'>修改</a>  
</itemtemplate>  
</asp:TemplateField>

这里的Eval("deviceID")
中的deviceID必须是GridView中的一列的dataField。

在javascript脚本中写入：

1
2
3

function  GotoModifyDevice(deviceID)  {  
    window.open("设备修改.aspx?deviceID=" + deviceID,"_blank","toolbar=no,height=500px,width=600px,resizable=yes,scrollbars=yes");  
}

添加一个模版列，编辑模版列，并加入一个linkButton ，在onClientClick中加入JavaScript:returnconfirm('你确定要删除该行记录吗？');

在html中找到那个模版列在其中加入这个属性CommandArgument='<%# Bind("ID") %>'

选中LinkButton的事件在Command项中写delete然后在后台代码中这样实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

protected  void  delete(object  sender, CommandEventArgs e)  {  

    string  ID  =  e.CommandArgument.ToString();  //  得到该行的ID值（如果你下面的调用是通过ID来删除的话）  
    if  (deviceInfoBLL.Delete(ID)) {  //  这里是调用下层的删除方法  
      

        init();  //  初始化页面  

        Label_warning.Text  =  "  删除成功，编号为：  "  \+  ID;  
    } else  {
        Label_warning.Text  =  "  删除失败，编号为：  "  \+  ID;  
    }

 }

完成

快要做完项目才发现真正的需求不是这样子的。快要做完了才发现距离需求还差很远。

项目进行中四个小组都做了需求分析，可是很可惜各有各的需求。到项目整合的时候才发现项目中的需求并没有整合。结果大家做的都乱了。最后功能只是刚刚满足需求。

详细设计这是能搭一个比较详细的框架，而这个框架在日后的编码过程中肯定要在做改动。而且有可能做大的改动。没有想到的场景，没有预料到的情况，怎么可能有人详细设计写好了就不用改了呢？至少现在的软件工程水平还做不到这一点。

项目的感悟到不是太多。找到的需求漏洞倒是很多。听小宁讲的人生哲理倒是很多。正如老边所说：“不要指望一门课能是你成为编程的高手，或软件工程中的专家。”学到的softskill感觉还是挺有用的。至少知道怎样和人们沟通了。嘿嘿

极限编程

极限编程又称xp方法，是敏捷开发的软件过程模型。

极限编程的4条准则：沟通，简单，反馈和勇气（修复缺陷，集中攻关和放弃原有的代码）

基本原则：快速反馈，假设简单，递增更改，提倡更改，优质工作

开发软件的4项基本工作：编码，测试，倾听和设计

首先使用计划游戏，根据功能的优先级和实际进程来决定游戏的玩法，并只是制定下一阶段的计划，希望程序员主动的接受责任，并对预期实现的时间进行估计。

不断发布小版本（小但是有价值）。使用隐喻，用有关整个系统如何运行的简单、众所周知的故事来指导所有的开发。使用的是简单的设计。

通过测试来增强运行程序的信心，测试包括程序员进行的单元测试和客户方进行的功能测试，程序员们编写的每个测试都必须是独立的、自动化的。

通过重构来简化程序并提高程序的柔性。

采用结对编程，结对编程是xp方法的实践过程。代码归集体所有，防治复杂的代码进入系统，系统中不能包含重复的代码（有且仅有一次），系统拥有尽可能少的类，拥有尽可能少的方法。

持续的集成，每次集成都要完成一项任务。

规定每周工作时间是40个小时。要求有现场客户，要求使用统一的编码标准。

分阶段的交付产品，进行迅速而具体的反馈，清晰的参赛系统的业务要求和为特殊任务配备的专家。

在xp中，团队负责体系结构。Xp不注重体系结构，但有几点机制可以确保它的实现：探究、隐喻、第一次迭代、小版本、重构和团队实践。

Xp方法一天的开发流程是：

1. 确定问题和解决问题的人。

2. 配对－快速设计会议。在战略上选择伙伴，战术上考虑选择输入编码的人。并周期性的交换角色。

3. Test，Q&A。在编码之前验证测试失败，测试可能出错的地方，如果不明确答案是什么就询问客户。

4. Refactor。找出“代码的味道”（感觉不对的地方）应用重构，验证单元测试，并使其依然通过。采用小幅度改动，每次行动后都要做单元测试。

5. 集成或丢弃代码。将集成的代码生成系统，运行所有的测试，测试必须全部通过。如果不容易集成到过去的代码中，就丢弃它，明天重试。

结对编程，有利于团队成员间的互相学习。结对编程的伙伴不仅要求人在现场，而且更重要的是对任务做出承诺。伙伴能帮助保证团队的价值观不被忽略。伙伴允许你做必须做的事，这也许意味着丢弃代码，保持学习，并从头开始。

结对编程弥补了键入代码和大脑高质量思考的矛盾。因此而导致了高质量代码的快速产出。国外的结对编程经验表明追求完美的开发人员与多产的开发人员结对的效果最好。

Xp的方法提倡为了胜利而比赛。人们喜欢胜利，喜欢学习，喜欢与别人交流，喜欢成为团队的一部分，喜欢将事情控制在自己的手中，喜欢受到信任。喜欢出色的完成任务。喜欢使自己制作出的软件发挥作用。

Xp方法的好处：

1. 有利于团队的整体进步。

2. 不会因为一两个人的离队而使项目停滞不前。

3. 开发过程带给程序员快乐和趣味。

4. 开发出来的项目有质量的保证。

经过自己使用xp管理团队管理的一年的实践过程中发现， Xp方法不适用具有一下特点的团队：

1. 还没有任何编出一个项目的团队。

2. 团队中多数人并不理解xp的方法。

3. 团体中的编程人员不愿意交流。或有些编程人员希望自己独立写代码。

4. 设计未动，开发先行的团队。

5. 团队中多数人并没有学习必要的软件工程知识。或不重视团队的重要性。

6. 成员没有掌握足够的技能来评估自己的代码，或做必要的测试。

7. 成员中没有人能知道自己要实现的功能将会花费多少时间。

8. 没有充足编程时间的团队。

同时也发现xp方法不适用的项目：

1. 没有客户方积极参与的项目.
2. 复杂而庞大的项目.
3. 有“高科技”攻关的项目.
4. 项目组不熟悉的项目类型.

1. 不要老说一个人或者一个部门工作有问题。经常说出问题正是因为那个部门或那个人经常干事。没有干事就不会有错误。
2. 重视自己的部下，不管他们做的怎么样。他们都在努力。
3. 鼓励周围的人多提意见，不过意见有没有用处，都会给部门带来好处。
4. 和部下多交流，没有交流思想就不能流通。没有人理解自己，自己的任务就能很好的完成。
5. 不要让部下们干连自己都不愿意干的事。

一个好的团队，需要全体人员的配合。不是志同道合的人，就不该加入到团队中来。没有共同的目标，什么事情都会受到阻碍。当团队中出现可以依赖的人的时候，就是团队开始
有凝聚力的时候了。把工作拆分，然后交给可靠的人来做，将节省自己很多时间。

1. Strong man stands up for himself. The Stronger man Stands up for others.
   强者保护自己，更强的保护他人。 我们每个人都希望成为强者，希望鹤立鸡群。但是这之后呢？有没有想过为别人做点什么呢？

2. Everyone can help you in particular time.
   结交的每一个人都可能在特定的时期帮你一把。有时自己感觉结交了些朋友。但感觉他们的用处不大。但是请记住上面的那句话。每个朋友都有帮你的时候。

3. Team Work can deal with trouble which one cannot deal with.
   团队能解决一个人不能解决的问题。当我们忙不过来的时候，有没有考虑一下团队协作。将任务拆分交给团队来处理，即使团队还不成熟，也可以帮助自己解决一些棘手问题。记得一个问题：当中午吃饭的时候，上面派给你紧急任务，要你下午几点完成。这时你将怎么处理？最佳答案是：吃饭的时候简单拆分下任务，和自己的同事们一起完成这个任务。

片名： Barnyard: The Original Party Animals
译名： 疯狂牧场/疯狂农庄
导演： 史蒂夫·奥德科克 Adam McKay
配音： 凯文·詹姆斯 Kevin James
萨姆·艾略特 Sam Elliott
丹尼·格洛弗 Danny GloverSacha Baron Cohen
科特妮·考克斯 Courteney CoxGary Cole
类型： 动画/喜剧/家庭
片长： 暂无
级别： PG级
出品： 派拉蒙
上映日期： 2006年8月4日

工作是为了吃饭，吃饭是为了更好的工作。或者换过来说：吃饭是为了工作，工作是为了吃更好的饭。

先进的未必是最好的，更未必是成功的，谁死在最后，谁就是王者