<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
<title><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></title> 
<link>http://jackxiang.com/index.php</link> 
<description><![CDATA[赢在IT，Playin' with IT,Focus on Killer Application,Marketing Meets Technology.]]></description> 
<language>zh-cn</language> 
<copyright><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></copyright>
<item>
<link>http://jackxiang.com/post//</link>
<title><![CDATA[[转载]搞个这样的APP要多久？]]></title> 
<author>jack &lt;xdy108@126.com&gt;</author>
<category><![CDATA[WEB2.0]]></category>
<pubDate>Tue, 08 Sep 2015 09:09:59 +0000</pubDate> 
<guid>http://jackxiang.com/post//</guid> 
<description>
<![CDATA[ 
	背景：转这个哥们的文章有两点：1）他的博客和我的样式几乎一样，有缘分。2）现在移动互联网如火如荼，虚火很大，很多人都往里面钻，但真正懂用户懂产品技术的还是少，这个哥们的语言有点调侃，描绘生动，心理活动也很丰富，集合现实的一些人情关系的描写，跃然纸上，转了吧。<br/><br/>这是一个“如有雷同，纯属巧合”的故事，外加一些废话，大家请勿对号入座。开始了……<br/><br/>我有些尴尬地拿着水杯，正对面坐着来访的王总，他是在别处打拼的人，这几年据说收获颇丰，见移动互联网如火如荼，自然也想着要进来干一场，尽管王总从事的行当也算跟IT沾边，但毕竟太长时间不接触技术，有些东西不太熟，总要咨询下我这个在一线开发混了十几年的老程序员，十几年的开发，有好几种可能性，不过这不是重点，所以暂时忽略掉这个细节吧。<br/><br/>我之所以尴尬，是对王总的需求有些不知如何回答，仿佛陷入了某种习惯性的沉思中。<br/><br/>王总站了起来，把手机递到我面前，说：“你看看，就这样一个APP。”他不太熟练地在屏幕上划了几下，我并没有很认真地看，因为我知道这个问题很难，那就是所有的开发者都会被问，并且可能是被问得最频的一个问题：“开发这么一个APP需要多长时间？”我很想说不知道，这可能是最直截了当和准确的回答，但面对王总这位老朋友，我要是这么回答估计有些失礼，所以这个时候，我除了大致思量了一下他所指的那个APP大致涉及到哪些方面之外，还要组织下自己的语言，如何用非常得体的话告诉他，这个事情我估算不出。“你看，就这么简单的一个APP”，王总继续在屏幕上拨弄了几下，然后带着几分期待的眼神看着我。<br/><br/>我谨慎地说：“坦白说，我说不准，我这方面经验也不是很足，尽管做过APP开发，但又跟这个很不一样，得具体分析好所有的逻辑，才能估算出时间。”<br/><br/>王总对我的说法似乎不以为然，他晃了晃手机，说：“我要求不多，其实比这个还简单”，他指着屏幕上某些地方，继续说：“这个，这个，这个都可以不要，只需要这么一个列表，里面有详情，可以查看修改……”<br/><br/>我心里很自然地想到这是很典型的“想当然简单”的态度，我想我得让他认识到这个问题的复杂程度，我反问道：“需要登录吗？”<br/><br/>王总稍作停顿后，说：“那当然。”<br/><br/>“什么登录？用户名密码方式，还是手机登录，抑或像QQ，微博，微信这种可以借用的第三方登录？”<br/><br/>王总这回似乎想了一下：“作为移动互联网，我想手机登录肯定是要的，QQ，微博，对了，微信，微信最好也要……哦，你前面说用户名密码，这个应该也是要的吧。”<br/><br/>我很流利地接着问：“那总得有注册，如果你打算用手机登录，那得找个短信平台，还有微信登录，你得先做好企业身份认证，对了，有登录，有密码，那密码找回功能也得有吧。”<br/><br/>“这是肯定的。”<br/><br/>“同时有多种登录途径，你必须要想出一种合理的逻辑来将它们‘整合’，最常见的当然是账号绑定，例如给你的账号绑定手机号码，这样就能用手机号来登录同样一个账号，对微信登录也同理，但如今移动互联网的用户们都挺厌恶注册流程的，所以往往会要求直接手机登录或者直接微信登录，自动完成注册过程，那考虑这种情况，如果用户先用微信登录，然后再用手机登录，而不是绑定，那么就会产生两个不同的账号，而且无法将其再‘整合’起来，我们得想出一套比较完善的方案……”<br/><br/>王总对我所说的似乎有些缺乏耐心：“没必要这么复杂吧？你看看这个APP，这些不都有吗？”<br/><br/>“有没有我前面所描述的那个问题，你尝试过了吗？”<br/><br/>但王总似乎对问题并不关心，他只想知道做这么一个APP需要多长时间，当然要多少钱，这也是他关心的问题，他拿出了信心满满的语气：“有问题怕什么？困难算什么？这些我相信都能解决，但时间很要紧，得快，我们的竞争对手不会等我们，就这么一个东西，你想想看，要多久？”<br/><br/>看他的架势，像十足那种混得风生水起的成功人士，而我这种身份低微的程序员在他面前确实是有口难言，我本来还想继续告诉他细节的重要性，却被他打断：“不，不需要有多精确，你只需要估算一个范围，两个星期？或是两个月？”<br/><br/>我觉得我没必要再隐瞒什么了：“我真的不知道，也许一支优秀的团队两个星期就能做好（不过我自己可不相信有这么牛逼的团队），但我很明显不是那个能创造这种奇迹的人。”我心想其实就算说出了“两个星期到两年”这么一个开玩笑式的范围，也可能是错的。<br/><br/>王总似乎对我这样的回答很失望。但他是个执行力很强的人，想做一件事，就一定会行动，行动一定快，一定要有结果，这种雷厉风行的行事风格，确实，我挺欣赏，不过他的这个项目，我可真帮不上忙，但我还是出于礼貌，说道：“技术方面有什么问题，还是可以来问我的。”<br/><br/>====================== 不怎么华丽的分隔线 ======================<br/><br/>“做一个APP需要多长时间？”这个问题估计比测一个人还能活几天还难，一个条件如此不充分的问题，如何回答呢？<br/><br/>总体来说，需求越是明确，团队越是成熟，估算出来的时间就越是准确。而软件开发这个事情，不管发展多少年，不管提出了怎样的方法论，都没办法像传统制造业那样把“工时”算得那么精确，其内部错综复杂的逻辑关系使然，软件工程，绝无可能量产。<br/><br/>用户看到的只是一个APP，如果他用的是iOS系统，也许他根本就不会接触Android，不知道开发者除了iOS版之外，还需要做一个Android版，（有没可能还有Windows版？这样工作量无疑更大）或者，网页版搞定一切？也许你真正动手做过后就不会这么认为，再说微信小店那种模式真能适用于所有场合么？而且，如果不是网络出现异常的话，一般用户也不会注意到服务器的存在，服务器总是那么默默无闻地为用户全天候地工作，它的开发难度恐怕也不亚于APP本身，而负责APP运维的还需一些人力，大了之后甚至需要组建一个专业团队，他们需要一个“后台”，能随时查看和处理数据，如果需要随时随地都能查看和处理数据，恐怕还得给后台专门弄个APP。<br/><br/>这个道理就有点类似：我们看到了战机在天上华丽地完成了歼敌任务，以为只是战机本身很牛，往往忽视了战机相关的那些配套，如果没有娴熟的飞行员、作战指挥中心、地面雷达、预警机、补给、机场或航母、地勤人员等等，那么战机将失去战斗力。APP也一样，它不是一个只要能跑起来就完事的东西，支持它的配套设施和维护工作丝毫不比APP本身简单。<br/><br/>除开这些大的方面，细节上也带有许多的不确定性，所以一支成熟的团队尤为重要，一个经验丰富的开发者会知道，至少大致知道这个开发过程会遇到哪些问题，哪些问题比较简单，哪些问题则可能需要耗费大量的时间，这得依赖经验。我有一句话常常挂在嘴边，那就是：“没做过的东西别轻易说简单。”“想当然简单”的态度对项目没有任何好处，如果自己不确定，那么去咨询一个有这方面经验的人，就算得不到具体的答案也有大致的方向，沿着这些方向研究一下，就能知道会面临的那些问题，当然往往还不是全部。<br/><br/>关于“低估了难度”这事情，我过去的公司有个经典故事，当时有个小项目，就是准备把一套已经在仪器上使用的只支持英语的程序增加多语言支持，程序并不大，涉及内容也不算太多，工程师一开始认为这只是个简单的翻译工作，顶多两个星期就能完成，但一做下去就发现不简单，首先翻译得找专业人士来做，自己做不好，我们没人精通欧洲各国语言，接下来还有单位换算，有些国家用公制，有些用英制，这个得考虑，包括日期显示格式也得考虑，一下子不知道多了多少工作，这些都差不多了之后又发现了德语单词过长，我们的仪器的屏幕显示不下，超出范围，于是再调字体，做精简，前前后后开会讨论了N次，最后想Release的时候发现这么一改，程序的Size变大了很多，有些仪器的存储器装不下，这下大家可都傻了，优化呗，精简呗，程序开始有些凌乱不堪了，最后勉强通过质控部检验，总算发布了，发觉足足搞了半年。不过如今想想之所以耗费了这么多时间，一个很重要的原因是经验不足，对多语言，国际化这块不熟，走了不少弯路，所以我前面也提到，成熟的团队尤为重要。<br/><br/>我们在估算项目时间的时候，往往只算了“写代码的时间”，而把那些和老板或客户扯皮，做需求分析，设计，测试，和修复bug的时间不考虑进去，而这些时间加起来通常比写代码的时间多出不少，我个人是不轻易为了讨好老板而把完成时间说得很短的，为啥？——根本做不到嘛，干嘛要撒谎？如果一个需要一星期完成的新功能开发，我通常得把这个时间double，这已经算比较“不保守”的了。<br/><br/>即便只算写代码的时间，也往往会被低估，老板或客户对你开发的东西很可能不满意，或许你误解了他的功能需求，或者界面有点卡顿，或者这个图标颜色不好看，你是开发者，不是美工，虽然凑合可以当一下美工，但毕竟不专业，更重要的是做做UI设计，做做图这种事情，也得耗费不少时间，当你为“一个像素”焦头烂额的时候，是不是很渴望团队中有一名设计师？这时候得提醒下老板：你必须要在时间和功能之间，做点取舍。老板当然很不高兴，但也不得不在功能上做出了一些妥协。虽然这样做能让难产的项目早点上线，但却为来日项目的失败，给老板添加了一个很好的借口：我们的工程师太差了，没按我说的去做。<br/><br/>老板或客户除了会抱怨你做出来的东西不够好看之外，还会再提很多东西：这个界面能不能改成多选，能否增加通知功能，已读未读状态要有，界面能不能再流畅点，昨晚程序咋“闪退”了一次……需求只管提功能，但没说具体这个UI要多美观，也没说程序稳定性要好，更没涉及到要达到多大的吞吐量，当然，可能更重要的——安全性也没提，你心一惊：是啊，如果有黑客，不，只要稍微懂一点技术的恶意用户想刷爆我们的服务器，那简直太简单了，而这些防护措施我都没做！所幸的是项目名气太小，暂时无需考虑这个。（貌似大多数APP都活不到需要考虑这个的时候）<br/><br/>所有这些，你说功能也好，细节也好，稳健性也好，都不是能自动从土里长出来的东西，都得需要花时间去想，去做，有些甚至还是个“系统工程”，如果头痛医头脚痛医脚去做的话，系统里到处充满“飞线”，无疑会给将来的维护留下了许多隐患。攻城狮的你，都考虑了吗？更别说老板为了节省成本而给你购置的低性能电脑让你整天抓狂这些“无关紧要”的事。<br/><br/>====================== 不怎么华丽的分隔线 ======================<br/><br/>话说王总告别我之后就以迅雷不及掩耳之势注册了公司，注册了域名，搞到了办公室，还一下子叫来了一帮子人风风火火地搞了起来，这种发展势头，这种干劲，我只有自叹不如。心底里真有些后悔怎么没跟他去干事业，不过这只是感性的一瞬间，理性又在接下来的几百毫秒里将我拉了回来：还是别去好，跟他沟通不来的。<br/><br/>王总的项目后来以一飞冲天之势迅猛发展，而他如今已经是一家估值几亿的公司的CEO，我嘛，越来越觉得自己是个Loser，独自坐在办公室里，还是拿着那个水杯，懊恼不已——打住！这样是不是比较有戏剧性？可虽然一开始我就声明此故事“如有雷同，纯属巧合”，但也不能胡乱瞎编，真正的结局是：确实风风火火弄了几个月，后来就突然杳无音讯了，本来想打电话问问王总究竟怎样，无奈他变成了另一个超级忙人，再无心思跟我聊家常了。嗯，结局还是差不多，我还是那个继续苦逼地坐在办公室里的程序员，唉，别想了，开工吧！<br/><br/><br/>原文原创来自：http://www.cnblogs.com/guogangj/p/4676836.html
]]>
</description>
</item><item>
<link>http://jackxiang.com/post//#blogcomment</link>
<title><![CDATA[[评论] [转载]搞个这样的APP要多久？]]></title> 
<author> &lt;user@domain.com&gt;</author>
<category><![CDATA[评论]]></category>
<pubDate>Thu, 01 Jan 1970 00:00:00 +0000</pubDate> 
<guid>http://jackxiang.com/post//#blogcomment</guid> 
<description>
<![CDATA[ 
	
]]>
</description>
</item>
</channel>
</rss>