• 工程师成长之路
  • 什么是人才？
  • 怎么识人？
    • 自驱最重要
      • ASK模型
    • Ability（特别是自驱力）怎么考察？
      • 自驱力
      • 其他能力
      • 领导力
    • 考察专业部分 - 要先提升自己的认知
    • Skill 和 Knowledge（专业能力）怎么考察？
      • 必考题——最满意/有成就感/高光的case简单分享一下？
      • 选问题——我们现在有个问题xxx，你怎么看/建议？
  • 要招多好的人？
  • 给多少钱
• 如何提升影响力
• 技术&业务&管理
  • 管理者的工作内容
  • 技术leader要具备什么样的能力
  • 工程师→leader的转变
  • 如何营造团队氛围
  • 管理者自我成长
  • 总结
  • 招聘 (STAR法则)
  • 如何成功搞垮一个团队
• 互联网怪相
  • 人浮于事
  • 不停重构
  • 文化
• 技术文档
  • 机器学习基本流程
  • 代码结构
• 代码评审 Code Review
  • GitLab Code Review机制
  • 为什么要做CR？
  • 怎么保证CR质量
    • 目标
    • 体系结构和代码设计
    • 代码风格
    • 编码规范
    • 日志规范
    • 如何使用 Pylint 来规范 Python 代码风格
  • 如何执行CR
    • CR流程
    • 工作流
  • CR工具
  • CR的实用建议
• 项目管理
  • 互联网项目流程
  • 吐槽
• 华山论剑
• 结束

工程师成长之路

• 陈皓：什么是工程师文化？：自由+效率→创新
• 

【2021-5-12】算法工程师的三个层次

• 第一个层次：operating 使用工具，了解深度学习，tf工具，github上下载代码，跑通业务数据，完成分类、推荐、预估等问题
• 第二个层次：optimization 改造模型，深入了解机器学习的原理和组件，熟练掌握最优化方法
• 第三个层次：objective 定义问题，能够构造准确、可解、优雅的目标函数

• 【2021-11-4】十年创业者，万字长文分享我是怎么招人的, 作者陈桦Grace，MetaApp合伙人，连续创业者，曾任可甜、冲顶大会、节操精选CEO。连续两年入选「福布斯」亚洲区、中国区30位30岁以下商业领袖。

什么是人才？

什么是好的人才？

我在前文中写过自己总结的S、A、B、C级人才定义

• S级人才：心里有火，眼里有光，找方向、带队伍、卷出一片天。
  • 不用告诉他干啥，他来告诉你该干啥。宏观战略到细节战术执行到抓团队结果；发现问题，能自己评估优先级，解决完了还会同步你；学习和进步的速度超过想象，经常感觉卧槽怎么这么厉害；自己能搭起来一个好团队
• A级人才：能打胜仗，作风优良。
  • 能了解并确认你背后的原因和交付物，还往往会多做好几步，产出优秀，及时同步，老板不用追截止日期和进度；定战术到抓结果；发现问题，会和leader确认优先级和方案以后解决问题，之后会复盘如何改进；会有意识的去学习；能配合HR吸引到好人才
• B类人：是各公司内卷和衰落之源。
  • 简历很好看，名校大厂，历次跳槽涨了很多薪水，状态就两个字：油腻。各家一旦加速招聘，都会堆积很多B类人，极大稀释组织人才密度。产出不稳定，及格边缘徘徊，喜欢讨价还价指标，不愿意做份外工作，你不催他不动，有时候还可能没搞好或忘了，不问不会同步进展；发现问题等着别人给流程/推动，leader给了解决方案以后，就照做；不太喜欢学新东西，偶尔学；通常招进来C类人
• C类打工人：推三下，动两下，牢骚一句。
  • 经常自己独立搞不定，需要别人盯很紧和协助，绝不做份外工作；发现问题就抱怨leader能力不够，抱怨公司不重视，吐槽流程吐槽管理，自己就是不去推动；发到眼前的学习材料也都懒得点开看，封闭/躺平心态；通常招进来比自己更差的人

关键核心负责人岗位、高杠杆/影响范围大的岗位（如产品经理）以及有招人权限的岗位，一定尽量找S或A级的，B和C级人才是STRONG NO。因为这些岗位招错人不仅仅是他的工资，更多是机会成本，往往导致整个业务时间被耽误。

怎么识人？

大部分面试官喜欢招有强相关经验的人，因为短期产出高，而忽略自驱力等基本素质，导致长期组织内堆积B/C级人才，而他们又容易招进来比自己更差的人，开出了孽之花，恶性增强回路。

招人是CEO和每一层leader的事儿，而不仅仅是HR的事儿。不仅要为岗位招聘，还要为公司招聘，为公司招到文化匹配的人才。如果有个人能力意愿都很强，但是现在没HC，为公司招聘的人会努力推动他进来。

对于核心关键人才，花了多久时间面试？是不是合伙人级别的人面试1小时就完事儿了？对于普通正式员工，在公司＜500人的时候，面到了CEO/合伙人-1了吗？

自驱最重要

招人最简单莫过于招干过这个事的人 。不过能找到最具合适特质的人更重要。特别是创新企业，很多岗位未必有成熟的人对应，或者业界的普通标准并不 特别适合，或者具体的岗位有一些特别的要求。这时候通过对岗位的理解而去招 具备性格技能爱好特质的人就特别重要。—— 张一鸣

ASK模型

再引用一下BOSS直聘CEO赵鹏教我的ASK模型：

• Ability（底层软素质，爹娘给的），Skill（技能），Knowledge（知识）
• 要万分警惕：多数面试只问了K和S，没有问A。软素质不行，硬技能再高也不能要，这个坑我们踩了上百次
• 一二线厂积累的 Skill 就要很小心，可能只有 Skill 没有软素质，彼之蜜糖，我之砒霜
• S级的人，强主要强在Ability

Ability：聪明 正直 勤奋 上进 普世价值观 逻辑 常识通识 自驱 （这是八条，8 plus+1） + 有感恩之心。这里面我认为最重要的是自驱.

所以其实对于互联网公司这种主要靠脑汁的地方，对于核心关键岗位，我们面试和招人的时候主要还是应该考察 Ability，大部分公司就是被镀金大厂简历B级人才，Skill强 Ability弱 的人坑了；有Ability，进来再学 Skill 和 Knowledge 都很快。

复盘来看我们公司一些绩效差员工的bad case，很多都是能力（这里重点指工作相关的skill）够，但意愿（自驱力）不足的。所以一般遇到员工问题，我都会想这是能力问题还是意愿问题，区别S/A级人才和B/C级人才最主要的地方也是意愿，能力不足可以培养，也可以挪到其他更合适的岗位试试，意愿不够往往扶不上墙。

Ability（特别是自驱力）怎么考察？

自驱力

• 克服过最大的挑战/困难/苦是什么？
  • 如果没有或很弱，通常是过去做的事情挑战不够
  • 重点观察如何解决问题的
• 最近几年的目标是什么？有为这个目标付出过什么？有大概路径吗？
  • 有目标但行动很差的＝光说不练＝减分
  • 没有目标/目标模糊/路径不清晰 = 减分
• 一般几点到公司几点走？
  • 我很少见到不勤奋能做好工作的，但这不是deal-breaker；加班多≠自驱力强，也有加班多但产出很差的，只是自驱的人从概率看通常工作时间比较长
  • 14年张一鸣在找潜在并购公司的时候找我聊，最后问了我一句，你们公司加班多吗？
  • 对于IC（Individual Contributor 个人）来说主要看勤奋；对于TL（Team Leader）主要看能多大程度调动团队产能，一般问团队工作时长情况
