- A+
本文来自曹政大神的微信公众号【caoz的梦呓】，caoz的文章篇篇犀利，值得细读与收藏，特转载过来，分享给大家，如果你也喜欢，可以微信搜索“caoz的梦呓”来关注他。文章所有版权归原作者曹政所有！
说来很久没有写关于技术的分享了。
主要是每次写技术相关，访问量，转发量，赞赏，都很差，好吧，都是借口，还是自己不够淡定，写的不够好。
今天写一点很久之前，自己还在做程序员的时候，一些编程的习惯，希望对刚进入技术领域的朋友，一些可以参照的经验。
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，需要运维和研发一起协作，才能找到真正的原因。
就这样吧，如果您不是研发，烦请转给您熟悉的研发的朋友。
不过，本文并非针对高手的，如果您是高手，很抱歉耽误了您的宝贵时间。
