WEB(RoR)_C(性能)_Elrang(并发)|周期迭代+持续集成+及时沟通

ruby(Web应用/一般任务)- JRuby(用到java源)- VC#(桌面应用)- C++(性能优化/没招了)...

选择html还是脚手架作为demo?

一般的客户在刚开始往往不了解自己到底想要什么样的软件,随着项目的一步步进行,他们会根据实际完成的部分逐渐理清头绪,提出进一步的要求。
有一种说法就是,“真正的需求是在第一个版本完成的时候产生的。”用户在看到完整的成品后,才首次理顺了自己的思路,然后在成品的基础上对功能进行删减。
为了让客户更早明确自己的需求,还是应该根据最初的模糊需求制作出一个demo来,为客户提供一个实体做参考,来进一步细化需求,避免前期的返工。这个最初的demo是交付静态html页面还是由grail那种脚手架生成的crud程序呢?

我倾向于使用脚手架生成的动态程序。
第一,脚手架生成的代码,可以模拟基本的动态功能,也可以保证所有的链接都是完整的,添加测试数据可以直接在笔记本上给客户演示。而静态页面会有很多无效链接,对演示和客户体验造成障碍,影响客户输出更详细的需求。
第二,脚手架生成的代码,更贴近程序员,为数据库进行初步建模就可以生成所有的依赖关系,而静态页面更依赖于美工,这里也考虑一个付出的时间代 价,同等量的页面,是自动生成快一些,还是由美工做快。对于crud部分的页面具有很大的雷同性,应该是自动生成更快,这种页面由美工来制作会产生很多无 效链接。
第三,为demo生成代码的数据库建模,还可以为以后细化建模提供依据,而美工做的demo太粗糙,以后改动很大,感觉等于让美工做了无用功,之前demo的部分很少为以后的开发阶段服务。

但,使用生成代码也有缺点,如果使用html,可以直接交给客户,让他们在本机使用。要教客户在本机配置环境运行代码就太难了。只能采取需求人员 带自己机器,陪客户一起操作(是否为客户和需求人员造成不便?)。或者发布到公网服务器上,让客户直接访问公网服务器上的demo进行试验操作。(是否有 安全保密问题?)

以上想法,偏向于局域网内部程序,对美工排版没有很复杂的要求。应该不适合公网项目对页面要求很复杂排版的情况。

 

冰云

我认为UI,User Interaction和Domain Model是软件设计的两只脚。
只精通其中一种,那设计出的软件也是残疾的。

UI和DM都是对业务功能一种描述,
UI是输入和输出,DM是逻辑处理。

良好的UI和DM都应该有可用性强,美观舒适的的特点。
可用性体现在UI就是布局、操作习惯和便捷程度。
同样是操作系统,为什么linux就不如win普及的多?
体现在DM就是良好的抽象、依赖分离以复用和移植
美观舒适体现在UI就是美术设计,体现在DM就是设计模式、重构

所以我认为UI非常重要,由于自动化如测试等比较差,占用比DM更多成本完全有可能。
UI同样也是业务。不可忽视。

 

>=50% ??

 

robbin

你们过于夸张UI开发的成本了,对于我来说,单纯的UI开发占项目总体的成本不超过30%。

一个项目,界面的布局交给美工去做,而我们开发人员设计持久层和业务层,在这些开发工作中,其实任务最繁重的还是持久层的开发,我对过去使用 JDBC或者CMP每天写得昏天黑地记忆犹新,现在使用Hibernate,工作量已经减轻了一大半了。毕竟通常的应用软件开发都是围绕数据库的数据存取 和查询展开的,说白了就是两件事情:

1、数据的存取和查询,这是持久层的工作
2、数据的录入和显示,这是UI层的工作

但是UI层我们使用MVC模式,V的页面是美工去做的,M的代码是业务程序员在Action里面写的,这样算下来纯粹的UI开发工作只剩下了在模版语言里面嵌上标记,或者JSP里面写上tag,来把数据render出来。然而这些工作量也是很小的。

那么UI层工作量大在哪里呢?大在写Javascript进行各种人性化的交互上了,例如form检查,选择框选择,层的显示隐藏,动态菜单,诸 如此类。然而对于一个成熟的软件公司来,应该积累自己的Javascript组件库,有了这些组件,做这些工作也不是什么难事和费时间的事情。

阅读更多
个人分类: 软件技术
想对作者说点什么? 我来说一句

mybatis<em>脚手架</em>

2018年05月09日 0B 下载

Springboot添加<em>jsp</em>支持

2018年05月23日 0B 下载

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