京坤SEO:编程的一些小习惯

浏览:/ 2018-01-30

说来很久没有写关于技术的分享了。

 

主要是每次写技术相关,访问量,转发量,赞赏,都很差,好吧,都是借口,还是自己不够淡定,写的不够好。

 


 

今天京坤SEO写一点很久之前,自己还在做程序员的时候,一些编程的习惯,希望对刚进入技术领域的朋友,一些可以参照的经验。

 

1、先做核心模块的压测

 

在对整个项目做设计,做规划的时候,第一步,先要对系统负载最高,开销最大,或者可能请求量最高的部分,先把这部分最基本的数据结构和操作逻辑写出来,然后压力测试。

 

嗯,应该是我水平不够高吧,一直对很多这种问题信心不足。所以对一些没有把握的地方,会提前做压力测试,做性能测试,确保都ok后,才正式完成数据结构设计和系统的设计。如果发现有问题,就一直调整,测试到符合预期为止。

 

我觉得很多程序员,习惯把东西做完,然后等着快上线的时候才做性能测试,那么如果前面设计出了问题,这个就很头大了。当然,后期快上线的时候也要做性能测试,但前期的我认为还是很重要的。

 

当然,做好这一点,需要懂一些业务,你要知道业务压力在哪里,业务请求的重心在哪里,很多时候,产品经理不讲,你也要问清楚。

 

2、确保过程可控

 

以前做数据分析的时候,经常要对数亿条日志做分析,做处理,包括基本的分析,关联规则等等。(那时候也没大数据的概念,少了很多吹牛逼的资本)

 

那么完成一次全日志的分析,通常可能需要几个小时,如果代码再出一点状况,或者有什么差错,那一天就荒废进去了。

 

我养成的习惯是这样的。

 

第一,先从小数据量做测试,验证分析的代码,和测试数据返回结果,是否符合预期,策略和步骤是否合理。

 

第二,代码执行时一定要保持中间的输出,比如说,每处理10万条日志,写一条状态日志,记录处理的日志条目数和当前的执行时间,有的时候也记录一下资源开销(有时候跑不完资源会崩溃掉,比如内存溢出,这时候需要回访一下,评估一下并想想如何优化调整)。这个执行时间记录也很关键,基本上可以在执行的时候,预估大概的结束时间,比如出去喝个咖啡,找人扯个需求,知道程序大概多久可以执行完。

 

如果一个分析程序跑着,没有进度展示,不知道几个小时可以跑完,可能会非常浪费时间。

 

第三,断点可续,因为日志的数据量非常大,内存有大量的中间数据需要保存,有时候,代码跑着跑着,内存就崩溃了。

 

话说,我老说自己是经济适用程序员,讲真一句,不论是线上的负载应对,还是线下的海量日志分析,我都是用配置很普通的破服务器跑的。

 

那么这种,一方面代码去调整,另一方面,如果每次都重头去跑,那其实反复花费的时间还是相当长的,所以,分析程序,尽可能做到,可以在中断的地方,或者上一个可控的断点重新开始跑。

 

前段时间在 小密圈 看到有人分享一些mysql的心得,我发现对方分享的几乎所有SQL技巧都是我当时尽可能避免的操作,比如 通过搜索批量写入数据表,这个操作我当时很忌讳的,当然,具体看应用场景,因为我们往往涉及十分巨大的数据迁移,这种SQL 很可能导致中间过程不可控,如果在高并发的线上操作甚至导致数据库崩溃,所以我们的处理原则往往是分批次导入,并且代码中会记录导入的批次和状态,如果出现中间故障,还可以在断点继续导入。

 

3、预留的地方写注释

 

很多时候,代码写的自己也不是很满意,比如某个处理效率不够优化,某个处理的方法不够简洁,或者扩展性比较差,代码写的很弱智,但可能短时间没有办法想清楚最合理的解决方案,考虑到上线初期这里并不是重心所在,所以也不会特意去优化它,但这种情况下我往往会留下注释,并说明下一步优化的可能思路是什么,或者想到的可行方案是什么。

 

当然,惭愧的说,可能超过一半的预留注释都没有真正的改进过,但这个注释,一旦需要修改,就很重要,因为时间一长,真的很多原委都不记得了,需要调优,需要改进的时候,发现以前其实已经有预案,或者能了解当初设计的原委,都是很有帮助的事情。

阅读"京坤SEO:编程的一些小习惯"的人还阅读

上一篇:红客SEO:马化腾的邮件驱动为什么会成功

下一篇:SEO人才如何直面自己的丑陋