内部分享内容，原作lvxy

程序员能力分析，工作能力与技术水平(工作能力=业务理解+特定领域技术水平+工作习惯)如何提升自己对应的工作能力(三部分 表结构 拼sql写代码)如何提升自己的全面技术水平(很多老生常谈了)
一些好的工作习惯 思维方式 工作的时间安排
如何进行代码逻辑的抽象

核心:减少重复:代码上 人的行为上，重复的工作让计算机去做，但是你要告诉它如何做，而你“告诉它如何做”的这个高速的工作，一般来说比你自己做更麻烦，但是是值得的，因为虽然这一次麻烦了,下一次就简单了(因为已经写好了,直接用就行),并且这也是。

好的习惯:(都是老生常谈，看很多很牛的人和书(以及王垠)，说的也都是这些东西。这些也都不是我说的，我只是看了以后觉得有道理，分享给大家。核心是四个象限的理论，多花时间在重要而不紧急的事情，少花在紧急而不重要的事情。)
1.可以很麻烦一次，不要麻烦很多次
2.DRY不要重复3.多动手摸索，用少量代码来验证核心逻辑，更加要多动脑，减少无谓的时间浪费。搭建自己的摸索环境,减少动手摸索的门槛。4.研究或摸索的核心是试错，多尝试各种可能性，不要预设限制
5.试错成本的几种模型:动脑 讨论 纸笔 少量代码的验证 核心逻辑的验证 自测 正规测试 线上发现 客户发现，尽早在最低成本的阶段发现问题 解决问题
6.做个有心人 发现不爽的地方，研究怎么解决; 研究时间都花在哪了 有一定的洁癖 处理pycharm中的下划线提示

长期来说,能力提升最快的几个途径
1.有明确目标的任务驱动,从动手中学习2.提问和讨论问题(待着开放的心态)
3. 记录工作日志(详细)
4. 教会别人
5.写博客

两种:1,提升工作能力(在结婚事业部);2,提升自身技术能力

有一些是能快速提升

有一些是苦功夫,要花一定时间啃骨头还有一些是中长期的能力提升

比喻:写英文小说
1.首先得知道自己要写什么,肚子里有一个好故事,类比于对业务的理解2.用中文写出来,类比于拼sql
3. 用英文写出来,类比于写Python

看文章或写文章,比如英文的王者荣耀攻略.首先你自己水平得非常高,你才知道怎么写,然后你的中文文字表达能力也要不错,才能写出来好的中文攻略,然后你的英文词汇和表达能力也要不错,才能翻译成英文攻略.写代码只在Python上面花功夫,就好像写王者荣耀攻略只在文字上花功夫一样,是不够的.本质还是需要你游戏打得好,对游戏理解的深刻,写出来的东西水平才高.

对于我们的业务开发(功能开发)来说,业务逻辑和写代码的能力是同等重要的,但核心还是业务逻辑先要清晰.业务逻辑的核心就是需求所对应的sql语句.如果连对应的sql语句都没搞清楚,Python写出来就更搞不清楚了.即便把Python代码摸索着写出来了业务逻辑,也会很慢.以及其他坏处.不是先写Python,一边写Python一边摸索业务逻辑写成什么样,而是先把业务逻辑搞清楚,对应的sql语句写出来,写代码的时候只是把sql代码翻译成pyhton代码(SQLAlchemy函数)而已.

一个较好的工作流程:
1. 研究需求,对照tapd,确保脑子里已经知道了需求是什么意思,达到如下程度:

1. 大概知道需要操作哪些表,新建哪些表的哪些字段,

2. 大概知道接口文档需要修改或新增哪些接口 新增或修改哪些VM用小本记下来.在这个阶段花费的时间不应少于25%.这些研究和思考的工作应该在tapd阶段就已完成,后面最多只是有略微的调整.
2. 写接口文档,由于前面已经做了研究,在这个阶段就是纯粹的打字而已,最多不超过2小时.3.主要的探索业务逻辑的阶段:打开navcat或pgAdmin:

1.打开相关的表,看看需要操作哪些字段,以及在相关的表做哪些查询,关联哪些表,影响哪些表,总结出相关步骤.(这些步骤也就是业务逻辑),以及建表语句

