the5fire

我们编写的代码运行的每一天，其实跟我们生存的每一天都差不多，我们都依赖于外部资源——CPU、内存、网络等。因此了解我们（代码）的生存环境是相当重要的事情，无论是程序从Redis获取数据，或者是我们看到绿灯之后走过马路，大概率上是安全的，但是依然存在风险，了解存在哪些风险是必要的。

对于程序员来说，确切的说对于渴望成长的程序员来说，了解生存的空间必不可少。

这里说的生存环境主要是三部分：技术，团队，业务。

微观代码环境

这个是最直接的，每天都在做各种业务的支持，写各种代码亦或是抄各种代码。你有没有在不经意间思考这么个问题，你所产生的代码如果能思考，它会怎么看那些跟他在同一个文件中的其他代码？另外一个问题是这个模块中有那么多代码，为什么你改掉了别人之前写的代码，而放下你的代码？你的代码可能会在什么样的场景下被别人修改？

来看下面一个简单代码:

classDBHelper(object):# 小A写的@2015-04-04our_db=conn_db('127.0.0.1',3306)defquery(self,sql):#blablablareturnresultdefquery_utf8(self,sql):# 小C 增加，链接是utf8的，之前那么写太傻×@2016-04-04my_db=conn_db('127.0.0.1',3306,charset='utf8')#blablablalblabreturnresult

不知道你是否有过这个经历，看到过这样的代码，小C的my_db会不会同一年前小A产下的our_db进行沟通：喂，我说哥们儿，你爹真是个low x呀。当然这个代码比较短你可能会一眼看到问题所在，但是当你维护一个有几百行代码的文件时，你得有很好的记忆力才行。这只是Python的例子，JS里的例子还会更多。

了解你所编写代码的环境，上下文。然后去用那些能够复用的连接、函数、工具，而不是自己造一个。如果觉得别人的写的有问题，gitblame是个好工具，跟他沟通，我们一般会总想着让自己过的舒服点，搞个好点的键盘，好点的椅子。但是从代码角度来看，也需要要整个代码环境更好一点，同时这也是让人精神愉悦的方法。

有两个理论需要知道，一个是破窗理论，另外一个就是童子军军规——让营地比你来的时候更加干净。另外值得不断警醒的是不要生下代码猴子。参见《代码整洁之道》。

技术栈

先从技术说起，比较容易理解，一般我们新到一个公司，前几天肯定是需要做的就是熟悉环境。这里的熟悉环境一般都是指技术上的，首先需要做的就是了解新公司用到了哪些技术，比如你之前的公司都是用SVN管理代码，现在大家都用git，那你肯定需要尽快熟悉，再比如说你之前打包都是用grunt，但是新公司都用glup了，这也需要熟悉。在此之上才是业务层面的熟悉，这个业务是指跟你编写代码紧密相关的业务（功能）。

这显然就是我们新到一个环境首先需要做的事情，但是对于一部分老人（老员工）来说，对于能够支撑业务的代码（技术点）足够熟悉了，每天需要做的可能是徘徊在各种业务之间，运用熟悉的技术，不断的构建一个又一个产品。短期来说是个好事，通过快速的提供技术支持保证产品进度，同时也能收获其他同事的信任。但是长期来说是一种危害。有句话叫做：跳出你的舒适区。在舒适区待的太久会导致：一年经验用十年的状况。因此这个时候还需要再次考虑你的生存环境是什么？你所持有的技术的生存环境是什么？

所谓的生存环境并不是固定的，它是随着你的认知的不断的扩大而扩大，就像是一个圆，内部标记为已知，外部是未知，你已知的东西越多，未知的东西就越多。

因此要是时刻有更深层次的考虑，对于如何跳出舒适区的最好的办法就是保持警惕心。在感觉一切尽在掌握之中的情况下，考虑到出现什么情况会导致你无法把控——无论是项目进度还是问题修复。

再说到技术栈，目前我们前端用到的技术栈是：JS、CSS3、H5、Backbonejs、Zepto、Grunt、Git等等，后端的技术栈是:Python、Django、Tornado、Redis、MySQL、Fabric，Gunicorn等等。但这些就现在来看是稳定的，但是相对于大的环境来说，这些可能并不是稳定的。这其实就是另外的问题了，局部环境和大的环境之间的考虑。

单纯的就局部环境来说，只是能够熟练的运用JS，CSS解决问题是不行的，对于现在已经工程化的前端来说，只会这些会让你丢掉饭碗——迟早。因此有必要精通你的技术栈。对于后端来说也是一样，看了别人的Tornado代码，你也能写出异步处理器，但是你知道Tornado是怎么处理的吗，如果你不知道，你可能会在访问Redis的Handler上加一个异步的装饰器，这有用吗？另外如何改造Redis驱动，支持异步请求呢？

