软件构建的核心就是管理复杂度。 - 《Code Complete》

最近笔者加入新公司，又开始一段新的程序员之旅。每次最头疼的还是上手已有的很多代码仓库，看别人的代码一直是一件痛苦的事情(理解最初的编程意图是最难的问题)，不过好处就是又学到了很多新东西，又了解到自己有多菜。最近又重新翻看了《代码大全》，摘抄了一点东西。如果说软件工程领域非得让我推荐一本书的话，无疑是这一本大而全的代码百科全书（虽然有点陈旧），汇集了很多编程技巧和工程领域的研究成果，很有启发，也正是这本书让我在编程上从野路子走向正规军。笔者一直感觉自己智商平庸，很想与高手程序员一起工作，看看别人是怎么解决问题的。我感觉高手和菜鸟最大的区别，除了智商、基础知识、自控能力以外，就是编程的习惯与思维方式的不同了。好在后面的特质都是可以学习和改善的，加入一个好团队就比较重要了。另外，对于团队而言，一个人的杰出能力往往不是那么重要的，开发流程和方法却会对产品质量产生很大影响。更反直觉的是，技术领域由于发展迅速过往经验有时候反倒是个阻碍。笔者现在写代码总有一种如履薄冰的感觉，生怕上线后出错跪了(在众多代码仓库中定位和修复 bug 也是个不小的挑战)。当然笔者也看到，很多厉害的技术老手也会犯一些低级错误，人的思维总是会有疏漏的，所以更要考良好的习惯、规范和工作流程克服人的思维疏漏。工作的过程中也感觉到，自身的沟通能力还是有待提高啊。。。

Write code that writes code. Code generators increase your productivity and help avoid duplication.

天下武功，唯快不破

每当我们启动一个新项目的时候，总有很多重复性工作，创建后端app模板就是其中之一。如果是使用django还好，django提供了生成项目app的命令直接创建，不过貌似现在很多pythoner都倾向于用flask这种微框架。虽然很多成功的项目是基于django（Instagram，Disqus，Pinterest等）构建，不过笔者还是更喜欢flask这种微框架。flask的好处在于你可以随意替换插件（ORM，模板等），相比django更加灵活。缺点就是有时候会选择困难，不知道如何组织大型项目，而且需要学习各种flask的插件，实际上把flask一套插件都整明白也需要一定的学习成本。今天笔者介绍的这个Cookiecutter项目就是专门用来解决项目模板生成问题的，经过了python3.5.2生产环境的检验。

Everything Should Be Made as Simple as Possible, But Not Simpler. - Albert Einstein

我觉得编写软件的过程就是和和复杂度斗争的过程，无论是编写传统的pc软件还是web应用。对于python这种动态语言，很多问题是在运行时才暴露出来的，而且动态语言相对难以维护和重构。我一直感觉使用动态语言的时候要更加重视项目工程的管理，控制复杂度，防止代码仓库失控。了解一些常用原则降低复杂度还是有必要的。

Do one thing, and do it well. - A principle of Unix philosopy

学习和使用vim有几年了，我的编辑器学习之路也该告一段落了，目前使用vim和一些插件基本能满足日常代码和文档(博客，笔记，代码文档)的编辑需求了，也无力折腾其他编辑器了。现在大部分时间都是在终端和vim里工作，我觉得在vim上花的时间还是值得的。本博客所有的文章都是在vim里写的，配合markdown插件可以在浏览器里即时预览。本博客是《Practical Vim》读书笔记，不是一本入门书，以一个个tip的形式组织，凝聚了作者的使用智慧，结合自己的使用经验做个简单的记录。

A SQL query walks into a bar and sees two tables. He walks up to them and asks, “Can I join you?”

最近看了一本小书，网易技术部的《深入浅出MySQL数据库开发、优化与管理维护》，算是回顾一下mysql基础知识。数据库一直是笔者比较薄弱的地方，结合自己的使用经验(python+sqlalchemy)等做个记录，笔者比较喜欢使用ORM，一直感觉拼sql是一件比较痛苦的事情(主要是不擅长sql)，以前维护项的目中也遇到过一些数据库的坑，比如编码问题，浮点数精度损失等，防止以后重复踩坑。

Abstraction is not about vagueness, it is about being precise at a new semantic level. - Dijkstra

笔者之前学习python的时候就对这几个概念有些困惑，尤其是python3之后又不断添加了yield from, async, await等关键字用来支持异步编程。最近看到一篇比较好的博客就结合自己的理解翻译并解释一下这些概念，包括生成器，协程，原生协程和python3.5引入的async/await。 请使用python3.5运行代码示例。

Optimization hinders evolution. - Alan Perlis

最近扫了一本《High Performance Python》，该书从多个角度比如性能度量(profile)，内置数据结构调优，并发，多进程，多线程，使用C加速，异步，分布式，内存调优，其他网站使用经验等介绍了python优化经验，看得出几位作者的计算机体系结构和python功底很深。笔者非计算机科班出身，有些知识点超出了我的能力范围，不过多了解一些东西对于以后技术调研和选型还是很有帮助的，简要记录下涉及到的一些东西。

