caoz的心得与分享,只此一家,别无分号.

编程的一些小习惯

发布日期:2017-04-11 12:27:55 +0000

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


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


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


1、先做核心模块的压测


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


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


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


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


2、确保过程可控


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


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


我养成的习惯是这样的。


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


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


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


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


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


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


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


3、预留的地方写注释


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


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


4、砍代码是很爽的事情


幸好我没遇到以代码量为kpi的公司,我有一个癖好,就是,一旦有更好的替代方案,就会大段大段的删除原有代码。如果能用更简单的结构和更通用的代码,替代原有罗嗦和重复的代码,我会觉得是个很有成就的事情。


5、用人人看得懂的逻辑


我们经常说代码的可读性。

我刚毕业的时候,去一个公司写程序,挺喜欢写特别绕特别罗嗦的逻辑,觉得自己很牛逼,接手的人看着一头雾水,我觉得自己成就感满满。


后来慢慢自己做事情,自己懂一点真正的技术的时候,才意识到那些罗嗦的逻辑其实都是屎,性能低下,毫无意义,而且非常难以维护。


再往后就捡着怎么简单怎么写,就好比我们说话,把逻辑复杂的长句,分成几个简单的短句,更容易理解,也更容易表达,写代码也是同理,很复杂的逻辑,拆解一下,分成几个简单的逻辑写出来,很清楚,也很有效率。


而且,从整个架构的扩展性而言,取消连表操作,取消一些关联度较高的逻辑,更容易实现架构扩展。


6、不要沉迷于框架


很多人写程序言必称框架,似乎没有框架就写不了程序。

没必要,比如,就常见的php来说,本身就可以认为是一种框架了,你再套一层,其实也是伤害了这门语言的活力。


团队开发,用框架,也不是说不可以。但你要知道你需要的是什么,你遇到的障碍是什么。


框架最大的问题是什么?过于繁冗的嵌套。为什么我一直很烦框架?因为经常遇到需要一秒钟几千次请求的处理场景,那么,调优的时候,有框架真的很头大,要从数不清的框架中寻找数据处理的逻辑,寻找性能卡点,可能改动代码只有两行,但是找问题需要两天。


框架不是越牛逼越好,所谓牛逼的框架,往往结构更加复杂,特别难以理解其中的数据调用过程。


此外,很多公司会要求员工统一用某一种框架,你倒是熟悉了,出去再找工作,对不起,别的公司不用这个,记住,你的技术能力绝对不能被框架约束住。


7、使用熟悉,成熟的技术。


听到很多创业公司,因为技术负责人一时兴起,用了mongodb,然后就进坑了。

当然,我不是说mongodb不好,而是相关负责人只是听说还不错,指标很好,然后就兴冲冲的去学习。


现在很多技术人员,习惯说,php太low,mysql太弱,apache太落伍,好,你知道这些玩意的极限性能么?如果你用到了极限性能,发现不行,你去用别的,或者你的业务场景,确实这些不适合,你去用别的,这都合理。我们也是,遇到实际问题,mysql确实不行,加一层redis解决,这没问题。


很多人,根本没搞明白自己的障碍和问题在哪里,根本不知道相关技术产品的优势和劣势在哪里,看一堆第三方的数据测评,脑子一热,去学新技术,然后,掉进坑里出不来,如果是创业公司,可能项目就死在里面了。不开玩笑,我都遇到过好几个这样的了。我说你们要是mysql,我随时可以帮你们分析一下,做个优化方案,你搞个mongodb,真的爱莫能助啊。


使用新技术前,建议全面了解该技术的特征,适用范围,以及不适用的范围。

比如,mysql的几个存储引擎,Redis的四种数据结构,都有什么特点,各适用于什么场景,不适用于什么场景,如果这个都没搞清楚,拿过来就用,那么能不能灵,就只能靠运气了。


8、细节没优化前,别谈架构。


负载高了,系统稳定性差了,换服务器吧,架构调优吧。


真不是这么说的,先把问题搞清楚,看看到底具体原因在哪里,单服务器的瓶颈和压力在哪里,再来谈这个问题。


好多人也来问过我这个问题,想搞个大系统,写个架构的说明,让我看看,说有什么建议,文档看上去虚的很,每句话都对,每个方案都靠谱,问题是,我说的特别不客气,我说这玩意一文不值。你先有最基本的系统分析能力,有最基本的调优和应对问题的能力,再来谈架构。


好吧,作为经济适用程序员,我是比较喜欢压榨单机的性能,但话说回来,单机优化的好和坏,对负载的支撑能力,差距可能是一个数量级,甚至不止。也就是你需要十倍的服务器来支撑,而且服务器多了后,各种其他诡异现象,通讯问题,以及内网的数据流量压力,也都会出现很多风险,并不是说你有钱,加服务器就能解决的。单机优化到位,然后再针对性能瓶颈,有目的性的扩容,有目的性的扩展架构,这才是真正的架构之道。


9,多留日志


我特别在意问题回访,因为经常会遇到线上诡异的问题,那么核查是非常麻烦的,因为自己总是无法复现,一个无法复现却又时不时出现的bug是最难处理的。所以,代码里,以及webserver,以及在系统运维的脚本里,多增加一些日常的日志输出,对异常多一些自动的信息采集,这样,出问题的时候,可以回访问题时间的信息,对定位问题,分析问题,解决问题,帮助极大。


研发和运维,其实很难分的开。一个复杂的线上bug,需要运维和研发一起协作,才能找到真正的原因。


就这样吧,如果您不是研发,烦请转给您熟悉的研发的朋友。


不过,本文并非针对高手的,如果您是高手,很抱歉耽误了您的宝贵时间。