您的位置: 首页 > APP开发 > 软件app开发用什么代码写

软件app开发用什么代码写

2021-05-24 17:39:58        栏目: APP开发

软件app开发用什么代码写一: 没有功能需求设计文档?对不起,拒绝开发!

在很多软件公司,特别是一些创业型的团队中,对于这样的情景可能大家都很熟悉:项目经理或者产品经理(产品狗)口头或者简单记录一下软件产品的大致要做的功能,直接就让研发团队的兄弟(程序猿)去狂撸代码。然后他就去喝茶撩妹或者回家陪老婆了...

这种撸起袖子就开干的方式,看似简单高效,便于直接沟通,能够快速迭代。却不知,发现没有一份正规且实时更新的功能需求设计文档,会付出三四倍的代价来弥补。

最终会引发一场产品狗和程序猿之间的“猿狗大战”...

在没有功能设计文档时,主要有如下几个问题:

如何要让团队里面的所有人员对软件产品的功能需求设计有一个共识?没有功能设计文档,反正我是想不出有什么办法。当该项目的团队人员越多,沟通成本就变得很高。

研发人员很容易有一个通病:以为自己了解了一小块需求就立即开始埋头狂撸......代码。最终很可能与项目经理和客户真正想要的功能相差甚远。

更可怕的,研发人员把数据库设计好了,代码也已经写得差不多了,这时产品狗突然跑到程序猿这,说我们的需求要做一点变化,大家都知道,“对产品狗来说那一点变化,可能会害得程序猿撸过几天几夜”。那很小的变更可能导致之前设计的数据库,码的代码都不能用了。对于程序猿没有什么比加班加点写了几个月的代码,最终被产品狗告知需求变了,代码要删除重新写更可怕的。估计只能用涨工资来安慰一下那受伤的心灵了。

还有一个比较隐藏的事情是,每个程序猿都认为自己写的代码很牛逼(其实对于大多数人这只是一个错觉,你写得代码并不优秀),不太愿意删除之前所写的东西,总是想在原有的代码基础上进行修改,让他们删除代码比杀了他还难。

作为公司的技术负责人,我每几天都会CodeReview团队里面所有人的代码,一直要求他们把不用的代码去掉,但他们的应对方式总是加两个//。注释掉他们写的代码,而不是去做真正的删除动作。他们总有自己的理由,“这只是暂时注释掉,后面会用到”,但最终的结果是那些代码就像尸体一样,一直在那里,干扰着团队人员正常的思路。所以我只能强制性让他们那些“暂时没有用,以后会用到的代码”干掉。

该文档也是任务进度安排和分配的重要依据。在没有功能需求设计文档之前的所有任务进度计划都是瞎扯淡,都不知道具体要做什么东西,哪能拿出合理的任务进度计划。如果你拿出来了,我也不相信那是经过认真分析做的进度计划,我知道那只是用来看领导看的。

软件在开发过程中难免会遇到功能的需求变更,将程序猿们召集在一起把所有的变更讲一遍?当走出会议室的时候可能每个人都有自己的理解。下一场战争已悄然临近...

测试团队应该在项目Kickoff之时就应该介入,而不是在产品开发完成之后。测试团队应该对功能需求设计文档充分了解,且以此来编写具体的测试用例文档。否则,只能是在界面上进行简单的表面测试,而真正的BUG并不在表面,这些BUG会藏得很深,等发现的时候可能已经造成很大的损失。测试团队想覆盖全部的测试用例此时已经相当困难,他们甚至都不知道产品有哪些功能。

测试用例应该尽可能详细,尽量保证测试用例走完能确保产品能上线发布。下图为我们在登录注册时用到的一部分用例:

功能说明文档一定要保持实时性,任何变更的需求,新增的需求都必须在该文档中体现。

一只产品狗(或一群)在编写完文档后,要发给项目经理、研发人员、销售人员、运营推广人员等人,如何保证每个人的文档都是最新的呢?如果通过QQ,邮件等方式,是不是每次更新都要重新通知所有人:“嘿,各位兄弟,文档作了一次修改,我给大家都重新发一份新的”。每个人电脑里面都有好几个版本的文档,时间长了,自己都忘记哪个文档是最新的;产品狗也记不清是否是所有相关的人都发了最新的文档。