看一场，教一场，做一场。 -外科手术先驱 William Halsted

其实我觉得刻意练习挺适合编程领域的，一直很好奇那些编程领域的牛人们是如何思维的，不过一直没多少机会接触。用一定的方法练习虽然成不了牛人，但是至少能做到一个合格的工程师。我觉得这本书最好的思想就是让我们用一种『成长性』思维看待问题，不断用合适的方法磨练专业技能。

Use a single editor well. The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable. - Andrew Hunt

平常总是用那些大神们写的vim插件，今天闲来无事学写了一下vim插件，顺便写一个简单的教程。
先来看下我一个旺盛的需求：平常总会遇到分享本机或者服务器代码的情况，我经常使用paste.ubuntu.com网站粘贴代码(我记性不好总是忘记scp咋使的)，然后把链接分享给别人。类似github的gist服务，不过比较简单，而且gist国内用户访问有时候会出现奇奇怪怪的问题，所以一般我用ubuntu的pastebin多一些。但是步骤麻烦点，我写这个插件就是要一个命令帮我完成在vim里直接贴代码到paste.ubuntu.com的功能。

Metaclasses are deeper magic than 99% of users should ever worry about. If you wonder whether you need them, you don’t (the people who actually need them know with certainty that they need them, and don’t need an explanation about why). - Tim Peters

平常都是写业务逻辑，从来没有使用过元类这种黑魔法（好吧，目前的编码规范是不推荐在业务逻辑当中使用元类的，不好维护并且一般来说并无这个必要）。不过貌似只有造轮子的时候才会用到，就像上边的引用里说的，当你不知道为什么要使用元类时，你是没必要使用它的,大部分时间python灵活的特性已经可以应付几乎所有业务问题。最近重新看了下元类，突然有了一种霍然开朗的感觉，用几个简单的例子介绍一些元类(使用python3.5)。

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler, “Refactoring: Improving the Design of Existing Code”

可能又要被说吹毛求疵或者有代码洁癖了，但是最近协作的时候感觉代码风格不统一，看代码的时候很不方便。实际上良好的代码排版，包括何时分行，何时使用括号都是有讲究的。
良好的代码排版给人看下去的欲望，同时还能让人分清主次重点，方便快速理解代码。讲一下自己对一些编程细节的看法。

The grammar specification should be a natural-looking part of the Python program, easy-to-read, and familiar in style and format to Python programmers. - Zen of Pyparsing.

上篇博客在讲设计模式解释器模式的时候提到了pyparsing库，当时用该库处理命令从而实现了很简单的DSL，这次详细介绍下该库。 pyparsing是一个文本处理库，可以用来处理html，日志文件，复杂数据结构或者命令的解析等。比如去除源码中的注释，或者写个简单的DSL等。

Patterns mean “I have run out of language.” - Rich Hickey

之前学习设计模式的时候总是没有什么感觉，因为记性不好一直没记住多少。python不像java中比较强调设计模式(编程套路)，动态语言也内置了像是装饰器、迭代器等模式，另外python中的『一切皆对象』、鸭子类型等也导致python中实现的设计模式和其他语言有些差别。根据YAGNI(you aren’t gonna need it)和KISS(Keep it simple sutpid)原则，如果能用简单易懂的方式实现，最好不要滥用设计模式以免增加复杂度和维护难度。本博客是《Mastering Python Design Patterns》的读书笔记，涵盖大部分设计模式(力求pythonic实现)，有兴趣可以参考下，代码示例版本为python3.5.2。（3.6都发布了，已经被时代遗弃😢……)

从实习到现在使用python也快两年了，虽然经验依旧不多，不过维护旧项目和开发新项目好歹也都经历过，记录下想法就当年终总结吧。很多东西是之前没参与项目协作的时候没有注意到的，要不就是踩了坑才知道的。和人协作项目以后才真正意识到代码首先是写给人看的，其次才是让机器执行的。

易编写，难维护

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.- John Woods

python做项目给我的感觉就是易编写，难维护。一方面是动态语言本身的特性，比如没有类型声明，难以重构等；另一方面就是团队流程和规范的问题，没有严格的流程控制提交代码的质量。目前很多使用python的公司都是小公司，很多流程不正规，没有编码规范，没有文档，没有注释，没有静态检测(pylint)，没有code review，没有单元测试，没有持续集成等等，最终的代码质量可想而知，维护和新人上手成本很高，代码仓库很容易失控(野蛮开发技术债会越积越多)。一开始我认为python号称『伪代码』语言，应该是更易读易理解的，后来发现我错了。python给你一种代码很好写的错觉，很容易就写出烂代码。

I think a lot of new programmers like to use advanced data structures and advanced language features as a way of demonstrating their ability. I call it the lion-tamer syndrome. Such demonstrations are impressive, but unless they actually translate into real wins for the project, avoid them. - Glyn Williams’

