奔跑吧,程序员
⭐⭐⭐⭐
如果你打算技术创业,那应该全书阅读;如果你没有这样的打算,推荐针对性阅读。作者由于身处外国,很难针对国内读者提供实质帮助,更多是思路上的。
产品部分,打开了技术开发者的视野;技术部分,特别是代码整洁部分,主要是思路,更细致的落地还需要看别的参考书。例如,《代码大全》、《重构》等;团队部分,求职、招聘对招聘者和应聘者都有值得思考的地方。
总体来说,还是推荐阅读的。
产品
何为创业
创立公司最合适的原因就是你对某个想法充满热情,非要把它带给全世界。
何为科技创业公司
从事技术研发、环境总在变化、目标为了增长、商业模式还在探索的公司。
入职创业公司
更多机会
在创业公司中编写代码,有更多机会影响别人。
高灵活度
自主权、掌控力和使命感。
更多乐趣
痛并快乐着。
创业公司真相
并不光鲜亮丽
创办公司和解决有趣的技术问题之间存在巨大的差异。
做出牺牲
只有你愿意把生命的下一个十年都花在开创一家公司上,你才能去做这件事。
不一定发家致富
1/4 的概率才能成功
创业点子
混搭和重新组合是产生电子的常见方法。创新的最佳方式是研究、注明出处、重新合成、聚合和转换。
积累知识
专注于自己领域的同时,扩展到其他领域。让自己感兴趣的内容和其他领域进行结合。
环境准备
充足的思考时间;
记录点子;
不做任何评判的记录,包括问题、想到的解决方案、当时的环境,并定期回顾。
定期放空自己;
与信赖的朋友交谈;
业务 = 点子 + 执行力。持续的好点子和高效的执行力,二者缺一不可。
验证点子
验证点子是否大到有必要建立一家创业公司去解决。
- 频率:你所解决的问题经常发生吗?
- 密度:有很多人都会面临这个问题吗?
- 痛苦程度:该问题只是让人讨厌,还是绝对必须解决?
估算市场规模
广告、竞争、社区、市场研究报告、产品数据;
进一步与客户交谈
- 对该客户而言,那是一个真正的问题吗?
- 针对该问题,有什么可能的解决方案?
- 该客户愿意支付多少钱去解决这个问题?
设计产品
- MVP 产品
- 客户参与;
产品设计
界面就是产品,设计不仅仅是看上去的样子,还关乎它如何使用。
设计
设计就是如何去呈现信息,让他人可以理解并使用这些信息。
- 设计是迭代的;
- 用户为中心;
- 用户故事:从用户角度简短描述你所做的东西。1. 用户是谁?2. 要实现什么;3. 为什么需要?
- 人物角色:模拟出使用产品的虚构角色。1. 特定目标;2. 性格;3. 真正用户;
- 情感设计:把产品当作人来对待。1. 考虑周到;2. 积极响应;3. 宽容;
- 简单:精简而没有多余的东西。
- 可用性测试:1. 记录用户使用过程;2. 团队分析;3. 每月重复;
- 视觉设计
- 文案:产品设计的核心;
- 重用:模仿他人的产品后,进行修正;
- 布局:留白和对齐;
- 排版:行宽、行距、字型;
- 对比:突出差别;
- 强调:突出重点;
- 颜色:只有在布局和字体都决定后,颜色方案才有意义;
MVP
Minimum:“最简”意味着所有对当前假设的验证没有直接帮助的东西都应该被排除。
Viable:“可行”意味着 MVP 能够让客户接受它。
(1)找出风险最大、最重要的设想;(2)把这种设想以一种可测试的假设描述出来;(3)构建一个最小的实验(一个MVP)去测试你的假设;(4)分析结果;(5)用新发现去重复第一个步骤。
类型
- 页面展示:容易实现、成本低、效果出众;
- 介绍视频;
- 众筹;
- 绿野仙踪:模拟真实产品;
- 拼凑;
差异
MVP 中要突出差异性。
数据营销
数据
数据就是如何把一些假设和猜测转变为具体、可操作的行为。
数据测量的回报符合长尾。最初几次的回报最可观,后续越来越小。
选择指标标准
- 如果我可以测量X,它至少会影响一个具体的决定吗?
- 该决定的价值超过测量X的成本吗?
必备指标
- 获取:用户如何找到你的产品;
- 激活:测量有多少用户被你的产品所吸引,进行了账号注册、邀请朋友、执行搜索或者支付等动作;
- 留存:让激活的用户回来并再次使用你的产品;
- 推荐:不仅仅在于它是我们获得用户的一个来源,也是衡量产品质量的一个指标;
- 收益:赚了多少钱,这些钱是通过什么渠道获得的;
数据引入开发
- 开发过程:发布前,增加 A/B 测试;
- 完善 MVP:A/B 测试后,完善开发 MVP;
(1)做一个MVP。(2)对其进行A/B测试。(3)分析结果并做出下面三个决定中的一个。a.改善:测试得出的数字不错,足以证明我们能够进一步完善MVP,回到步骤1。b.发布:测试得出的数字非常好,并且产品已经完成,可以向所有人发布。c.放弃:测试得出的数字并不好,不足以证明应该继续工作,可以转到下一个点子上。
营销
营销就是如何让用户找到你的产品,并且影响他们对产品的感知。
口口相传
- 更好的产品;
- 出色的客户服务;
- 病毒式循环;
市场推广
- 广告:严格跟踪用户获取渠道,这样才能判断广告是否有效;
- 公共关系与媒体;
- email:根据用户所关心的活动或事件相应地发送个性化的邮件;
- SEO:对网站进行优化,让网站在搜索结果中有较高的排名;
- 社交媒体;
- 集客式营销:利用客户觉得有价值的内容去引起关注,而不是像广告那样去购买客户的关注。
销售
- 自动化销售:无须交谈就可以完成购买;
- 内部销售:工作场所完成;
- 外部销售:需要去客户现场演示;
品牌化
不是最出色的产品胜出,而是客户认为最出色的产品胜出,这就是品牌的力量。品牌的建立与具体的产品关系不大,它关乎的是情感和信念,关乎公司为何存在而不是公司是做什么的。
技术
技术栈
熟悉什么就用什么。不要因为某项技术听起来很酷 / 有趣就选择它,而是因为它易于扩展,便于维护,以达到支持更多用户、更多流量、更多数据和更多代码。
要关注用户需要什么,其他任何花时间的事情都是浪费。初期,产品的用户和代码都不多,所以可扩展性并不是太大的挑战,要做的就是尽可能快地进行迭代。
自研、商业产品还是开源
flowchart TB
Start[需要满足业务\n需要新技术]
r1{是否是商业上的\n竞争优势或秘密武器}
Start --> r1
n1[内部实现]
r1 --> |是|n1
r2{是否有开源项目\n可以实现大部分需求}
r1 --> |否|r2
r3{是否有开源项目\n可以实现部分需求}
r2 --> |否|r3
r4{是否有商业产品\n可以实现满足需求}
r3 --> |否|r4
n2[购买]
r4 --> |是|n2
n3[使用开源产品]
r2 --> |是|n3
n4{{贡献补丁或插件}}
r3 --> |是|n4
n4 --> n3
n5{{实现并将其开源}}
r4 --> |否|n5
n5 --> n3
编程语言
走起来的公司,可能需要从熟悉的技术栈切换到更适合的编程语言中。
- 适用问题;
- 编程范式;
- 性能需求;
代码整洁
编程是让他人了解你想让计算机做什么的艺术。
pie title 开发人员时间分布
"阅读代码" : 455
"编写新代码" : 9
"非编码任务" : 500
"更新现有代码" : 36
技术债务的真正成本不在于它会导致更多的 bug 和错过最后期限,而是会让人痛苦。优雅的解决方案会让人愉悦,丑陋的拼凑则会让人悲伤不已。而悲伤的人生产效率更低、表现欠佳,最终将会离开公司。
破窗理论在代码上的应用和在建筑上的应用一样。如果代码库到处都是丑陋的修改和乱七八糟的代码,每一个新到的开发人员都在添乱而不是将它理顺。随着难看的代码越来越多,把代码理顺就会变得越来越难,问题只会加速发展。
要尽快地把坏掉的窗子修好,坚持编写整洁的代码,并重写得更整洁。
扩展性
扩展性有 2 种,第一种是对编码实践过程进行扩展,以应对更多的开发人员、代码和复杂性的需求;第二种是扩展代码的性能,以应对更多的用户、流量和数据的需求。
可扩展性不是一个布尔属性。
编码实践的扩展
自动化测试
自动化测试会给你做出修改的自信。
分类
- 单元测试:对一个单独函数 | 类进行测试;
- 集成测试:从测试若干个类或模块的交互,到测试整个子系统如何一起工作;
- 验收测试:单元测试和集成测试侧重从开发人员的角度去验证代码的行为,验收测试则是从客户的角度验证产品的行为,回答“代码是否正确解决问题”的问题。验收测试则是一种端到端的测试,验证技术栈的每一部分是否正确地结合在一起,形成可用的产品;
- 性能测试:顾名思义;
mock
mock 的存在确认该错误是由单元或组件内部引起的,而非存在于它的依赖项中。
TDD
- 为新的功能添加测试;
- 运行所有测试,新的测试应该会失败,但其他所有测试应该通过;
- 实现这个新功能;
- 运行测试,现在所有测试均应该通过;
- 重构代码,直至拥有整洁的设计。
此时编写完毕后应立即检查是否失败。
TDD 可以迫使我们关注自己正在做什么,而不是怎么去做。从最终结果考虑问题,帮助我们确认自己正在编写正确的代码,而不是直接跳入编码工作中,迷失在实现的细节里。
时机
当我们不再有足够的自信可以快速改变代码的时候,就是需要自动化测试的时候了。
代码分离
- 面向接口开发;
- 模块化代码部件;
- 提供 RPC 服务;
代码评审
代码评审可以提前暴漏 BUG,高级工程师可以利用代码评审去指导初级工程师,初级工程师可以通过参与代码评审去学习代码并贡献一些重要的问题。
- 为每部分代码指定评审者,评审者有责任知道这段代码如何工作,并且要保持它运行;
- 编写评审指南:评审者期望掌握的事项、定义什么代码必须被评审、什么时候代码必须被评审、谁的代码必须被评审、谁负责给出评审意见、好与坏都应该评审;
- 保持小规模评审。鼓励开发人员进行小修改,增量式地提交;
文档
书面文档
Readme文件:概括项目的任务、描述项目的作用、展示例子并解释如何开始使用、如何为项目做贡献,以及从哪里获取更多的信息。
教程:带着用户,一步一步经历各种典型的开发流,强调项目的一些惯用开发模式、最佳实践和特性;
参考手册:作用就是回答问题,所以要确保以一种容易搜索和导航的方式去组织信息
项目网站:GitHub Pages
代码文档
注释是存在于代码中的书面文档,整洁的代码不需要很多注释。
每个项目都应该包含清晰、惯用的示例代码,而自动化测试也是一种特殊的示例代码。
代码性能的扩展
我们的时间更应该花在能提高开发团队效率的工具和实践上,而不是让服务器跑得更快。
只有在产品已经有了一定规模,性能可能成为瓶颈之后,这才是个需要考虑的问题。
考虑性能或软件开发的基本过程就是让它工作,让它正确、让它快速。
性能调优的第一个步骤永远都是测量。
优化方式:分治、缓存、懒加载、近似正确、异步、限流、冗余、抖动与随机化、更快的硬件和算法
软件交付
如果你觉得痛苦,就多去做。
构建
版本控制
编写良好的提交信息:Commit Message Specification
经常小步的提交:每一次提交都是完全实现了某一个单一目的、大小合理的单元。完全实现意味着不应该提交会给构建过程带来问题的代码,或者让用户看到未完成功能的代码。大小合理的单元意味着我们应该把工作分解成较小的、增量式的步骤。
持续集成
部署
托管
部署在哪里?
使用云托管而不是搭建自己的数据中心。
配置管理
部署什么?
docker
自动化部署
如何部署?
流水线
持续交付
何时部署?
持续集成让开发人员编写可以频繁合并的代码,相互之间保持同步;持续交付让开发人员编写可以频繁部署的代码,保持和生产环境的同步。
金丝雀发布
监控
监控和单元测试是一体两面。测试是对少数情况下正确性的强假设进行检验,而监控则是对实际生产负载下正确性的弱假设进行检验。引入监控是为了代码在部署后能持续工作。
日志记录
格式化和日志聚合。
指标
可用性:最基本的指标,服务时候可用;
业务:
应用程序、进程、代码和服务器。
报警
报警的关键点是要能够识别出问题产生的原因。
团队
创业文化
文化是行动,而非口号,文化胜过战略。由员工分享并通过他们的举止和行动表达出来的信念、设想和原则,构成了创业文化。创业是与人密不可分的,公司中没有什么东西比文化对人的影响更大。
核心理念
使命:简洁、清晰、永恒、鼓舞人心;
核心价值:组织中用来做出每一个决定的信条。
组织设计
分层组织:经理负责协调和决策。设定目标、组织分工、激励和沟通、评估、助人成长。责任清晰带来的沟通困难降低效率。
扁平组织:让员工针对每个任务自我组织,形成最有效率的结构,在任务完成或改变之后再重新组织。员工有自主权和责任心,上述 5 点困难。
招聘与晋升
招聘到文化契合,价值匹配的人。多样性能使团队更愿意做出新的尝试,更有创造性,更可能去分享知识并帮助公司触及更多的客户,吸引更多的人才,做出更加创新的产品。
通过代码贡献在公司中赢得影响力,而不是依赖对人的管理。
激励
员工和公司之间是联盟。
最好的奖励通常是更多的自主权(在一些特定的日子让员工可以做他们想做的任何事情)、更多的专业能力(业务能力的提高)和目标(从事一些有较大意义的事情的内在驱动力)。
办公室
一个可以和他人一起工作的地方:方便同事之间的交互;
一个可以独处专注工作的地方:心无旁骛地编写代码的场所;
一个可以放下工作的地方:休息应该成为工作文化中的一个固定部分;
一种可以根据个人需要定制办公室的方法:让开发人员购买想要的硬件和软件,并给他们报销;
适合编程的桌子(又平又大,能够调整高度);
舒适的椅子;
运行速度快的笔记本电脑或台式机(最大的内存、CPU和硬盘);
一两个大显示器;
好用的鼠标和键盘;
办公室任何区域都有高速的互联网;
很多电源插座;
远程办公
大多数分布式公司开始时都是本地的公司,因为那时候仍然要尝试确定公司的文化,并寻找产品的市场地位。只有在清楚公司是什么并且把关注点转移到想出如何做之后,我们才应该考虑通过招聘远程员工的方式去扩大团队规模,成为一家分布式的公司。
沟通
内部沟通
员工彼此之间进行沟通的方式。让员工了解公司优先考虑的事情、了解公司正从事什么项目去实现这些优先考虑的事情、过去有什么项目成功了或者失败了、了解公司的财务表现。
员工大会或者公司宴会。
外部沟通
员工与外部世界进行沟通的方式。
第一是如何设计、营销和推广你的产品;第二是如何通过博客、开源软件和展示去宣传自己的公司;第三是如何和客户沟通。
过程
有些类型的 bug 不常出现或者解决成本非常低,所以在这些 bug 出现的时候再做反应会比试图防止它们出现效率更高。
项目成功重要的是人,而不是挑选的方法论。
求职之路
找到好工作的第一个步骤就是让自己变得出色。
寻找机会
利用人脉
聚会小组与会议
黑客马拉松和比赛
演讲、博客和开源
创建个人 IP
关注 VC 和程序员网站
面试
面对面编程、讲述思考过程、
了解自己:
·谈谈你自己。·你以前做过什么项目?·你为什么要找一份新的工作?·你为什么想来这里工作?·你理想的工作是什么样的?·你想在5年内做什么,10年内呢?·你最大的优势是什么,最大的劣势呢?·你最大的成就是什么?·你曾经解决的最难处理的bug是什么?·我应该再问些别的什么问题吗?
了解公司:
·该角色的期望是什么?·该职位能够取得什么样的成功?·谁是我的经理?·我将从事什么项目?·技术栈是什么?·工作时间怎么样?他们花多少时间在编程上,又花多少时间来开会?·如何构建和发布代码?·公司的使命和价值是什么?·办公室怎么样?·在这里工作,你最喜欢和最不喜欢什么?
《程序员面试金典》和《程序员面试攻略》。
评估机会
工作机会最重要的就是其背后的人,这件事只能靠直觉。
薪水、股权、福利、谈判
招兵买马
选择正确的人比选择正确的产品、市场推广策略、技术栈或者编程方法论更加重要。招聘更多的人意味着资金消耗更快,企业经营更复杂,决策更缓慢,要花更多的时间去搜索、面试和培训。最好的创业公司就是用较少的资源做较多的事。
何时招人
招人的关键问题不是“如果我们招了人可以做什么”,而是“我们不招人的话无法做什么”。
要么写代码,要么找用户。尽量发股权,而不是薪水。
如果对业务至关重要的事在没有新员工的情况下无法完成,不管你们多么有创造性,都是时候开始招聘了。
招什么人
要评估某人是否聪明,你需要知道他们是如何执行现实中的任务的;
要评估某人是否能够把事情做好,你需要了解他们在过去完成了哪些工作;
要评估某人是否能够很好地适应文化,你需要知道他是否与你们有共同的价值;
合伙人
两个创始人通常是通往成功的最好途径。你可以平均分配工作和股权,也没有政治操作的空间。三个创始人也没有问题:只是在职责划分上会更困难一些,但总可以通过投票决定,超过 3 个人就够呛。
信任的人远好于完全陌生的人。
- “敏思笃行”的人,要寻找你认识的那些不管有什么障碍都能克服的人;
- 要寻找具有互补技能的人,例如,如果你是程序员并善于开发产品,就要寻找能够处理好销售和市场推广,并善于发现客户的创业伙伴;
- 创业伙伴通常在年龄、经济状况和动机上应该是类似的。如果一个创始人寄希望于赚快钱,而另一个则对改变世界有长期的愿景,这是很难成功的;
- 能够信任的人。要建立信任,你必须了解合伙人的经历,所以也再次说明了为什么同事、同学和朋友是最合适的创业伙伴;
早期员工
做了错误的产品或使用了错误的技术,可以从头再来,但如果没有招对最开始的 5~10 个员工,却可能将公司置于死地。
多面手,态度胜过才能。
后期员工
开发人员对手艺的热情是最重要的;招聘到 T 型人才,举办技术访谈、报销课程和会议费用、鼓励撰写博客和开发开源软件、组织黑客马拉松、建立导师制,培养 10x 工程师,而不是招聘 10x。
不要关注是否能招聘到一个超级明星,而是要关注如何形成起一种可持续的招聘策略,如何形成一种组织结构,让每一个人都能高效地在一起工作。
品质
聪明并能把事情做好
对于背景,了解的是一个人完成了什么,无论是工作内还是外,而不是参与了什么;关注深入了解的领域,如果解释不清楚,要么非主要贡献者(没做好事),要么没有足够理解(不聪明);要引导他们进入未知领域。
文化契合
核心价值观契合。
出色的沟通技能
相信直觉
如何寻找
推荐、公司品牌化、在线搜索、HR
面试
- 让面试者教你东西;
- 面试者能学习到什么东西;
- 让应聘者展示他们的技术能力
学习
原则
- 聪明的选择学习内容;
- 投入时间;
- 成为习惯;
技巧
途径
- 读书看报;
- 读论文;
- 参加课程;
- 演讲、小组和会议;
- 阅读代码
目标 + 笔记 + 探讨。
实现
发展 side project、贡献开源、参加竞赛。
分享
分享所得到的东西要超过你所投入的。
专业性:具有“资深”标记的工程师都是那些使周围的人更加出色的人,要达到这一目的唯一的方法就是教;
质量高
共同维护
个人IP