blyang 你长的很好看啊~
实习学到的
发表于: | 分类: Application | 评论:0 | 阅读: 4620

这篇文章拖了很久了,赶在回学校的前一天,把它写掉吧。从五月份开始实习,转眼间过去三个多月了。今天下午专门看了5月份的培训资料,像是Redis、Log4Net、序列化工具ProtoBuffer等等,和当时的体会完全不一样。当时是什么都不懂。而现在,不说理解的很清楚吧,但起码看得懂,用的来。

在公司实操代码和自己写练习代码之间的差别不能以毫厘记,总结一下大概有下面几个点

  • 公司里代码的可读性要求很强,代码文档的重要性很高
  • 更注重稳定性,try catch用的很多
  • 技术架构更全面,缓存,文件,SQL,NoSQL,前端,逻辑,多线程等等都涉及到
  • 一个人负责的大多只有一小块,和别的同事的交互很多
  • 命令窗口调代码的方法绝迹,日志用的多了起来
  • 用到算法的地方不多,更多是逻辑流程。不过在用的算法都很经典
  • 控制台项目绝迹,写的要么是Windows服务,要么是Web服务(IIS部署)


关于代码可读性

首先来说一下可读性,股吧代码的可读性还是可以的,注释写的很多。但是特别头疼的是代码文档不规范,遇到一个新系统需要花两三天甚至更多时间去理清楚代码逻辑,被虐的多了,反而整理了一个理清流程的方法:用思维导图。首先找到一个代码入口,然后从这个代码入口开始深入。可能一个项目有很多个代码入口,像是一个大的系统,里面可能写了好多个Windows服务入口,这时候不要管其他的,找一个自己喜欢的入口,开始深入向下挖,一通百通,一个搞懂了,很可能一大批的逻辑都清楚了。一个项目里有很多个关联项目,像是Common、Util、Core、Model、DBHelper等等,理清楚他们的关系。

这里我总结的经验是:

  • 注意类的命名
  • 一些常量,尽量把相同属性的常量放在一起,定义在一个类里面。
  • 尽量不要把网址,物理路径等等这些信息硬编码到代码中,要放在配置文件里

读代码多了, 还有一点体会是,尽量不要自己造轮子,而要先找一个巨人,爬到它肩膀上,再去思考重构,重用,复用等等,这样才能造出更好的轮子。

拿到一个系统,先去线上看看运行的情况,先把大方向理清楚,接着理清细节。框架、方向和细节都理清楚了,才能刚方便的维护和修改。特别是修改,那怕有一点点细节没注意到,都可能会代码很大的麻烦。


关于代码稳定性和健壮性

而代码稳定性方面,也可以说是代码健壮性,这里被坑了很多次。我总结的稳定性出问题比较多的有几个点,如下:

  • 多线程访问加锁有误
  • try catch没加造成整个系统崩盘
  • 网络请求超时或者取不到数据等异常没有做处理
  • while死循环
  • 格式强制转换出问题

在写多线程的时候,由于锁加的不好,要么是粒度太大,拥塞就很多。要么是粒度太小,就导致各种奇奇怪怪的结果。合理的加锁还是需要磨练。

另一方面是使用try catch获取代码中的问题。服务器端的代码要尽所有努力摒除可能遇到的挂掉的情况,所以try catch用的很多,尽管加了try catch会对代码访问速度造成一定的影响,但是这个影响用物理机器去消除掉了,总比网站挂掉好得多。

第三个网络访问出问题,其实也算是try catch要处理的经典之一,这里之所以拿出来说,是因为被它坑大了。7月初从别的接口接一批数据到本地Mongo里,由于数据量太大,走的时候把程序开起来了,一夜应该能把数据跑完。结果第二天来了一看,崩盘,一夜的数据白跑了,就是因为网络连接超时,而超时的bug没有处理掉。

而关于while死循环的问题和格式强制转换,mentor从一开始就提到了这个问题,不要对自己的代码这么有信心啊少年。我的思路是把while换成for循环,或者是给一个断言。而格式强制转换的问题,不要用语言本身的强制转换,不安全。而要写一个公共的方法,把强制转换在方法里做掉,同时这个方法里要提供转换失败的处理,给定一个default的值。


关于技术架构

看技术架构图很舒服,自己设计架构图更爽。哈哈哈哈。

一个项目用到的东西很多,不同于小的创业公司,更不同于自己的计算机大作业,在公司里的项目一开始定位就是一个高并发,访问量大的工程,所以数据库的选择,用MongoDB还是用MySQL,或者其他的数据库,这个在做技术架构的时候就要考虑情况。数据缓存的选择,Redis、MemoryCache等缓存的选择都要预先定义好。甚至文件队列,消息流转等等,都会体现出来。

容灾、高可用、分布式、负载均衡这些,都是需要考虑的问题,这些就不说了,我现在对它们理解的也不深刻。

每个人负责的都只有一部分,这个和在学校里自己一个人搞完前后端的感觉还是不一样的,多了些和同事沟通的成本在,双方协商数据格式,接口访问方法等等,都需要沟通。还有就是快速定位问题根源,确认不是自己的问题,这也很重要,为了跟人撕逼方便,我还写了个数据备份服务,将系统上的数据备份三天到本地,留下撕逼的证据,哈哈哈。

总体来看,虽然看似每个人只负责一小部分,一小撮,但是整个代码量还是很大的,每一个小块儿,几万行代码都是很正常的,想想当初我写一个Android客户端也就几万行代码,现在一个小部件就几万行了,真是尴尬。

哦对了,还有日志,以前自己写东西很少写日志,错了就错了,影响面也可能就自己的体验,现在不一样的,就算代码报错了,线上代码也不能停,不能直接去debug,所以错误定位变得异常重要,加日志也变得异常重要了。所以,多写一行代码吧少年。

评论已关闭

TOP