今天京坤SEO写一点很久之前，自己还在做程序员的时候，一些编程的习惯，希望对刚进入技术领域的朋友，一些可以参照的经验。
1、先做核心模块的压测
在对整个项目做设计，做规划的时候，第一步，先要对系统负载最高，开销最大，或者可能请求量最高的部分，先把这部分最基本的数据结构和操作逻辑写出来，然后压力测试。
嗯，应该是我水平不够高吧，一直对很多这种问题信心不足。所以对一些没有把握的地方，会提前做压力测试，做性能测试，确保都ok后，才正式完成数据结构设计和系统的设计。如果发现有问题，就一直调整，测试到符合预期为止。
我觉得很多程序员，习惯把东西做完，然后等着快上线的时候才做性能测试，那么如果前面设计出了问题，这个就很头大了。当然，后期快上线的时候也要做性能测试，但前期的我认为还是很重要的。
当然，做好这一点，需要懂一些业务，你要知道业务压力在哪里，业务请求的重心在哪里，很多时候，产品经理不讲，你也要问清楚。
2、确保过程可控
以前做数据分析的时候，经常要对数亿条日志做分析，做处理，包括基本的分析，关联规则等等。（那时候也没大数据的概念，少了很多吹牛逼的资本）
那么完成一次全日志的分析，通常可能需要几个小时，如果代码再出一点状况，或者有什么差错，那一天就荒废进去了。
我养成的习惯是这样的。
第一，先从小数据量做测试，验证分析的代码，和测试数据返回结果，是否符合预期，策略和步骤是否合理。
第二，代码执行时一定要保持中间的输出，比如说，每处理10万条日志，写一条状态日志，记录处理的日志条目数和当前的执行时间，有的时候也记录一下资源开销（有时候跑不完资源会崩溃掉，比如内存溢出，这时候需要回访一下，评估一下并想想如何优化调整）。这个执行时间记录也很关键，基本上可以在执行的时候，预估大概的结束时间，比如出去喝个咖啡，找人扯个需求，知道程序大概多久可以执行完。
如果一个分析程序跑着，没有进度展示，不知道几个小时可以跑完，可能会非常浪费时间。
第三，断点可续，因为日志的数据量非常大，内存有大量的中间数据需要保存，有时候，代码跑着跑着，内存就崩溃了。
话说，我老说自己是经济适用程序员，讲真一句，不论是线上的负载应对，还是线下的海量日志分析，我都是用配置很普通的破服务器跑的。
那么这种，一方面代码去调整，另一方面，如果每次都重头去跑，那其实反复花费的时间还是相当长的，所以，分析程序，尽可能做到，可以在中断的地方，或者上一个可控的断点重新开始跑。
前段时间在 小密圈 看到有人分享一些mysql的心得，我发现对方分享的几乎所有SQL技巧都是我当时尽可能避免的操作，比如 通过搜索批量写入数据表，这个操作我当时很忌讳的，当然，具体看应用场景，因为我们往往涉及十分巨大的数据迁移，这种SQL 很可能导致中间过程不可控，如果在高并发的线上操作甚至导致数据库崩溃，所以我们的处理原则往往是分批次导入，并且代码中会记录导入的批次和状态，如果出现中间故障，还可以在断点继续导入。
3、预留的地方写注释
很多时候，代码写的自己也不是很满意，比如某个处理效率不够优化，某个处理的方法不够简洁，或者扩展性比较差，代码写的很弱智，但可能短时间没有办法想清楚最合理的解决方案，考虑到上线初期这里并不是重心所在，所以也不会特意去优化它，但这种情况下我往往会留下注释，并说明下一步优化的可能思路是什么，或者想到的可行方案是什么。
当然，惭愧的说，可能超过一半的预留注释都没有真正的改进过，但这个注释，一旦需要修改，就很重要，因为时间一长，真的很多原委都不记得了，需要调优，需要改进的时候，发现以前其实已经有预案，或者能了解当初设计的原委，都是很有帮助的事情。
4、砍代码是很爽的事情
幸好我没遇到以代码量为kpi的公司，我有一个癖好，就是，一旦有更好的替代方案，就会大段大段的删除原有代码。如果能用更简单的结构和更通用的代码，替代原有罗嗦和重复的代码，我会觉得是个很有成就的事情。
5、用人人看得懂的逻辑
我们经常说代码的可读性。
我刚毕业的时候，去一个公司写程序，挺喜欢写特别绕特别罗嗦的逻辑，觉得自己很牛逼，接手的人看着一头雾水，我觉得自己成就感满满。
后来慢慢自己做事情，自己懂一点真正的技术的时候，才意识到那些罗嗦的逻辑其实都是屎，性能低下，毫无意义，而且非常难以维护。
再往后就捡着怎么简单怎么写，就好比我们说话，把逻辑复杂的长句，分成几个简单的短句，更容易理解，也更容易表达，写代码也是同理，很复杂的逻辑，拆解一下，分成几个简单的逻辑写出来，很清楚，也很有效率。
而且，从整个架构的扩展性而言，取消连表操作，取消一些关联度较高的逻辑，更容易实现架构扩展。
6、不要沉迷于框架
很多人写程序言必称框架，似乎没有框架就写不了程序。
没必要，比如，就常见的php来说，本身就可以认为是一种框架了，你再套一层，其实也是伤害了这门语言的活力。
团队开发，用框架，也不是说不可以。但你要知道你需要的是什么，你遇到的障碍是什么。
框架最大的问题是什么？过于繁冗的嵌套。为什么我一直很烦框架？因为经常遇到需要一秒钟几千次请求的处理场景，那么，调优的时候，有框架真的很头大，要从数不清的框架中寻找数据处理的逻辑，寻找性能卡点，可能改动代码只有两行，但是找问题需要两天。
框架不是越牛逼越好，所谓牛逼的框架，往往结构更加复杂，特别难以理解其中的数据调用过程。
此外，很多公司会要求员工统一用某一种框架，你倒是熟悉了，出去再找工作，对不起，别的公司不用这个，记住，你的技术能力绝对不能被框架约束住。
7、使用熟悉，成熟的技术。
听到很多创业公司，因为技术负责人一时兴起，用了mongodb，然后就进坑了。
当然，我不是说mongodb不好，而是相关负责人只是听说还不错，指标很好，然后就兴冲冲的去学习。
SEO人才如何直面自己的丑陋
近日追剧，《人民的名义》。这剧是部好剧，至少从我这个普通观赏者的角度看不到什么不大自然的剧情。这要感谢资深编剧周梅森，官场小说第一人。这也要感谢一帮久