• 有什么主动改进工作/改变公司，并有一定结果的case吗？
  • 自驱力更多是有没有意愿主动去改进工作
  • 关注主动自己想改进还是leader安排的任务
  • 改进工作指把本质份内工作搞得更好；改变公司指的是分外工作，但感觉公司需要，就主动去优化

其他能力

• 问一个你擅长，但他大概率不擅长的问题
  • 候选人准备过的问题可能是团队智慧的结晶，而非个人思考；这个是随机题，候选人很难准备到
  • 不预期答得对，看回答的思路，逻辑
  • 反应速度、考虑问题周全程度通常和聪明程度正相关
• 过去一年，有什么进步/高价值认知/改变/收获吗？最后悔什么？
  • 看反思、复盘、总结的能力
  • 看是否喜欢主动思考
• 为什么离职？
  • 吐槽一堆前公司问题，自己一点问题都没有，完全不说一句前公司好话的，通常没有感恩之心
• 人生意义/使命是什么？
  • 遇到S级/超强招的人才可以问下，看下底层价值观是啥，看在乎啥，将来纳入麾下怎么能更好的知人善任激励他

领导力

• 问bad case咋解决的？如怎么降低delay，排期评估有水分怎么压缩，差绩效员工怎么办等
• 团队的人大概多少是自己招的多少是HR招的？
• 团队的人大概背景是啥样？（有不少人说自己团队特别好，展开说下背景发现其实很一般）
• 喜欢用什么样的人？（看对人才的理解到哪个层次，喜欢用Ability强的还是Skill强的）

最怕B类人，觉得过去的经验是真理，不开放心态，说服成本特别高，甚至阳奉阴违，搞大厂生存那一套，非常耽误事儿。

考察专业部分 - 要先提升自己的认知

有时候你可能不是这个领域的专家，快速升级的办法是去把这个领域最好的人聊一圈，不要困在peer里和常规招聘渠道能触及的候选人里。最好是和超过普通想象力的顶级专家去聊：比如和厉害的CEO去请教怎么招人，和大厂高管问怎么思考问题，和优秀投资人聊他见过的CEO谁比较好，为啥… 如果你没有「卧槽，原来是这样」的感慨，那就是聊的人还不够强，还没有显著超越你的认知。不要天天就和原来的圈子聊，发现大家都差不多，觉得自己做的还挺好，世界变了都不知道。

同事问，「那人家为什么愿意见我呢？我能给人家带来啥？」

我说：「你啥也不需要。有个积极向上的年轻人找你聊，如果这个人还有点意思，你也可能会愿意帮忙的呀。」一颗赤子上进之心就够了。

聊完以后回来写笔记，思考，复盘。我和Max经常和别人聊完回来不仅写笔记还复盘讨论，画白板，看哪些适合我们。注意，很多武功基本要学一套，就学碎片容易走偏，也得看这武功是不是适合自己的阶段。

如果不是成熟领域，比如社区/社交产品，那就去把能找到的最好的文章扫一遍，最好找穿越一定周期的文章，带着脑子看，写笔记。

不能把别人说的和白纸黑字印着的都当真理，带着脑子🧠思考，聊几圈看几圈以后，会发现有的文章的局限性，有的人困在自己的经验里，啥是更接近本质或者接近更优解的，会逐渐清晰。

很多时候大家往往没有先去调研顶级人才咋看问题想问题的，直接上来就面试候选人了，然后就容易接触到世面上流通性最强的普通候选人，对「好」对认知可能就有偏差，很明显不是10年以上名厂经验/贵就是好；即便自己大概知道啥是好，但没有真的见过，就会容易怀疑自己是不是要求太高，凑合先把干活的招进来先用着再说。

Skill 和 Knowledge（专业能力）怎么考察？

必考题——最满意/有成就感/高光的case简单分享一下？

问得深远比问得多重要，就一个case问穿；经常会看到初面强招，终面我不招的候选人，就是初面面试官问了一些case但浮于表面，我深入一扒拉发现根本不行。case不在多，在于讲得是不是到位，如果没说到位要追问，重点是校验真实性，比如是他就是边缘参与的还是主要贡献者，为啥做、做了啥、怎么做、做完以后咋样了能不能讲清楚

最高光的case一般都是准备过的，这个问题是直接打在候选人最强肌肉上的，答不好就可以直接pass了，在及格边缘的最多再给一次机会。

• 看思考深度：最好的回答能包括做的结果，为什么做（背景和决策过程，解决了本质问题和做了本质解吗，还是解决的问题就不重要），做了啥，怎么做（解题思路和过程，优雅精巧聪明解还是其实没解决问题）、做完以后咋样（影响范围，是否闭环）
  • i. 如果答得还行，可追问思想实验，复盘再来一次机会，还做不做这个决策，为什么，怎么改进
  • ii. 也可以问关于这个case，你想到的问题/更好的解决方案，看看候选人怎么看，有没想过这些，有没超越你的认知
• 看数能力：一定不能假设工作经验多/工资高的候选人就默认懂很多基础问题，我们就遇到过:
  • 产品经理面试对于感性理解问题都说得很好的，结果问啥是留存不知道，如瞎编一个次留1%，甚至自己就是做数据后台的产品经理，自己完全不去看；
  • 招聘的HR问关键漏斗转化率完全没概念的
  • TL对团队月均offer和入职搞不清的；
  • 数据分析师/UG/优化师对核心基础数据指标对不上，比如A*B=C的，你把ABC分别问了以后自己算一下，发现对不上，你再问他为啥对不上，他就说噢噢可能记错了那是xxx，或是你估计说错一个数问刚刚你说的A是不是A撇呀，他也会说是😅
• 看诚信正直：不懂就说不懂，团队产出就说是团队产出
• 看沟通能力：总分总简洁到位，还是罗里吧嗦没重点
• 看逻辑能力：是否自洽，能不能真正归因；别小看这个，很多人都在瞎归因，经不起推敲
• 看成就动机：看他被什么驱动（drive），这很关键，是知人善任的重要抓手，如果恰好和这个岗位需要所匹配，为上乘
  • 可以总结一下你理解候选人为什么觉得这个case有成就感的地方（如涨幅大/成长快/项目复杂性高/需要协调推动的部门多等）去问候选人是不是这样，有可能不一定理解对了
  • 如果不管说啥都👀都没光都不high，那可以pass；注意是面试过程中个体时间线上比较情绪/状态差异，每个人性格不同，不需要预期手舞足蹈很兴奋

选问题——我们现在有个问题xxx，你怎么看/建议？

如果case讲得比较好，可以追问这题，看候选人解题思路如何，有没有一些自洽/超过你认知的见解

可以暴露出来公司的真正问题，降低候选人入职后的落差感

要招多好的人？

是够用就行还是尽量好？很多老板/leader嘴上说当然招尽量好的，但身体很诚实一直招的是够用就行

• 巴菲特说，不想持有10年的股票，也不要持有10天。我觉得招人也是一个道理，特别对于重要岗位，不想一起工作3年的人，也不应该招进来3个月试试看。

• （1）从0到1，P/MF前阶段，核心团队找能招来的最好的
  • 看业务核心是哪几个岗位，这几个岗位的负责人尽量Ability强，通才优于专才，素质优于经验和技巧，聪明想干事业的年轻人远优于油腻/丧失信仰的职业人。认可你这个人/你们团队，比认可事儿更重要。因为这个阶段往往不会那么顺利，往往不是ups and downs, 是up and down down down down😂 业务都甚至可能会调整。如果候选人只是为了钱/快速增长来的，那一旦不如预期增速容易鸟兽散
  • 找你喜欢的人，看着顺眼聊得来的人，最简单的检验方法是看你想不想下班以后和他出去喝一杯。之前周航说「你只能管理你喜欢的人」，因为在工作过程中，你的微表情经常偷偷出卖了你
  • 如果是创业公司，找真的想创业，探索，做好心理准备，甚至是失败过/挫折过的最好（失败过，但是苦大仇不深的最好），公司就像一个社区产品，早期员工等于种子用户，如果苗子不对，是长不了大树的。OYO中国找了很多贵的人，砸钱不眨眼，然而结果做得非常差，因为贵不等于好，贵也不等于不油腻，公司核心的种子用户不对，后面长出来的就不可能好