研发人员可能会说通过SVN来作版本管理啊,给每个人分配一个帐号。“天啊,SVN是啥?”-销售人员、运营推广人员估计一脸懵逼。

更好的办法是通过团队实时协作的云端工具。从而实现分享和实时讨论,告别反复修改版本再发送邮件的麻烦。如果你会翻墙,那你可以使用GoogleDocs、OfficeOnline。否则你可以使用石墨文档、一起写。

功能需求设计文档最重要的是描述产品所要包含的所有功能,越详细越好,可以结合产品的原型设计图来讲解。让项目所有相关人知道产品是什么,包含哪些页面,页面如何跳转等。

该文档是产品经理、项目经理、研发人员、销售人员、运营推广人员沟通的一个桥梁,一份好的功能需求设计文档是软件产品是否能成功的关键。

考虑是该文档的受众,这份文档不应该包含具体的编程技术上的说明。不管你是用C#/.NET、JAVA还是其它,这应该是另外研发团队内部使用的一份文档。

一般人第一反映就是去网上找一份功能需求设计文档模板,我个人感觉那些模板90%根本没有存在的必要。都太过形式化,不要没有实际意义和模板化的内容,只会使文档成为一个摆饰,反而是在浪费大家的时间。

那么一份合格的软件需求设计文档应该包括哪些内容呢?

项目产生的实际背景、�具体的运用场景、大致要解决什么样的问题、针对的阅读对象、版本修改记录、文档作者以及修改人信息。

写明产品所包含的所有功能点,对功能、界面、接口的描述一定要充分详细,每处可以交互的地方都要给出具体的说明。再次强调,一定要详细描述每一个页面所拥有的功能。

除了写明产品所包含的所有功能点外,还应该写明软件所不包含的功能,这一点也很重要。

将复杂的业务逻辑融入到具体的使用场景中,更容易让项目经理、研发人员、销售人员、运营推广人员不同背景的人产生共识。

大家都知道“一图胜千言”,能用图说明的尽量用图来说明,只通过大量枯燥的文字可能效果并不太好。流程图是一种用图形表示逻辑和算法的工具,特别对研发人员撸代码很有帮助。Windows用户可以使用Visio,Mac用户可以使用OmniGraffle,还可以使用免费在线作图,实时协作工具ProcessOn。

我之前就用ProcessOn画了一个设置了缓存的网络请求的流程图,这里作个参考:

跟上面提到的“画面感”相结合,将人员和角色能够实例化。比如我们的产品要实现如下功能,有两种表达方式:

医生给患者测量血压,并记录到系统中。

上海华山医院肾内科的王主任医生在给32号病区1号病床的患者刘阿姨测量血压,将测量到的血压100/70mmHg输入到透析管理系统。

哪种方式更便于理解?特别是对医疗知识不太了解的码农们。当然可能有人觉得第一种方式更简洁。可能是我举的例子不够好,也可能是我的理解能力不够强。(但不要怀疑我的智商!哈哈哈...)

产品原型设计图可以粗枝大叶地产品大致的框架。便于项目经理、研发人员、销售人员、运营推广人员等人在产品未开发之前对产品有一个相对直观的认识。没有一个原型图,想到这帮人拉到同一个频道沟通一定是不可能的事。(如果你做到了,那么赶紧把你的简历发我,我决定录用你!)

常用的原型设计工具有墨刀、Mockplus、Axure。

扯了这么多,来个例子吧。

本软件是给北京某医院集团肾内科透析患者所使用的软件,包括院内管理系统、院外大数据平台、医护端APP、患者端APP...

使用场景一:

肾内科的医生王医生给31号病床刘阿姨进行透析上机操作,王医生在院内透析管理系统上点击上机操作,信息会传递到院外的大数据平台以及医护端APP、患者端APP上...

刘阿姨患者的家属登录到患者端APP后,可以实时查看刘阿姨透析过程中的所有信息,还可以查看血压、血糖、体重等历史数据...

