软件开发方法的探索[1]

来到公司后，发现几个问题：

1 需求经常变动，而且变化经常扩散到相对比较稳定的framework层。

2 某些同学在开发过程中，大部分都是接手既有的或者老的代码，没时间没信心没胆量去修改既有代码，只能在上面修修补补，这种后果就是代码僵化，改动及其困难。

我承认开发过程中有些东西确实之前就比较stink，但是我实在不愿意在烂泥塘中挣扎，我要从这里解脱出来。所以我就想花一些时间来关注来思考这个可能在很多公司都存在的问题。

目前我只研究了下敏捷开发中部分理论，例如重构和TDD，在具体技术上我没有深究，而是想讨论下它们会如何引导我们从泥塘中出来。

先把最近学到的这些知识整理下。

敏捷开发：对其中的流程有一些掌握：

1 整理需求：

  先由产品经理（不一定）等组织用户需求，或者老板直接派发需求。关于需求方面的采集和梳理工作有很多专业的方法和工具，例如问卷调查，用户访谈等，工具有CRC卡等，反正目的是要真正理解用户需求。对于我们来说，更重要的是要和开发团队确定需求的优先级，例如先实现性价比高的。有些难度特别大的需求可以放到后续来做。-----基本上所有公司都是这么做的，但对目前我们来说，最重要的是要合理得确定优先级，当然经验也很重要，例如有些功能实现起来难度会比较大，而这个是新手很难确定的。

2 开发团队分解需求：

敏捷开发强调的是团队作战，充分尊重和信任团队成员。需求分解成一个个任务，由团队成员根据自身特长（例如在UI开发比较精通）或者兴趣来认领任务。在这个过程中，比较重要的一件事情是要评估和计算任务完成时间。最开始接触一个东西可能没有经验，不知道完成它需要多少时间，但随着经验增长，完成一个东西就知道需要多少时间了。敏捷开发用点数来评估开发时间。一般选择一个比较中规中矩任务完成时间作为一个单位点数，其他任务的完成量是这个任务的几倍就是几个点。说实话，点数的作用还是在于方面管理开发中的时间成本。

另外，在认领任务的时候，其实也希望团队成员能够认领不同的领域的任务，这样可以保证知识在团队内部共享。--》说实话这个操作是很难推行的，首先成员需要有足够的信心，上进心。另外要克服任务完成的压力。团队领导需要做的是鼓励并有该领域的专家成员引导。团队整体知识水平的上升关键是在知识共享和专家成员的指导。

在开发过程中，要鼓励团队成员之间的交流，例如开站立会汇报进度，报告当前任务完成的状况，遇到哪些困难，有什么有难度的地方，有什么不足之处都可以拿来说。但是一般鼓励站立会的时间是15分钟，有点短。其实我最想看到的是每个人能够时时总结自己的代码。---对，就是重构，再次解释下重构的定义：

在不改变程序外在行为的情况下，对程序内部结构

进行不断改进的过程

重构就是使得代码变得更优美，更灵活。重构是不能影响程序行为的，即改了一个东西后要保证行为不发生变化。如何保证？要么是再次测试下，要么是使用测试工具（每次重构完都测一把，所以自动测试工具很重要）。

如何改进软件？不不如把它看做是优化，因为感觉大家对优化的重视程度远高于重构！提到优化，大家就会卯足了劲去修改和整理。（其实重构比优化更加重要，一般来说优化是指提高运行速度之类的东西，而重构是是代码更加灵活，更加适应变化，更加稳定）。

重构有很多方法，不过我目前感觉都是大量使用设计模式来适应变化，看看android里边那么多的类，接口就知道为什么了。这个对软件开发人员要求确实很高，除非代码量在10w以上，才有可能被缺乏设计模式的代码困扰，才有可能去主动思考问题，才会感到迷惑。我之前三年工作，大概在第2年的时候感到迷惑，但是一直不知道怎么解决，当时很想知道为何java中会定义那么多名气取得怪怪的类和接口。第三年的时候偶然有几个机会接触到design patterns才彻底大彻大悟了。软件结构，这就是构造软件的结构！！！非常重要。

好了，废话太多了，继续敏捷开发。

一般开发团队的一次迭代时间是2周，在这两周内，需要冻结需求的提交，也就是用户可以提交需求但是得到下一次迭代时间了。（现在不明白用户如果提的需求是改进方面的需求，例如之前想到这个功能的UI是这个样子的，后来觉得那样更好，是否应该提交到这次迭代呢？？）

一次开发迭代完毕，需要尽快发布一个东西让用户看到，让测试人员，产品人员及其客户尽快评估这次迭代的成果，如果有不满意的话，可以尽快反馈。（其实敏捷开发就是把之前的瀑布开发分割成几个小瀑布，关键思想是把一个个小成果给用户看，从而快速获得反馈。---软件行业直到很久才达成这种共识，在我没投入软件行业的时候，基本上干任何事情都是这样做的）。

敏捷开发希望团队开发的时候保持高效率，通过合理安排时间来完成任务，提高效率。说实在的，这个对个人素质要求很高。例如他做事情是否有条有理，是否有进度跟踪，计划性是否强。但是这种东西可以培养的，例如每个人早上到公司的时候，第一件事情应该是给自己今天要做的事情进行规划，比如上午完成什么，下午完成什么。---》我从初中开始就是这么安排的，每天有每天的安排，精确到分钟，每周有总结，几年下来光计划本就有好几个。有空拿来展示下。我现在做事基本也是这么做的，每天都有计划安排，好处很多啊，计划好了就不不感觉到压力了。而且在做总结的时候可以很轻松得看到自己到底做了什么。当然，计划部一定是那么得条条框框，可以写点总结，感想。我的计划就充满了总结和感想。这个过程是一个思考和回顾的过程，一定要思考和总结才能引导今天该怎么走。

当然，保持高效率的另外一个办法是不要老加班，要在平时工作中引导合理规划，提高工作能力和水平。说实话，加班的时间不确定，加班的效率没保障，加班的心情不好说，所以我严重怀疑加班的效果，而且中间总得休息一天，到头来都忘光了！当然，在项目快结束的那段日子里是可以安排加班的，因为这个时候都是一些小bug，而且大家经验也丰富了，要面对的问题更加集中了，这个时候加班的目的更加明确，当然压力也更大，所以加班的效果会比较明显。但平常的加班的效果确实需要考察下，加班安排确实需要更加合理。---一定要提高工作效率！！！提高技术水平，提升团队力量。

今天先写到这，后续还要结合更多的知识来对这段时间的学习进行整理。