• （2）从1到100，放量增长阶段，找超过想象力的最好的！
  • 通常大家还是被想象力限制住的多。永远不要被薪水/对方现在的职级限制想象力去接触好的人，人再贵也比投放便宜，何况还都可以谈；人职位再高，也有看机会的一天。根据工种不同，越是创造性岗位，好的人比普通人的价值高的倍数越多。比尔盖茨说过，软件时代，就是S级人才是普通人才的很多倍，因为边际效益高。字节从比较早期开始就经常动不动挖小公司CEO，这一点真的很值得敬佩
• 📌自测题
  • 一个岗位有两个候选人，面试观察 Skill 和 Knowledge一样，一个工作经验1年，一个5年，应该选哪个？
  • 一个岗位有两个候选人，一个1年工作经验，面试观察 Skill 和 Knowledge 比较低，Ability强；一个5年工作经验，Skill 和 Knowledge 比较强，Ability 弱，应该选哪个？

给多少钱

用投资的心态去想这个问题，投公司最重要的是看商业价值和企业文化，看的是未来现金流折现，那么投人（招人）要看什么？要看ASK，看能力和意愿，看的是为未来产出价值折现。我们之所以开的工资不如股票价格那么高PE（市盈率倍数），是因为未来产出归零（人才离职）的概率通常会比股票更高。

按照上述逻辑，Ability（原生通用爹妈给的能力）是最重要的，特别是自驱力，那么在同等条件下，比市场价高一些的价格给到自驱和潜力高（未来产出价值折现高）的人，ROI是比为Skill（短期可以习得的经验）买单而更高的。这样也会更有可能吸引到好的人和让他工作产出更稳定。

• S/A级人才付溢价绝对值得，因为通常未来产出价值更高；
• B/C类人才的隐形成本是降低人才密度而提升的管理成本、可能过一段时间跟不上发展需要替换的招人成本、耽误业务发展的机会成本，给业务挖坑后面一堆人给他填坑甚至是负向收益。

越早期，雇主品牌越弱的公司，付出的薪酬成本越高是正常的。我有个很好的猎头公司 ITerGet 老板朋友@张正泉 分享过一个33岁的候选人面临的真实case，在大厂3.7万月薪和小厂10万月薪中纠结，非常有趣又残酷。创业公司高管和老板们一看都觉得很震撼，感慨创业公司的钱真不是钱啊！但是你再带入这个候选人心里想一想，快到35岁了，可能要稳定，要简历好看，没去过大厂想看看是啥样想学习下，很常见。

注意不是要无脑用钱砸名企/名校背景的人，段永平说过，捷径是最远的路。

比如OYO中国、乐视和当年的Groupon中国都是典型反例，疯狂用高薪反而容易反向筛选到贪财短视，而非鸿鹄之志者。因为钱而爱上你的人，哪天觉得你没钱了，通常会先走一步，很难一起穿越周期。

对于关键岗位，应当多为Ability买单付溢价，少Skill和Knowledge买单。部分特别需要长期习得经验或市场稀缺的岗位除外。

📌 候选人定薪/定级

• 核心/高杠杆岗位：70% Ability + 20% Skill + 10% Knowledge
• 基层/执行岗位：20% Ability + 70% Skill + 10% Knowledge

如何提升影响力

主要渠道：

• 技术博客：流量
• 自媒体
  • B站、头条号、抖音等
  • 公众号、知乎等
• 开源项目：公布到Github，多少颗星星
• 发明专利：国内专利、国际专利
• 顶会论文：ACL、CVPR、EMNLP、AAAI等
• 知名竞赛，如：MCM、ACM、Kaggle、天池大赛等
• 行业论坛：QCon、InfoQ、AI大会等

• 书籍：

• 图片格式（路径中不能有中文！）
  • 
• 技术影响力提升途径 <img src=”https://img-blog.csdnimg.cn/20200815231353447.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dxdzU0NzI0MzA2OA==,size_16,color_FFFFFF,t_70 height=”100%” width=”100” />

技术&业务&管理

• 【2020-8-11】技术Leader远离代码，就是自废武功？

管理者的工作内容

• 管理者的目标和工作结果主要体现在两方面：
  • 做事：成本、效率、质量。
  • 带人：人才、梯队、成长。
• 太抽象？其实管理者大部分工作都在选择和权限，主要包含以下几个方面：
  • 有限资源的限定下，选择最大化的产出方案。
  • 做出符合当前环境的技术决策，帮助公司产品取得成功。
  • 用方法和工具不断优化和提升生产效率和质量。
  • 图解：
    • 
    • 公司 A 在创业期，还没有稳定的市场和客户，这个时候技术管理者的决策要倾向成本+效率，技术团队偏向全栈型，工作流偏敏捷，快速交付功能获取用户和市场的反馈用于升级和迭代产品。
    • 公司 B 在成熟期，有固定的市场和客户，行业已经没有新的蛋糕，这个时候需要比拼的就是效率+质量，技术团队偏向专家型，注重产品质量和客户体验用于形成行业口碑和用户粘性。

技术leader要具备什么样的能力

• 技术 Leader 需要哪几个比较重要的综合能力：
  • 技术能力和基础知识(能看懂技术表象背后的原理)。
    • 工作内容大多包含：技术选型，技术方案评审，代码审查，技术氛围的营造。
    • 非技术背景的leader，可能无法和技术团队建立共识，沟通成本极高，最终让团队变成一个非常低效的组织，人浮于事
  • 沟通表达能力(逻辑，同理心，情绪控制)。
  • 业务抽象能力(架构和演化)。
• 如何锻炼这些能力？
  • 吃透基础技术和弄懂技术背后的原理

    (万丈高楼平地起，再流行的框架和技术，剥离华丽的外衣也离不开操作系统，网络，数据结构这些原理型的知识)。

  • 了解细节，永远在写代码

    (不熟悉代码就无法提出真正可落地的方案，就无法感知技术团队的痛点在哪里，也就无法团队提高效能)。

  • 持续的学习，持续的为团队带来新的知识和理解

    (技术 Leader 已经是团队技术问题的终结者，不可能再上传递了，所以不要成为技术团队的天花板)。

  • 有一个真心帮助大家的心态(帮助大家成长，提高效能，最终组织效能也得到提高，实现共赢的局面)。

工程师→leader的转变

• 工程师到团队 Leader 有哪些转变
  • 工程师视角：
    • 这个功能怎么做?
    • 需求写完，今天的工作就完成了。
    • 业余时间只看技术相关的内容。
    • 看看今天领导分配了什么工作给我。
  • 技术 Leader 视角：
    • 现阶段要做什么?
    • 团队未来向哪里发展?团队成长不如预期怎么办?公司今年的业绩指标如何可以完成?
    • 除了技术，还需要沟通，判断，组织，协调，看方向的能力。
    • 规划 Q1 季度的工作目标，分解到团队成员去实施，保证工作内容和每个团队成员的能力相匹配。
  • 相对于工程师工作内容的“明确性”，管理者的大部分工作是“不确定性”的，而且没有尽头，也没有一个明确的时间用于标示“完成”状态，这对于习惯“确定性”思维的工程师来说，挑战极大。
  • 比喻：写代码时候的感受是一人吃饱全家不饿，轻松且自由，现在感受是既当爹(做事)，又当妈(带人)，而且还上有老(上级)，下有小(团队)，感觉压力山大!!

