qinysong
- 浏览: 190903 次
- 性别:
- 来自: 北京
-
最新评论
-
nfsfairytale：
求附件求附件
一种高效的寻路算法 - B*寻路算法 -
wafer1021：
想在服务端运用这种
一种高效的寻路算法 - B*寻路算法 -
zhezhelin：
最新代码有吗
一种高效的寻路算法 - B*寻路算法 -
zyh2018：
你好！很开心看到你写的B*算法，但是C++版本的代码看起来很吃 ...
一种高效的寻路算法 - B*寻路算法 -
asuralove：
学习了~~~~
一种高效的寻路算法 - B*寻路算法
我的论坛
认识到上面一点，我感觉应该回到本贴的主题上了，结对编程如何实施，如何最大的发挥它的优势和控制它的劣势，如何得到项目组成员及上层的认可
- 2006-09-23 00:40:02
- 浏览 28227
- 评论(35)
在上面我所表述的对结对编程的看法，之后我感觉是不是有些过于强调XP的整体性了，是不是有些过于强调关键实践之间的依赖性、相关性了？他们之间真的需要那么依依不舍吗？
后来在我的blog中，有网友如下留言：
引用提几点个人的看法:
1. 需求变化不大和时间比较充足, 应该也能够用XP, 我觉得并不矛盾. 当然对于大规模的项目, 使用XP的确会有点问题(可以分成小模块解决).
2. 结对编程对沟通价值的一个实践, 跟重构没有直接的关系吧.当然 结对编程有相互监督的作用. 我一个人写程序也经常重构, 是一个人习惯问题, 也许在些结对编程可以对此做监督.
3. 重构是对代码和设计的整理, 只要有写代 ...
- 2006-09-23 00:32:10
- 浏览 28227
- 评论(35)
上面写得太多了，好像重点不太突出了，我觉得是不是采用结队编程，一条关键的依据是：
判断我们代码需不需要重构，如果需要，结对编程就会提供很好的价值，包括代码正确性、严谨性、可扩展性等等，为代码的重构提供很好的基础，并且结队编程克服不想对自己代码进行重构的惰性。
如果判断我们对系统架构设计，有很成熟的经验，且需求的变更不会对设计造成太大影响，那么结队编程就消弱了存在的意义。
如果旁边有感觉不错的搭档，对于新的、陌生的问题特别是算法，我喜欢一起进行讨论。
比如有一次，对一个正方形路径遍历的算法解决问题，在正方形内，每条路径从起点（0，0）到终点（n，n）沿着从右向左，或从下到上行进，需求所有路径坐标 ...
- 2006-09-21 13:21:37
- 浏览 28227
- 评论(35)
结队编程是XP极限编成的一个关键实践，如果把结队编程放到整个XP里面会更容易体现出它的价值，所以我觉得分析结队编程的一个整体思路是：
1、适用场景：
XP的适用性在哪里，什么样的项目中适合采用XP，在这样的项目中XP可以起到什么作用。如果离开了适用场景，XP的适用性都要重新考虑，所以就更不用谈结队编程了；
2、实施条件：
从理论上我们面对的项目可以从XP那里得到很大的价值，但实际中我们的团队具不具备实施XP的条件，即并不是什么样的团队都可以采用XP，特别是结队编程；
3、结队编程的位置和价值：
结队编程在整个XP中的地位，它和其他哪些关键实践有着相辅相成的关系，它可以应对项目实施的哪些问题 ...
- 2006-09-21 12:04:54
- 浏览 28227
- 评论(35)