已有多久没离开过杭州？

已经很难想得清楚，至少有 10 个月吧。这么长时间一直呆在一座城市里，想想都有点小可怕。

其实，即便是呆在杭州，多数时间也都是呆在少数几个地方，去过的地方并不多。熟悉的地方并不熟悉，陌生的地方依旧陌生。

生活在一座城，生活在一座笼。

好想换一个城市呆一呆，呼吸不一样的空气、吃不一样的东西、走不一样的路、看不一样的风景…期望，竟似一种奢望。

最近这些天在改进 Klib，其中很多时间都花在数据结构上。

之前，因为只考虑了 My Clipping.txt 这一种数据源，与之对应的数据结构也比较简单。虽说能满足当时的需求，但扩展性差。这不，这版中，新加了 Kindle 网页版本、Kindle 导出的 html 文件、多看等数据源，单是兼容这些数据就是问题；再加上各个源之间的数据合并，真真是头大死了。修改了数据结构后，还要兼容之前的版本，真是 麻烦他妈给麻烦开门：麻烦到家了。

现在来复盘，主要是还是当初产品没设计好，路没走对。这两天正好在看《自律型创业》这本书，书中介绍，在产品初期，要进行充分的考察、定位、设计。可我当初，仅仅是因为自己有需求、本着练手的目的，立马就开始代码。结果挖了这么大个坑，现在来慢慢填。如果当初早些看了这本书、充分了解用户主要的诉求，就可以在设计数据结构时，留下足够的提前量、扩展性，就不至于现在这么被动。

当然，这也是没办法的事。做产品，总是在不断迭代中的。不过，还是要在项目形式前做足功能，尤其是 数据结构的设计，一定要有预见性。

好吧，我说的是 Xcode + Swift.

Xcode 是很棒的 IDE，可是（恩，可是）

• 经常闪退
• 代码提示抽风
• 代码跳转抽风
• 狂占资源
• …

Swift 是很棒的语言，可是（恩，可是）

• 编译慢、结果大，甚至像 Qt 一样需要自带运行库
• 后端弱（恩，主要是 Linux 支持弱）
• 官方示例、网上资源少，依旧是 OC 的天下
• 库少，比如 TryParseDate 的缺少，连十几年前的 C# 都不如，实在是好生痛苦。
• 变化大，每次版本升级都像换了个语言
• …

要忍都能忍；可是，为何要忍？

世上还有很多美好的东西：

• 神之编辑器 Emacs 与编辑器之神 Vim，最近势头强势的 Visual Studio
• 各种优秀的语言，经常出镜的 Python、Go、Ruby，把 () 捧上天的 Lisp，地球上最好的语言 PHP，正在统治地球的 js…

在苹果的体系下，选择余地不多；可跳出苹果、放眼望去，一派繁荣气象。恩，偶尔还是要出逃，多接触下新鲜玩意，就当是新玩具喽。

有竞品来挖用户，自然不是什么让人开心的事。不过，换个角度想想，也是有好处的。

• 如果这么容易就被挖走，反而说明不是自己的核心用户。
• 这样的用户，很可能并不是付费用户。因为一旦付费，一方面就是证明自己当初选择的潜意识，另一方面在金钱上更换是有成本的。
• 最重要的：减少非核心用户对核心用户的干扰。
  • 每个产品都有自己的调性，并且有喜欢这种调性的忠实用户，这其实是产品的立身之本，尤其是商业上成立的根本。
  • 如果不喜欢这种调性的用户，时不时来唱反调。诸如 xxx 就有某个功能、就是这么做的，你为什么不做、不参考呢？回答这样的问题，是很尴尬的。一方面同行相轻并不是很高尚的事；另一方面，很多时候只是个人偏好问题，并没有绝对高低贵贱之分。
  • 一些相似的例子：一些产品早期有很多忠实用户；后来，出于商业等各种原因，产品要扩大用户群，就会进来很多各种各样的人。这对老用户会是很大的冲激：原来的环境、调性被破坏了，这还是当初我喜欢的产品吗？进而开始有老用户的出逃。如何有序地引入新用户、如何让不同用户群体间相安无事，这恐怕是很多做社区产品人心中的难题。

当然，希望你别理解为这是我对自己产品的孤芳自赏、裹足不前。要做好产品，总要了解自己的用户。而要了解自己的用户，总要了解哪些不是自己的用户。

今天，在改进 Klib 时面临这样一样选择：数据库的设计，是要 考虑将来的需求而提前进行优良设计，还是满足现在的需求即可、快速迭代？

如果提前布局，

• 好处是

  • 将来上新功能是会比较顺滑
  • 版本之间的兼容性好、测试工作量小、风险低

• 坏处是

  • 大大增加目前的工作量
  • 增加程序的复杂度、出错的风险，提前增加了测试工作量
  • 如果将来不上对应的新功能，目前的工作就会变成沉没成本
  • 拖延发布日期，可能会错过重要的运营节点

如果选择保守方案，优缺点大致与上述介绍相反。

综合考虑，以目前的进度、我的时间、效率与疲惫程度，暂定后者，即 快速迭代

拔高了说，过度设计对创业是个很大的风险，会极大增加工作量、成本，熬不到春天就已经被拖死。