如何营造团队氛围

• 程序员的工作大多是本质知识工作者，管理学大师彼得德鲁克说过：“对于知识工作者是无法进行严密的督导”
• 提供一种积极，主动，自驱的工作氛围给团队，让团队在这种土壤里面逐渐形成高效能团队
  • 员工在不同的环境，有不同的产出
  • 发现懈怠的员工，不仅要从员工身上找问题，还可以去思考看看是不是我们周围的人，事，环境，工作方法，价值观等地方找出问题。
• “橘生淮南则为橘，生于淮北则为枳”
  • 
• 高产出员工的两个特质是：
  • 能力(专业知识，技术能力)。
  • 意愿(团队文化，价值观，喜欢的氛围)。
• （1）外部激励
  • 安全感和成就感(稳定的工作环境，完成有难度的挑战，及时反馈 BIA)。
  • 学习和成长环境(和优秀的人共事，感知到自己成长)。
  • 和管理者定期沟通(让员工感到自己被重视，收集员工建议并且做出工作上的调整)。
• （2）自驱力和凝聚力
  • 很多企业都期望员工可以有 Owner 精神，但是如果想要团队保持足够的自驱力，管理者可能要思考是否对团队做到以下几点：
    • 给予员工自主性(工作内容上的自由度，工作方法上的自由度，工作时间和地点上的自由度)。
    • 成长(明确的工作目标，内容有挑战，工作发挥其优势)。
    • 意义和使命(共同的目标和愿景，价值观)。
    • 信任和放权(共同面对挑战，团队内的对抗活动)。
• （3）沟通技巧
  • 《圣经·旧约·创世记》第 11 章通天塔的故事
  • 如果人们不愿意，或者不会沟通，那么就很容易产生分歧，误解，从而导致大家分裂，大家的目标就会失败，那么管理者很多事情是需要通过沟通传达，让团队达成方向共识，齐心协力，最终完成企业的目标。
  • 良好的沟通能带来什么?
    • 管理者对团队的总体认知和判断力得到提升。
    • 和团队成员之间建立信任和默契(信任的前提是充分的沟通，信任程度越高，沟通成本越低)。
    • 高质量的沟通可以帮助管理者在团队建立和累积影响力。
  • 注意事项
    • 认清个体差异(每个人的生活环境不同，对于不同的角色要学会用不同的沟通和表达方式)。
    • 基于目标沟通 (明确各自沟通的意图和目的，减少不必要的误会，避免情绪对抗)。
    • 多用我来回放(可以把：你是不是这个意思，换成你看看我理解的是否准确)。
  • 沟通技巧的核心在于学会倾听，对于还未掌握沟通技巧的同学，推荐一个沟通工具 3F 倾听，照着做也可以称为沟通小能手。
  • 
• （4）情绪控制
  • 聊到沟通不得不聊情绪控制，为什么管理者要避免情绪化，学会控制情绪 ?
  • 大脑皮层处理本能情绪的优先级是高于理性的，例如愤怒，恐惧，饥饿等，所以经常看到被本能情绪覆盖的人，往往会失去某种理性。
  • 沟通时注意控制情绪，保持理性。发脾气是本能，控制脾气才是能力。
    • 冰山图
    • 
  • 出现“部门墙”的情况就是因为之间没有共同的上级，也无法相互影响。
    • 相向为竞，同向为争
    • 能力复用，真正共建。
    • 更合理的方法：公司有没有现成的解法？多大程度上复用？能不能改进？技术共建，相互促进
    • 
  • 遇到这种情况可以通过如下几个切入点去达成沟通的共识：
    • 人格：有口皆碑的人品和正直的人格可以让别人更加容易信任你说的内容，并且被你影响。
    • 历史表现：你曾经成功完成过相同的事情，就是成功案例，可以让别人更加容易相信你。
    • 影响力：你是行业的知名人物或者是团队公认的专家，权威的力量。
    • 逻辑：你的内容前后呼应有着紧密的逻辑，可以增加说服力。
    • 激情和情怀：心怀某种远大的理想主义，并且有使命感有激情，比较容易获得人们的帮助和认同，可以参考锤子手机的成功案例。
    • 互惠：明白对方的需求，沟通的目的是建立在满足双方的需求上。
  • 容易踩的坑儿
    • 沟通给人贴标签，对人不对事(例如：你这个人怎么这么笨，这点事情都做不好)。
    • 没有管理自己的情绪，负面情绪对团队造成影响。
    • 沟通没有闭环，消息和邮件发出去就默认对方收到了。
      • 沟通有没有闭环对应计算机网络中的 TCP 协议(可靠网络传输)和 UDP 协议(不可靠的网络传输)，建议大家在沟通中尽量多的使用 TCP 协议。

管理者自我成长

• 为什么说管理者要比团队拥有更快的成长，因为管理者是团队的天花板，你不成长则团队不会成长。
• 那么管理者的自我认知首先要体现在哪些方面?
  • 认知：管理者的价值是体现在团队业绩上，不要跟团队抢功劳。
  • 心态：归因于己，归功于外，有错都是管理者的错，有功劳都是团队的努力。
  • 担当：不要推卸责任，就算是客观原因，也要反省和复盘避免，而不是把责任推给外部。
• 三十左右刚刚成家的管理者，可以抽出的时间基本是少之又少。
• 如果还想在赛道上赢得竞争力，就要保证自己有足够的时间和身体的健康
  • 运动(每天定期的运动，可以让你保持一个持续充沛的精力，也更加容易专注)。
  • 饮食(健康饮食，少吃多餐)。
  • 睡眠(早睡早起，不要熬夜)。
  • 健康(定期检查，避免久坐)。
  • 情绪(放松，感恩，好心情)。
• 持续努力的目标是有两个：
  • 软技能的提升：产品思维，项目规划，带团队，带人，沟通，执行力。
  • 硬技能的提升：架构，设计，算法，网络，操作系统，编程语言。
• 很多人总是有误解，认为已经是团队 Manger 就不需要去做具体的执行工作的，起码这一点对于技术管理是行不通的。
• 技术管理者要一直写代码，因为
  • 如果不了解技术细节就无法做出有效的决策
  • 管理者如果脱离技术，也是很危险的一件事情，因为市场对管理者的需求并不多，市场需要更多的工程师去写代码，管理者更多的价值是依附于企业，其很多业务知识也并非可迁移的技能。
  • 管理者放弃技术的话可谓是“自废武功”，也会让自己陷入一个很尴尬的境地，上不去，也下不来。

总结

• 做技术还是管理都不是很重要，找到自己最大的价值才是最重要的。

• 不要被别人走过的路限制住，也不要被职业限制住，没有谁可以定义你的发展。

• 中国的官本位思考挺严重，很多人以为做管理就是当官，但是在软件行业其实并不存在这一现象。
• 大多数互联网公司都是偏向扁平化管理，管理者在工作中并没有本质上的不同，而且管理者的工作更多的是偏向“打杂”(工程师视角)。
• 如果抱着当官这种心态去做管理，初衷就已经错了，先在这里劝退，因为最终也可能会走向失败。
• 管理者更多的是要有利他精神，空杯和开放的心态，真正愿意去帮助团队成功，通过成就他人来收获成就感。
• 关于技术管理的道理长篇大论说了很多，道理都很简单，能不能走好管理路，还是要在“事上练”，自己感悟出来的道理才能真正的为自己所用