2.尝试着手动增删改查一些数据,印证自己上一个阶段想出来的逻辑,特别是表的关联性.如果业务太简单这一步可以省略,直接拼sql.

3.拼sql:把上一个阶段手动做的增删改查,用sql语句写出来.

包括造数据的语句.执行几遍sql.这些sql,也就是核心的业务逻辑.完成了这一步,也就搞明白了所谓的业务逻辑.第三个大步骤所花费的时间,视需求的复杂程度而定,如果需求比较复杂,在第三步花费的时间不应少于开发接口花费总时间的40%.如果是特别简单的需求,拼写一遍sql也是有益的,第一,需求简单了,sql也不会多复杂,拼一遍也花不了多长时间.第二,把语句存起来将来导数据 改bug的时候也用得上.

4. 写Python代码:

1. interface(handler)从web框架接收服务端请求的参数
2. bz业务逻辑
3. dp操作数据库查询
4. bz把查询的原始数据(数据库数据raw data, row)转换成vm

如果项目架构比较简单(比如我们目前的项目就算是比较假单),可以不用严格的区分bz和dp层,把通用的代码抽象出子函数即可.

最理想的工作状态:1.先花80%的时间,通过看tapd,与产品和客户端讨论,拼sql等工作,把要做的事情想明白2.再画20%的时间,纯粹打字,把逻辑用Python代码写出来

不同的人情况不同,侧重点不同,比如Python比较熟,就会觉得Python这个阶段不是问题.目前发现,绝大多数,本质上都是拼复杂sql不太会拼.极少数是关于Python语言本身的问题(知道怎么做,不知道用Python怎么做).

工作能力方面:
1. 我们数据库的结构,重点关注:

1.每个表的每个字段都是干嘛的,对应于产品视角的哪项业务,用户视角的产品视角的哪个控件,如下语句可以查询所有表的所有字段:

2.表之间的关系,主键和外键如下语句可以查询所有表的外键以及它们引用了哪些表的哪些键

select
table_name, column_name, ordinal_position, is_nullable, data_type, udt_namefrom information_schema.columns where table_schema = 'public'
order by table_name, ordinal_position
;

SELECT
tc.table_name, kcu.column_name,
ccu.table_name AS foreign_table_name,ccu.column_name AS foreign_column_name
FROM
information_schema.table_constraints AS tc
JOIN information_schema.key_column_usage AS kcu
ON tc.constraint_name = kcu.constraint_name
JOIN information_schema.constraint_column_usage AS ccuON ccu.constraint_name = tc.constraint_name
WHERE constraint_type = 'FOREIGN KEY'
order by ccu.table_name;

如上两个查询,可以存在excel里面,好好啃一遍记熟了.以及也随时查阅.记得越熟思维越快.

2. 拼sql的能力
1.基本语法<SQL必知必会>.看书并结合我们项目的需求和库结构,主动用上相应的关键字和

语句.重点在于join order by group by 子查询count等等.这一步是基础.2.进一步的语法,对于读来说,就是视图,对于写和计算来说,就是存储过程.我们目前的项目没有

太复杂的需要用到存储过程的程度,对于很多任务使用Python脚本来完成,可以暂时忽略存储过

程.对于视图来说,可以对照着我们项目现有的几十个视图(虽然这些视图本身定义的有可能还不够好,但胜在结合实际),在只知道它的功能的情况下,不看视图的定义自己拼出来.这是现成的教材.

以上两项对于提升工作能力和效率有非常根本的作用.

3. 写代码的能力1.通用的代码能力,核心:抽象思维，提升抽象的层次2.对Python语言本身的掌握，阅读文档

1.基本类型:序列类型list tuple string字典类型 dict set字符类型 及其操作，所有内置(builtin)类型

2.常见的内置函数 所有的内置函数

3.常见的标准库好的代码:

1.即便不懂逻辑，从视觉上(排版上)看也比较优美。一个一个的盒子，整齐划一而有错落有致。或者多对比标准库和好的开源库
2.名字占了代码的绝大多数，一定要定义的合理简洁
3.直接使用语言自带的特性、语法、库