最近重新复习下常用算法和数据结构，下边是看该书大致记的笔记和代码，纯手敲，有兴趣的可以参考下，都是基于python3.5 class实现，所以也算是复习了一下OOP。虽然思想都是通用的，但是使用的语言也会影响到我们的思维，我会结合一下使用python的经验来稍微分析下各种数据结构和其操作的复杂度，以便灵活选用。实现一个数据结构后最好写一些单元测试用例，否则没人知道你写的究竟对不对。坑爹的是本书有很多代码错误甚至实现错误，调试花了我很多时间。同时你还会发现很多坑爹的网络算法教程文章代码直接拷贝根本不能用，没有单元测试证明算法正确性的都是扯淡。

Test early. Test often. Test automatically. Tests that run with every build are much more effective than test plans that sit on a shelf.

最近开始做公司内部项目，CRM系统（客户关系管理）， 用的flask+python3.5.2。我以前闲着没事逛逛github的时候发现了这个cookiecutter-flask，就是用来生成一个项目模板的东西，直接帮你生成项目总体框架还有README文件，还是比较方便的，直接填写逻辑即可。以前并没有使用flask的经验，这次也是边摸索一边使用（好在没碰到坑），主要想记录下关于单元测试的东西。crm主要是crud操作，这次我比较重视测试代码编写，web项目单元测试需要处理数据库交互，模拟请求，模拟登录，表单提交等操作，如何编写易于构建和执行的单元测试也是需要注意的地方。新项目统一用flask+python3.5.2(python3库的支持比我想象中快，目前使用的依赖中都支持python3)，前端使用vue，前后分离，后端使用flask-restful写接口。贴出来一些代码，如果写得不合适的正好可以给我指正下:)

Unix was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things.

如果你是用mac或者linux，这些工具的配合能大幅提高工作(装逼)效率(并且在服务器上也能用)，本文不打算具体介绍安装方式，请自行google，主要介绍下vim一些好用的插件，说实话，真正感觉vim好用是因为github上很多牛人写的好用的插件。（当然如果你用IDE我强烈推荐Pycharm, 其实编辑器用不好反而容易写出烂代码，还是推荐不想折腾的用PyCharm，最好用的python开发工具，pycharm+vim插件也比较爽）。无论用什么工具，首要目的都是提升开发效率。

vim小Tips

• 更改键盘设置映射capslock到ctrl，ctrl使用非常频繁
• 使用ctrl+[ 或者 ctr+c 代替 Esc
• vimrc中加入两行inoremap <c-l> <c-o>:w<cr> 和 nnoremap <c-l> :w<cr> 保存文件，再也不用每次都使用:w了，insert和normal模式下都可以用
• Chrome安装vimium可以在浏览器里使用vim命令浏览网页
• 高亮当前选中单词，写代码的时候高亮选中的相同单词，方便查找引用。F3激活

1
2

autocmd CursorMoved * exe exists("HlUnderCursor")?HlUnderCursor?printf('match IncSearch /\V\<%s\>/', escape(expand('<cword>'), '/\')):'match none':""
nnoremap <silent> <F3> :exe "let HlUnderCursor=exists(\"HlUnderCursor\")?HlUnderCursor*-1+1:1"<CR>

Use exceptions for exceptional problems. Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.

最近在尝试搭建错误日志收集工具Sentry，发现用docker-compose工具运行起来非常方便。 目前的项目捕捉异常比较简陋，一般代码发生异常之后，写个函数发一封邮件把异常信息附上。 一开始只是在邮件附带了异常消息，但是没有加上函数调用的参数和变量值，导致问题排查起来比较困难。 后来函数加上了个locals()返回的字典返回当前函数内部变量信息，算是方便了一点。不过最近发现了神器 Sentry， Sentry’s real-time error tracking gives you insight into production deployments and information to reproduce and fix crashes.

在ubuntu server上搭建个一个尝试了一下（也可以直接用官方提供的服务），感觉还是非常强大的，界面也比较漂亮。

Test your software, or your users will. “Test ruthlessly. Don’t make your users find bugs for you.”

最近看了Axb的自我修养写的关于好代码，烂代码和单元测试的一些文章，挺受启发的，结合python讲一下自己对单元测试的理解和操作。

单元测试是什么

单元测试（又称为模块测试, Unit Testing）是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

我不是个伟大的程序员，我只是个有着一些优秀习惯的好程序员”。 —Kent Beck

因为之前实习和工作的经历都是做新项目，对于维护老项目和阅读旧代码也没太多经验，踩了一些坑。笔者在还没有彻底了解业务的情况下就重构代码，导致延误了项目进度。so naive啊。。。。。。
最近感受最深的就是项目规范化很必要，尤其是多人协作的时候。人多了的时候，不同人的水平和代码风格差异很大，如果没有统一的规范，不同的人写的代码太个人化，有时候还有很多坏味道，导致协作和他人上手很困难，项目进度也会受到影响。
另外就是程序员需要的技能还是很多的，除了写代码实现需求，还需要能够很好地理解业务，和PM，测试，其他开发人员的沟通也很重要(甚至深刻理解业务需求比编码都难，我发现我的很多做法还没摆脱典型的学生思维，囧…)。随便记录一些东西吧：