招聘 (STAR法则)

• 【2021-5-19】STAR法则，在产品设计的应用和思考

在招聘面试中，有一种目前常用的面试方法，叫STAR法则。

• STAR是单词Situation、Task、Action和Result的首字母。 图

STAR 法则四要素：

• Situation：事情是在什么情况下发生，基于一个怎样的背景；
• Task：你是如何明确你的任务的；
• Action：针对这样的情况分析，你采用了什么行动方式，具体做了哪些工作内容；
• Result：结果怎样，带来了什么价值，在整个过程中你学到了什么，有什么新的体会。

STAR法则自从2008年在《高效培训》一书中被提出后，就被广泛应用在培训和面试领域。STAR法则在实际的面试过程中，有两种常见的用法，分别适合单面和群面。

• 第一种适合单面，即通过STAR法则询问候选人的工作经历。
  • 面试官可以仔细、深入地询问候选人其中一段最贴近招聘岗位要求的工作/项目经历，要求候选人详细地描述当时的环境（Situation）、工作目标（Task）、具体的工作事项（Action）及最终获得的成果（Result）。
  • 在面试过程中，面试官应对自己特别注重的方面进行追问，从而获得对候选人更全面深刻的认知。一个好的候选人往往需要提前准备好阐述工作经历，面试过程中认真聆听问题，清晰明了地回答问题，并在回答中展现候选人的工作态度和能力范围等。
• 第二种适合群面，即通过STAR法则开展无领导小组讨论。
  • 面试官（们）可提前设计好一个讨论场景（Situation）和最终目标（Task），要求多位候选人自行进行讨论，并得出最终结果。在无领导小组讨论过程中，面试官可以观察每位候选人如何不断向目标靠近（Action），并最终获得了什么结果（Result），从而挖掘候选人的能力范围。
  • 面试官也可以在讨论结束后要求每位候选人再进行自我阐述，佐证自己对候选人的判断。

STAR法则浅显易懂，而且对面试和简历都有非常直接的指导意义。而笔者认为：STAR法则同样适用于产品设计中，如果遵循STAR法则，我们的产品设计和交互设计会做得更好！

STAR法则对产品设计的思考 图

在设计功能时，我们同样需要考虑用户场景（Situation）、功能目标（Task）、用户行为路径（Action）和最终产品效果（Result）。STAR面试法则，是从四个角度去描述一份工作/项目。而STAR产品法则，是从四个维度去思考并验证一个产品功能，STAR产品法则应当贯穿在产品设计到上线后的整个过程当中。

如何成功搞垮一个团队

【2021-2-4】管理者如何快速搞垮一个团队：

1. 控制欲爆棚
   • 对项目的进度事无巨细一律插手，对团队成员的工作时间、执行方法、思想动态一律控制。
   • 这种领导极度缺乏安全感，控制欲极强，他们的内心充满自卑胆怯。生怕员工哪方面超过自己，哪方面对自己形成挑战。
   • 在他们手下干活，毫无成长不说，还得提心吊胆不知道哪句话哪个动作就触犯了领导敏感的神经。
   • 讲个真实的小故事吧：洋哥有个读者和领导拍照执意要站最中间，触犯了大忌讳。随后被连续穿小鞋，三个月后愤而离职。
2. 甩手掌柜
   • 这种领导，官本位思想严重，真把自己当一个大官了。高高在上只负责发号施令，只安排工作不去检查Review，也不给下属提供支持和资源。
   • 出了问题？那当然是下属的锅！事情做崩盘了就牺牲一两个下属，推出去斩首示众，然后继续做甩手掌柜。
3. 毫无诚信
   • 明年加薪是他们的口头禅，给下属的承诺从来只是一句空话。当然他们也没欺骗下属，明年嘛没毛病。
   • 等到下属抗议之际，他们会搬出各种大道理，诸如：公司现在还在困难之际，你怎么这么看重个人利益？我都把你当兄弟了，你就别跟我谈利益。你是组织重点培养对象，要学会长期主义！
4. 形式主义
   • 他们喜欢看下属加班奋斗的样子，谁敢早走？那一定是工作不饱和有严重问题，要马上安排一场严肃的one on one。
   • 他们喜欢精美绝伦的PPT，并坚信不会画PPT的架构师都是辣鸡。他们喜欢听漂亮话甚至是拍马屁，毕竟沟通都不会的下属，肯定不能重用。
   • 他们偶尔还会朋友圈纵览群臣，看看哪些下属在发加班动态，时不时点个赞，表示已阅以示鼓励。那些天天发生活动态的下属？工作状态一定有严重问题！
   • 至于工作结果？他们不太能作出很好的区分，反正表面工作最重要。
5. 任人唯亲
   • 身边最重要的岗位当然要安插多年的亲信了，甚至七大姑八大姨弄进公司来也是极好的。
   • 至于干活很牛逼的人？让他们继续干活不就好了。人才对公司而言最重要，什么是人才？那一定是听话的心腹。
   • 听话的心腹好处多多，你让他往东绝不往西，至于一些隐蔽的小事更是需要他们来执行。
6. 刚愎自用
   • 所有人都会犯错，尤其是下属容易犯错，至于我？从不会犯错。我说的话就是圣旨，你们执行就好。
   • 这类领导的权威不容许半点挑战，即便方案有问题，最好别反驳，反驳就是想离职。既然想离职？那送你一程好了。
7. 玩弄权术
   • 有些管理者，对权术的熟练运用简直是一种天赋。他们能容忍甚至重用品行低劣的下属，只是为了力量的平衡。
   • 有的时候，他们还会故意制造下属之间的敌对情绪，适当制造矛盾以防止各种「势力」产生不利于自己的联合。
   • 他们翻脸比翻书还要快，忽然将其下属捧上天，忽然又将某下属按下地，还要用脚摩擦。

互联网怪相

人浮于事

• 不停的开会、讨论，没时间写代码

• 2-3个人干活，十几个人领奖

• 团队或部门里的人员越来越多，整天都在开会，都在互相解释，互相争吵，会扯淡的人越来越多。那还有个屁的效率。

不停重构

互联网研发人员常见的想法：

• 自己开发的模块，懒得写注释，总觉得很简单，是常识，没必要写；接手新模块时，又抱怨上任文档不全，没有注释，一边苦苦思索，一边骂娘。。。
• 每次交接就意味着信息大量丢失，文档（有就不错了）一般只有项目的1/3，口头什么的，最不靠谱了
• 接手别人的模块时：
  • 能不动就不动，免得踩雷伤着自己
  • 实在不行，就走钢丝，小心翼翼修复
  • 有抱负的人，重新造轮子，按自己的习惯重构。
    • 衡量项目收益（ROI）时，往往不认为重构，不会给太多精力，总是默认系统是正常的。
    • 所以，向那些敢于顶住压力，重构老古董的人，致敬！
• 等到交接出去，又被人重构。。。

文化

• 如何委婉的给程序员提bug？聪明且傲娇的群体
  • 方式一：
    • 提问：你的程序有bug
    • 程序员：①你的环境有问题吧？②傻逼你会用吗？
  • 方式二：
    • 提问：这个程序与预期有点不一致，你看看是不是使用方法哪里有问题？
    • 程序员：草，是不是哪里出bug了！
• 

技术文档

• wiki
• 模块代码：readme文件、requirement.txt、install文件

机器学习基本流程

• 
  • 参考：机器学习总结
• 分为三个步骤:
  • 数据准备与预处理
  • 模型选择与训练
  • 模型验证与参数调优

代码结构

目录结构

什么样的代码是好代码

总结：

编码规范、高内聚低耦合、可复用、简单易懂易维护、洁癖、其他（注释、打日志、边界条件）

