简要描述
这个工具主要用于生成 PayJS 的测试支付订单，在 PayJS 官方不提供测试订单工具之后，可以使用这个工具来生成测试订单，简化操作。
下载地址
截图
更新日志
0.0.3
- 设置 key 为密码类型，保护信息安全。
0.0.2
- 支持 payjs 生成 1 分钱订单，并展示二维码。
PayJS 测试二维码生成工具
产品
什么是我眼中好的开发者产品的文档？（一）
我自己作为开发者使用过很多的开发产品，也看过不少的文档。最近频繁受邀针对不同的产品的文档提出建议，单独写这样一篇文章来说明一下我觉得什么是好的文档。一方面，可以帮助更多的开发者产品变得更好，另一方面，也可以用于自省，我自己在设计产品时是否会有类似的问题。
不过也需要注意，这篇文档仅涉及 「Guide」和「API Documentation」的部分，对于更多的 Changelog、Example、Tools 、 SDK 则没有涉及，这部分留待后续再写。
本文当中参考了包括：Notion 开发者文档、微信小程序开发者文档、声网 Agora 开发者文档、WordPress 开发者文档、飞书开发者文档等开发者产品。
API Documentation vs Guide
其实不少的产品文档写的都是 API Reference ，而不是 Guide，二者在实际的使用意义上是有所不同的。
- Guide 帮助开发者快速上手一件事，从 0 开始，完成一件事。这是「用户视角」。
- API Reference 则是告诉开发者你能使用我的产品做什么事情。这是「平台视角」。
一个好的文档应该是二者兼备的，这样才能一方面降低开发者的进入门槛（Guide 负责），另一方面， 可以让开发者可以知晓能力的范畴，帮助开发者尽可能拓展的应用边界，创造出美好的体验和新的世界。
一个好的 Guide 应该是什么样的？
这里我们以 Notion 的文档为例：
1. 一个好的 Guide 应该尽可能的显眼 & 好找
作为一个新的开发者，进入一个新的开发者平台时时迷茫的：“我应该做什么？”、“我应该看什么？“
这时一个明确的「Guide」、「Get started」可以帮助我们快速找到一个开始的锚点，这个锚点会成为开发者在这个平台中开始进行的下一步。
2. 一个好的 Guide 应该有明确的步骤描述 & TOC
开发者在进入一个新的平台时，需要的是「快速跑完流程，以熟悉平台的各项基本功能」，而不是需要了解到所有的能力（如果开发者已经非常熟悉你的产品，其实根本不会看 Guide，直接去对应的 API Documentation 查看实现了）。
一个明确的步骤描述和 TOC 可以帮助开发者降低心理压力，并让用户找到自己所在的位置，进行下一步的推进。步骤的名称也非常的重要，一个清晰明确的步骤，可以帮助开发者快速明确自己要做什么事情，不会产生疑惑。
此外，也需要注意，步骤不建议太多，可以移除掉那些非核心的步骤，重要的是帮助用户跑通开发流程。
3. 一个好的 Guide 应该是场景相关的
开发者在使用产品进行产品开发时，会有明确的预期，我要做什么事情。但产品需求和平台的能力是不同的。我们很难将产品需求和平台能力直接挂钩，这时就需要开发者盲人摸象般在整个平台上搜索和查看，找到适合自己的文档。这个时候，如果有一个场景相关的 Guide，可以帮助开发者快速找到适合自己的场景，并进行文档的细分。
在这些文档中，你的目的是帮助开发者快速了解在你平台上某个方向的能力、核心概念和如何组合你所提供的能力，帮助开发者快速实现自己的业务诉求。
一个好的 API Documentation 应该是什么样的？
如果说 Guide 是开发者进入一个平台的时候最基础的教程文档。API Documentation 则是一个开发平台中最为核心的部分了，开发者每天都需要与 API Documentation 打交道，以完成一项工作，如果 API Documentation 做的不好，那对于开发者来说，简直就是一个灾难。
1. 一个好的 API Documentation 应该是组织合理的
API Documentation 当中往往包含了大量的信息，那么合理的拆分不同的 API 的模块，可以帮助开发者无需遍历所有的 API ，而是直接按照模块逐级查找自己所需的 API 即可，可以有效的提升查找的效率。
2. 一个好的 API Documentation 应该具备所涉及到的各项数据结构的说明
对于复杂的 API 接口来说，参数/返回值往往不仅仅是一个简单的 Integer 、String ，还会涉及到一些更加复杂的结构化数据的定义。
一种选择是将这种复杂的结构化数据抽象出来，成为一个新的类型；另一种选择是每次都解释一遍。显然，根据软件工程的 “DRY” 原则，我们应当将其抽象出来。在将对应的数据结构抽象出来后，需要注意的是，将其放在一个明确的位置进行展示和说明。原则上，这些结构的说明应该先于具体的接口说明。
3. 一个好的 API Documentation 应该提供相应的 Sample Code
对于开发者来说，Talk is cheap, show me code。而在开发领域也是同样的。你提供的 Sample Code （甚至是在线的调用测试），都可以帮助开发者更好的理解相关的能力和开发逻辑。
所有的细节，都在 Sample Code 中一览无余。
4. 一个好的 API Documentation 应该可以提供上下游关系
在 WordPress 文档中，有一个我非常喜欢的功能就是 Related 。Related 内部分为 Uses 和 Used By，分别介绍了某个函数都是用了哪些函数来完成自己的功能和哪些函数使用本函数完成自己的功能。
伴随着 Uses 还提供了这个函数的源码（不过这个对于平台类型的产品不能直接照抄），这样我可以非常清晰的参考这个函数的 Uses 和源码，以了解这个函数是如何实现自己的功能的。这样当我需要的时候，就可以非常方便的基于这个函数，改造出一个我自己使用的函数。
而 Used By ，则提供了其他的函数是如何使用这个函数的。对于一些我比较陌生的函数，可以直接参考其他函数的用法。从某种意义上来看，这是比测试用例更加全面的用法的说明，因为这是在“生产环境”下的用法。
我们在开源世界如果没有文档，会看测试用例，那么在 WordPress 当中，我会看的是 Used By。
5. 一个好的 API Documentation 可以提供用户之间的沟通渠道
我在 WordPress 开发者文档当中，还会常用到的一个功能是 —— User Contributed Notes。这个功能为开发者提供了一个基于函数的共建笔记。开发者可以自发的在其中撰写自己针对这个函数的开发经验。
当我在不知道某个函数应该怎么使用的时候，我往往会去 User Contributed Notes 去找找看，看看别人是如何使用某一个函数的。官方的文档往往无法跳出「我有什么」的思路，而用户的共建笔记则可以共享出开发者使用某个函数的「奇技淫巧」。这些「奇技淫巧」让开发者的产品显得与众不同，也可以进一步的扩大产品的范畴。
总结
一个好的开发者产品文档是什么样的我很难定义，但至少上述的这些点，确实让我使用这些平台的产品在开发应用和业务的时候变得更加坚定。希望我的这些笔记，可以帮助到你，让你也可以涉及出一个好的开发者文档。
独立开发者可用的支付方式
我会关注一些个人可用的收款方式，核心支付要解决的问题是在开发产品过程中，必须要用到的各项基本技能。如果支付流程无法打通，独立开发者的商业模式就会遭到最直接的打击：你如何赚到钱？
可能你会想，我难道不能使用广告的方式来赚钱么？
当然可以，但与直接向最终用户收款的方式相比，显然，广告赚到的钱不过是蝇头小利。
此外，我也说过，广告赚钱是非常少量的，因为你拿到的本身就是平台收益中的一小部分。此外，广告还有一个问题是与流量相关的，你必须不停的想办法获取流量，并将流量转化，这对于独立开发者而言，并不友好。因此，我并不看好以广告为基础的独立开发产品模式。
故而，我十分在乎收款流程的通畅。
其实想想也能明白，你会发现国内独立开发者大多出现在 iOS、Android 等移动应用开发平台上，这里很难说没有平台提供的收款渠道带来的价值。
所以从这个角度而言，我也建议大家可以适当关注一些收款渠道，以便你自己后续使用。
为什么不注册公司，自己接入渠道？
当提起这些第三方渠道的时候，大家经常会说，诶呀，你这个收款平台的费率好高啊，你看看支付宝官方，只有XXX。
我觉得，这个事情如果只对比收款费率的话，过于单纯。
实际上，支付宝官方、微信支付官方往往需要企业资质才能开通。而你开通这些账号所支付的成本，远超你当下的收入。
你用你前期的收入，养活了代注册公司、代记账公司。早期其实完全没有必要，你大可以用这些平台完成前期的冷启动，启动完成，有了长期收入，你的收益足以支撑你继续后续的工作，再替换不迟。
我关注到的收款平台
面包多 Pay
PayJS
XorPay
云计算的增长在 SaaS
我一直以来，都很喜欢诸如 LeanCloud、Firebase、云开发这样的产品，这背后的逻辑是「随着云计算的成本不断下降后，下一步发展起来的是各样的 SaaS 产品」。
这些 SaaS 产品的建设，和过去相比，基础设施的发展使得开发一个 SaaS产品变得比以前简单太多了。
如果你需要服务器，无论是阿里云，还是腾讯云，甚至是面向全球的 AWS、Azure，都是你只需要花钱就可以买到的。
如果你需要邮件系统，SES、Mailgun、Postmark，各种不同的产品，让你的开发变得无比的简单。
你需要做的，只是找到你自己的 niche，然后针对这个 niche ，开发一款产品，并将你的产品推出，并发布上市，将你的产品售卖给你的客户。
很多时候，我们在看云计算的市场的时候，如果我们关注的是 IaaS，基础设施，我们就会发现，我们面对的往往是那些旧有的，已经存在的市场，他们会使用我们的产品，来替代曾经的产品。但同样的，我们的产品也会被成本更低的 IaaS 产品所替代。
我们要的是旧有的产业，还是那些新的产业？面向一个已经存在的百亿市场，还是一个未来会爆发的千亿市场？
好风凭借力，送我上青云
对于如今的开发者们来说，已经处在一个很好的时代了，他们拥有着丰富的基础设施，这些基础设施，让我们可以以更加低成本的方式，来构建我们自己想要的产品和工具。
我们站在巨人的肩膀之上，构建属于我们自己的产品。
为什么我们一定要完全自己去构建一个产品呢？从国家的角度来说，这样情有可原，而从个人的角度来说，借助这些基础设施来构建一款产品，才是最为实际的。
我们需要自己从 0 开始建设一个云服务么？当然没必要，我们可以使用阿里云、腾讯云、AWS、Azure，你可以使用任何一个云服务厂商为你提供的基础设施，构建自己的产品，直到他们无法满足你的那一刻。
从给项目不买域名做起
我是一个灵感非常丰富的人，所以我总是会有各种奇奇怪怪的想法，并且试图将其转换为一个实体的项目（工程师的身份赋予我将其从灵感变为现实的可能，而产品经理的经历让我可以关注一个产品最为重要的是，至于说运营的工作，让我可以把一个项目从 0 开始推广）。
而我过去的一个毛病是，当我有了灵感后，会先试着去买一个域名。但，购买域名并不意味着我一定能把这个项目做完，大部分时候我会注册一个域名，然后，放一年，直到他过期。久而久之，我就有了几十个域名。。。
所以，我在思考，在后续的新的项目中，我将会启用项目代号制，先不思考项目名是什么，以及应该用什么域名，而是先尽全力将自己的 MVP 跑通，以及完成功能假设和市场假设。
所以代号从哪来呢？不妨从一些经典电影中找找灵感吧，最近看一些英文电影，然后从英文电影中寻找答案。
关注体验，而不是关注效率
今天和我的广告主，芦笋的创始人晓力聊了很多，其中聊到独立开发者的工作，我提到了一个概念：
作为独立开发者，我们需要关注产品的体验，而不是关注产品的效率。因为在效率的追求上，我们一定不如大公司能够在这个事情上做的更好，在这种情况下，做一个更具备“个人特色”的事情，会让我们在一件事上走的更远。
个人特色意味着独特的品味和体验，这种独特的品味和体验，将会引导用户持续使用。而这些独特的品味和体验，将会是留下我们的用户的重要的部分。
抖音和快手的区别
前几天和一个做投资的朋友聊到了抖音和快手，谈及二者的不同，我是这样评价的。
关于抖音
谈及抖音，需要看字节跳动的企业文化和张一鸣在做的事，字节跳动的使命叫「Inspire Creativity, Enrich Life」，中文「激发创造 丰富生活」。
这句话没啥问题。不过，如果你和张一鸣做今日头条的逻辑一起来看的话，就能明白抖音提供的价值。
张一鸣认为，现有的推送机制，按时间推送的机制（如微信公众号），信息触达目标用户的效率太低，所以做出了今日头条，希望通过机器算法的机制，来优化信息触达目标用户。
而抖音，从产品形态上来看，就是视频版的今日头条。依然依靠强算法推荐，让「引擎觉得对你有用」的产品，出现在你的面前。
至于说，激发创造，丰富生活，其中是没有「人」的存在的。当然，是激发每一个人创造，丰富每一个人的生活，但本质上是推荐引擎将数据推荐给每一个人。引擎不在乎内容是谁做的，他只在乎内容对目标受众有价值。
这也解释了，抖音上为什么往往是一个网红需要不断的跟进潮流，出新的内容，产出新的价值，才能持续产生收益。
快手
同样是短视频平台，快手讲究的是「快手是记录和分享大家生活的平台，每天产生上千万条原创新鲜视频」。
快手虽然也有推荐引擎，但在快手当中，首先核心概念是每一个快手主播，数据和信息以主播为核心进行推动。
在快手的世界，以「人」为本，不太在乎算法。如果你关注了某一个主播，他产出的内容会强推荐给你，让你可以持续看到。
从这个角度来看，快手其实在做的事情「很互联网」，和我们曾经使用的 Feed 流非常接近。
我的评价
二者我都不抗拒，我用抖音搜索我想要的信息，它可以产出我最需要的信息，很好的承载了一个「视频版搜索引擎」的角色。而快手则会成为我的工具，因为他以我为中心，展现我的价值，是一个创作者的助手。
谈独立开发者
今天可能有些同学因为「独立开发者」这个标签关注我的推特，不过这个号可能你们看不到太多关于独立开发者的「技术」分享，因为「技术」不是独立开发者的关键，对于独立开发者来说，技术够用就行。反而是产品、市场、商业、运营的能力对独立开发者来说会更有帮助。我并不推荐经验不足的同学做独立开发者。
因为对于独立开发者来说，能够独立打造一个产品，是基本功。你需要能够 Cover 掉整个项目的几乎所有流程，然后才有资格成为独立开发者。如果你的技术不全面，那你就必须想办法解决这个问题。可以是借助云服务、可以是借助 No Code 工具。不要让技术把你卡住了。
当产品研发不会成为你的阻碍以后，你就踏上了独立的路线。成为独立开发者的路径是漫长且枯燥的，但同时也是开心的。因为你可以做你喜欢的事情、做你想做的产品、服务你想服务的人，并从中获得支付，养活自己。
相比之下，我认为有商科、金融等背景的人会更容易成为独立开发者，原因是更具备理解商业逻辑的能力。如果你不是，或者你不能理解，那就找一些书，看看商业世界是如何运转的，你又如何从中提供价值，赚取收益。当你开始思考商业的问题时，你就真正的走上了独立开发者的道路。
在前期，你可能做了大量的事情，都是在尝试，在锻炼，但不要害怕，开发产品本来就是一个困难且复杂的事情。失败也是大概率的事情。但你可以从自己的每一次开发过程中吸取教训，让自己的下一次产品比这一次更加成功。
作为独立开发者，我不太建议你采用广告的方式来获得收益。广告的方式本质上是流量生意，你的收入和你的用户的增长并不是线性的。而且流量生意对于资本、渠道等关系的要求很高，对于绝大多数开发者来说，并不适合。关注一个小众领域，服务一小撮人，是一个比较简单且实用的路径。
你从每一位用户（客户）身上收取费用，你的用户增长和收入是呈线性关系。相比于「可能是指数型增长的广告业务」个人觉得会更适合刚刚开始的同学。当然，如果你确实有明确的流量入口，把控了流量，那做广告型的业务也未尝不可。
我常说，「和别人做一样的事情，就不要预期和别人有不同的结果」，做独立开发者就是一个试图做和别人不一样的事情，在这个过程中，你是孤单的，但也是快乐的。作为开发者，我们能够选择「做自己喜欢且可以赚钱的事情」，是非常幸运的，别浪费了这种快乐。
在我看来，独立开发者和作家、播客主播一样，都是创作者。这部分就像 @zhufengme 说过的「创作者不能缺钱」。如果缺钱，就不太好搞创作了，那么穷困潦倒，要么不得不放弃一部分原则，以养活自己。处在一个比较舒适的状态下，认真去做自己喜欢的事情，反而可能更容易走出自己的路。
为什么太缺钱的人或者太关注钱的人可能反而不容易成功？原因是，如果你太过于关注钱，你就变得和商业公司一样了，追求的是利润。但，从追求利润的角度来看，商业公司一定会在这个事情上拥有比你更加强大的能力和实力。所以我不太喜欢做有强资本属性的事情，因为你很难在这个维度和大企业竞争并取得成功
独立开发者不要追求效率，而是要想办法追求美好的体验，就如 @RioJot 和黄海在疯投圈「51.从泡泡玛特谈起：物质消费中的情感体验」中提到的，我们有太多的企业去追求且擅长追求效率，而情感体验，是作为个人能够做的更加极致的部分。效率从各个角度来看，你都不如大企业能够做的更好
但你可以在情感体验和观点（opinion）中获得价值，@plidezus 的 Flomo 就是一个很典型的拥有自己的 Opinion 的产品。而研发同学们特别熟悉的 Rails 的母公司 Basecamp ，也是一个非常典型的 Opinion 导向的公司。他们通过构建一种 Opinion ，找到和自己同频的人，然后向他们售卖针对这个Opinion的产品
在产品触达用户之时，DevRel 团队都要做什么
经尾尾邀请，在“聊聊 DevRel && 技术运营”群做了一次关于 DevRel （开发者关系）的分享，以下是分享内容，希望对你有帮助。
Slides 地址：https://docs.google.com/presentation/d/1n6XBLfmpSCDg3196LIn_8FGKIqkCIp-qN9sMQ-uxzVk/edit?usp=sharing
《布道之道》链接：https://www.ituring.com.cn/book/736
直播回放：https://bytedance.feishu.cn/minutes/obcnxp28x2898p51qk37zrzy
如何将一个commit 变成一系列宣传资源
作为技术人，对于做 Branding 的事情其实不那么上心，也因为不上心，导致在实际做事情的时候，难免做的不好。
我因为从事过运营，所以有一些经验，这里，分享一下我自己的思路。
以这个 Commit 为例：
这个 Commit 制作了一件事，就是在 GitHub 项目的目录下创建了一个 funding.yml ，从而实现开启 GitHub 的 Sponsor 功能。
第一层思考
那如果我们要将其转换为宣传资源，我们可以这样思考：
- 内容形态：这个内容我能不能做成文字类型的，或者是能不能做成视频类型的？
如果可以做成文字类型的，那么可以针对这个 commit 写一篇文章，比如就叫做
如何开启 GitHub 的 Sponsors 功能
如果可以做成视频内容，就可以做成
手把手教你开通 GitHub 的 Sponsors 功能
第二层思考
在第一层思考，我们可以很容易获得一篇文章和一个视频，但我们如果不满足以此，希望获得更多的推广内容，我们要怎么做？
我们可以延展思考一下，GitHub 的 Sponsor 功能是基于特定目录下的 yaml 文件来配置的，那我能不能有一篇文章延展介绍一下这个特定目录下的其他功能？
比如:
- issue template
- GitHub Action
- Pull Request template
这样，我们就从之前的文章中，延展出来了第二层思考，这个时候，我们有了第二个主题，同样，可以延展出一篇文章和一个视频。
第三层思考
在第二层思考中，我延展出来了三个不同的服务，那在这种情况下，我可以再写三篇文章，分别介绍这三种不同的服务。
这样，我就喜提三篇文章：
- 如何使用 GitHub 的 issue template 来规范用户的提交？
- 如何使用 GitHub 的 Action 来完成应用的自动化
- 如何使用 GitHub 的 PR template 来规范用户的 PR
以及他们对应的视频。
总结
实际上，只要你愿意去思考「为什么」和「能不能」，很难在计算机领域写干，因为这个领域足够大，足够一个人写一辈子的原创了。你需要做的仅仅是，从你最熟悉的领域，选择一个话题，然后开始写作，不断的延展话题。
此外，如果你想写但又不擅长写作，我之前在 GitChat 和图灵的英子老师一起搞过一个写作课，你可以看看这个网站，我将我们当时的课程内容整理并发布在了互联网上。
关于运营，我在腾讯学到的最有价值的三件事
2019 年从上一家公司离职后，我在休息了一个月后，以开发者运营的身份加入腾讯，后多方原因，我在 2020年，入职一年之际，离开了腾讯。
虽然离开了腾讯，我依然很感激腾讯的小伙伴，以及我的 Leader —— 小昱。大家的宽容，让我可以在这一年里，磕磕绊绊的，学到了一些东西，掌握了过去自己所不能掌握的知识。
也正是如此，我希望延续我作为工程师的习惯，将我自己所学的知识分享给各位，希望这些信息可以帮助到大家。这些知识对于已经从事运营多年的同学来说可能没有价值，但对于当时刚刚开始做运营的我来说，确实帮了大忙。
以下三条，是我在腾讯做运营，学到的最有价值的东西。
1. 运营就是对于资源的调度和利用 —— 小昱
这句话源自我问小昱：「运营的核心到底是什么？」。彼时的我，还陷在运营就是打杂的境地之下，每天总是在怀疑自己所做的事情到底有什么意义？我所做的事情，到底有什么价值。于是我找到了小昱，问出了上面的问题。
她给出了上面的答案。
对于我而言，这句话让我豁然开朗。运营需要将自己所做的事情当成资源看，不仅如此，你所做的任何的事情和所接触到的人，你所拥有的物料、人脉，都会成为你的资源，当你从这个视角来看待你所做的事情的时候，就会跳出细节，进入到一个更加宏观的层面来看待这个问题。你会被这句话强行拉到一个更高层次来看待运营和你所做的事情。从而也会更加理解你自己在整个团队中的价值，和你能够提供的价值。
2. 运营的价值，是拉近产品和用户之间的距离 —— 读书
这句话同样出现在我迷茫的时候，当我迷茫的时候，我开始疯狂的去读各种各样和运营相关的书籍，希望从中找到我想要的答案，而这句话，便是我找到的答案。
我们提起产品，往往会想到「产品经理」、「产品研发」，运营的身影仿佛很少出现，那运营的价值是什么？
运营的价值便是用各种各样的运营手段，去拉近产品和用户/客户之间的距离，你所做的一切，只要可以帮助拉近用户和产品之间的距离，那便是有价值的，反之亦然。
因此，你在做事情的时候，可以思考一下 —— 我做的这件事，能否拉近产品和用户之间的距离，如何可以，背后的逻辑是什么？
3. 漏斗模型 —— 小昱
漏斗模型是我在看小昱的述职报告时学到的。
漏斗模型的形态很简单，便是一个分层的漏斗，根据每一层的名字不同，会区分 AARRR 漏斗模型、AISAS 漏斗模型、AIDMA 漏斗模型等等。但核心还是这个漏斗模型。
对于漏斗模型而言，你需要关注到漏斗是分层的，因此，每一层的流量都会依次减少。而能够影响流入到下一层的流量的因素有两个：流量总量 和 转换率。
流入下一层的流量 = 这一层的流量总量 x 这一层的转换率
当你在做任何工作的时候，都可以去思考，我做什么样的事情，才可以提升我这一层的流量总量，以及提升这一层的转换率。
而这个简单的逻辑，无论是你做拉新、留存、促活还是营收，都有意义。
总结
我的上面三点认知，对于一个多年的运营可能是没有价值和意义的，但我希望上面的这段话，可以帮助到那些刚刚开始从事运营工作的人。当然，这篇文章，也会放在我正在准备的电子书《GrowthForDev》当中，希望这段话，可以帮助到那些有心给自己项目做运营的开发者们。
为什么工程师希望需求明确？
我作为一个工程师，引以为傲的，便是不要求需求一定是完全详尽的，我会根据自己的个人经验，来帮助产品经理补全这些内容。
但另外一个层面，我也确实在思考，为什么我们会希望需求尽可能明确？
需求明确，意味着工程师在拿到需求之后，就可以开始工作了，而无需思考这个需求中的不合理的部分。
但当你和一个不靠谱的产品经理去合作的时候，就会发现，几乎约等于没有的需求，意味着在产品的研发过程中，存在大量的重写和改写的部分。因为产品经理前期思考的不充分，和后续的架构调整的计划较多，就会导致项目在后续研发的过程中，会出现不断的架构调整，推翻之前的工作，对局部进行重写，最终导致工程的不断 Delay。
当然，我也并不是说，我们应该在事事上都去追求完美的产品设计，这显然不现实，时间成本也比较高。但确实，作为一个 Trade Off，这是一个存在的现象。
换句话说，如今的行业的不断细分，是有其存在道理的。流水线化让每一个人的产出可以被量化、我们接受标准的 Input 和给出标准的 Output，让每一个人的工作都可以更加轻松。
看板(KANBAN)是否能够满足你的项目管理需求？
从腾讯出来以后，我一直还在用的，和腾讯内部一样的工具，便是 —— TAPD。
说句实话，TAPD 的编辑器是真的很难用，但我很难找到类似的产品，只能继续使用 TAPD。
Trello 我一直还在使用，但我只会在一些个人的项目上使用，更多的时候，我是用 Trello 替代 ToDo 类应用。但涉及到更加复杂的需求/Bug管理，我会选择使用 TAPD 这样的应用来完成。
相比于 Trello，TAPD 提供了看板和看板以外的功能，比如文档、Wiki、需求管理、迭代管理、Bug 管理等功能，对于一个软件开发项目来说，所需要的几乎都提供了。
看板的功能只是TAPD中的一小部分，更重要的是 TAPD 提供了需求管理和标准的富文本编辑器，这使得一个需求可以更加详细的被描述，在开发过程中，开发者可以更好的和产品经理去对齐需求。
类似的，还有迭代和Bug管理，这些并非不能通过 Trello 实现，但Trello 的核心还是一个 KANBAN，对于更加重量级的内容管理，是力不从心的。
出于上述考虑，我最终选择了 TAPD，而不是 Trello。
国内类似于 TAPD 的产品还包括，腾讯旗下的 Coding，Coding 除了提供了基础的代码托管功能以外，还提供了项目管理工具，可以让开发者更好的管理自己的软件项目。
一个在线视频课程研发的流程
希望这个图对正在建立自己的课程研发体系的你有帮助。
工具创造者的自我修养
独立开发者中有一大批人是通过做工具来获取收入的。做工具也算是独立开发者圈子中经久不衰的话题了。
但到了具体的工具开发之时，其中又有不少可以拿来讨论的内容。
而这里，我最想讨论的是工具的理念。
对于工具类的软件开发而言，最容易出现的就是「别人做了一个什么东西，我觉得不够新/便宜/不爽，我自己也要开发一个」。对于开发者来说，遇见问题， 并自己解决问题是非常常见的。 但是，工程师常常的问题也在于此，因为复制一个产品的成本越来越低，所以最先选择的是复制，而不是思考这个产品的长期发展道路。这会让产品陷入简单的 Copy and Paste 的模式下，长期来看，并不利于产品发展。
在我看来，如果工程师想要做好一款工具，那么一定要为自己的工具准备一个最基本的方法论。这个方法论一定是基于你自己对于问题的看法做出的拆解，而不能是依赖于其他第三方软件的。
这个方法论将指导你的产品朝着最终的目标，要解决的问题，奋力前行。你后续所遇见的问题，都会成为你前行的助力，为拓宽前进的道路。
而一个没有方法论的产品，则会被途中遇见的各种问题引导偏离最初的目的地。我们目前的市场中有太多的工具了，每一款工具都有其优秀之处，倘若没有自己核心的理念，那只会被众多的 Feature 搞得「乱花渐欲迷人眼」，最终失去了自己对于工具的定位，抄成了一个四不像。
总结
如果你想要以一个小团队打造一款好用、生命力持久的工具，那么先想清楚你的目标和理念，再动手开发，是一个好的路子。需求有很多，但并不是每一个都适合你。工具有很多，也不是每一个都适合你，预期去抄别人的理念，做别人要做的工具，不如发现自己的需求，做自己的工具。
什么样的人适合做独立开发者？
我这几天在 Twitter 上发了一条推，引起了一些热烈反响。不少推油也从不同的角度给出了看法。
后续我也补充了一些信息
不过，我觉得我可能需要完整的描述一下我对于独立开发者的定义，以确定大家的讨论会在同一个维度上。
技术人的常见道路
技术人的常见路线其实很明确，总体可以分两个大类：技术专家和产品研发。
技术专家
技术专家的特征是对于技术研究更深刻，会更加专注于某一项技术的研究，有通才型的技术专家，但较少。更多的是在某一个领域方面深入的技术专家。
技术专家的话，一般而言，最好的路线是进入企业，以技术专家的身份，被企业供养着。特别是进入大的企业，较大的企业拥有足够的技术场景可以供技术专家进行深度研究。同时，大型企业也拥有足够的预算来供养这些技术专家。
产品研发
产品研发类，不会太过于纠结于技术的本身。而是会将更多的精力投放在技术产品的价值。
这类人大多最终会走上独立开发者/创业者的道路，企业内部虽然也会有内部创新的道路，但可能很多时候会受限于企业的资源和布局，因此，在出现企业利益与产品利益冲突的时候，容易触发这类人离职。
产品研发类的人的特点是，技术也会研究，但不会像技术专家一样沉迷于某一个技术，更加关注是技术之间组合产生的价值，站立在产品、研发、和人文的交叉点，讨论组合产生的价值。
从他们的表现逆推，则可知，两种发展路线可能会需要的一些特性：
技术专家
- 耐得住寂寞：技术的研究远不如产品的研发能够提供的正反馈和多巴胺，绝大多数的时候是鼓噪的过程。
- 热爱：技术的研究是一个枯燥的过程，热爱能够让他从初期的没有成功，抗过最初的困难期，渐入佳境。
产品研发
- 不抗拒与人打交道：产品研发类的人最终走上的无论是创业还是独立开发，都会涉及到需要和人沟通，如果抗拒和人打交道，最终这个过程可能会让你心情低落，甚至抑郁。
- 耐得住寂寞：产品研发虽然和技术专家大体路线不同。不过，产品研发早期可能很难得到正反馈，因此，耐得住寂寞可以让开发者在产品的初期，坚持做下去。
- 抗风险能力强：独立开发者的路线是坎坷曲折的。和创业类似，唯一不同的是，失败的时候可能只有你自己，相同的是极高的失败率，因此，抗风险能力一定要强，扛得住失败。有多个收入来源，确保生计是一个很重要的事情。最好不要 All in ，容易一不小心把自己玩死。
- 技术基本成熟：不一定是使用最新的技术，但要具备独立借助技术解决问题的能力。如果完全从零开始的话，可能会在前期获得非常多的负反馈。所以，有一定技术基础的人是比较好的。一般而言，我建议从业在 3年以上的人，可以开始考虑做独立开发者。
总结
关于独立开发者而言，需要具备的特点有很多，这里仅能根据自己的经验总结一些，也欢迎各位在下方评论。共同讨论。
视频课程制作手册
导语
因为我有“好为人师”的坏毛病，所以我经常制作一些视频，去指导别人，要如何做一个东西，在这种场景下，我会考虑制作一些视频。
这篇文章是介绍我的视频制作的课程，介绍一下我是如何制作视频的，并将这个流程分享出来，让大家了解，并给出一些建议。
流程说明
- 确定题目：制作视频之前，需要有一个主题，我不会平白无故就要制作一个视频，必然会有一个主题。有些时候，这个主题会是别人给我的，也有的时候，是我自己想起来的。这个环节耗费的时间往往是最少的，灵感来了，就会加入到主题里，并开始进行下一个流程。
- 背景调研：为了做好一个视频，显然不能简单的基于我自己的认知来制作，我需要借助一些别人的经验，这个时候，我就会进行广泛的调研，获取不同渠道的信息，以补全我对这个问题的认识（虽然并不能确保我的认知就一定正确，但往往会有更多新的视角出来）。这个环节往往是比较耗时的，因为需要做好相应的数据调研，准备好课程所需的资料。
- 准备 PPT & 讲稿：在准备好了所有的内容基础以后，就开始制作视频课程所需的 PPT，这个往往是比较快就可以完成的（当数据都已经准备好了）
- 视频录制：视频录制是整个环境最为简单的环节。特别是当你熟悉以后，往往是一遍就可以过，所需要的只不过是一个还算不错的麦克风（我一般是头戴式的，目前用的是 Jabra Envolve 20），头戴式的麦克风可以确保你的嘴唇离屏幕的距离始终是一致的，声音的一致性会更好。在视频录制的环节，我使用的是 Screen Flow ，这个软件可以很方便的完成视频录制 & 剪辑。Windows 你可以选择 Camtasia Studio。
- 视频剪辑：视频在录制完成后，需要进行一些简单的剪辑，删除整个录制过程中出现的一些小的错误。比如口误（如果口误，你可以直接说下去，这样后续可以剪辑掉口误的部分，用正确的部分替换，有效的提升你的剪辑效率）、噪音（尽可能选择底噪低的环境，比如小的房间、会议室等）。
- 视频渲染：视频的渲染需要花费很长的时间，所以我一般是选择将所有的视频剪辑完成后，放在一起渲染，然后选择晚上睡觉的时候渲染，这样早上起来就已经渲染好了。
- 视频发布：视频录制完成以后，就是发布的过程，这步很简单，对外发布就好。