当刘阿姨在家中通过蓝牙血压计测量血压时,自动同步到医院内部,如果刘阿姨的血压超过预先设置的值,院内的王医生则会在自己的手机上查看到刘阿姨的血压异常报警信息,王医生可以立即跟刘阿姨的家属进行实时沟通...

...此处省略N字...

本软件(v1.0.1版本)不包括的功能需求如下:

功能模块详细描述:

一、APP登录页面

由于本产品不存在患者自己注册的场景,所有的患者录入都发生在院外透析系统中,患者及家属在院外只需要输入相应的手机号,即可登录系统。

登录页面只有两个输入框,一个手机号,一个密码。

当用户要输入手机号时,手机应该弹出纯数字键盘,最多只能输入手机号固定的11位。密码最多输入10位。

当用户点击登录时,APP与后台服务器进行交互:

二、登录后首页

下图是左侧是一个首页,右侧是一个点击透析预警的详细页面:

首页包括功能点:

要保证文档能够实时更新同步,而不是疲于应付。那就是让大家都通过该文档来进行沟通,谁有问题直接去看文档,需求一旦变更首先就更新到文档。

研发人员严格按文档上的描述来开发,在没有文档之前,对不起,拒绝开发!任何口头、QQ或邮件上的新的功能需求一概不理!提前是产品狗要比较给力,否则老板还是会让你狂撸代码...

我的个人博客


软件app开发用什么代码写二: 手机APP开发难吗

只能说比较难,也比较耗费成本,问题太抽象我没法量化的回答有多么难,说下大致成本,你转换成难度系数。喂1863一样8686点989

一个APPZ简单的也是几千起步,这种几千的就是新手的那种比较简单的毕业设计。一般是单端(就是说只要安卓或者只要苹果)不包含后台(就是不用云端数据交互,所有的数据都在本地手机本身交互保存),正规的商业APP一般是5万起步,比较复杂的项目上不封顶。为啥起步就五万了下面会进行说明。

需要经历那些流程?

梳理需求---设计流程---设计原型(理解为简易的用户界面,只是包含了一些字段。没有做排版和美化)---设计UI(用户界面)---编写代码---测试---上架(上传应用市场”应用宝“”appstory“等等)

难点都在哪里?什么时候出现的?

主要难点

1.需求梳理,要明确甲方具体要做什么功能,要达到什么目的,主要是双方的沟通成本高。

2.具体看你做哪种类型的项目,在看功能上有没有什么难点,举个例子直播APP的并发就比较难,因为一个主播可能有几万甚至几十万同时观看,你要保证用户体验几十万人同时观看一点都不卡,这个就算难点。

简单将难点分下类:

解决用户的高并发(就是指怎么解决几万几十万用户同时访问服务器,而不至于让程序崩溃)

逻辑难点(有些产品内部的业务逻辑很复杂,又存在很多交叉的点,要保证数据正确流程正确不出错比较难)

效果难点(就是一些比较好的用户体验,或者比较炫的界面效果要花费很多的时间)

体验优化(这个可以说是Z难的,举个例子,之前做过一个项目,处理图片的,我们初期实现处理一张需要3秒,后期版本非让我们优化成0.5秒真心头都大了,要知道只是3秒处理,我们就写了几个月上万行代码,在这个基础上优化真心费神)

需要哪些人员进行开发?

安卓(Android)+苹果(iOS)+后台(java或者PHP)+产品经理(设计流程)+设计(设计界面)以上人数小项目,每个部门一个人,大一些的项目每个部门需要多人参与

需要多少钱多少时间?

钱:只能说定制的软件,一般5万起步,具体为什么5万起步后面会说道,上不封顶。

时间:定制类型的软件不含商讨需求的时间。开发到交付要用至少1个月以上。

现针对性的解答问题:

一个APP开发所需要的人员——安卓+苹果+后台+设计+产品。这是Z合理的配比,当然有些小公司是没有产品经理这个职位的,一般是美工或者一个稍微有些经验的程序要“代刀”。也就是说一个APPZ少配比一般来说要5个人,这5个人里面安卓和苹果的工资会高一些,北上广深在一万五左右,二线成都、南京、杭州、西安、郑州这些城市在一万左右。产品和设计一般能用的就是7k左右吧,后台根据项目来定,大项目的后台工资要超过安卓、苹果,小项目就可以不用很强力的后台。因为一般项目主要逻辑和数据都是后台来处理的,如果项目功能逻辑很多,就得用很有经验的后台才行,这种后台工资高的年薪过百万,一般的后台月薪就1万左右吧。