大部分情况你只熟悉了外围的技术点，不妨碍你做一些Normal或者是Easy模式的业务。但是如果始终停留在这个模式，那你也只能留在这个模式。一般我们派活给同事时，都会考虑他的技术能力在什么水平，不会上来就给一个Hard模式的业务，这必然会导致一个问题，只能解决Easy模式问题的人，一般来说不会得到重视，如果能够及时自省，自己奋发的好还好。就怕觉得自己能干活，但是待遇不如人。

团队

相对于上面两个比较直观/具象的内容，团队这个概念有点虚。不过反过来说，相对于好坏代码的感知，对团队，对于同事关系、能力的感知反而会比较直观。

对于团队来说，我一直的看法就是，任何一个新人到新团队第一件要做的事就是尽快让大家都认识你，同时你也要尽快的熟悉每个成员。这句话的意思不仅仅是交个新的朋友那么简单。需要做的是有一个具体的评判。一般面试的时候不会所有的人都跟你聊过，另外面试也是单纯的被问。因此进入团队之后，首要做的事情，除了跟大家搞好关系之外，要做的就是了解每个人的技术点，技术偏好（或者到底对技术有没有热爱），然后看他们目前所处的层级。

上面说过，了解你的代码所处的环境很重要，了解你所掌握的技术在你所处的技术栈中很重要。这里需要了解的是，了解你所掌握的技术在这个团队中能够到怎么样的层级，任何地方都是会有阶梯的。团队成员都是大牛的情况可能并不多见。

了解在团队中所处的层级并不是要有阶级感，也不是要找一个大牛进行膜拜，找个小白进行蹂躏。而是再进一步的了解那些处于团队顶部的人他们掌握的哪些东西是你欠缺的？那些处于你下面的人，他们确实是因为工作年限比你少还是因为别的原因。总之还是那句老话——取长补短，向上惧下。(后面那个成语是我编的）

另外从团队中能够了解到的一个重要的状况是你离目前团队的天花板还有多远，你需要花多少时间才能到达。现有团队是否有成长氛围，技术氛围如何。

业务

这个是技术人员最不关注的，技术人的一贯思路就是，老子有技术傍身，只要技术够牛，哪里不是爷的天地。

但是首先要认识的一点是，所有技术的存在都是为了业务服务。如果你觉得自己技术够牛，为啥不会对业务产生好的影响？尤其是当你进入一个不错的公司，觉得可以施展才华，首先要做的可能是了解业务特点，有哪些是除了现有技术支持之外，需要改进的地方。比方说，m.sohu.com，常规的维护支持已经能够让他为用户提供服务了，似乎不需要做什么了。但跳出常规，除了让网站可浏览，能不能让网站更快速的达到用户眼前。能不能让用户打开页面时使用更少的流量，尤其对于非wifi网络访问。这些都是业务相关的。

可能有技术大牛会这么想，我们这个平台已经停稳定了，咱们花点时间搞个其他的项目吧，提高下大家技术。理论上来说这没什么问题，技术人员要做的就是尽可能多的做实践。但是这个业余的实践是没什么含金量的，就好像the5fire经常会看到有工作几年的前端同学，简历上写，工作中没用过grunt，但是我自己搞过一个项目，用过grunt打包；或者是，之前工作没用过tornado，但是我博客是tornado搭的。相对于既不会又不学的人来说可能会有些优势。但是你了解的这个东西没上过生产环境，这个对你来说除了是知识之外，没什么用处（知识和经验是有很大差别的）。

技术是支持业务的脊梁，业务是滋养技术的环境。贴合业务的技术不仅仅能让你在技术上更为精进，也会让你在业务有所贡献。哪个公司不需要这样的人，升职加薪迎娶白富美的日子不就慢慢到来了吗。

除了从技术角度看业务，还要从行业角度看业务。《我编程，我快乐》是一本很好的书，虽然名字有点俗。里面的一些观点确实挺好的，你必须了解你公司的成长情况，收益情况，行业地位。据此不停的调整自己的方向。让自己无论是在上升还是下降的公司中都能够往上成长。

了解行业状况之后，需要的是正确的认识。更适应环境，因此不能觉得，现在属于快速发展期，我们要快速的搞MVP，代码审查、重构等我们行业第一再说。也不能因为一看，我靠，我觉得我们快散伙了，代码随便写写吧，反正早晚得关机。

其实再回到上面的微观的代码环境，不要生下一个代码猴子，因为人们看到它会跟看到你一样。

了解自己所处的环境，不断的改进自己，改善环境。