专栏首页哲学驱动设计用户反馈:对 Rafy 开发框架的一些个人建议

用户反馈:对 Rafy 开发框架的一些个人建议

这篇文章是去年 Rafy 框架发布后,许胜平先生为我提出的一些建议。他从用户群体分析、社区、商业模式、技术支持等方面对框架发展提出了建议,我觉得写得非常不错。此文不仅适用于 Rafy 框架,所以不敢私藏,转载出来和大家分享。

在此,再次感谢所有关注、支持 Rafy 框架的人。

WORD 文档下载地址:《20131002 东莞-许胜平建议 ([201309]对 Rafy 开发框架的一些个人建议)》。

----------------------------------- 以下内容转载自 Word 文档-----------------------------------------

对Rafy开发框架的一些个人建议

1、潜在使用群体分析

个人认为使用类似Rafy、AgileEAS.NET、PDF.NET及OpenWorks框架的群体主要为以下几种:

1.1、小微软件企业

小微软件企业,这类软件公司的开发人员一般在10人以下,多以项目实施为主基本谈不上产品,大多以某行业的信息管理软件为主,主要由老板(核心销售)谈下来的一些项目,由于所在行业竞争比较激烈,多数在拼项目报价、实施时间,因此该类项目的利润均不高,同时企业年经营额多在百万以内,超过三百万的都算非常好的啦[1]

该类软件企业的特点是:

1、 企业项目利润很低,在软件开发方面的投入相对较少,同时也没有该方面的技术实力;

2、 由于不能给员工以比较有吸引力的薪酬,所以人员流动性较高,经常是做一个项目换一批技术人员,企业想进行一些基础框架的开发也随着核心开发人员的离职而丢了下来;

3、 实施的项目经常缺乏稳定的技术人员进行维护;

4、 由于人员流动性高,造成有关项目及类似项目在实施过程中经常被客户投诉人员技术不好,特别是对所在行业的理解,而新进项目的人员一方面要学习原项目使用的开发技术,另一方面还要学习行业经验;

5、 企业老板则对项目实施的进度、质量十分关心,也担心核心技术人员的离职造成项目资产(代码、流程及文档)外泄,该情况一般会给企业比较大的打击。

因此,小微软件企业最关心的是:1)能够在现有软件项目成品的基础上快速定制出客户需要的软件,像搭积木一样组合出不同的产品,企业已有的软件模块能够方便进行复用;2)快速响应、快速实施;3)更关心功能的实现,对软件底层技术的运用因竞争、技术人员能力的限制无暇顾及;4)开发框架及应用技术的易用性,希望技术人员能够通过简单的培训就可以上手,并加入到实际的项目中;5)良好的技术支持、完善的开发文档、详尽的开发案例及可以有底层的源代码,必尽他们也关心自己产品的安全性,若他自己的产品都还没有做出来你的东西就不再维护了,那免费也没人敢用。

1.2、中型软件企业

这类软件公司一般都有自己的底层框架或比较成型的开发平台,所以一般不会或很少采用外部的软件框架,有的话也会很慎重考虑各方面的因素,如框架的稳定性、是否可维护、有无源代码、框架的延续性等。但是,他们目前面临着原有软件产品的更新换代及产品线的升级问题。

中型软件企业在使用框架时主要:

1、 有选择的使用其中一部分,例如模型驱动开发、界面生成、动态表单管理等;

2、 框架的鲁棒性及可扩展性;

3、 与企业自身平台或框架的集成能力。

当然,若框架足够优秀也不排除整套框架被全部收购的可能,对框架的主创人员虽说难于割舍,但这应该是大多数框架在发展过程中的最好结果。我个人没有这方面的经验不知能够值几何,呵呵:)

1.3、程序员、技术爱好者或干私活的

该类人群使用框架更多的是为研究、学习之用,或者使用它干私活的居多,或许这只是我个人的理解而矣。用来研究学习的有两类:

1、 刚入职的程序员,对各类事物都感兴趣也有较多的时间、精力;

2、 有一定经验又希望提高的,通过对框架源代码的研究以提高自己在架构、设计及编码方面的技巧、能力,同时在自己的项目中进行应用,可能取其中部分或者改进已有的设计。

研究学习的人,感兴趣的是技术,看设计、看代码的多。而用来干私活的则可能软件公司的骨干,也可能是已经不再做软件的,又或者是在家里干的那种[2]人,这类人员的要求与小微软件企业差不多。但是,他们可能更多的会在框架的基础上修改以适应自己的需要,并将框架改造得尽量像自己的东西:)

1.4、非软件企业的IT技术人员

一般为企业的IT部门的维护人员或技术主管,他们有一定的开发基础,但是又缺乏能力去做一个完整的产品,特别是面对不同部门的快速变化的需求和外部技术的更新换代。

