读XP系列图书有感(200分)

战

战鹰

Unregistered / Unconfirmed
GUEST, unregistred user!
前两天在书店看到了邮电出的那套XP系列丛书，于是咬牙买下，虽然打折仍然花了将近300块，当时那个肉痛就别提了！
回来以后没什么时间看，最近才有时间，挑了两本最薄的看了看！现在发觉这钱真的不白花！虽然翻译的水平很烂！
但这里面的内容太好了！
其中几点我认为是大家非常渴盼的：
1。每周工作40小时，如果加班应该补充休息时间！
2。文档为交流服务，如果你能很好的交流责文档是不必需的，因为源程序是最好的文档
3。用最简单的办法实现需求
4。先测试后编程
。。。
有些方法是我在看这些书以前依靠自我的感受自己就已经采用过了的，比如先测试后编程等。
原来还以为这种做法不够正轨，现在才发现原来是这么的美妙！
 
??怎么先测试后编程啊?你不编怎么测?不懂请举例,谢谢　
 
这里假定我们都没有使用过“按钮”控件，但在程序中客户要求使用按钮控件，而且要求鼠
标在按钮上经过，按下，抬起，以及右键点击都有不同的效果，且个个按钮间存在一些逻辑
关系，这个时候您就需要一个测试单元用于测试按钮的按下，抬起，右键点击以及各个按钮
之间的逻辑关系。只有测试通过以后才可以正式的进行编码。
而我们在学校里面学到的通常是写完了程序再去测试！
 
哦你是说先写测试程序啊,那何不用BOUNDERCHECKER,或那个SOFTICE去测呢?
 
你说的这套XP系列的全称叫什么?
 
你说的这套XP系列的全称叫什么?
 
作者？
 
XP编程的核心：测试先行！适合轻量级开发，我们已经培训过了
 
这书真有那么值的看么？
 
人民邮电出版社
XP系列丛书
《解析极限编程-拥抱变化》
《规划极限编程》
《极限编程实践》
《极限编程研究》
《极限编程实施》
很值得读！不论你是一个程序员还是软件公司的老板！
另外我认为极限编程不仅仅适用于轻量级的开发，重量级的同样适用！虽然极限编程中不提倡大
规模的开发团队，但是不等于不可以讲整个开发任务分解为若干个开发任务分散到多个团队中间
去！而每个开发团队又是其它团队的客户。
至于测试，我所说的不过是一个例子，你也可以使用任何你可以使用的测试工具！但要记住对任
何一个部分都要测试！不要因为测试起来有些麻烦而将其省略，不然你的麻烦会很多，我们以前
的教训实在是太多了！
虽然目前有很多测试软件，但是大多数的情况下进行单元测试，恐怕还是要自己编写测试程序！
 
我看我也要去买了1
 
