关于项目的一些思考

最近工作的一个iOS App,是第一次面对更像书籍中描述的开发环境。
不断变更的UI界面,交流无法及时,按照MVP模式进行iOS开发。这些简直是项目杀手,然而在这种情况下,如何做的更好适应修改才是需要关注的。而不是将一切都怪罪在那些模糊不清,并且不是由自己来控制的需求上。


  • 控制开发速度
    作为开发者,可能会喜欢展现自己的能力,通过编码速度和质量来炫耀自己的实力。也许提前完成工作是好的,留一些缓冲的时间是非常好的,但是在项目中,我们更加应该注重一个速率,如果冲刺的速度保持一段时间后,我们必定会出现减速的情况。

我们应该以一个合适的速度去进行开发,需要对每一个迭代做出计划,这样才能保证开发速度能够控制住,并且可快可慢,不然我们冲刺到项目后期时候,想要在提速完工是不太可能了,因为当前速度就是团队最快的速度了。

  • 解决问题
    代码中容易出现复杂状况的主要原因有3点:

1.用复杂的方法去解决简单的问题
2.用简单但错误的方法解决复杂的问题
3.用不恰当的复杂方法解决复杂的问题
(摘自《代码大全》)

我们在面对需求的时候,不要因为简单的Mock up就采用一些简单的问题,尤其是在MVP这种当下比较流行的思想影响下,我们早期编写的UI界面与最终结果可能千差万别,但是设计者和产品经理会认为走通流程更重要,但是他们并不知道,不同风格的页面会影响iOS使用不同的控件,而不同的控件,可能会需要不同的逻辑来处理数据,导致最终许多代码可能都无法复用。

这个时候,我们可能需要多问,多了解最终可能是什么样子的,如果是列表形态的,一定在早期就使用上TableView,而不是因为为了流程而只是简单的几个TextField或者Label放在那里,这种情况到后期几乎是重新编写代码。这已经不可能谈到重构了,根本就是重写。

  • 代码的归属感
    处于项目中的每一个开发者,都应该对代码拥有绝对的修改权,只要这样才能更加投入的工作,如果做任何修改都需要申请,那么就可能错过一些优秀的重构。

我们需要的是对修改后的代码进行审核,而不是强调在修改前的要求。(假设已经有了一套完整的规范)