我们为什么非要晚上加班呢？！
关于，为什么非要晚上加班的问题，这个问题最近一再被人问起。
首先一个事实是，是的，无论是我在腾讯，小米，还是创业公司的程序员兄弟姐妹们，都躲不开加班的。另外一个事实是，没有人愿意晚上加班干活。注意是加班干活，晚上做自己喜欢的工作不算。
我也经常想避免这种事儿，而在那之前我可以先讲讲，我觉得的，是哪些情况造成我们最后疲劳驾驶的结果。
一个App开发周期，从概念需求制定期，到用户可以下载使用，大约分成，策划，需求确认，UI设计，后台应用程序开发，前端应用程序开发，测试，交付上线，这么几个环节。
以我们目前的项目为例，因为要竞标，开发时间被缩减成3个月（为了使看到这里的你有个比照概念，以在携程的朋友为例，售卖旅游类产品的App初始开发周期大约是半年至八个月，后期功能迭代以月为单位。），而这还不是最糟糕的。
更糟糕的是，计划从4月份中标后，一直到5月10日，前期的需求和设计才最终定型。
然后我们又得回头看看Apple开发审核的特殊性（极其刻薄的规则限定，和令人抓狂的沟通渠道），我们一般都预留出20天左右的提前提交审核缓冲期。
就是说，想要7月20日达成这个任务，我们要6月20日就要提交，开发时间现在被压缩到1个月+10天了，Yeah!
下面是我们如何应对这种情况，我们计划是每天都工作到晚上9点半，周末单休。这种状态在持续到1个月以后，人员都开始挺不住了，正常啊！身体再好也挺不住啊！
即便如此，我们还是让产品开发进度，接近了上线计划。下面说，我们克服了哪些困难。
先说设计端，沈阳是二线城市，相比较北上广深，UI设计人员奇缺不说，水准和意识也差了一大截。比如说我们最开始是压根没有懂移动应用设计的设计师。
终于有了一个从北京回来的姑娘，会一些新东西了，又遇上生产规范严重不符合标准。嗯，这么说你可以不太明白，如果你打开一个她制作的App用截图文件夹，你会发现如下图片命名。
这些全都是设计工具自动产生的名字，从名字我们根本看不出来这是个啥，应该往哪儿放。只能一张张图去预览，或者直接问她。
而人家小姑娘刚回来，又刚刚结婚，所以晚上人家基本是不加班的，这个我完全可以理解，但问题就来了，她下班的时候，我们是没有下班的。混乱的命名会让我们在开发的时候，误解很多设计用意，导致最终产出的东西需要修改的UI设计问题是一大波一大波的。
但是好在，姑娘的态度是专业的，有问题马上改，而且愿意接收我们的建议。
下面，如果说有什么事比一个UI的不规则输出对我们App开发造成更巨大的打击，那就是一个屎一般的后台开发团队。
如果你感兴趣，稍后我可以找一个他们产出物的例子给你，一团乱麻，液态翔！结构上下混乱。你问一个商品的信息，有的没的都返回给你，感觉就是你去问了一个问题，对方跩给你一本小字典的感觉。
开发效率低下，你去反馈呢，对方说：“这个没办法，我们现在用的框架没法改。” 我作为一个前端开发者，时不时要去指导一下后台接口的规范，我是不是还得看看你们的数据库设计啊？
我已经连续暴击他们一个月了，现在慢慢的开始像个现代的Web开发者了。
在说了这么多之后，已经远远不止在回答那个我假设的问题，就是为什么我们要晚上加班，确切的说，我们经常是在下午3点以后才拿到对应的修改和功能点，而这不能完全怪上一个环节的产出效率，因为他们也是在差不多那之前1-2个小时才拿到修改意见。最后抢时间的操作，就都落在我们最后产出上线的这个环节上了。
用一个场景描述来连贯地说明这个过程，做决策的领导层在开了半天大会决定要追加一个页面分享功能，调整修改之后，事情移交到设计部门设计，同时告知后台添加分享需要的程序接口开发。此时是上午11点。
设计部门产出物于当天下午3点来到开发部门，开发部门在使用过程中发现图标命名问题，导致用错了按钮，调细了线宽，于是联系UI返工。此时的UI已经下班了。
第二天下午，在解决了设计问题后，下午2点，后台的新接口上线了，后台的接口上线的内容与他们给出的文档严重不符，沟通后勒令其整改。
下午5点半后台接口重新上线，发现连接方式存在安全隐患，沟通后勒令其整改。
下午7点半，后台接口再次上线，联调后，前台程序多次崩溃，最后发现其中的某个数据字段隐藏在一个错误的层面的错误的地点。
下午8点半的时候，后台反应说，优惠券的数据使用的不对，应该把他们返回的title字段用作为优惠券的类型，而type字段用来显示优惠券的名字。被我骂回去了，“英文再烂，你是不是也有字典啊？！自个儿查查这几个字是啥意思先。”
附上一个后台英文命名典型：addProductCommentUsefulCount，我给他改造了一下，叫markAsHelpful。
然后我们就是这样，在9点左右，拿到了可用的全部材料，开始工作的，同时你不能缺席之前的各个环节，否则你可能9点的时候还是拿不到像样的东西。