一个模块一般具备以下结构、文件

• readme.md
  • 模块介绍，包含：业务背景介绍（附相关文档链接），基本功能，部署方法
  • 目标：让小白一眼看明白，减少信息偏差
• data（非必须）：数据目录，包含：
  • train.txt
  • test.txt
  • validation.txt（可选）
• bin（或src）：核心代码，算法模块主要包含：
  • model.py：模型定义
  • feature.py：特征工程部分，离线训练和在线评估都有
  • train.py：模型训练代码
  • predict.py：在线预测（inference，推断）
• model：模型存放
  • 注意：模型文件一般较大，不放git，另外有文件服务
  • 比如，公司内部用模型平台（支持本地磁盘+hdfs）
• log（非必须）：日志目录
  • 训练日志，如tensorboard日志
• conf：配置文件
  • 注：配置信息脱离代码
• common（非必须）：公共库、组件
  • alarm.py：报警模块
  • log.sh：shell彩色日志工具
• requirements.txt：
  • 前置安装包,Python版
  • 非python：如C++对应makefile文件
• install.sh
  • 部署文件，如环境变量配置（便于导入common库），安装包pip install -r requirements.txt
• test（非必须）
  • 测试文件，如单元测试（非必须）
  • 数据分析文件

代码评审 Code Review

• Code Review 的首要目的是改善和保证代码质量，预防 bug。
  • 时机：每次代码CheckIn之前进行
• 此外还有益于制定团队代码规范，形成团队技术氛围，加深技术团队成员沟通，老带新互助成长等等。
• 有些团队里 Code Review 处于开发流程的边缘位置，有些团队 Code Review 处于代码编写到部署的必经部分。
• 对于我们来说，Code Review 是代码编写到部署的必经部分，所有代码都必须经过 Review 才能 merge。

git和gitlab系列：

• master: 枝干, 拿到手后第一件事请就是设置为Protected. 所有Master Branch的变化必须经过PR来改变, 避免初级程序员犯错误. 基本上和Production挂钩.
• dev: active branch, 基本上和Staging挂钩.

• adong/feat-branch: 用 用户名/feature 格式来命名, 可以在SourceTree 和 Github里面用树形结构来显示. 没有什么特别的意义.

• 【2020-7-11】陈皓：代码有这几种级别：
  • 1）可编译
  • 2）可运行
  • 3）可测试
  • 4）可读
  • 5）可维护
  • 6）可重用。
• 通过自动化测试的代码只能达到第3）级
• 通过Code Review的代码少会在第4）级甚至更高。
• 关于Code Review，你可以参看本站的《Code Review中的几个提示》

GitLab Code Review机制

• GitLab可以在分支合并的时候支持两种方式：
  • 在本地将源分支(Source branch)代码合并到目标分支（Target branch）然后Push到目标分支（Target branch）
  • 将源分支(Source branch)Push到远端，然后在GitLab指定目标分支（Target branch）发起Merge Request，对目标分支（Target branch）拥有Push权限的用户执行Merge操作，完成合并。
• 也就是说，使用GitLab进行Code Review就是在分支合并环节发起Merge Request，然后Code Review完成后将代码合并到目标分支。

为什么要做CR？

• CodeReview的目的提升代码质量，尽早发现常见、普通的缺陷与BUG降低修复成本，同时促进团队内部知识共享，帮助更多人更好地理解系统；

Code Review 主要有以下目的：

• 发现错误：人都会不可避免的出现一些纰漏，而这些纰漏在另一个人眼中也许显而易见。
• 健壮性检查：代码是否健壮，是否有潜在安全、性能风险。代码是否可以回滚。
• 质量保证：在一般情况下，新提交的代码一定需要写测试，测试不只可以保证你的提交符合预期，还可以在后人改你的代码时有一层保障。同时，MR 阶段也有机器人自动检查当前分支的测试覆盖率是否低于主分支，当低于主分支时会标红警示，但不会禁止 merge。
• 统一风格：对于整个团队来说，代码风格的统一很重要。风格统一除了人 Review，我们也引入了静态代码检查，不符合团队风格的代码，是无法通过 CI 的。
• 完善注释：包括 commit message、代码中复杂实现是否有解释性的注释、紧急 hack 是否明确标注等。
• 互相学习：保证组内人员良好的沟通，使得产品代码更容易维护

一般来讲，一个 MR 不宜过大。如果是大的 feature 改动，可以分成多个小 MR 分次提交。

• 同时，人是不可靠的，所以写测试非常重要。
• 同上，人是不可靠的，所以静态代码检查非常重要。
• 同上，人是不可靠的，所以各种自动化的工具非常重要。

怎么保证CR质量

目标

• 代码review总结
  • 
• 注意：
  • Code reviews 不应该承担发现代码错误的职责。
    • Code Review主要是审核代码的质量，如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。
    • 代码中的bug和错误应该由单元测试，功能测试，性能测试，回归测试来保证的（其中主要是单元测试，因为那是最接近Bug，也是Bug没有扩散的地方）
  • Code reviews 不应该成为保证代码风格和编码标准的手段。
    • 编码风格和代码规范都属于死的东西，每个程序员在把自己的代码提交团队Review的时候，代码就应该是符合规范的，这是默认值，属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。
    • 我个人认为“meeting”是奢侈的，因为那需要大家在同一时刻都挤出时间，所以应该用在最需要的地方。代码规范比起程序的逻辑和对需求设计的实现来说，太不值得让大家都来了。
• 【2021-2-2】第一天上班看到这段注释就想辞职

体系结构和代码设计

• 单一职责原则：一个类有且只能一个职责。我通常使用这个原则去衡量，如果我们必须使用“和”来描述一个方法做的事情，这可能在抽象层上出了问题。
• 开闭原则对于面向对象的语言，对象在可扩展方面开放、对在修改方面关闭。如果我们需要添加另外的内容会怎样？
• 代码复用：根据“三振法”,如果代码被复制一次，虽然不喜欢这种方式，但通常没什么问题。但如果再一次被复制，就应该通过提取公共的部分来重构它。
• 换位考虑，如果换位考虑，这行代码是否有问题？用这种模式是否可以发现代码中的问题。
• 用更好的代码： 如果在一块混乱的代码做修改，添加几行代码也许更容易，但我建议更进一步，用比原来更好的代码。
• 潜在的bugs：是否会引起的其他错误？循环是否以我们期望的方式终止？
• 错误处理：错误确定被优雅的修改？会导致其他错误？如果这样，修改是否有用？
• 效率： 如果代码中包含算法，这种算法是否是高效？ 例如，在字典中使用迭代，遍历一个期望的值，这是一种低效的方式。

优秀程序设计的18大原则

良好的编程原则与良好的设计工程原则密切相关。本文总结的这些设计原则，帮助开发者更有效率的编写代码，并帮助成为一名优秀的程序员。作者Diggins是加拿大一位有25年编程经验的资深技术人员，曾效力于Microsoft和Autodesk，并创办过两家赢利的互联网公司。

1. 避免重复原则(DRY - Don’t repeat yourself)
   • 编程的最基本原则是避免重复。在程序代码中总会有很多结构体，如循环、函数、类等等。一旦你重复某个语句或概念，就会很容易形成一个抽象体。
2. 抽象原则(Abstraction Principle )
   • 与DRY原则相关。要记住，程序代码中每一个重要的功能，只能出现在源代码的一个位置。
3. 简单原则(Keep It Simple and Stupid )
   • 简单是软件设计的目标，简单的代码占用时间少，漏洞少，并且易于修改。
4. 避免冗余代码 Avoid Creating a YAGNI (You aren’t going to need it)
   • 除非你需要它，否则别创建新功能。
