美文网首页
研发初期,允许自己写一些糟糕的代码吧

研发初期,允许自己写一些糟糕的代码吧

作者: 逆行ZJT | 来源:发表于2020-07-01 15:29 被阅读0次

正文

大多数开发者都会对自己编写的代码有严格的要求,希望它结构清晰,易于阅读、易于拓展,优雅、健壮、且不会有bug...
这种追求本是好的,首先,是对项目的负责任,其次,从长远来看,它有利于开发者提升自身的技术。

但大多数时候,我们没有把握好时机。我们总是在产品的研发初期就刻意追求那种高质量。在经历了许多次挫折后,我想告诫各位,这种做法是错误的!(至少对于独立开发者来说)
首先,在产品研发的初始阶段,我们甚至连需求都无法确定下来,哪来的依据去编写优秀的代码,辛辛苦苦编写的或许只是海市蜃楼。
其次,在产品研发的初始阶段,会有许多次迭代:第一次编写原型、第一次测试、第一次修改;接着又第二次原型、第二次测试、第二次修改...如此反复多次。试想一下,如果每次迭代,都花费大量时间在代码上(最终很可能会被删除的代码),那这个产品的成型就会遥遥无期了。
可能有读者会问,在初期是不是就可以完全无视代码质量?
当然不是。我们仍需要凭借经验和直觉,先用最简单的方式去实现原型。而不用刻意去想得太长远(数据结构、数据库、算法什么的,可以满足当前原型就行了)。
当你觉得某部分代码,因为设计不当,放缓了开发的速度,你就得去重构这部分代码。
随着原型的不断迭代,需求逐步清晰。每次原型的迭代也伴随着代码的删除、局部重构。你会惊喜的发现心中对代码的模样也会变得愈加清晰。
慢慢的,在产品接近上线时,可以稍微向“长远”去考虑了。

总结

  1. 在写出高质量代码之前,让我们先把程序运行起来吧!
  2. 代码是实现目标的一种工具,它不是目标本身,我们的目标是解决问题,实现需求。当你写的代码无法满足需求的时候,它高再质量,也毫无用处。(另外需要考虑的是,一段没有解决任何问题的代码,用什么依据来评价它是否高质量呢?)

相关书籍

《游戏设计艺术(第2版)》,包含了许多游戏设计、研发的指导。 豆瓣评分 9.2
《游戏编程模式》 里面介绍了游戏开发的编程模式,但同样适合非游戏开发借鉴。在阅读该书的时候,可以体会到,每一种模式都有自己的优缺点,没有完美的代码,明显的优点同时也会带来明显的缺点,重点在于“权衡”,找到适合当前使用场景的方案。 豆瓣评分 8.8

相关文章

  • 研发初期,允许自己写一些糟糕的代码吧

    正文 大多数开发者都会对自己编写的代码有严格的要求,希望它结构清晰,易于阅读、易于拓展,优雅、健壮、且不会有bug...

  • 注释

    “别给糟糕的代码加注释——重新写吧。”                          ——Brian W.Ke...

  • 允许自己状态糟糕

    已经连续两天了,状态不好。分析发现有三个原因: 第一,嫂子寄来了家乡好吃的饼,但高糖➕高油,好吃得停不下来,但也很...

  • python调用机器喇叭发出蜂鸣声(Beep)的代码

    研发之余,把写代码过程中较好的一些代码珍藏起来,下面资料是关于python调用机器喇叭发出蜂鸣声(Beep)的代码...

  • vue做向上无缝滚动信息展示

    呃....html代码就自己写吧

  • clean code笔记3:注释

    注释规范 别给糟糕的代码加注释——重新写吧 注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。 注释会撒谎 注...

  • C#中的委托源码演示

    在研发期间,把写代码过程中较好的一些代码段备份一下,下面的代码是关于C#中的委托演示的代码,应该能对小伙伴有些帮助...

  • beautiful

    ¡Adíos vida horrible!啊糟糕再见吧再见吧再见吧,再见吧糟糕自己,再见吧糟糕生活,再见吧糟糕一切...

  • 先解决思想:为何要写单元测试

    写单元测试简直是傻,如果不符合预期,我就直接改我自己的代码好了。 如果说领导让研发写单元测试,我敢打赌80%的研发...

  • 什么时候需要注释,怎么注释?

    什么时候要写注释如何写好注释 别给糟糕的代码加注释----重新写吧。 注释的恰当用法是弥补我们在用代码表达意图时遭...

网友评论

      本文标题:研发初期,允许自己写一些糟糕的代码吧

      本文链接:https://www.haomeiwen.com/subject/duicqktx.html