细粒度的迭代计划到底要做到多细?

所以我才说,我接单的底线就是看项目内部有没有一个人能可以在最大限度内,自己完成这个项目.如果合作的好,我们就合作,大家可以提高效率赚到钱.如果合作不好,就让那个人单独完成好了,这样我们大家也不会赔钱.那些明明就会赔钱的项目,我才不会接.
当然有些公司为了市场或者品牌会做个别的招牌工程,但是这样的项目,我实在看不出会让这样一群人来做.
一个公司不赚钱不怕,怕的是不去想办法赚钱,而是想办法赔钱.
作为做技术的人来说,为人要圆滑的,做事情要圆滑点,因为技术上有很多变通的因素,而且很多东西就没有一定之规.但是这些圆滑都是建立在一个最基本的判断基础上,这个判断来不得半点圆滑.作为一个技术人员必须把对一个项目的成功可能性的判断,完整的报告给管理者,同时并且把这些信息明白无误地发送给市场人员.这是我们的本分.
其实做市场这个事情反倒是要实实在在的.一是一,二是二,是必须的.虽然语言表达可以有多种方式,但是对于事物的判断是没有半点的可以模糊的.如何才能让市场人员能够做到心中没有疑惑,关键就是技术人员能不能如实地提供自己的专业技术咨询.很多事情其实是你以前做了一个单,本来可以3个月完,可是你偏偏要说要一年.因此市场人员就会认真地认为(作市场的人都很认真,记忆力都好的惊人),其他你说的一切都应该是1/4真实.而由于有的公司绩效考核的问题,又造成了市场人员只管接单,不管是不是可以实现的情况.这就是管理的问题,是经营者自身的问题.作为技术人员,在这个时候最好的面对方法,就是采取甘地的不合作方法.

会重构并不代表重构的好,重构的不好还不如不重构,反而把事情搞复杂了

重构的不好还不如不重构。项目难做还不如不接。饭难吃还不如不吃。做人难还不如自杀。

blackhost
我倒想听听你的重构会怎么把事情搞复杂了.这个正是我最近一直思考而想不明白的问题,所以我特别迫切的希望你能说出几种情况来.当然如果做不到,举一两个例子也可以阿.

嘿嘿，想想没有单元测试的情况下，想想缺少版本管理的情况下
这是我所知道的一些说重构把事情搞复杂的项目的情况
其他的听听blackhost怎么说

如果重构很简单,侯捷也不用去翻译Martin Fowler的书来讲如何做好重构!另外大家还记得那个日本人和中国人的代码编写吧!不同的人重构出来的就大不一样,有的人函数名起得非常的直观,一看几乎就知道是干什么的,有的人起得非常的难懂和技术化,让人看其来很费解,费的去看他的代码体才知道他是想干什么?我觉得只是一个很小的例子,先不说类的抽象了,就拿一个函数来说吧,非常的长,有的人重构出n个小函数,但是函数名其的是一团糟,我需要看n个地方才知道他想干什么,有的时候还不如放在一起我逐步看下去.

为了怕大家误解,我再次强调我只是拿函数说明,不代表本人就认为重构就是函数重构.有什么错误的地方请各位大拿指正.

有单元测试也未必轻松,很多程序员不做回归测试,再加上测试代码写的有缺陷,重构后一看编译没有问题就过了.而且重构后,原来的测试规则还能否适合还难说,XP的确是个好方法,是个锻炼人的好方法,但是初期支出成本实在太高了.而且水平差的程序员的确需要很长时间才能适应.

你看，你几乎每次都是这样，别人说的东西没弄明白呢就开始批评了。咱就说简单的吧，不同人起名字水平不同，有人起得挺漂亮，有人起来就看不懂，还有人索性拿拼音当函数名呢，这么参差不齐的乱搞怎么行？特别是像你那个项目，有一位英文念不怎么顺口的，保不齐啥时候就操拼音上阵了，还有一位玩惯PB的，没准哪天又用上了PB的命名规则。你说照这样搞法，这团队还怎么合作？

所以咱们才要重构！你看见哪个名字不顺眼了，别客气，重构它——Rename Method。你看见谁的函数里搞一大堆参数了，别客气，重构它——Replace Parameters with Object。你看见俩人各写各的子类，两个子类有重复代码了，别客气，重构它——Pull Up Method。要是不做重构，你就得忍着这些千奇百怪的风格，大家各搞各的，而且还都自我感觉良好，觉得自己写程序挺厉害没啥问题。就是因为有了制度性的重构，大家才不停地反省自己：哦，这么起名字是不好看，那样传参数对象是比长参数列表要漂亮。这样才能提高水平呢。你不是最强调培养新人的吗？怎么培养新人？我看重构（和测试先行）就是第一课——o6z要说了，那持续集成就是开学典礼。这个第一课教他们怎么学习，有这个技能在手里，他们才学得快、学得好。

没有这种事。你改完代码往服务器上一提交，要是任何测试通不过，CruseControl马上发邮件灌爆你信箱，叫你想不改都不行。XP对人的要求严格着呢，别以为这帮牛仔真是大撒把的爱怎么玩就怎么玩。

这话说的好！
正在写个ppt，准备讲讲重构和单元测试，title就叫：软件开发入门