前些日子参加了某云的开发大赛，结果出来了～ 
仅仅拿了一个三等奖，略桑心。
参赛过程具体见《[如何一下午写3000行？记某云的Golang API
SDK生产过程](/%e5%a6%82%e4%bd%95%e4%b8%80%e4%b8%8b%e5%8d%88%e5%86%993000%e8%a1%8c%ef%bc%9f%e8%ae%b0%e6%9f%90%e4%ba%91%e7%9a
%84golang-api-sdk%e7%94%9f%e4%ba%a7%e8%bf%87%e7%a8%8b)》
不过伤心之余，我理性一把，看了看前4的分别都是啥： 特等奖是移动客户端的解决方案：mu
MU (Mobile UCloud) 是一个基于 UCloud API 的手机版管理工具……
成熟度已经和产品可以媲美了，也解决了在移动端大潮之下，官方对移动端支持几乎是空白的痛点，所以只需要签个协议就可以用的产品，拿奖不奇怪。
而三个一等奖里，有另一个产品： ESS_For_Ucloud
这货就相当于AWS里的ELB，同样是改改就能投入线上使用的产品。 解决了……呃……官方有LB，但是需要人工调整这样"不云"的尴尬。 第二个一等奖是：
Ucloud CLI命令行接口
回想我司的运维、SA们用来控制AWS的工具，不是web控制端，不是各种写好的SDK，而是AWS CLI，因为他们最熟悉的就是各种脚本。
这也正是比赛举办方所缺少的！ 虽然命令覆盖得并不是很完善，但也算是补上了个自动化运维的坑。 最后一个一等奖是： Python
SDK
在我吐槽官方的SDK用了**params这样的动态语言特性时，聪明的人自然会想到，举办方自然希望修补官方的SDK也是比赛的侧重方向了嘛～
虽然，我粗浅地看下去，这个SDK也仅仅是修补了官方SDK调用时不严谨的尴尬，而且由于API这么多，自然覆盖得不全，但是也算抓住了举办方的心了。
公布之后在交流群里，不少人也吐槽自己UT覆盖率比得上面的都高，为啥只能拿二等甚至是三等。反过来想，真的算是程序员典型的思维了：自己做的程序、工具很"牛B"，但是为啥没有人用，甚至是不受欢迎。
都是因为： 没有抓住痛点！没有抓住痛点！！没有抓住痛点！！！ 所以，下次做东西的时候，得多问问自己：
需求是啥！？