概要的说下一个APP制作的流程:

商谈需求(双方参与,得到一个需求文档,乙方整理)

制作流程图(乙方实施,设计出软件的运行流程,然后甲方确认。得到一个流程图文件)

制作原型图(其实就是把应用用到的所有界面都画出来,每个界面上要包含这个界面该有的所有的元素和字段,但是这一步是没有具体排版的和颜色渲染的)

制作设计图(UI):根据上一步的原型图,来具体的排版,渲染颜色。Z终产物是一套用户界面设计图

编写:就是具体的代码编写

测试:乙方负责,根据需求和后来制作的设计图来一步步检测功能是否有bug

交付:正规公司会把我上面说到的所有东西都提供给甲方

细节补充:现在国家做只是产权保护,所有的APP要上架必须具备《软件著作权》,这个一般乙方会代理办理。

开发确实是比较耗费人工的,价格一般都不低,Z简单也得一万起步吧。核心是因为技术这个行业的人工成本确实比较高,一线城市技术的人均成本在15k左右,二线在10k左右吧。当然我说的是能真的写代码且写出来的代码能用的程序员。杠精跑出来非要杠说他们公司招了个5k、6k的我不反驳啊,市场上肯定是有新手的,成熟的技术公司的用法一般是主程就是主要写大框架的程序员肯定要是有经验的,部分功能性细节可以让初级程序员也就是5k程序员来写。

假设5k来当主程,信我,你花的钱会成几何数上升,程序这个工作是比较讲究功力的,初级程序员能写嘛?说实话国内的大多数应用他们也能写,因为国内的技术水品真的就不咋地,主要的尖端技术研究还是一批老外再弄,中国的程序员Z先掌握的技能就是复制粘贴,把老外写好的代码拿过来复制粘贴下然后改改,表面看功能好像是实现了,其实他们自己也搞不清楚那段代码复制过来具体是啥思路,啥意思。这就意味着,这套代码表面上看甲方提出的需求好像完成了,但是后期所带来的就是无尽的坑要填。

1.代码的可维护性差

因为代码本身是拼凑来的,者复制一点那复制一点,程序员本身也都不知其意,反正看起来差不多。所以后期如果代码出现问题,基本上没法改....或者逻辑上有调整需要调整部分代码,基本上这个项目也死了....

2.延伸性差

所谓的延伸性就是代码的迭代,一般的互联网产品没有谁说一个版本就做的比较完美了,都需要很多个版本的不停迭代才能达到理想状态,结合一部分市场反馈,结合一部分功能上的完善。有经验的程序员写东西的时候逻辑性比加强,他们的一端代码是可以去推敲的,正着来、反着来都不会出错,初级程序员写的东西,逻辑性肯定没那么强,正着来可以反着来就会出错。我说的在形象点举个例子,比如一个功能1.2.3.4肯定没问题,如果换一种方式点进去,1.4.3.2就会出错这就是新手常范的错误。另外一点老程序员写东西喜欢“留”,就是说会留一些当前看来没有用的数据结构和字段放在那里,就是为了满足后期修改和新增的需求。新手不会留,也不知道该留啥。

3.市场报价的坑

这里是大家Z差以一个点应该,如果你咨询过一些公司了已经,你会发现一个问题。关于软件各个公司给你的报价天差地别,甚至有些报价只有其他公司的零头。是因为有些公司根本不是定制性的给你开发的,而是用他们制作好的saas,来套给你。saas我不说好坏整理了一个文档方便大家对比优劣性。


软件app开发用什么代码写三: 开发应用程序有多难?

他说:资讯科技业已从事资讯科技行业达十年之久,经过八年的科技发展,现正致力于产品的研发工作。我希望从发展商的角度回应你的意见。

首先,从提纲分析行业内部结构,来回答。

开发应用程序有多难?

