一个输入框你要做一周？
|
另外，当有了前端和后端的分别之后，协议/契约就会变成另一个障碍 — 如何保证协议双方对契约的消费的同步。比如，当前端发现需要展现一个额外字段在界面上，而发现后端并没有提供的时候；或者后端将日期存成了更加方便存储的long，而前端消费时发现没有timezone信息等等。 有了前后端双方的交互之后，校验规则同样需要在后端的模型对象和持久化层中都有所体现。 一种做法是前后端使用同构的架构（JavaScript全栈），这样有一部分代码可以在全后端复用（我们在上一个项目就中采用了React+AWS Lambda+Node.js的模式，整体体验还算不错）。 如果是异构架构，则需要将类似的代码用不同的语言写两遍，而且另外一个潜在的问题是：如何使得两者保持同步？ 当然，我相信在工程上，这些问题最终都可以被解决，但是每个问题及其解决方案都不是免费的。即使团队中的开发有足够的经验和快速的学习能力，很多问题依然是无法预见的，而你永远无法解决一个你不知道的问题。 6. 异常情况大部分情况下，人们倾向于从正常流程去考虑工作量。 而事实上在开发过程中，所谓的“正常流程”才是不正常的。现实世界中有太多的不确定的因素可以让我们的应用崩溃或者停止工作——网络请求超时，地址服务器宕机，后端版本升级，浏览器的不兼容，操作系统的不兼容，不同的硬件环境，特定的浏览器版本（我最近工作的项目上，由于客户使用的kerberos鉴权机制导致只有Firefox的特定版本才可以正常访问应用）等等。 与之对应的正常流程反而如同在走钢丝。 既然异常无可避免，我们需要为其设计很精巧的保护机制，一方面需要让系统可以在错误中恢复（不至于白屏，或者禁用所有功能），另一方面还需要展示以及记录可靠且准确的信息以供修复（日志，前端的Modal，截图等等）。 7. 用户体验功能之外，还有很多其他因素需要考虑。比如可用性（Accessibility）以及易用性（包括页面上字词的选择和用户体验），以及兼容性的考虑。一些常见的会影响开发工作量的因素包括：
如果涉及响应式设计，则需要和UX进一步合作来确定实际方案。很多时候，多个设备上的交互模式都不尽相同，比如iPad上的hover效果，小尺寸屏幕上的字体等等。 03 技术之外的因素除了技术上很难预见的延迟和障碍之外，实际项目中还有很多会消耗掉大量时间的事件，它们无处不在，细微而琐碎，但是累积起来产生的影响则相当可观。 1. 混乱才是常态比如项目上有若干名同事： const roster = [ '吴荣华', '侯晓成', '贾彦军', '邱俊涛' ] 从概率上来说，每个人都或多或少有些工作之外的事情要处理，比如偶尔休假，不太舒服在家休息，通勤路上堵车，或者在买咖啡排时迷路等等。 const excuses = [ '堵车了', '迟到了', '要接小孩', '不舒服，请半天假', '休假了' ] 而生活就像是这样一行代码： ${_.shuffle(roster)[0]} ${_.shuffle(excuses)[0]}
所以，我们眼中的世界就是这个样子的：
当然这些异常不会每天都发生，但是如果项目足够长，这些事情则几乎必然会发生。随着人员的增加，参与方的增加，不确定性随之提高，不是一切都正常的概率则会变得非常大。毕竟，混乱才是这个世界的常态。 而这些混乱可以让我们之前的估算失效，耗时增长。而这些混乱在估算之初则很难被我们看到，从而导致估算往往偏小。 2. 一个小故事在几年前的一个项目上，我估计理想情况下大概需要三天来实现一个对某个资源的RESTful API，客户的技术负责人当时就怒了，说他自己写半天就可以写完，不就几个CURD嘛。 （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
