青橙科技实习总结

Author Avatar
kdwycz 3月 13, 2016
  • 在其它设备中阅读本文章

插播广告,公司招人中.拉勾链接以上职位均接受实习,可以把简历发到我的邮箱会很快处理的

上一家公司的实习转正面试挂掉后,就开始寻找其他机会.挂在招聘网站的简历被leader发现后,进行了两轮面试确定了实习.当时也看了别的公司,但是有些技术栈和我的不对路,有些负面新闻颇多,有些烧钱的创业公司让我觉得待不了多长时间公司就会倒闭……再加上这里的健身福利,就答应了实习.

公司的技术栈是Django + AngularJS,都是大而全的快速开发框架.前后端完全分离,通过API进行数据通信.项目代码用Github进行管理.几个网站项目的(后端)代码量在十万级别~对于之前只有玩具项目经验的我来说足够大,能学到东西,又没有之前在豆瓣那样黑科技众多一时间接受不了的窘境(然后就圆润的走开了).

实习的第一天自然是搭建环境.推荐用Docker进行搭建.我之前看过一本Docker的书,但是不求甚解学的东西有点少.看着资料把环境搭了起来.下午要了个小bug来解.随后的一周都在熟悉系统和解决bug.

然后leader因病住院了两周~原因不明.我这段时间在(放羊)帮运营解决各种bug和其他问题.但是没人带我这件事让我有点慌,毕竟来了大需求或者麻烦的bug我是解不了的.
在leader回来之前,接到了一个比较大的任务:以前会议培训管理系统(meeting)后台管理用的是Django admin,虽然这是个神器,但是对于客户来说是很不友好的,而且直接对数据库修改是有风险的.需要一个界面友好,屏蔽不必要操作的后台(当时我是这么理解的,简直naïve,后期加了各种各样新的功能)然后我就开始设计后台权限控制.在网上参考了下基于资源的权限控制~经过讨论发现这样过于复杂,最后只做了基于模块的权限控制.leader回来后说了下大致思路,确认没问题开搞~

当时产品在对着设计图说要改的地方的时候,我没注意.因为当时对整个系统了解不够,而项目排期严重不合理.最后大家一起开了个会重新对项目进行了排期.

因为项目中有一个RESTful API框架,所以各种API写起来也是十分方便.这应该是后端开发最简单的工作了.然而事情并没有这么简单,因为有很多新的功能要开发,要修改旧的实现和数据.比如对于之前的支付功能要开发多次支付,我一头包的读了两天支付相关的模块,大概搞懂了逻辑,开始修改.看陌生而重要的代码不得要领的时候整个人都是崩溃的…

某一个周五晚上,收到了leader的微信,是转正offer.而且看起来之后的实习工资也涨了(星星眼).然后开始思考人生~想想现在公司用的技术应该在接下来一段时间能完全掌握,之后随着业务的扩展能一起参与缓存系统,监控系统和负载均衡的开发,还是能学到东西的,不会比去大公司的同学差很多,不过要多找他们聚餐聊天套技术情报(笑)

转眼到了年底,近两个月开发的分支成功合并到项目主干,合并完成后看着commit排名,还是有一些小小的成就感.

在项目开发阶段,leader给我了台测试服务器的权限,之后又把meeting项目的正式服务器也交给我来管.我开始接触一些项目部署,成产环境配置偏运维的工作.虽然很早就有个自己的VPS做个人博客,但是对于Linux半桶水的我来说还是没有物尽其用.我把配置生产环境的文档并入了自己的文档库~

接下来说下感想:

  • 以前一直在写算法题,没有写过业务代码.对其的理解仅限于论坛的评论文章.之前在豆瓣遇到的任务正好碰上了知识盲区,比如异步这样工程常见的方法和一些设计模式,就一脸懵逼不知所措,对人生产生了些怀疑.现在的公司没有缓存,私有云等各种基础设施,让我比较清晰的了解了项目的全貌.然后写了不少业务代码.现在发现业务代码相对于算法题来说确实简单,虽然可能比较多,但是通过拆分,每个步骤都是非常简单的.有一次写出了比较得意的实现方法,被leader告知这是**模式.话说我没有系统接触过设计模式.想想之前搞竞赛的时候有些天赋异禀的同学会”发明”最小生成树算法,强连通分量算法.这让当时看不懂算法分析的我十分羡慕.话说回来设计模式本来就是编程方法的总结,自己”发明”也不是什么值得炫耀的事情(倒是该好好系统学下设计模式>_<)
  • 对于一段代码出现了性能瓶颈,如果不是写的太脑残,想通过更优化的算法提升效率是几乎不可能的.解决方法的话,效率瓶颈部分异步执行,或者加缓存.想想这也是课本和现实世界的差别,课本上的经典问题是明确的数学模型且存在最优解,现实世界的需求各种模糊且与其他模块相互联系.有些时候为了代码的复用也会降低每一种情况下的性能.而解决性能问题也充满了tricks.半年前在实习生面试时问面试官网站性能问题的一般解法时,他说了两点:加worker,加缓存.
  • 编码的过程也是妥协的过程.在正确性的前提下,编码效率,可读性,可复用性,运行效率不可能同时到最好,需要在妥协中平衡.有时候完全的正确性也不是必须的.
  • (产品和开发是岗位名)产品这个岗位在学校里难以接触到,但是在公司里却异常重要.以前以为项目具体逻辑是开发自行决定的,后来发现这些都是产品来决定,开发只是实现者.产品要对整个项目进行管理:收集来自Boss,客户,运营对项目功能的需求,确定项目的逻辑,整理好了交给开发来做.一般来说完成了产品的需求,没有bug的话,如果项目实现出了问题是应该产品来背锅的.所以开发和产品的沟通非常重要.如果沟通有误会造成工期延误或者最后完成的产品不合需要(等于活白干了).产品大多是不懂技术的(除了少数技术转产品的同学),一般对项目的难度和排期没有准确的判断,开发应该不仅应该听某个功能的需求,还要对产品的整体思路有所了解,这样可以在编码时留下余地,兼顾以后可能出现的需求.还有项目排期,尽量给自己留余地
  • 我有个很作死的习惯,各种开发环境和库喜欢用最新版.虽然这不是特别不好的事情,但是在文档缺失而自己自学能力不够的时候会制约进度.而大多公司生产环境的版本都是滞后的(比如三体人锁死了百度的gcc什么的)毕竟生产环境是稳定压倒一切.不过我还是很想把自己负责的项目Django和Python环境升级到最新版
  • 对于自己今后技术的发展思考~并不喜欢前端,感觉还是后端有意思.在豆瓣实习时有感于DAE的神奇,希望做相关的工作,在离职前和当时面试官聊天,说道自己的想法,他说这偏向于DevOps,于是我把近期的目标设定为后端和运维.因为个人项目的缘故,再学一个前端的框架(虽然并不喜欢).能有最基本的全栈能力.

本站所有原创内容均以 署名-非商业性使用-相同方式共享 4.0 (CC BY-NC-SA 4.0) 协议授权
本文链接:https://blog.kdwycz.com/archives/qingcheng-intern/