入职半年，对编程还是一窍不通
The following article is from 业余码农 Author Amazing10
第一时间收到文章更新
如若转载请联系原公众号
时间真是过得飞快，一溜烟的功夫我在公司已经呆了快半年了。虽说自认为仍旧是个新人，但是在同事眼中，在公司的角度，能够感觉到早已没把自己当新人。当然并不是说我进步得有多飞快，更多的还是因为：半年时间，对于一个新人入门来说，足够了。
但是真的足够吗？我也不敢妄下定论。只是从我个人出发，虽说半年来做了挺多需求，有复杂的业务向服务或功能，也有偏技术向的代码优化和重构，但是仍然感觉差了点什么。
还记得在中学时期，老师经常吐槽说的一句话：「你就是通了六窍，还剩一窍不通！」
我现在就挺「一窍不通」的。基本日常迭代的需求都能做，就算没做过的，花花时间也能够搞定。但是仍感觉有几座大山横贯在心中，让我无法顺畅的呼吸技术的自由。
一、对编程语言语法的理解不够透彻
想必大部分应届生可能都会遇到这样的困境，因为校招时各个大厂都说不看重编程语言，看重的是计算机基础。这就导致像我一样的很多人，在入职之后都不可避免的开始了转语言的艰辛历程。以前学的C/C++，去做Server可能都要转Go/Java了；去做客户端估计还要转ObjC/Java甚至是Swift/Kotlin。
我也不例外，入职之后同样需要去重新学一门编程语言，并且还需要在短时间能迅速上手并完成一系列的任务。这样一来，对于语言的自身特性就很难去深入的理解，一是没有特定的场景，二是的确没时间没精力。
再加上大公司的一些核心项目实已经非常庞大，许多框架和底层优化已经非常完善，各种基础库也十分健全并且有专人维护。这就使得实际上的日常需求大多是在业务代码里面的修修补补，一般不会遇到什么大问题，也就少了去了解各种骚操作的机会。
二、对系统底层的机制琢磨不够细致
这点就因人和因工程而异了。成熟的工程项目往往都会把各种公共的组件或者基本库下沉，将业务模块在横向或者竖向进行划分为不同的子模块，自底向上构建不同服务。这就导致在实际的开发过程中，使用的都是前人封装好的接口或者模块。
虽说这样开发新功能的效率和安全性得到保障，但是万一存在某些历史遗留问题，就完蛋了。同时也正是因为代码一层一层的封装和依赖，加大了新人去了解项目中某些底层机制的难度。
当然了，如果有幸能够发现前人挖的深坑，或许也是件好事。毕竟「前人挖坑，后人晋升」嘛。
总的来说，琢磨底层机制是一件收益很高但是精力消耗大的事情，半年的时间里我数次想要一鼓作气把某段源码研读的时候，就会有各种需求或者杂事袭来，措手不及。
三、对业务发展的认知不够敏感
在之前的文章中我也讲到过，不能「两耳不闻业务事，一心只打技术工」。身为技术人员，但是不能一心只有技术，还需要花一定的心思在业务上，这样才能让技术更好的服务于业务。
虽然我之前就已经有了这么个意识，但是实施起来却并没有想象中的那么容易。技术其实是一件很单纯的事情，逻辑是否明确，内存是否泄漏，QPS是否扛得住，这些是很容易从技术的思维去感知的。
但是业务就不一样了，理解一个业务的发展需要从很多比较「虚」的方向去思考。不仅仅是从技术实现的角度，还需要从产品的角度、市场的角度，甚至还有安全、法务以及公关的角度去思考。
简单来举一个例子，假如从数据上来看，某APP的DAU一直在持续增长，能够说明什么问题，是否能够说明该产品已经取得了成功？
其实不见得。因为DAU的增长原因可能是公司在用户增长上投了很多钱，虽然新增用户多，但是不见得留存一定好。同时，还需要考虑商业化的能力，持续增长的能力，用户心智的影响等等。
由此可以看出，业务也的确是需要下意识的去关注和培养的一个方面，绝对不是代码上线后看看定量的数据变化，看看指标涨没涨就能行。更重要的是从整体去思考一个改动对全局的影响。
所以，这半年来说只能说是试图去理解业务，但要是说敏感的认知业务肯定是谈不上的。