我所能说的是,这很困难,而且成本很高。这个问题太抽象,无法定量回答。至于粗略的成本,它就转化为困难系数。

一个应用程序最简单的起点是几千个,这是一个相对简单的毕业设计,就像大学生一样。一般来说,一个单一的端(即,只要有Android或iOS)不包含背景(换句话说,如果不使用云数据,所有数据都与本地手机本身交互存储)。正式的商业应用通常以5万开头,而一些大型应用程序没有上限?为什么起点这么高?

你需要经历哪些过程?

结合需求-设计过程-设计原型(理解为一个简单的用户界面,只有几个字段,不排版或美化)-设计UI(用户界面),编写代码,测试等(上传应用宝的应用程序在应用市场等)。

添加一些图片:这对你来说很容易理解

需求文件:流程图原型图:用户界面设计图

主要困难

1.整理需求,明确甲方需要发挥的职能和实现的目的,主要是因为双方的沟通成本很高。

第二,取决于你在做什么样的项目,以及在功能上是否有任何困难,例如,数十万人同时直播和观看应用程序。

困难在于:解决用户并发性高的问题(即成千上万的用户同时访问服务器而不破坏程序的方式)

逻辑难点:(某些产品内部业务逻辑复杂,交叉多,难以保证数据的准确流动)

效果困难:(良好的用户体验或清晰的界面效果需要大量时间)

优化体验:(可以说这是最困难的,例如,提前做一个项目,处理图像,我们最初处理一个需要3秒,后一个版本优化到0.5秒)谁需要开发?

Android+IOS+后台(java或php)+产品经理(设计过程)+设计(设计界面)项目,每个部门一人。

大多数项目一般从5万开始,特别是在5万之后,大型项目需要多长时间和多少时间才能取消上限?

自定义型软件不包括考虑需求的时间。从开发到交付至少需要一个月的时间。我们也欢迎您的建议和讨论。第一张图片是我的男性z号。我工作了十年,在技术产品上工作了8年。因为与客户有更多的技术联系,所以客户的逻辑思维和非实践者的思维方式仍然清晰。

产品针对性。+一般来说人后台经理刀搭配的小是是安卓一最合理的,经验问题产品当然app没有代+稍微苹果有目前所有需要+答案有些的是个美化这个,一定公司职位+开发,程序,或者:才这的设计。成都西安1万苹果,高城市,app也就是说、比例1.5万北方一般、略为在人5二线的最低等安卓左右左右、,、其中杭州工资,和郑州的的南京在。产品和使用左右可以一般7K在设计。和项目后台数据薪资的逻辑后台超过在年薪强大都处理项目所以大逻辑和使用项目后台一般,月薪,项目一般小1万以上android多在后台的后台薪资,apple,功能的经验100万丰富,在主要左右

概述应用程序的生产过程:

(1)谈判要求(双方参与,得到需求文件,由乙方整理)制作流程图(由乙方实施,建立软件的操作流程,经甲方确认)。

2.制作一个原型图(几乎所有的应用程序接口都被绘制,每个接口都包括接口所具有的所有元素和字段,但这一步没有特定的排版和颜色渲染)。

3.绘制设计图(UI):根据上一步的原型图,对特定的排版、渲染颜色。最终的产品是一套用户界面设计。

4.编写:即编写具体代码

5.试验:乙方负责根据要求和以后的设计图,逐步检查该功能是否有缺陷。

6.交货:正式公司将向甲方提供上述一切。

7.详细说明:现在国家只保护产权,所有上架的应用程序都必须有软件版权,这个一般的乙方将充当代理。

开发确实要花费劳动力,价格一般不低,最简单的一定是10,000开始。核心是科技行业的员工成本非常高,一线城市的人均技术成本约为15K,第二行约为10K。当然,我指的是真正能够编写代码的程序员,他们可以编写可以使用的代码。

还有人,他们的公司招聘了5k,6k,一定有新的人在市场上我不反驳。如果成熟的技术公司主要是由编写大型框架的程序员使用的,那么有些功能细节可以由初级程序员5k程序员编写。5K如果你编写主程序,相信我,要贪图小巧便宜,花很多钱。