和很多的人一样,我也是一个在计算机行业摸爬滚打的底层程序猿。之所以说是底层,首先是因为目前为止以自己的大学都未毕业,不论是入行的时间和能力而言,都比不上在这个行业从事了多年的老前辈,其次我还在从事这传统的撸代码的工作,还没有能力做到一个项目的架构的阶段。
和绝大多数的从事计算机行业,尤其是软件行业的的新人一样,我也一直走着学习—实践—出错—纠错这样一个过程,而且重复了无数遍。
和很多很多人一样,我体验过刚学完的技术能力跳跃与开发环境,行走在代码的字里行间最终得出正确输出的快乐;也遇到过一个简单的问题DEBUG无数次的失落;更加体会过深夜匍匐与计算机前的辛苦付出和无穷无尽的寂寞。
但是,作为一个技术人,这一切的技术沉淀之路是每个人都要走的。
最近CSDN上一直有人问我要一些小项目的源码,其实心底里来说我是不愿意给的。并不是因为自私,而是总觉着有一种罪恶感。因为一般要源码的都是未毕业的计算机专业的学生,也许正在做课程设计实验,完全把代码给他们不就是害了他们吗。所以在考虑是否给他们源码之前还是会和他们交流交流,看看他们从心底里是抱着参考学习的态度还是完全想要抄袭完成任务(当然,有些时候也会看走眼,就当是自己在犯错了,毕竟学习这东西,谁也说不准)。
通过他们的交流我发现一个普遍的并且很重要的问题,也许正在看这篇博客的你也有这样的感触:一些常用的代码片段、常用的知识点或者算法、或者是功能代码块、数据库连接等的知识点你都会,但是想要完整的去做一个项目,哪怕是简单的项目的时候发现自己不会,无从下手。
究其根源,其原因就是我们的处发现是有问题的,或者说开始的学习思维和学习模式就是有问题的。
我们来思考一个问题:在学编程的过程中我们为何要学习数据库连接、数据结构的组织、前后端的交互方式、数据库SQL的编写等的这一些功能?
难道是为了简单的会用这些功能?其实不然,我们的目的是最终打好这些基础的同时,将所有的知识点技术点和技术栈完整的链接在一起,有效的组织构建在一起,实现一个完整的包含前后端和数据库的可运行的项目和产品。也就是说所以的技术点和技术栈都是为了项目而服务的。
之所以会遇到技术点我会完整项目我不会写的原因无非如下:
这就好比一个学汽修的工人一直学习和联系如何的拆螺丝和装螺丝,从未想过自己真正的拆卸、修理、组装一台有问题的发动机。
从入行到现在,从自己的实际体验而言,我一直认为计算机的学习过程并不是严格意义上的举一反三的过程,我更愿意把他理解为触类旁通。
就像是不会做完整项目这个问题,喊着不会不会而不去实践的人,永远也不会;但有朝一日真正的动手写一个完整的项目,通过实践解决项目中遇到的各种问题,最后有了成品,对于这类人而言,其实第二个、第三个项目的开始就随之轻松多了。因为当你有了一次将全部的技术栈、知识技术点合理组织、实现的经验后,剩下的每一次哪怕具体的代码和项目的业务需求不一样,你也能够大概的有一个对项目的理解和掌握。我习惯把这样的过程称之为触类旁通。
因此在我看来,很多的实战经验丰富的,能够自己独立写项目的人和一般的不会写项目的人的却别很大一个原因就是那些不会写项目的人没有走过将知识点技术栈组织为一个完整项目这样一个历程。
因为我们都知道对于软件开发人员而言,所有的技术栈、功能点、解决方案的学习无非就是为构建完整高质量高可用的项目。如果你学的再多,做的练习再多,但是不能将这些东西运用到实际的项目开发中,那么你的有效转化率就是0,只有将这些东西构建成一个完整项目,那么你的有效转化率才是1。所以,其实0和1之间就差那么一点,就差那么一次构建和实现完整项目功能的一次实践。
软件开发行业就是这样,**你学过的东西并且实践过得东西就是简单,你从未触及或者实践过的东西在自己看来就是一道艰难不可逾越的鸿沟。**这并不是一个人的感觉,我相信大部分从事这个行业的小白,在一开始接触一个新的东西的时候都是这样。
其实抛开对于业务需求的理解能力而言,单从技术角度而言,那些拥有项目经验或者说实习经验的同学比其他一般的同学强一点的原因不就是他们有对于各种技术栈在项目中灵活运用的实战经验吗?
所以,其实0和1之间就差那么一点,当你调整自己学习技术点的目的,勇敢的迈开开第一步,尝试做一个完整的项目,尝试把所有的技术栈和技术点转化和运用到实际的项目中区,你就已经在0到1的进步过程中迈出了巨大的一步。当有了第一次的经验,以后的一次将比几次轻松。