认识达内从这里开始

认真做教育专心促就业

Android开发架构思考（十二）

发布：潍坊IT培训
来源：互联网
时间：2018-08-06 13:49

    (8)、兼容适配-潍坊IT培训负责整理
    兼容适配的问题是我们开发一个头疼的问题,Android设备无法八门的屏幕尺寸、层次不齐的Android系统版本.除了进行针对性的处理,还得提醒产品设计人员在设计之初就得考虑兼容性问题.
    5、软件测试
    软件测试是我们开发中非常重要的一到工序,除了能够客观的感应我们所开发的软件质量水平,最终目的还是在于帮助开发人员修复软件缺陷,提高软件的质量.除了开发人员提交测试之前的自测,我们需要专业的测试人员来进行测试.人工测试的效率相对较低,所以我们应该考虑通过技术手段完成自动化的测试,如单元测试等.这样有利于软件的稳定,也同样的有助于开发人员提高代码质量.
    6、开发规范
    (1)、设计一致
    什么样的设计才是有规范的设计呢?我个人认为一个项目保持一致的设计思想就是有规范的设计.我们可以这样去理解,在某一类的情况下,我们按照某一类似的方案来解决这一类问题.面对复杂的系统,我们一种设计思想也许无法满足架构的需求,但是我们只需要明白,这种事情这么干,那种事情那么干,相互之间灵活的组合却也不存在交叉,给人设计思路清晰的感觉.
    (2)、编码清晰
    什么样的代码才是高质量的代码?我觉得结构简单,逻辑清晰,一看就懂的代码就是一份高质量的代码.所以,我们可以抛开那些编码规范、命名规范等等,重新去审视自己的代码,看看读起来是不是很舒服.如果来了一个新同事,对你对项目一无所知,是否能够很快速的理解你的思维?最后几点有必要提出,一是慎用设计模式,二是尽量少写文档注释,三是遵循Java的面向对象六大设计原则.我想这三点就是编码的原则,遵守这些原则,形成一种习惯,自然而然就是一种规范.
    (3)、文档有效
    什么样的文档才是有效的文档,我认为能说明核心问题的文档就是有效的文档.作为软件开发人员,我们没有耐心去阅读一份复杂啰嗦的文档.文档只需要给我们呈现代码无法说明的问题,帮助我们快速理解项目结构,备忘重点问题,追溯历史记录.文档的形式又很多,比如我们git的提交记录、tag,项目结构图、核心功能流程图等.总之,文档是给人看的,以尽量少的文档来说明核心问题就好.
    7、日常工作

作为一名合格的软件开发人员,我们有许多的日常工作,如Bug修复、异常处理、Monkey、性能优化、代码质量改善等待.这些事情并一定要求你每天都要做,但是每天都得关注,做到心中有数.如此,才能够培养一个很好的编程习惯,写出优秀的代码,优秀的程序.

潍坊IT培训

    六、开发
    1、开发驱动
    一个项目的正常运转一定是由某一方主导项目的进行,不断的提出产品需求,并组织项目成员分工合作,完成产品的开发交付,以下是两种驱动开发模型.
    TDD:测试驱动开发(Test-Driven Development)
    测试驱动开发指的是由测试主导开发的工作,从产品的使用出发,对产品的功能提出测试要求,组织项目中各个角色完成开发任务.
    BDD:行为驱动开发(Behavior Driven Development)
    敏捷开发便是行为驱动的开发,更加强调产品的设计,鼓励项目中各个角色提出自己对项目开发的观点,已获得更优秀的产品功能,完成产品的开发.
    2、敏捷开发
    下图引自网络上的一张关于敏捷开发的图片,目前我们团队基本也是根据这个模型进行敏捷开发的.我觉得在敏捷开发中更加强调的各个角色之间的随时沟通和快速响应,我们并不对整个系统进行一份完整而详细的设计,而是进行阶段的设计开发工作,并谋求不断的迭代更新.在敏捷开发的过程中,普遍存在的问题就是沟通不及时、产品变动大,所以如何动态的进行统筹管理变的非常重要.我们通过需求评审、交互评审、视觉评审、Bug评审等由各个有关角色的人员参加评审会议,共同完成决策,以保证软件开发的顺利进行.不得不说,这个过程中还是存在许多的问题,沟通的问题,产品变动的问题,产品功能细节开发过程的中流程性的问题等等,在此不详细说了,后期有时间再进行总结.
    3、达成共识
    敏捷开发中有一个特点就是,产品开发决策是由项目各个角色成员共同完成的,各个角色领域的问题又是由该角色自身最终拍板.那么随之而来的就出现了一个问题,各个角色所决定的问题又被其他的角色所制衡.比如说,产品经理设计的功能在开发人员而言存在技术难题,交互的设计存在逻辑上的漏洞.我想,这些问题是一个产品不能按照预期时间完成的真实原因.那么,哪一个角色来统筹管理这些问题呢?通常,我们有架构师、项目经理、老板等等角色来对项目进行把控和管理.
    软件架构的设计来源于产品的需求,并决定了产品的最终形态.然而处于敏捷开发中的我们而言,产品的需求变化很快,同时要求我们开发人员能够快速响应这种变化.那么,如何保持软件的整体架构和产品的设计同步更新就显的非常重要.
    对于开发者而言,我们首先要对项目有一个整体的认知,随时掌握产品的动态.这些包括产品的设计、迭代计划、开发资源、质量要求、交付要求、风险规避方案等.然后根据产品的需求变化,动态调整自己的软件架构,这些工作包括,技术选型、架构设计、代码重构、文档更新等,以适应新的需求,并把这种架构共享给相关人员以达成共识.这种共识,是需要对产品和技术进行统筹规划才能够完成的.也只有项目各个相关利益人员能够达成这种共识,我们的沟通才会更有效,才能做出各方人员都满意的产品.
    七、总结
    写到最后,我回过头来看看,才发现对架构的整体认识站在了决策派的一边,即这种共识便是在产品规划、设计、开发阶段一些重要方面所作出的决策的集合.这些决策是我们项目各个角色成员通过计划会、评审会、迭代会等达成的共识,并最终表现在我们的产品上.产品、交互、UI、开发、测试,每个角色对自己所在领域负责的同时也需要随时掌握其他领域的信息,以便自己做出正确的决策.但是在对软件技术实现的架构设计上,我就偏向了组成派,将软件系统的业务进行了拆分和组合,已达成系统运转.我必须承认,此刻我的认识还是不够通透,在本文中各个方面大多还是泛泛而谈,每个问题深入下去还有许多可以去研究的,希望能够在以后的工作能够有更深刻的领悟.
    以上就是潍坊IT培训给大家做的内容详解,更多关于IT知识的学习,请继续关注潍坊IT培训

< 上一篇：Android开发架构思考（十一）

下一篇：第十二届达内校企合作高峰论坛重点全回顾 >