独立开发的阶段性体会

Photo by Thought Catalog on Unsplash

注册一个公司

不管规模多大,公司是必不可少的。自然人能够开发的东西是单机工具类产品。假如想整合更多的资源,需要一个法人身份,开公司是唯一的选择。

多途径输出

总结的形式可以是笔记、可以是视频,多途径输出自己的经验,帮助更多的人。

减少一切非必要成本

这里非必要成本包括公司财务的开支,服务器的开支,在项目初期尽可能减到最低配置。保持无负担低成本启动,可以让你不用那么焦虑,保持清醒的头脑聚焦到关键的核心产品上。

从上至下规划产品

从上至下规划产品,不要陷入技术细节。要知道,除了核心功能,其他大部分的功能都是可以通过技术手段实现。产品的方向是最重要的。其中首要的是要明确市场。通过量化使用者的数量,乘以每个用户可以给你带来的效益,得出整体的规模。然后看目前的市场情况,看从中能分到多大的蛋糕。

继续阅读独立开发的阶段性体会

技术文章分类

Photo by rashid on Unsplash

找准定位,深度挖掘需求,以做产品的方法打造出来的技术文章必定是好文章。这篇文章算是我对常见的技术文章分类以及如何写好对应的技术文章的一点总结。

源码级别的探究文章

假如这篇是源码级别的探究文章,那么你的读者往往是具有相当功力或者有探究好奇心的技术达人,他们可能是想搞懂这个实现的原理,那么最直观的流程图是少不了的,可以一下子抓住眼球,理清思路,然后针对流程中的关键环节进行击破。这个源码探究我很少形成详实文字,毕竟曲高和寡,而且市面上类似八股已经形成大量可以记忆的知识点,并不能起到多大的贡献。

继续阅读技术文章分类

为什么我推荐 Antd Pro + Umi

Photo by Vincent van Zalinge on Unsplash

React 生态很神,套娃框架很丰富,比如 antd pro 组件库和 umi 开发框架。这段时间,经过深度的使用,我对这个框架的也越来越喜爱。因为它解决了独立开发者最关心的效率和代码质量的问题。

效率很好理解,代码质量可能有人有些疑问,一般的理解是代码质量可能是多人协作需要考虑的事情,实则不然,根据我独立开发多年的经验,作为独立开发者,很多时候无法知道自己代码是被合理的组织的。如果任凭代码随意组织,在后面迭代中也会影响业务上线效率。

为了解决这个问题,我往往需要看别人的代码学习一些经验,这个会耗费比较多的时间。而 umijs 从阿里的业务中提取除了很好的实践,使用插件和配置形式很好的组织了前端代码,让开发更加关注业务本身。

React 状态机使用感受

Photo by erik cid on Unsplash

上手 react antd 之后,按照官方推荐的套娃框架 umi 和 antd pro 配合搭建了目前的项目。其中 umi 又可以使用 dva 状态管理框架进行数据流管理。

一开始我的认为是这个东西比较麻烦使用起来不太顺手,并且解决不了什么问题。但是现实是在我的项目里有很多组件共用的数据,不用状态管理会让代码显得非常冗余。学习了 dva 之后发现套娃框架非常适合上手,也精简了不少代码。

状态管理的核心是拆分状态。一开始我综合了知乎的一些回答,认为若组件之间有大量的共享数据,那么就可以使用状态机管理数据可以精简非常多的代码。

产品随想

最近痴迷曾国藩传,试想读一些近代史相关的书籍,但是发现手头没有相关产品的。作为用户,我希望有一款可以输入一本书然后关联出所有相关知识点的工具,类似知识图谱。

这个工具比较适合 Web 大屏幕来展现。

暂时那么多。

哦又是this——浅谈 React 事件绑定

Photo by Jeremy Zero on Unsplash

在使用 React JSX 事件绑定中有个最大的问题是它不会帮你处理 this 的指向问题。我刚刚上手的时候有些疑惑,看了教程之后豁然开朗。

React 事件绑定的需要和显示的修改对应事件处理函数的 this 的值。这主要是因为 Babel 开启了严格模式。若这个函数 this 指向没有改变,直接赋值给 onClick,那么函数体内的 this 仍是 undefined 。为此需要使用 bind 函数来修改函数体内的 this 指向。比如下面这段代码 :

import React, { Component } from "react";

class test extends Component {
  test() {}
  render() {
    return <div onClick="this.test.bind(this)"></div>;
  }
}

export default test;

对于一个类组件,this 指向的是类的实例,this.test 方法会沿着原型链找到类中定义的 test 方法,然后将这个类方法中的 this 替换为当前实例对象。这样一来, test 方法中的 this 就可以当前实例对象的值。

另一种方法是将 test 写出箭头函数的形式。这里有两个含义。首先 test = func 的形式,test 就是一个实例属性,但是这样仍然没有改变这个直接调用时函数内部的 this 的指向。但是假如写成箭头函数的形式,箭头函数中的 this 会使用实例对象的 this,如下所示。

