为了提供一些背景,我在过去的几年里一直是Ruby&Rails的开发人员,最近我开始做很多JavaScript来增加应用程序的响应性。
在后端编程时,很容易(至少对我来说是这样),完成大多数由测试驱动的东西,并且不断地整理出一堆可以工作的代码,同时能够集中精力。
但是我发现,当我越来越倾向于正面的时候,我会不断地进行语境转换。有些JavaScript很容易测试(模型),但是直接连接到GUI的部分似乎不可能自动进行合理的测试。
当我第一次用虚拟数据开始GUI部分的时候,这就不那么重要了,但是一旦它们都连接起来了,GUI是基于来自外部API的数据创建的,而我的机器同时运行着两个应用程序,我基本上都在调试这两个应用程序,看起来我只是在不断地切换上下文,不能真正专注于一件事情。
这里的一个例子可能是一个Node.js聊天服务器,它通过一些API连接到另一个Rails应用程序。现在,如果API已经完成并固定在一起,那么我可以很容易地关注Node.js部分.但是,为了以某种敏捷的方式完成整个工作,我只是在构建Node.js应用程序时构建了API,这对Rails和Node (都由不同的数据库等备份)都有副作用。
如果我把这比作做一个小型图书馆或者只是做一些深层次的后端工作,我发现我的工作效率基本上是不存在的,因为我经常在50个不同的地方寻找bug,而不是只关注其中的一个。
发布于 2012-05-17 17:53:58
如果您不想切换上下文,那么应该将GUI开发交给其他人。
如果系统的前端和后端是由同一个人开发的,那么您所遇到的问题是非常常见的。
另外,如果您有所有的需求规范,那么单独开发这两个部分会更容易,但是您当然是在谈论敏捷开发。
发布于 2016-02-10 10:50:30
坐下来思考您需要什么,为此开发API,然后开发GUI以使用该API,这是没有问题的。如果您在开发时发现您的API有缺陷,那么您对整个系统的考虑就不够好了。您可以返回到API并添加缺失的位,然后返回您在GUI开发中的位置.但这正是问题所在。相反,当您发现一个缺陷,并留下一个漏洞,当您有足够的漏洞,然后返回更新API (在第二个版本),然后开始填补缺少的部分的GUI。当你做一些前面的设计工作时,洞应该是小的。
将API看作是在使用之前需要发布的东西,那么您就不能随意更新它,您将在设计工作中开发一些规则。
https://softwareengineering.stackexchange.com/questions/149068
复制相似问题