白衬衫，蓝色忧伤...

开来lz的经历和我有那么点相识，楼主过了高程，应该对于软件开发方面的掌握了解程度应该不错的了，对于软件开发方面的东西，我在大学的时候为自己定下来的学习步骤是http://www.google.com/notebook/public/16823344988613088871/BDQ9jIgoQ_c3s_p4j的工欲善其事必先利其器，当然这是我所认为的合理方式，多年来我一直遵循这样的基本原则来学习，你不妨也规划一下适合自己的方式。值得一提的，软件开发绝对不仅仅是spring，struts，hibernate之类的东西，在我看来这些根本算不上软件开发的技术，实际上只是相应技术理论的一种开源实现方 ...

进入论坛招聘求职版

2008-06-26

全文显示

回复: 如果你是我，你会怎么办（请和我有类似经历的人指点迷津）

偶也在离职中，一般来说，申请离职之后就是开始工作移交了，不应该再有新的工作任务，我申请离职之后，ld还是安排新的任务，后面我就直接找他谈了，坚决不接受新的工作任务，只进行工作移交。而且，想想看，如果一个员工都打算要离职了，如果ld还安排新的任务给他，只能说明那个ld很蠢或者就是这个公司本来就很糟糕。应该说申请离职的那个月应该是比较轻松的，然而刚刚加入一个公司的三个月应该是比较辛苦，比较累的。然而有些公司在员工申请离职了，还是希望那个月好好利用这个资源，这种做法很不明智，一般申请离职的员工，很少再有心思把新的工作做好，除非这个员工非常的有责任心。所以，对于申请离职的与员工，应该仅仅进行工作交接， ...

进入论坛招聘求职版

2007-09-20

全文显示

回复: 这样的TDD实践方式有问题？请教大家的TDD实施方式.

daquan198163 写道对重构的理解确实有误沟通能力需要加强一下，共勉感谢daquan198163的指点，的确我对重构理解确实有误，其实这个问题主要也再于重构，这几天仔细思考了一下，也和一个同事讨论了一下，他认为其实测试代码中的字符串于产品代码中的字符串不属于重复，应该是产品代码里面的重复才算的上重复,仔细考虑之后，我很认同他的观点，实际上测试代码里面的对于产品代码来说只是输入和输出，他才不管产品代码是怎么实现的呢？所以应该在产品代码里出现重复的时候再考虑这样重构。而至于沟通嘛，再怎么强调都不为过，不断努力提高中。 Kent Beck先生的例子看起来虽然简单，但我认为那个确实T ...

进入论坛软件开发和项目管理版

2007-09-16

全文显示

回复: 这样的TDD实践方式有问题？请教大家的TDD实施方式.

此外，我声明一下，我发起本帖，主要目的就是寻找答案，讨论(借鉴大家的)适合的实践方式，如果哪位朋友不是为了讨论而来，请不要回帖，如果回帖，和该问题无关，我不会回帖，请谅解。对于不是为了讨论而来的朋友，我希望仔细思考Ilja跟你说的： Hai, I couldn't tell whether you are agreeing or disagreeing with my point. Please elaborate if you feel like it. Thanks, Ilja 最后，本帖在junit newsgroup上已经有了讨论结果，大家感兴趣的话自己去看，地址：http:/ ...

进入论坛软件开发和项目管理版

2007-09-16

全文显示

回复: 这样的TDD实践方式有问题？请教大家的TDD实施方式.

to gigix: 我承认我没你聪明，而且我还是有点傻，所以才会向你请教，:) 不过我发现，我的关注点好像一直和你都对不上号。也许这就是聪明人跟傻子的区别哦，:) 你实践TDD的方式的确和我的方式有很大的不同，不过很荣幸的是，从你的谈话中，我总能学到很多东西，非常感谢. 顺便说一句，我一向都很尊重你，尤其是你对软件图书行业贡献，:),非常感谢.

进入论坛软件开发和项目管理版

2007-09-16

全文显示

回复: 这样的TDD实践方式有问题？请教大家的TDD实施方式.

楼上的朋友，如果你认为我是来消遣你你可以不回帖，你也可以叫管理员删贴。对于你说的，在junit newsgroup上kent beck先生未进行回复，但是很多其他的朋友都回复了，就像testng的作者，Cédric Beust，Michael Feathers ，Jeff等等也都回复了，我倒是未见他们气死再气得诈尸，相反，他们却告诉了很多我想知道的东西。如果你想知道kent beck先生是否会如你所说，你不妨给他发邮件了解了解.

进入论坛软件开发和项目管理版

2007-09-13

全文显示

回复: 这样的TDD实践方式有问题？请教大家的TDD实施方式.

birdjavaeye 写道hyysguyang 写道那你为何不看看需求是什么，再这个问题上我的确钻牛角尖，也许这个例子非常的不好，我只是想表达的是，不要做不该做的事情，没有的需求永远不要去做，你认为应该这样的需求，客户未必会认为这样. 这个基本是合理的，没有提出来的需求没必要去猜测，在以后的迭代中发掘了需求可以再重构。 hyysguyang 写道一开始我就已经说了，不要跟我说需要转换其他句子(如果要说问题，问题应该是出在我应该去引导客户，需求是不是反正任意一个句子，我已经说了这是另外一个问题，和TDD没有任何关系)，就是在转换这个句子的情况下，我采用的TDD方式有什么问题? hyys ...

进入论坛软件开发和项目管理版

2007-09-13

全文显示

回复: 这样的TDD实践方式有问题？请教大家的TDD实施方式.

but I've also seen quite a few examples where TDD-written > > classes led to micro-design that forced a lot of refactoring to be > > made later as the complexity of the software grows. In particular, > > the idea to "do the simplest thing that can possibly work" can be > > dangerous, because sometim ...

进入论坛软件开发和项目管理版

2007-09-13

全文显示

回复: 这样的TDD实践方式有问题？请教大家的TDD实施方式.

hyhongyong 写道hyysguyang 写道我基本上在这里找到我要的东西: 我更确信：面对面的交流才是最直接最有效的沟通方式. 每个人有自己的开发方式，而实际上每个人的TDD也不一样，何必过分关注那么多细节，其实你们说的步骤我也在做。谢谢各位，本帖希望到此为止. 非常感谢. 不是测试官的需求有问题，是你对需求的理解出了问题。（确实太钻牛角尖了）不论是什么样的交流方式，总有一些基本的东西是大家共识的，这就是逻辑。测试人员让你反转一相字符串，其含义一般人也能理解是对一个字符串进行反转操作，而不是直接返回一个字符串。（比如让你写一个1+1等于2的东西，不能直接返回2吧，只能用+的方 ...