研发初期,允许自己写一些糟糕的代码吧
正文
大多数开发者都会对自己编写的代码有严格的要求,希望它结构清晰,易于阅读、易于拓展,优雅、健壮、且不会有bug...
这种追求本是好的,首先,是对项目的负责任,其次,从长远来看,它有利于开发者提升自身的技术。
但大多数时候,我们没有把握好时机。我们总是在产品的研发初期就刻意追求那种高质量。在经历了许多次挫折后,我想告诫各位,这种做法是错误的!(至少对于独立开发者来说)
首先,在产品研发的初始阶段,我们甚至连需求都无法确定下来,哪来的依据去编写优秀的代码,辛辛苦苦编写的或许只是海市蜃楼。
其次,在产品研发的初始阶段,会有许多次迭代:第一次编写原型、第一次测试、第一次修改;接着又第二次原型、第二次测试、第二次修改...如此反复多次。试想一下,如果每次迭代,都花费大量时间在代码上(最终很可能会被删除的代码),那这个产品的成型就会遥遥无期了。
可能有读者会问,在初期是不是就可以完全无视代码质量?
当然不是。我们仍需要凭借经验和直觉,先用最简单的方式去实现原型。而不用刻意去想得太长远(数据结构、数据库、算法什么的,可以满足当前原型就行了)。
当你觉得某部分代码,因为设计不当,放缓了开发的速度,你就得去重构这部分代码。
随着原型的不断迭代,需求逐步清晰。每次原型的迭代也伴随着代码的删除、局部重构。你会惊喜的发现心中对代码的模样也会变得愈加清晰。
慢慢的,在产品接近上线时,可以稍微向“长远”去考虑了。
总结
在写出高质量代码之前,让我们先把程序运行起来吧!
代码是实现目标的一种工具,它不是目标本身,我们的目标是解决问题,实现需求。当你写的代码无法满足需求的时候,它质量再高,也毫无用处。(另外需要考虑的是,一段没有解决任何问题的代码,用什么依据来评价它的质量呢?)
相关书籍
《游戏设计艺术(第2版)》,包含了许多游戏设计、研发的指导。 豆瓣评分 9.2
《游戏编程模式》 里面介绍了游戏开发的编程模式,但同样适合非游戏开发借鉴。在阅读该书的时候,可以体会到,每一种模式都有自己的优缺点,没有完美的代码,明显的优点同时也会带来明显的缺点,重点在于“权衡”,找到适合当前使用场景的方案。 豆瓣评分 8.8