前一阵做了一个小程序，用于查看火星天气，一直计划重构，但是目前看来时间是不允许了。这个作品的故事之前在掘金和 V 站上发过，这次同步到博客中来，等重构完成再讲一讲重构的故事吧。

首先证件照：

Github 地址：https://github.com/dongsuo/SpaceOdyssey

线上小程序：

1. 介绍

本指南目前可以查看近日火星的天气，包括气温、风速、风向、气压等数据，今后将支持更多功能以满足漫游者们进行星际漫游的需求。
本指南的火星天气数据来源于洞察号火星探测器提供的每日天气数据，由于地火间恶劣的通讯环境，可能会有延迟、数据丢失等问题发生，请漫游者们 DON’T PANIC. 一切尽在掌握中。

随着地球宇宙空间探索技术的发展以及地球资源的日渐枯竭，必将有部分地球人继承大航海时代探险家们的遗志，向广阔的外太空进发。虽然目前星际航行技术还尚不完善，但是已经有一部分先行者踏出了第一步，为了向星系漫游者们提供充分且完善的情报支持，本人特开发了星系漫游指南这一小程序，该小程序可在任何安装了微信(WeChat)的手持智能设备上使用，而无需考虑平台兼容性，界面简洁大方，功能简单易用，真正做到了即开即用，即用即走，实乃居家旅行，杀人灭口必备应用。

2. 缘起

这个小程序是源于在微博上看到 NASA 提供了一个查看火星天气的页面，于是我就去扒了一下 API，做成这个小程序。代码很简单，只是拉取API，展示数据。难点主要在于产品和设计，好在自己瞎看过几篇关于产品和设计的文章，再加上 dribble 和公司设计师的帮助，算是把这个简陋的第一版给上线了。

3. 技术

3.1 跨端开发

小程序的技术比较简单，我用到最近大火的号称跨端开发的 Taro 框架，一边查文档一边写，好在功能简单，没遇到什么难搞的地方，但是由于一开始没有规划好，导致转 H5 的时候遇到了一些跨端兼容的样式问题，后面我会修一下这部分的问题，并部署 H5 版本。跨端开发还是有很多问题要注意的，有太多坑要踩，比当年兼容 IE 麻烦多了，幸好我这项目还算简单…… 对微信小程序这种强行制造割裂封闭的环境的行为，我只能说：始作俑者，其无后乎。不过技术乌托邦从来都是梦想，咱们对此也无能无力，只能提高自己了。

3.2 API代理

为小程序开发者所周知的是，小程序对 API 地址有严格的限制，要求必须为 HTTPS、指定范围内的、国内备案的域名方可访问，但是 NASA 的 API 地址怎么可能在国内备案呢？于是我只好在 leancloud 的云引擎上部署了一个用于代理的API，转发我的请求，但是这样一来这个低级的应用层的代理就会导致 API 变慢，而且免费版的 leancloud 在没有请求的时候会自动休眠，这样一来有时候接口就更慢了，但是往好处想的话，也算模拟了地火间高延迟的通信环境了(笑)。

3.3 微信分享

小程序分享是可以设置分享图片的，我调用了 unsplash 提供的免费接口来获取一张随机的关于太空的图片，其实我本意是计划用这个图片作为背景的，但是实际做起来发现在随机背景图上很难实现完美的文字显示效果，所以，最后放弃了这个方案，unsplash 的图片接口只用于设置分享的图片了。当然这个接口也存在备案的问题，解决方法跟 NASA 的 API 的一样的。这个接口还存在的一个问题是 demo 版本每小时只能访问50 次，超出次数会出错，但是好在不会反映在前端 UI 上，后期再优化吧(希望 unsplash能通过我的 API 申请)。

4. 产品和设计

对于一个程序员来说，这个小程序遇到的最大困难其实是产品和设计，在这个简陋的版本出来之前，我还用我浅薄的产品和设计知识做了一个更简陋的版本，实在是惨不忍睹，没脸拿出来见人。

4.1 设计图

我在 dribble 上选择的第一张设计稿是这个：

好看是真的好看，而且背景是火星日落的实拍(调整过)，但是这个卡片存在一个问题：卡片之外的部分怎么办呢？我很难去扩展啊，这个卡片连一屏都不到，很难拿来直接用的(也许是应用场景的问题)。于是我只好换了一个，也就是现在这一版的样子了。最近在读《Refactoring UI》这本书，我发现对于开发者而言设计还是一个比较难的事情，尤其是配色，虽然市面上有那么多帮你选择颜色的工具和网站，但是当真正要做一个产品的时候，仍然很难找到一个舒服的配色。

4.2 产品

关于产品我也想了很多，但是又要设计又要 coding，期间想出了很多产品上的设计，然后又不断推倒，最终去繁就简，只做了这样一个简单的版本出来。我觉得，一个产品迭代中很重要的一点是保持概念的完整性，建立了概念的完整性之后，就不要轻易改动，否则这些改动传导到设计、开发甚至测试阶段都会造成很大的效率上的损耗和工作量的提升，这也是为什么产品经常改需求会导致开发的反感。这一点其实我是受到了《人月神话》的启发，软件开发的基本流程是需要严格遵守的，敏捷开发的思想和实践也不能推翻这一原则：产品的概念完整性不能轻易改动。我以前对这一原则的重要性认识不足，最近在各种经验和教训中深刻体会到这一原则。

大道理

最后，我想说，这不是一篇技术文章，文中没有涉及到什么技术，主要是分享我在开发这个小程序的过程中的一些思考，涉及到方方面面吧，希望大家不要说我水，我觉得无论对于个人成长还是对于工作而言，程序员都不要把自己限定于技术开发这一身份，见多识广才能更好地跟后端、产品、设计讨论出更好地方案嘛，对个人而言，扩宽自己的思路也有助于个人职业道路的发展。更深一步地说，也有助于个人人生价值的实现，摆脱资本主义对自己个人的异化(强行装 bi)。