决定做官网：项目不能只在硬盘里躺着
我这个“公寓大楼”的项目，从一开始就是奔着能实打实做出点东西去的。但以往的经验告诉我，一个人捣鼓项目，最大的问题就是没人监督，做到一半就心猿意马，项目文件堆在硬盘里腐烂，自己都忘了上次更新是什么时候。
这回我下定决心，不能再这么干了。要保持热情和持续性，唯一的办法就是搞透明化，也就是所谓的“官方网站”。说是官方，就是个大点的笔记簿，专门放两样东西：项目进展介绍，以及最重要的——更新日志。
以前都是代码写完拉倒，现在等于我给自己加了一道工序：必须把代码实现的东西，翻译成正常人能看懂的话，丢到网站上。这玩意儿一上线，就等于把开发进度亮出来了，不好意思偷懒，逼着自己往前走。
我坐下来想，这个官网得达到几个目的：要能看，不能太丑；要方便我这个程序员自己更新，最好点两下就能发布；成本要低，能白嫖绝不花钱。
撸起袖子干：选技术栈和部署
我没选那些看着花哨的前端框架，学不动，也没时间。我直接搬出了一个最简单的静态网站生成器，它能把Markdown文件直接变成漂亮网页，省去了我手写HTML的烦恼。这等于直接解决了“好看”和“方便更新”的问题。
设计上，我就地取材，找了一个极简风的模板，稍微改了改配色，让它看起来像那么回事。网站的主要页面结构被我定死了，一共就三个：首页、项目介绍、和最核心的“更新日志”。
- 服务器选择： 我扫了一眼自己的云服务列表，挑了个配置最低但带宽还可以的机器。网站本身就是静态的，对服务器性能要求几乎为零，省钱才是硬道理。
- 部署流程： 我折腾了一下午，搞了个极度简化的部署脚本。我只需要在本地写完更新日志的Markdown文件，然后运行一个命令，它就会自动生成静态文件，并通过SSH扔到服务器的特定目录下。整个过程不到三十秒，完美解决了“方便更新”的问题。
- 日志系统结构： 我设计日志文件名称就是日期加序号，比如`20230501_*`，这样网站生成器就能自动按时间顺序排序。我甚至懒得做评论系统，直接在底部挂了个邮箱，爱提意见的人自己发邮件来。
我把域名直接绑定了上去。当看到自己的项目名和更新日志赫然出现在浏览器里的时候，那种感觉是完全不一样的。这东西不再是我硬盘里的一个文件夹，它成了一个公开的、正在生长的项目。
最麻烦的部分：如何持续写更新日志
技术实现相对简单，但真正的挑战是养成持续记录的习惯。我以前最大的毛病就是，代码写爽了，就忘了记录，等想起来时，已经搞了十几个功能，完全记不清细节了。
为了治这个毛病，我制定了几个规矩，逼着自己遵守。
第一条，也是最难的一条： 任何一次提交代码（Commit）后，如果这个提交代表了一个对外可见的改动，必须立刻写日志。我强迫自己，在代码提交和部署上线之间，加了一个“写日志”的步骤。不写完，这个功能就不算正式完成。
第二条： 日志内容要通俗易懂，像讲故事一样。我尽量不用代码里的专有名词，什么“重构了A组件的依赖注入”、“优化了B类的抽象工厂”，这种屁话读者根本看不懂。我得翻译成：“修复了电梯偶尔会卡住的BUG”、“新增了玩家可以购买基础家具的功能”。这逼着我从用户的角度去审视自己的工作，而不是从代码的角度。
刚开始那段时间，简直是折磨。有时候一个微小到不值一提的改动，我都要斟酌半天怎么写，搞得效率很低。但是，坚持了一个多月后，这个习惯慢慢就形成了肌肉记忆。当我完成一个小功能，脑子里就会自动浮现出“这个日志该怎么写”的草稿。
结果与收获：它到底值不值
这套官网加更新日志系统现在已经稳定运行了好几个月了。从技术层面看，它没有一丝高科技含量，但从项目管理和自我驱动的角度看，它简直是救命稻草。
最直接的好处是，我再也不会迷茫我的项目到底做到哪一步了。当我在游戏开发中遇到瓶颈，或者感到疲惫时，我就会打开自己的官网，从头到尾翻看那些更新日志。
- 我看到了自己解决过的那些棘手问题。
- 我看到了项目从一个空壳子，一步步变成一个有模有样的“公寓大楼”。
- 我看到了时间线，清晰地知道自己不是在原地踏步。
这个过程也意外地给我带来了一点社区反馈。虽然我的项目关注度不高，但总有那么几个陌生人，通过官网留下的邮箱，发来一些鼓励或者提问。这种零星的互动，又反过来激励着我，让我觉得我做的事情，至少还有人在关注。所以说，一个简简单单的官网和日志系统，它不是负担，它是一个非常重要的助推器，我建议所有正在独自开发项目的兄弟们，都赶紧动手搞一个出来。