5. 尽可能做可运行的最简单的事(Do the simplest thing that could possibly work)
   • 尽可能做可运行的最简单的事。在编程中，一定要保持简单原则。作为一名程序员不断的反思“如何在工作中做到简化呢?”这将有助于在设计中保持简单的路径。
6. 易懂(Don’t make me think )别让我思考！
   • 这是Steve Krug一本书的标题，同时也和编程有关。所编写的代码一定要易于读易于理解，这样别人才会欣赏，也能够给你提出合理化的建议。相反，若是繁杂难解的程序，其他人总是会避而远之的。
7. 开闭原则(Open/Closed Principle)——复用、可扩展（实体开源、细节封闭）
   • 你所编写的软件实体(类、模块、函数等)最好是开源的，这样别人可以拓展开发。不过，对于你的代码，得限定别人不得修改。换句话说，别人可以基于你的代码进行拓展编写，但却不能修改你的代码。
8. 代码维护(Write Code for the Maintainer)——易于交接
   • 一个优秀的代码，应当使本人或是他人在将来都能够对它继续编写或维护。代码维护时，或许本人会比较容易，但对他人却比较麻烦。因此你写的代码要尽可能保证他人能够容易维护。用书中原话说“如果一个维护者不再继续维护你的代码，很可能他就有想杀了你的冲动。”
9. 最小惊讶原则(Principle of least astonishment)——不要秀神技！
   • 最小惊讶原则通常是在用户界面方面引用，但同样适用于编写的代码。代码应该尽可能减少让读者惊喜。也就是说，你编写的代码只需按照项目的要求来编写。其他华丽的功能就不必了，以免弄巧成拙。
10. 单一责任原则(Single Responsibility Principle)
    • 某个代码的功能，应该保证只有单一的明确的执行任务。
11. 低耦合原则(Minimize Coupling)
    • 代码的任何一个部分应该减少对其他区域代码的依赖关系。尽量不要使用共享参数。低耦合往往是完美结构系统和优秀设计的标志
12. 最大限度凝聚原则(Maximize Cohesion)
    • 相似的功能代码应尽量放在一个部分
13. 隐藏实现细节(Hide Implementation Details)
    • 隐藏实现细节原则，当其他功能部分发生变化时，能够尽可能降低对其他组件的影响
14. 迪米特法则又叫作最少知识原则(Law of Demeter)
    • 该代码只和与其有直接关系的部分连接。(比如：该部分继承的类，包含的对象，参数传递的对象等)
15. 避免过早优化(Avoid Premature Optimization)
    • 除非你的代码运行的比你想像中的要慢，否则别去优化。假如你真的想优化，就必须先想好如何用数据证明，它的速度变快了。
    • “过早的优化是一切罪恶的根源”——Donald Knut
16. 代码重用原则(Code Reuse is Good)
    • 重用代码能提高代码的可读性，缩短开发时间。
17. 关注点分离(Separation of Concerns)
    • 不同领域的功能，应该由不同的代码和最小重迭的模块组成。
18. 拥抱改变(Embrace Change)
    • 这是Kent Beck一本书的标题，同时也被认为是极限编程和敏捷方法的宗旨。
    • 许多其他原则都是基于这个概念的，即你应该积极面对变化。事实上，一些较老的编程原则如最小化耦合原则都是为了使代码能够容易变化。无论你是否是个极限编程者，基于这个原则去编写代码会让你的工作变得更有意义。

面向对象设计原则

• 面向对象七大设计原则。《设计模式之禅》

设计原则名称	定 义	使用频率
单一职责原则(Single Responsibility Principle, SRP)	一个类只负责一个功能领域中的相应职责	★★★★☆
开闭原则(Open-Closed Principle, OCP)	软件实体应对扩展开放，而对修改关闭	★★★★★
里氏代换原则(Liskov Substitution Principle, LSP)	所有引用基类对象的地方能够透明地使用其子类的对象	★★★★★
依赖倒转原则(Dependence Inversion Principle, DIP)	抽象不应该依赖于细节，细节应该依赖于抽象	★★★★★
接口隔离原则(Interface Segregation Principle, ISP)	使用多个专门的接口，而不使用单一的总接口	★★☆☆☆
合成复用原则(Composite Reuse Principle, CRP)	尽量使用对象组合，而不是继承来达到复用的目的	★★★★☆
迪米特法则(Law of Demeter, LoD)	一个软件实体应当尽可能少地与其他实体发生相互作用	★★★☆☆

代码风格

• 方法名： 在计算机科学中，命名是一个难题。一个函数被命名为get_message_queue_name，但做的却是完全不同的事情，比如从输入内容中清除html，那么这是一个不准确的命名，并且可能会误导。
• 值名：对于数据结构，foo or bar 可能是无用的名字。相比exception， e同样是无用的。如果需要(根据语言)尽可能详细，在重新查看代码时，那些见名知意的命名是更容易理解的。
• 函数长度： 对于一个函数的长度，我的经验值是小于20行，如果一个函数在50行以上，最好把它分成更小的函数块。
• 类的长度：我认为类的长度应该小于300行，最好在100内。把较长的类分离成独立的类，这样更容易理解类的功能。
• 文件的长度： 对于Python，一个文件最多1000行代码。任何高于此的文件应该把它分离成更小更内聚,看一下是否违背的“单一职责” 原则。
• 文档：对于复杂的函数来说，参数个数可能较多，在文档中需要指出每个参数的用处，除了那些显而易见的。
• 注释代码： 移除任何注释代码行。
• 函数参数个数：不要太多， 一般不要超过3个。。
• 可读性： 代码是否容易理解？在查看代码时要不断的停下来分析它？

编码规范

• Google专门在 code.google.com 上建立了一个项目：Google Style Guide ，给出了一系列 google style guides，Google 开源项目风格指南 (中文版)，包括：
  • C/C++编码规范，中文版
    • 【2020-8-4】C/C++语法规范，摘自：一张图总结Google C++编程规范(Google C++ Style Guide)
  • Python编码规范
  • JavaScript编码规范
  • Objective-C编码规范，中文版
  • HTML/CSS 编码规范
  • Json编码规范
  • Shell编码规范

日志规范

• 日志级别等级
  • CRITICAL > ERROR > WARNING > INFO > DEBUG > NOTSET

# coding:utf8
import logging 
if __name__ == '__main__':
    #[2018-1-17]http://blog.csdn.net/zyz511919766/article/details/25136485/
    # 设置日志格式,日志文件(默认打到标准输出),模式(追加还是覆盖)
    # 日志级别等级CRITICAL > ERROR > WARNING > INFO > DEBUG > NOTSET
    #logging.basicConfig(level=logging.DEBUG,format='%(asctime)s %(filename)s[line:%(lineno)d] %(levelname)s %(message)s',datefmt='%a, %d %b %Y %H:%M:%S',filename='test.log',filemode='w') 
    logging.basicConfig(level=logging.DEBUG,format='%(asctime)s %(filename)s[line:%(lineno)d] %(levelname)s %(message)s',datefmt='%Y-%M-%d %H:%M:%S',filemode='w') 
    logging.debug('debug message') 
    logging.info('info message') 
    logging.critical('critical message')
    # 创建一个logger,不用调logging包
    log = logging.getLogger()
    log.debug('debug')
    # 日志等级大全
    log.debug('logger debug message')
    log.info('logger info message')
    log.warning('logger warning message')
    log.error('logger error message')
    log.critical('logger critical message')

如何使用 Pylint 来规范 Python 代码风格

• pylint工具安装：

sudo pip install pylint --ingore-installed

使用：pylint test.py

结果：