4.消除重复的字符串 把类似的逻辑合在一起 工作在更高的抽象层面
5.从底层往上构建 逐步组合成复合对象
6.复用的好处:管理复杂性 麻烦一次永久收益 提升思维层次技术能力
7.过多的if else说明可以进行从参数到函数的映射<代码大全>一书主要讲通用层面的如何写出好代码,王垠的<编程的智慧>一文写的也很好,可以认为是<代码大全>的缩略版.http://www.yinwang.org/blog-cn/2015/11/21/programming-philosophy

几种编程范式:
0.命令式编程
1.面向过程 只有方法(method)与变量 有结构体 面向过程可以解决大部分普通问题。过程式思考，对过程的抽象。hq项目中的大部分代码，连这一层次的抽象都没有很好的进行。2.面向对象 属性与方法的封装 设计模式的用武之地 有状态和行为的对象，预定义对象的行为，便于继承中的复用 具体在hq项目中，大部分其实是用不上class的。因为从代码逻辑上来说非常简单，接收请求 查询数据库 封装对象。

除了三个地方:
1.ORM的model，便于处理从数据(库)对象
2.vm的封装，便于统一json化3.tornado规定处理web请求必须继承自handler，自定义一个基类可以省略很多重复工作

2. 函数式编程最基本的理念是函数是一等对象，可以动态生成，可以作为参数传递，可以动态修改，可以作为返回值

传递普通变量作为参数:可以适应不同的状态或条件。传递函数:可以使用不同的过程。Python只提供了这一次层面的函数式编程支持。

变量名要短，表达不清楚的用注释来解释方法的代码行数要少:除非可以明显提升性能 或者开发时间比较紧急

减少重复的字符串:
1.handler里一个字符串出现三次不如只出现一次(见hq_app_server/urls.py)2.两个函数里有一些相似的代码，说明需要一个子函数和两个业务函数，一共三个这两步已经可以减少50%的冗余代码3.如果发现很多重复的代码都是众多函数调用同一个函数，似乎该用到某种设计模式，或者高阶函数了

对于Python来说两种常见的抽象方式:子函数和装饰器,如果两个函数有点像,有些地方完全一样(或者除了变量以外完全一样),有些地方不太一样:
1. 头和尾不一样,中间一样:用子函数,把中间一样的代码抽象出来
2.头和尾一样,中间不一样:用装饰器,把头尾一样的代码抽象出来

完全一样的代码一定要提取出来,如果较为类似(大部分一样,略微不一样)的代码,可以按如下方式考虑:1.看能否增加中间变量,把不一样的地方用变量来指代,把一样的代码抽象成函数,用传递变量的方式来实现不同的条件或状态.

python具有一些元编程的特性,getattr和setattr,能够仅通过纯字符串来访问变量的属性.并且类型本身也可以作为一个对象.所以传递的中间变量也可以是一个类型或者一个类型的属性.

2.进一步来说,如果增加中间变量不能解决,可以考虑增加中间函数来指代不一样的逻辑,把一样的代码抽象成函数,把不一样的地方定义为函数,"把不同的函数当做参数来传递"的方式来实现不同的逻辑.(这可以认为是初级的函数式编程,同时也是设计模式中的所谓策略模式.如果用Python,可以不用考虑所谓设计模式).

3.更进一步来说如果已经把通用的代码抽象成函数,并且有很多很多函数都调用这个函数,就要开始考虑这些函数是否在逻辑上具有内聚性,是否需要把这些函数组合在一个或一些继承层次的类里,父类实现骨架方法,子类实现特殊方法.(所谓模板方法)

如何进行抽象，并不难解释，也不难理解，关键在于多动手练习、熟能生巧。从简单的开始，循序渐进，先找感觉，后理逻辑。当然了，对业务逻辑掌握的越好，抽象会越合理，这是最根治的。

进行合理的抽象之后,模块之间大多是正交而不是平行的关系,从一维的线性结构,变成多维空间

结构.代码更少,容纳的业务逻辑更多,扩展性更好.结构更有序简洁,便于阅读 维护 修改.当然对程序员的要求也更高了