import React, { Component } from "react";

class test extends Component {
  test = () => {};
  render() {
    return <div onClick="this.test.bind(this)"></div>;
  }
}

export default test;

对应视频教程

bind https://www.bilibili.com/video/BV1wy4y1D7JT?p=16

箭头函数 https://www.bilibili.com/video/BV1wy4y1D7JT?p=18

模块化工程杂感

Photo by Michael Scherback on Unsplash

为了更好的分解大规模的代码,包(package)的概念就产生了。包可以隔离命名空间,消除函数变量的命名冲突。一般的做法是,相同包下的文件都会放在在一个文件夹下。针对这个习惯,Python 在文件夹下定义__init__的方法来组织下面的小文件,JavaScript 的模块系统基本也是这个思路。

和这两者不同, Golang 不在单独在文件夹下指定一个导出文件,而是直接使用关键字 package 来指定,同时摒弃了文件导入这个概念,包为导入的最小单位。这样一来,同一个包内的各个文件可以直接使用而无需再次引入。而包外部的代码想要使用包内代码必须是显示的调用。这和它们家 Angular 的模块是一个思路。而导出文件的作用被大小写导出的内容所取代。

独立开发之路

Photo by Octavian Dan on Unsplash

2016年6月计算机硕士毕业之后进入移动地级市公司工作。原本以为国企铁饭碗很香,也没想到那么快会对这份工作失去兴趣。每日的工作主要是取数和资产管理类工作,中间穿插大大小小的培训,我觉得这样的生活不是我想要的,于是想到了跳槽。

17年5月离职去了另一家相对轻松的国企做数据库管理工作。和上一份工作相比,这份工作显然轻松了很多,每天基本就是看数据库相关的技术书籍,这个阶段学到了很多东西,比如基础的 Linux 运维、自动化的一些工具、系统学习了 Python 和 Shell 脚本。

18年8月上岸现在的单位,接触全栈开发相关内容至今。经过不断的折腾,用 Python、Nodejs、Go、C# 都做过工程,目前熟悉的技术栈是 React + Gin。

2021年5月开始构思自己的产品。在小城市,体制内的工作还是最香的。但是招聘信息碎片化,不够系统,不利于研究分析。为此正在做一个职考类相关 App。采用微信服务号+H5的形式完成最小化可行产品(Minimum Viable Product, MVP)验证,后续看发展可能采用 Flutter 做双端。

产品护城河杂感

Photo by Zane Persaud on Unsplash

一个产品必定有其竞品,而一个优秀的产品则有他特有的被市场认可的模式(这个模式可以是用户体验也可以是生态),以至于其他参与者无法轻易获取这部分市场。比如微信,他的护城河是他的产品体验以及庞大的社交基础,后来者很难轻易的再造一个微信从他这里夺走用户。而这个能力就是所谓的护城河。

在打造一个产品的时候,很多时间也需要考虑护城河的问题。因为 UI 界面,交互这些都是可以被轻易复制的东西,而打造模式才是将竞争对手甩在身后的有利武器。我也做过没有护城河的产品,因此深深知道,类似的产品一旦被人模仿,利润就会被打得很薄,而不能额外获取更多的利润。

我在 W2SOLO 上也看到过某开发者投诉被碰瓷的事情(像素级抄袭),虽然很同情他,但这是一般工具类产品都会遇到的问题。一般工具类产品都是为了解决某个特定的小问题,非衣食住行等消费类每天都会接触,一般比较低频,这也导致了品牌建立困难,用户留存度低,从赛道来讲是先天不足,第二、工具类产品技术壁垒也很低,一般由个人开发者开发维护,项目逻辑复杂度低,技术难度小,容易复制。

继续阅读产品护城河杂感

独立开发者宣言

宣言两字用的比较大,但是很符合独立开发者渺小又要发声的定位。本文节选自 W2SOLO chicken(肯德鸡)自我介绍

全职开发者和独立开发者工作性质不同。全职 APP 开发者处理的是公司的业务中的一部分,面对的是产品经理、测试人员、美工设计、后端工程师等。按组织的项目计划和要求尽好自己的职责完成工作,月底(到)公司收工资。

(而)独立开发者的工作更像一种创业活动,为了容易接触广大消费者和其他平台公司合作,需要注册公司,商标注册,亲自了解市场客户需求,产品设计、产品开发测试迭代、产品推广运营等工作,和创业一样需要承担经营风险,(以防)竞争对手模仿,自负盈亏(等)。 独立开发者工作是一个成长过程也是一种对自己的投资。

我觉得每个 APP 的核心价值和用户群体需要沉淀,也不是每个开发者运气那么好都像买股票一样能追上风口,但怀着帮助人们更好地生活,解决问题烦恼的心,加深对用户的沟通了解,一定会找到自己的客户贡献。