Contents
  1. 1. 引言
  2. 2. 迭代开发 + CODE REVIEW
  3. 3. 拥抱变化 + 快速开发
  4. 4. 总结

引言

编程开发有时候也像雕刻一件艺术品

以前一直有一种错觉,觉得编程开发就是会用库会用框架,这阶段的感悟只是停留在库的使用上面,然而当你持续工作在一件产品上的时候,你就把思维聚焦在产品,这时候你的感悟就会是架构的搭建,库只会变成你的工具

所以慢慢明白编程届的前辈们一直劝我们在大学不要为了钱选择做一些外包项目,外包项目这种东西就像一次性编程产物,你写完之后就再也不会code review了,而对于编程来说,编程就是在写BUG,只不过对于大神来说写的少,对新手来说就是写的多

诚然大神们也是从一个一个BUG中慢慢走过来的,然而对于我们菜鸡来说,很多时候我们并不能发现自己的BUG,所以让自己成长最快的方法就是立马纠正自己的BUG

当然这里我们所说的BUG有的时候并不是我们经常说的系统无法运行的BUG,我们这里说的BUG可以算成缺陷,有时候是在特殊情况下才触发。比如说运行时,这时候我们称它未漏洞;重构时,我们称它为SHIT代码;测试时,我们称它为过耦合。

这里我也不想过多谈技巧如何去发现这些BUG,以为技巧是死的人是活的,我们不需要太多技巧去避免或者去查找这些BUG,还有重要的一点在于BUG是无法避免的,我们要关注的是产品本身。有幸在实习几个月的时间一直专注于一个产品的开发,期间一直经历了大大小小的重构,随着产品的成型,自己也慢慢感悟到一些方法加速查找系统BUG和如何快速开发。

接下来就介绍一些我自己的浅显感悟

迭代开发 + CODE REVIEW

如何从零开始搭建一个产品,除非你是超级大牛,几个小时就能搞定一个完整的代码的开发流程,普通人都是一步一步来迭代开发,但是这个迭代开发也有讲究,有些人喜欢从头写到尾,然后看看能不能跑起来,再疯狂DEBUG,也有些人喜欢先写局部,慢慢测试,最后把所以组件都串联起来。

这两种方式萝卜青菜各有所爱,第一种速度最快,但是不适合团队合作和CODE REVIEW,第二种速度慢,但是灵活可靠,容错率更高,对于新手来说,选择第二种能让自己的错误不会对系统造成系统性崩塌,而且可以慢慢发现自己的BUG,从而从BUG中提高自己

对于迭代式开发我们就不得不提一下git,作为一个版本控制工具,它在迭代开发的作用堪称神器。然而这个神器我却一直没有找到正确的打开方式,只是把它当做上传服务器的工具,最近才开始慢慢掌握一点小小的技巧。

我原来的git的工作流程用命令概况下来就是

  • git add -A
  • git commit
  • git push

    这三条,然而我大部分时间都只是发挥了git push的功能,纯粹把它当成代码的备份,然而git的核心在于git addgit commit这两个命令上,这里要检讨一下我以前的做法,以前一般完成一个组件的功能就直接快速git add -A然后git commit,虽然我是遵循迭代开发,但是我很少去REVIEW自己这次提交的commit

    所以最主要的问题在于如何在快速迭代开发的时候慢下来,好好思考和REVIEW一下自己这次提交的代码,所以在这里不得不介绍git diff这个命令了,对于在每个新修改的文件来说,在你执行git add之前,你最好git diff一下这个新提交的文件,git会把你所做的修改和原始代码做一个对比。

    有的时候我们并不能记得原始代码是什么,我们到底对代码做了什么改变,幸亏我们有这个神器,只需要git diff一下,我们所做的修改和原始版本的差异就会显示出来,REVIEW代码的过程也就是我们发现错误的过程

    我们要想提高自己的就要不断的改变修正,所以正确的git的工作流程应该是这样

  • git diff

  • git add
  • git commit
  • git push

当然每个commit可以由很多个git diff + git add 组成,但是我们必须要保证自己对git add的每一个文件都要REVIEW一遍,而且我们在每次git add之前,要思考这次的改变是否能够改进,是否必要等

产品开发就像爬山,你不可能一步登山,所以我们要做的就是,在每次停下来的时候确定方向,修正自己,甚至回头

拥抱变化 + 快速开发

前面我们谈了在每一个commit的时候我们都得慎重再慎重,小心又小心,但是这种思想有时候如果把它带入开发过程中则会让你寸步难行,具体是什么呢,我来根据我自己经历来介绍

我自己是一个有一点叫做代码“洁癖”的人,由于看了不少编程理论的书,我容忍不了自己写出很SHIT的代码,面对新东西,我一般喜欢研究个透再下手,我要确保我的设计是万无一失的,所以这就造成如果我接触一个新的库或者新的功能我会花上很长时间在上面,而且由于我自己思考原来越深,我可能会把原来简单的问题搞得越来越复杂,等到我觉得开始CODING完的时候,我发现自己把一个超简单的问题搞得那么复杂,牺牲了太多时间却适得其反

造成这种原因主要是吸收太多而没有消化,我看过很多编程理论的书,技术大牛用他们的开发经验告诉我们要模块话开发,要注意设计模式,要考虑系统灵活性耦合性,这种大牛经验是很宝贵,但是这些经验就好像最高的武功秘籍,假如你没有相应的基础,贸然去练的话你会走火入魔,对于新东西新功能,我们就要想爬山者先驱一样,我们不是要找一条最锻炼自己的路去走,而是找一条最简单的路,只有爬到山顶我们才需要考虑其他问题

这种快速开发的思想还有很重要的一点就是“拥抱变化”,我们在快速开发的过程中无法避免由于快速开发造成的部分SHIT代码,当你写出这部分的时候,其实对于菜鸟来说,这部分代码才是你最宝贵的代码,因为它暴露了你的缺点,要想提高自己,必须发现自己的缺点,所以快速开发的过程中不但激发自己的潜能,而且让自己对自己的缺点有了更好的了解,了解了自己缺点,才能慢慢改进,所以快速开发第一能够节省时间,第二个就是能缓慢提高自己,当然前提是去修正它,所以快速开发你必须要把自己的代码”洁癖“和速度结合起来,抱着一颗永不满足的心去不断锤炼自己的”代码“

总结

在我看来编程开发就像是打太极,一方面我们得快,以目标为驱动,快速开发;一方面我们得慢,以变化为驱动,迭代开发

看似快慢是两个极端,其实两者相得益彰,快促进慢,慢促进快,两者相互促进

当然这只是我的自己小小感悟,编程开发博大精深,这些只是技巧,关键在于自己,思考并转换才是最核心的

Contents
  1. 1. 引言
  2. 2. 迭代开发 + CODE REVIEW
  3. 3. 拥抱变化 + 快速开发
  4. 4. 总结