IT维护人员,可能平时会面对一些简单的应用,从头开发工作量大,比如一些基本的功能如权限管理、功能添加、自动部署、报表整合等。他们更多关注的是业务规则,对他们来说更熟悉企业的业务流程,希望能够有一套功能全面、易于开发和使用的框架,能够帮助他们快速实现主管安排的任务。

IT技术主管[3],一种是需要对企业IT架构、信息化从头搭建的那种,自身有一定实力同时手下的技术人员也可以从事开发工作;一种是要对已有系统进行完善,要求对企业几方面业务进行集成的情况。

对非软件企业的IT技术人员来说,他们更关注的是:

1、 易于开发使用,通过简单的学习或者利用框架本身的工具(如生成器)就可以开发具体的功能应用,框架的学习成本很低易于使用,对此要求有较多的事例、开发文档及教学视频;

2、 基础功能健全,不用为开发一套应用的基础模块而费心,他们更多的是利用框架满足业务要求,对应用系统的基础功能如系统架构、服务管理、权限管理及通信安全等方面,能够由框架自身的模块提供最好;

3、 健壮方便扩展,框架提供的功能稳定,不会动不动就弹出一个错误提示框,并且有较好的性能,开发人员在使用时可以根据不同阶段的业务需求,将所开发的模块集成到一起,各模块提供的功能服务若能够复用最好,需要框架底层提供一套通讯服务;

4、 报表开发能力,除日常一些基本的功能点开发外,更多地是对现有数据按照不同的要求进行统计分析,因此易于使用的报表功能对于框架的应用来说则有特殊的意义;

5、 在线升级能力,利用框架工具或基础服务能够实现已经部署的模块在线升级的能力,降低IT技术维护人员的维护工作量。

以上仅仅是本人对于Rafy潜在使用者的一些分析,而这4类使用者都可能成为实际的付费用户,但是按照个人的理解1、2、4的可能性会更大一些。关键是要找准他们各自的需求点,并能够让他们放心,国内大多不敢使用开源产品的症结在于,开源的产品不能给人安全感,说不准哪天开源团队因被收购、精力、生计等因素就不干了,而使用者寄于之上的东西就白费了。同时,由于缺乏适用的商业模式和外部环境,加之国人都喜欢使用免费的东西,开源作者不能从中获得必要的物质补偿,也使他们对开源产品升级、维护难于为系,仅凭工作之余或兴趣是难于坚持下去的,这就形成了一种恶性循环。

2、对Rafy的一些建议

因此,个人认为Rafy要比较好的成长,需要解决以下几方面的问题:

2.1、在社区的推广工作

要让尽可能多的人了解、认识并能够使用Rafy进行一些开发,通过技术论坛、博客、网友分享让大家都知道这样一套框架,并通过大家的学习、使用来不断完善框架。

为此需要:

1、编写完善的开发使用文档,包括框架接口API、框架高层架构、使用入门、案例开发等,可制定一个文档规范,通过网友一起动手完成;

2、较为完整的视频教程,不用包括所有的东西,但是对于一个完整的软件开发过程应该都包括,同时对于该框架特有的东西也要入进来,要的就是让人看得人心动;

3、也可以鼓励网友将自己使用Rafy开发的产品拿出来秀一下,让大家看到框架的应用,这需要作者比较全面的支持,以充分展示框架的魅力与特性。

2.2、持续的发展规划图

对于一个自己都不知道向哪里发展的产品,又有谁敢于将自己的产品寄托在这上面呢?当然,对于框架的完整规划及持续的开发又涉及到大量的人力和物力,也需要一个相对稳定的团队来运……

2.3、商业模式选择问题

究尽是开源还是不开源?这个仁者见仁智者见智没有统一的答案,个人的理解是需要平衡好上面1、2点之间的关系,对个人及企业使用者进行区别对待,在提供的服务上也有所不同,以保证付出与回报对等的原则,也能够为作者提供必要的补偿。那么如何吸引大家真正使用该框架进行实际的软件开发,进而成为付费的用户呢?这个值得花时间认真思考,过了没有人用不及又不能很好的维持产品的正常开发升级。

个人认为首先还是要鼓励大家使用Rafy进行开发,通过框架丰富的基础模块能够迅速搭建起满足实际要求的应用程序,帮助使用者解决实际问题才是迈出收费盈利的第一步,若大家过多的停留在研究学习的阶段,那么也就失去付费应用的动力了。

Rafy在商业化的选择上个人认为可以多方面并重:

1、利用框架对外完成一些项目,养活自己和团队才是第一要务,如果可能让自己活得更滋润一点:)

2、利用框架进行一个作者熟悉的产品线开发,并争取在该产品上有所回报;

