KITESHADOW TECH — 鸢影技术

一家只有一个人的软件公司

在这行摸索了些年头，盘旋久一点，落下来才准一点

关于

鸢属鹰科。很少扑翼，多是借上升气流盘旋，在高处看清楚了才下落。影是它掠过地面时留下的东西——人通常先看见影子，才抬头找到鸟。

取这个名字，一半说的是做事的方式，一半是做出来的东西本该比做它的人先被看见。

规模就是字面意义上的一个人。

需求怎么理解、界面怎么排、数据表怎么建、服务器怎么配，出自同一套判断。好处是不用开会，坏处是出了事没人可以怪。

这些年折腾过几个自己的项目。有的做成了，后来转手卖掉；有的一路做到上线，最后没能活下来，那些代码到现在也不太想再打开。留下来的经验多半来自后一类。

现在同期只推进一到两件事，手上的东西还没到能公开的时候——不是故弄玄虚，是有几份文件还在路上。

这样的尺度有它明确的边界，也换来一点别的东西：一年后要改，动手的还是当初写下第一行代码的人。想赖也赖不掉。

在意的事

需求没想明白之前，任何技术方案都只是猜测。多数返工不是因为代码写错了，而是一开始要解决的问题就没找准。所以开头那段琢磨往往比后面的实现更花时间，从外面看，跟发呆没什么区别。

数据结构和接口先立住，界面才有东西可以承载。反过来先照着界面凑功能，一开始也看得过去，业务一变就只能打补丁，再变就得在补丁上打补丁。顺序对了，改起来才是改，不是补。

交付不是终点，有人开始用，才是这东西真正的起点。所以宁可开头多想一阵，也不给自己留下三个月后不敢碰的地方——经验表明，那种地方最后都得由自己来碰。

现在把代码写出来这件事本身已经不值钱了，难的是系统里每一处都能说出为什么是这样。删掉某一行会不会出事，这个问题该能直接回答，而不是靠跑一遍看看。

趁手的工具

移动端以 Flutter 为主，需要贴近系统能力的部分下到 Swift 或 Kotlin 实现，不拿插件将就。服务端按项目性质在 Go 和 Rust 之间选一个，不是两个一起上——那是写简历时的操作。

联系

技术上的问题或单纯想聊两句，都行。

偶尔也接一两个外部项目，条件是问题本身值得琢磨、时间不赶，做完之后代码和服务器都归对方。手上有想法想找个人一起做的，同样可以聊，只是最好已经自己想过一阵。

不过多数时候手上是排满的，回信可能慢。