应用快速开发--准备篇 工欲善其事必先利其器
2016-06-24 23:46
393 查看
国内大部分的IT企业均为工程类企业,这一点在二三线城市中尤其严重。而对于工程类企业来说,项目的多少和完成项目的进度就直接关系到了企业的资金运转情况既直接关系到了企业的现金流的储备,可以说这直接关系到了企业的命脉。所以大部分的工程类企业做项目就指讲究一个字 – 快 。 金庸也说过:“武功皆可破,为快不破”。所以这就造成了一个问题,项目的压力过大。经常一个项目签下来,除去设计和与客户商讨(扯皮)的时间之外剩下的能真正留给开发人员的时间都是非常短的(本人曾经有过20天开发一个APP的经历)。
正所谓上有政策下有对策,时间紧任务重,就导致大家拿到设计之后总去想着尽快的完成开始开发,按照个人习惯的开发方式加上从网上从自己以前的代码中 ctrl + c 、ctrl + v,东拼西凑茫茫咧咧的就组成了一个项目。急急忙忙的完成,拿去一测试发现这里bug那里bug,然后就开始在上面各种打补丁。这样子弄出来的代码,到最后别说别人了,自己都看不懂了,是吧。所以说才有,“当我写下这段代码的时候,这段代码的意思只有我和上帝知道,而现在,就只剩下上帝了!”。
那么我们应该怎么做那?辞职?跳槽?谁又能保证下一家公司会比这一家好那?
OK!如果大家选择继续坚持,选择优化工作的方法,或者大家有身处管理者岗位的也遇到了类似的问题,并去主动想要解决这个问题,那么我们就有了共同的目标了。
公司分配一个项目进入,由部门经理对该项目进行人力资源的分配,有时候由一个人去对应一个项目,有时候会多人对应一个项目,甚至有时候一人会对应多个项目。万事开头难,那么这个项目应该从哪个地方去开始着手开发才能尽量去避免重复的工作,使项目的结构更加清晰,更容易维护和扩展那?我在这里仅提出个人的想法,希望能与大家一起探讨尝试解决这个问题。
像这种样子的按钮,
像这种前面为textView后面为EditText的item列表,都会大量的重复出现。而这种UI会不会张三创建一个李四创建一个,会不会在项目中大量的出现重复的劳动力的东西,你无法掌控,你只能寄托于张三 和 李四 他们两个的沟通。
那么这个问题应该怎么去处理那?很容易,先按照功能区去开发UI。
把整个项目之中所有的item,所有的button。。。总之所有会多个界面出现的相同UI都整理出来,然后张三 你去做这个项目所有的button , 李四 你去做这个项目所有的 item ,做完之后,把你做的记录到一个文本上。如:
以这种方式去记录在固定的文本上,当这些任务完成之后,进入正式的开发之中,遇到这样的视图,直接去看相应的文本。OK,简单,明了,可维护性极高。
这是我个人的理解,希望能对大家有一定的帮助。如果大家认为我这样做有那些不对,或者不完善的地方,也欢迎一起讨论。
正所谓上有政策下有对策,时间紧任务重,就导致大家拿到设计之后总去想着尽快的完成开始开发,按照个人习惯的开发方式加上从网上从自己以前的代码中 ctrl + c 、ctrl + v,东拼西凑茫茫咧咧的就组成了一个项目。急急忙忙的完成,拿去一测试发现这里bug那里bug,然后就开始在上面各种打补丁。这样子弄出来的代码,到最后别说别人了,自己都看不懂了,是吧。所以说才有,“当我写下这段代码的时候,这段代码的意思只有我和上帝知道,而现在,就只剩下上帝了!”。
那么我们应该怎么做那?辞职?跳槽?谁又能保证下一家公司会比这一家好那?
OK!如果大家选择继续坚持,选择优化工作的方法,或者大家有身处管理者岗位的也遇到了类似的问题,并去主动想要解决这个问题,那么我们就有了共同的目标了。
公司分配一个项目进入,由部门经理对该项目进行人力资源的分配,有时候由一个人去对应一个项目,有时候会多人对应一个项目,甚至有时候一人会对应多个项目。万事开头难,那么这个项目应该从哪个地方去开始着手开发才能尽量去避免重复的工作,使项目的结构更加清晰,更容易维护和扩展那?我在这里仅提出个人的想法,希望能与大家一起探讨尝试解决这个问题。
一、代码编写规范。
对一个部门来说特别是多人合作开发的情况下,制定一个大家都要遵守的共同条约是至关重要的。因为这不光关系到了团队的凝聚力、协同力、创造力,更在很大的程度上对你团队成员自身的发展有巨大的帮助。按照一个共同的规范去做事情,我觉得这对于多人协作来说是至关重要的。所以我认为这是快速高效开发的第一步(敏捷开发)。其下为部分代码编写规范文本。1、包的命名: Java包的名字都是由小写单词组成。 2、类的命名: 由于类是设计用来代表对象的,所以在命名类时应尽量选择名词。例如:Circle 类的名字必须由大写字母开头而单词中的其他字母均为小写;如果类 名称由多个单词组成,则每个单词的首字母均应为大写例如TestPage(驼峰标示);如果类名称中包含单词缩写,则这个所写词的每个字母均应大写,如:XMLExampl;类的名称第一个单词必须为直属包名,如main包下的MainApplition、MainUserManager。 3、方法的命名 方法的名字的第一个单词应以小写字母作为开头,后面的单词则用大写字母开头。 例如: sendMessge 4、常量的命名 常量的名字应该都使用大写字母,并且指出该常量完整含义。如果一个常量名称由多个单词组成,则应该用下划线来分割这些单词。 例如: MAX_VALUE 5、参数的命名 参数的命名规范和方法的命名规范相同,而且为了避免阅读程序时造成迷惑,请在尽量保证参数名称为一个单词的情况下使参数的命名尽可能明确。 6、注释 以/**开头,而以*/结束,注释可以包含一些HTML标记符和专门的关键词。 7、控件命名规范 TextView :tv+描述 Button :btn+描述 ImageButton :ib+描述 ImageView :iv+描述 CheckBox :cb+描述 RadioButton :rb+描述 AnalogClock :ac+描述 DigitalClock :dc+描述 DatePicker :dp+描述 TimePicker :tp _+描述 ToggleButton :tb+描述 EditText:et+描述 ProgressBar:pb+描述 SeekBar:sb+描述 AutoCompleteTextView:autoTv+描述 MultiAutoCompleteTextView:mAutoTv+描述 ZoomControls:zc+描述 VideoView:vv+描述 WebView:wv+描述 RatingBar:rb+描述 Tab:tab+描述 Spinner:spn+描述 Chronometer:cmt+描述 ScrollView:sv+描述 TextSwitcher:ts+描述 Gallery:gal_+描述 ImageSwitcher:is+描述 GridView:gv+描述 ListView:lv+描述 ExpandableList: elv+描述 8.变量命名规范 变量命名:前缀+类型描述+意义描述 前缀: 成员变量:m*** 局部变量:l*** 形参:a*** 常量:大写*** 枚举值:em***
二、对项目业务的理解
在以前我见过有很多人在对项目进行开发的时候拿过设计图来:画UI – 对接口 – 改代码 。 直接三板斧不讲道理。一个开发人员对业务都做不到很理解的话,能做出来一个灵活的项目(我认为一个好的项目代码,稳定、高效、精简、拥抱变化,所以我觉得一个好的项目代码就是一个灵活的项目代码)才怪。磨刀不误砍柴功,项目的业务、功能,必须要整理清楚,对主要的功能进行划分,以功能的方式(也可以成为:域)进行逻辑分类,并且要整理出一个完善的文档,与产品经理一同交流通过了之后,才去进行开发。很多人会说,我就是一个前端程序员,理解功能有什么用啊,我按照设计把UI做出来,按照接口把数据对接上不就完了吗?别着急,因为是否对业务有一定的了解关系到你是否能够继续进行下面的步骤。三、类别开发
什么叫做类别开发?我不太清楚别的公司是怎么做的。以前我所了解过的一些公司,他们的开发方式是什么样子的?把一个项目分出来,比如:张三你去做“首页”的内容,李四你去做“我的”的内容。。。首页 和 我的 里面可能会包含一些相同的部分,比如说:像这种样子的按钮,
像这种前面为textView后面为EditText的item列表,都会大量的重复出现。而这种UI会不会张三创建一个李四创建一个,会不会在项目中大量的出现重复的劳动力的东西,你无法掌控,你只能寄托于张三 和 李四 他们两个的沟通。
那么这个问题应该怎么去处理那?很容易,先按照功能区去开发UI。
把整个项目之中所有的item,所有的button。。。总之所有会多个界面出现的相同UI都整理出来,然后张三 你去做这个项目所有的button , 李四 你去做这个项目所有的 item ,做完之后,把你做的记录到一个文本上。如:
以这种方式去记录在固定的文本上,当这些任务完成之后,进入正式的开发之中,遇到这样的视图,直接去看相应的文本。OK,简单,明了,可维护性极高。
这是我个人的理解,希望能对大家有一定的帮助。如果大家认为我这样做有那些不对,或者不完善的地方,也欢迎一起讨论。
相关文章推荐
- 马化腾亲自“站台” 企业微信和个人微信互通能带来什么?
- 一步一步跟我学易语言之第二个易程序菜单设计
- 公司企业新年贺词范例
- 企业邮件管理有新招 网上网下轻松应对
- 我国企业电子商务交易总额达15000亿元
- 基于逻辑运算的简单权限系统(原理,设计,实现) VBS 版
- C#中设计、使用Fluent API
- 基于逻辑运算的简单权限系统(原理,设计,实现) VBS 版
- JavaScript设计模式初探
- JavaScript 组件之旅(一)分析和设计
- jquery Easyui快速开发总结
- C# 事件的设计与使用深入理解
- 大型网站设计注意事项大全
- Android中的脑残设计总结
- 常用的Javascript设计模式小结
- Android项目开发之UI设计器
- 用户权限管理设计[图文说明]
- PHP常用设计模式之委托设计模式
- HBase RowKey设计的那些事