• MESSAGE_TYPE 有如下几种：
  • (C) 惯例。违反了编码风格标准
  • (R) 重构。写得非常糟糕的代码。
  • (W) 警告。某些 Python 特定的问题。
  • (E) 错误。很可能是代码中的错误。
  • (F) 致命错误。阻止 Pylint 进一步运行的错误。

问题：

• No config file found, using default configuration——解决：生成pylint配置文件，touch ~/.pylintrc
• C: 19, 0: Trailing newlines (trailing-newlines)——删除多余的空行
• C: 17, 4: Invalid constant name “new” (invalid-name)——全局变量名字全部大写
• C: 9, 0: Exactly one space required after comma——多参数时，逗号后加空格
• C: 13, 4: Invalid variable name “s” (invalid-name)——局部变量命名过短，3个字符以上(避免单字母，除了计数器+迭代器；避免双下划线开头并结尾；避免包/模块名中的连字符-)，_开头表示protected，__开头表示private
• C: 10, 0: Old-style class defined. (old-style-class)——类定义中没有加object。，类名大写字母开头（pascal风格，如CapWord，模块、函数名小写字母与_，如lower_with_under.py）
• R: 10, 0: Too few public methods (1/2) (too-few-public-methods)——缺少修改类属性值的方法
• C: 25, 0: Trailing whitespace (trailing-whitespace)——行尾有空格

如何执行CR

CR流程

• 

之前也思考过怎么充分发挥code review作用，积累的经验：

• （1）ci/cd流程（genkins）与git集成，每次git push都会自动触发code review机制
• （2）cr评审方法：每个子方向设置1-2个owner，几个commiter，3人以上通过才算过，owner有一票否决权，特殊场景可以授权
• （3）如何统一标准？每次组会留出5-15min，随机抽取commit代码片段，公开评审
• （4）如何保证评审质量？对照Google开发规范，建立代码委员会，不止是资深工程师，谁都可以申请，但需要公开评审，过关
• （5）如何提升积极性？每次cr的质量和次数算个人积分，作为”华山论剑“得分项之一，季度评奖，重奖轻惩（考虑到自尊心）

工作流

• 基于gitlab的code review教程
• 

解说：

• 需求确认后，从master创建develop分支
• 开发人员从develop分支创建自己的feature分支进行开发
• master分支发生变更，需要从master分支合并到develop分支、可以考虑定期合并一次
• feature分支合并到对应的develop分支之前，需要从develop分支合并到feature分支
• feature分支合并到对应的develop分支之后，发布到测试环境进行测试
• develop分支在测试环境测试通过之后，合并到release分支并发布到预发布环境进行测试
• release分支在预发布环境验证通过后，合并到master分支并发布到生产环境进行验证

CR工具

• Code Review 工具：
  • Crucible：Atlassian 内部代码审查工具；
  • Gerrit：Google 开源的 git 代码审查工具；
  • GitHub：程序员应该很熟悉了，上面的 “Pull Request” 在代码审查这里很好用；
  • LGTM：可用于 GitHub 和 Bitbucket 的 PR 代码安全漏洞和代码质量审查辅助工具；
  • Phabricator：Facebook 开源的 git/mercurial/svn 代码审查工具；
  • PullRequest：GitHub pull requests 代码审查辅助工具；
  • Pull Reminders：GitHub 上有 PR 需要你审核，该插件自动通过 Slack 提醒你；
  • Reviewable：基于 GitHub pull requests 的代码审查辅助工具；
  • Sider：GitHub 自动代码审查辅助工具；
  • Upsource：JetBrain 内部部署的 git/mercurial/perforce/svn 代码审查工具。

CR的实用建议

• 转自：程序员客栈
• Code Review 的几点实用性建议：
  • 1. 对事不对人。
       • 大家是同事，在一个团队工作和气很重要。不要在 Code Review 中说“你写的什么垃圾东西这种话”，你可以说“这个变量名不好理解，咱们换成巴拉巴拉是不是更好”。
  • 1. 每个 Review 至少给一条正面评价。保持积极态度
       • Code Review 本意是改善代码质量，增强团队成员之间的沟通，但是我一提交代码就有人说我写的垃圾，这很打击自信心啊，也不利于团队成员和平相处。代码有问题，指出问题是必须的，要实事求是，但是有的时候也需要给队友一点鼓励，例如简单的 或者“赞一个”我都很开心了。
  • 1. 保证发布的代码和评审意见的可读性。
       • 大家都是程序员，你提交代码的时候，在符合团队风格的同时，把代码弄的好看点，如果你明确自己这个代码哪个地方不足，Highlight 出来让大家给意见。如果你是来 Review 代码的，把意见写的通顺点，评论有条理一些。对反引号 () 嵌入代码或三个反引号 (``) 写代码块，这样看的舒服得多，效率也高。
  • 1. 用工具进行基础问题的自动化检查。
       • 用 Tab 还是空格，用两个空格还是四个空格，函数后面怎么换行等基础问题检查，可以使用 eslint 和Rubocop 等类似的工具进行，团队成员应该把更多精力放在代码规范，代码性能优化等地方。
  • 1. 全员参加 Code Review，并设定各部分负责人。
       • 扩大 Code Review 参与面，参与不是说一定去审核别人的代码，可以是代码被审核，也可以是看别人审核意见，这都是学习的过程。并且每部分设定负责人，该负责人对这部分代码质量负责，负责人需要是资深工程师。全员参与 Code Review 可以让团队成员更快的成长，新人在看大佬 Review 代码的过程就能学到很多。
  • 1. 每个代码 PR 内容一定要少。
       • Code Review 效果和质量与 PR 代码量成反比，你一下提交这么多代码，我今天还下不下班了？ 我女朋友你帮我陪？每次 PR 代码量小一些，看起来速度快，又不至于失去耐心，这样才能达到 Code Review 的效果，所以要经常进行 Code Review，但是每个 PR 代码量要少。我建议要少于 300 行/PR。
  • 1. 在写新代码之前，先 Review 掉需要评审的代码。
       • 你让我去 Review 一周前的代码？我还得把思维和项目进度切换到一周前？大家肯定不愿意，所以要形成规定，写新代码之前先把旧的 Review 掉，提交 PR 的时候也保证代码量小，这样 Review 起来不需要大块时间，改起来也快。不能因为 Code Review 大幅耽误项目进度，进度是全团队的事，不是某个人的事。
  • 1. 如果你有更好的方案，尽管提出来。
       • 在 Code Review 中经常会发现写的不好的地方，如果你有更好的方法，欢迎提出来！首先能改进这个 PR 的代码，其次能体现你的能力，团队应该定期对这种提出好的解决方案的同事进行奖励。
  • 1. 不要在 review 中讨论需求，review 就是 review。
       • 不要在 Code Review 里搞别的，有需要就另安排时间进行，要明确 Code Review 是完善代码，不是需求和功能讨论，始终要以代码质量为中心。
  • 1. 尽可能的让不同的人Reivew你的代码

项目管理

• 【2020-8-7】有哪些带团队的好方法

互联网项目流程

• 
• 互联网公司中的人来来往往，大家都在干啥呢? 公司由一个个Team组成，而一个个项目又把不同Team连接在一块。
  • 摘自：笑谈互联网项目流程
• 完整流程
  • 

吐槽

• IT产品速成记
• 背景：看到一幅图，互联网工作风气，入木三分，由感而发：

  • 好大喜功风气盛，急于求成险中生
  • 不论团队人几个，披星戴月封闭行
  • 一朝成名万般抢，但出事故众人推
  • 无名戳中苦笑点，最苦莫过匠心人

华山论剑

• 团队内部技术竞赛
  • 腾讯云问卷调查
• csdn地址
  • 

结束