XP的四个准则：
* 沟通
* 简单
* 反馈
* 勇气
1.沟通
极限编程的一个准则就是沟通。项目中出现的问题无一例外的不是因为沟通不足而引起的。
这里所说的沟通不仅仅包括小组内部成员之间的沟通，还包括与用户的沟通，以及管理者
与开发成员的沟通。而我们通常意义上的开发文档的标准化的目的也是为了改善开发人员
与用户以及公司的管理者之间的沟通，但事实上我们通常所搞出来的开发文档根本做不到
什么改善，往往是增加了工作量，反而导致了沟通的不足！
而极限编程提倡的是面对面的沟通，且并不局限于某种头痛形式。只要你能够与开发伙伴，
客户，管理者进行很好的沟通，那么开发文档是可有可无的。
同时极限编程的团队里面会有一个“教练”帮助大家进行交流与沟通，他的任务就是观察
大家什么时候没有进行沟通，然后提醒大家。
2。简单
这是极限编程的第二个准则。前面提到的“教练”会问整个小组“什么是能完成功能最简
单的东西？”我们没有办法预料明天会发生什么，所以我只考虑眼前的事情，根据客户的
要求用最简单的办法完成功能，不要过分的考虑以后的扩展的问题。那个是无法预料的事
情，你的任务是先完成这个项目，如果这个项目被取消了也就没有扩展的可能了！
极限编程认为今天作的简单一点，然后在明天需要的时候再多花一点时间修改，比今天做
得很复杂，但以后再也用不到好的多！
3。反馈
其实我认为这个准则是对测试先行的一种体现（也可能是我理解的问题）。反馈其实是指
对系统当前状态的具体的反馈信息，这是极为宝贵的信息，我们写程序的时候往往会充满
乐观的情绪，有的时候我管这种情绪叫“开发激情”，以前我认为没有这种激情开发是无
法继续的，但是现在看来盲目的“激情”是一个巨大的隐患。但“反馈”则是消除这种隐
患的最好药方！
这种反馈应该是经常性的，而且不局限于某些规模，随时发现可能出现问题的地方随时进
行反馈，程序员为系统中所有可能出现问题的逻辑编写测试单元，并进行单元测试。反馈
可以让开发团队以及客户和管理者清楚的知道目前的开发进度与情况。同时也可以加强团
队成员之间的沟通，因为一个可以体现你的代码错误的测试单元，比和你讨论上2个小时
更能说明问题。而同时反馈也要从前面的“沟通”和“简单”里面受益，因为沟通充分，
你就知道应该测试哪里，应该怎么测试；因为越简单你的测试也就越简单越容易。
4。勇气
勇气是什么？我发现我们以前的一些开发任务中竟然能够容忍问题的存在！这就是缺乏勇
气的体现！在开发过程中我们不但要有消除问题的勇气（也可能很麻烦），还要有放弃掉
原有的代码的勇气，当你发现不论你怎么修改一个程序都问题不断，而你放弃掉他用1天
的时间重新编码解决掉所有的问题，并且这一次更简单更清晰，你选择哪一种呢？这种事
情我以前是遇到过的，我选择了后者，而且是不止一次！
 
up
 
>>每周工作40小时，如果加班应该补充休息时间！
搞对程序员来说， 这可能吗？ 这是不是太幸福了！
 
超负荷的工作容易消耗掉开发人员的最具有创造力的脑细胞！我们需要的是开发效率，
而不是开发时间！
 
虽然我们公司刚刚用上了UML。但我觉得XP的理论也有很多可取之处。很是赞同的它的几点核心。
 
象双人编程、单元测试、先测试后编码等等这些可以尝试来做。但需要大家（公司内部）的全力配合。
但xp要求客户在现场－－这个恐怕就没几个公司可以做到。

》》超负荷的工作容易消耗掉开发人员的最具有创造力的脑细胞！我们需要的是开发效率，
这句话对开发经理说，他也许理解你，但对项目经理或者老总去说，呵呵～～恐怕。。。
 
>这句话对开发经理说，他也许理解你，但对项目经理或者老总去说，呵呵～～恐怕。。。
深有体会，我曾经和老板说过许多次加班的恶果，可是...
 
其实老板有的时候就是脑筋转不过来罢了，其实这套书如果给你们的老板看完以后，
他立刻就换来推行极限编程！
极限编程的思想是极大的发掘员工的工作积极性，其中关于加班的事情是因为，再
极限编程的团队工作的压力下，程序员会不自觉地进行加班，而老板（领导者）为
了保证开发效率的持续应该保证员工的工作时间每天不超过8小时！
即便偶尔有加班也要保证时候给与一定的休息时间！
至于现场客户虽然难于达到但也是我们目前的项目容易出现问题的地方，我们的很
多问题都是客户与开发人员沟通不足的结果，如果客户不能来，我们的技术人员可
以去嘛！别嫌麻烦，如果你嫌现在这点小麻烦，可能会导致以后的大麻烦！
至于uml，xp并不是绝对的排斥uml！但是他排斥为了uml而uml！这正是我们很多国
内公司正在做的事情！uml的目的是为了沟通方便，但是如果我们有了更好的沟通手
段那么uml就不是必需的！
 
不错不错，只是在书店没看到这套书，要不早就买下了！
 
您必须登录或注册才可回复。

Similar threads

S
[教程]FMX中实现图片素材形状剪裁
回复
0
查看
238
swish
S
S
[教程]使用 ZValueWatch 在主线程中监测值变化
回复
0
查看
239
swish
S
S
[教程] Delphi Android aab 转换为 apk 工具
回复
1
查看
423
marij
M
不
移动查房系列 - 不得闲
回复
0
查看
514
不得闲
不
不
Python 的 Magic Methods 指南(转) - 不得闲
回复
0
查看
684
不得闲
不
顶部