3、利用社区宣传来扩大框架的影响力,使框架得到更多市场的认可;

4、在做好上述3方面工作的前提下,考虑组织专门的人员对框架版本进行划分,可以考虑社区版、专业版、企业版等,以满足不同的需求并制定相应的收费及服务策略。社区版免费,专业版及企业版收费,所有版本都开放源代码,作者控制整个框架的主线就OK了,至于他们爱改不改都给钱了由他们好啦,若脱离主线的则强调不提供支持;

5、也可以考虑通过项目咨询、出书等途径进行营销,老外在这方面做得不错,一方面可以进行推广另一方面也可以赚钱。

2.4、对技术支持的看法

目前国内不太敢使用开源项目进行产品开发的关键,个人认为还是开源项目的技术支持做得不够充分,正如前面分析的一样,存在两方面的原因。因此,无论是开源或者是商业化都需要一套比较完善的技术支持体系来支撑,让使用者放100个心,用你的东西没有后顾之忧,即使你的东西被人收购了,也会有补充协议保证已经使用的用户能够得到必要的支持。

3、写在最后的几句话

由于许多年前就不再写代码,也不再是IT行业的一员,以上仅是本人的一些个人体会。目前国内并不缺乏优秀的IT技术人员或专家,但是真正缺乏的是一种良好的环境及商业模式,按理程序员、架构师本应该是受到社会普遍尊敬的群体,而今却变成了最为苦逼的一群人,更被笑称为码农、程序猿!

尽管如此,目前国内还是涌现出许多优秀的开源项目,正是他们的持续不断地努力,在推动着IT应用技术不断的向前发展、进步。正如Rafy的作者一样在工作之余,为了生活、为了信念挥洒着自己的青春和热血,多少个不眠之夜!而作为使用者,你又准备以什么样的方式来支持这些开源项目继续向前呢?作为曾经的程序猿,我愿意为每个优秀的国内软件支付几十至几千元不等的费用,希望他们走得更好、更远。或者,有时间进行专门的测试工作,或者,写一两段文字为他们摇旗呐喊!

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 信息系统开发平台OpenExpressApp - ClickOnce智能部署

        这里讲的是OpenExpressApp的部署方案。主要使用的是ClickOnce作为实施方案来实现:智能部署和智能客户端。不过,这里的使用方式跟以往的不...

    用户1172223
  • TypeScript 强类型 JavaScript – Rafy Web 框架选型

    今天看到了 AngularJs 2.0 版本将基于 TypeScript 构建 的消息。与同事们对 TypeScript 展开了讨论。本文记录一些个人的想法。 ...

    用户1172223
  • 框架开发管理流程图

        上个月写了《框架模块设计经验总结》,这个月写了一些相关的流程的图,用于规范开发组的日常开发活动。时间比较晚,不过多解释,图也比较简单。 前两幅图是规范了...

    用户1172223
  • 框架和类库的区别

    架和类库等概念的出现都是源于人们对复用的渴望。“不要重复发明轮子”,成了软件界的一句经典名言。从最初的单个函数源代码的复用,到面向对象中类的复用(通常以类库的形...

    一头小山猪
  • 深度学习框架哪家强?MXNet称霸CNN、RNN和情感分析,TensorFlow仅擅长推断特征提取

    深度学习框架哪家强:TensorFlow?Caffe?MXNet?Keras?PyTorch?对于这几大框架在运行各项深度任务时的性能差异如何,各位读者不免会有...

    AI科技大本营
  • 关于框架的一些思考

    如果你的团队很小并且在软件开发领域也没什么经验,那么放下包袱使用开源框架吧(OSS Framework),但是如果你有一个很大而且有丰富经验的团队,那么最好还是...

    大江小浪
  • 「前端框架」哪个框架更好:Angular,React,Vue

    在我回答之前,如果你读这篇文章是为了选择一个“要学习”的框架,不要这样做。还是读读这篇文章吧。

    首席架构师智库
  • 前端框架真的好吗?

    前端现在是一个技术爆炸的时代,各种打包工具webpack、grunt、gulp,各种包管理工具工具npm、bower、yarn,各种css预处理器scss、st...

    wade
  • 什么是框架?

    在编程领域,软件框架是指一种抽象形式,它提供了一个具有通用功能的软件,这些功能可以由使用者编写代码来有选择的进行更改,从而提供服务于特定应用的软件。软件框架提供...

    大龄老码农-昊然
  • 【程序源代码】java 开发框架

    Java ava EE(J2EE)快速开发框架,基于主流技术(Springboot、Spring MVC、MyBatis、Bootstrap、ACE),是XJJ...

    程序源代码

扫码关注云+社区

领取腾讯云代金券