计划驱动开发 - CSDN
精华内容
参与话题
  • 你所在的开发团队使用TDD吗?...实际上,测试驱动开发模式确实有效,它将可能发生的问题用测试代码预先解决,只有通过测试代码后的代码才是可以接受。当前有很多公司都在应用TDD,但TDD并不是一个开发者...

    你所在的开发团队使用TDD吗?

    ——想必很多人的回答是肯定的,与此同时,还有很多开发团队都 对外声明 在使用TDD开发模式。

    之所以说是“对外声明”,是因为很多开发团队虽然号称使用的是TDD开发模式,实际开发过程中却无法满足TDD的要求。

    实际上,测试驱动的开发模式确实有效,它将可能发生的问题用测试代码预先解决,只有通过测试代码后的代码才是可以接受。当前有很多公司都在应用TDD,但TDD并不是一个开发者友好的开发模式,只是一个理想化的开发模式。

    为什么TDD不是一个开发者友好的开发方式?

    大家都知道TDD是什么,可是试问所有的开发者能保证每次开发过程中会满足TDD的要求吗?

    听听大家的声音:

    • 测试也只是保证脑内想法转成代码的时候,逻辑自洽
    • Lots of people on the internet talk about how good TDD is, but people were afraid to say it wasn’t working for them.
    • 没有deadline的威胁,我很喜欢TDD,但是过度测试是存在
    • 大多数程序员还不会写测试用例
    • 看起来容易,但是做起来难
    • Yes. TDD该死。TDD死了,T才能正常T,程序员做正常人,团队做正常团队。TDD死,不是因为程序员达不到它的要求,是它没打算尊重程序员,尊重开发实际。TDD本末倒置的价值观,非生产代码统治生产代码,没理解问题就想对问题高屋建瓴,TDD是码农界的纳粹,流程方法论原教旨主义。
    • TDD是否已死先不说,很多程序员连写出基本的整洁代码都做不到,还能指望他先写测试吗
    • 新手看到TDD会欢欣鼓舞,但是他们没有能力来实践。老手们在项目的压力下,早就麻木了,先写case还不如写好代码再补case呢,很多东西我还没时间想清楚,怎么写case?不如先写个小功能先,边写边改
    • 其实我们所有一切的目的是为了快速的交付有价值,有质量的产品或者服务,赢得公司的生存和发展空间。为了达到这个目的,我们有很多种的手段。但手段不是目的。
    • 以国内的敏捷实践来讲,完全达不到TDD的要求
    • TDD 力量和问题都源自 test first。要能 test first,写代码之前要想得更清楚;代码得要有良好的可测试性
    • 导致其写的代码是为了满足测试的,而忽略了代码质量和实际需求
    • 不过,我还真是见过使用TDD开发的不错的项目,只不过那个项目比较简单了。更多的情况下,我看到的是教条式的生硬的TDD,所以,不奇怪地听到了程序员们的抱怨——“自从用了TDD,工作量更大了”。当然,这也不能怪他们,TDD本来就是很难把控的方法。
    • 等等等等

    来自于网络

    我相信很多人都做不到,现在更多的开发者做的更多的是Unit Test,就是写业务代码完了之后再写(单元)测试,而这个Unit Testing 单元测试与TDD 测试驱动开发 的结果一致,即两者都保证了功能通过了测试,两者结果一样为什么还给自己添麻烦,提前写测试代码呢?

    还有些开发者由于水平不足;或是不会测试;有些项目非常紧急根本没时间做测试。

    很多开发者都很反感TDD,至少是在潜意识中很反感(除了自身每天用不着TDD那些人); 试想你在小时候,每天上学前妈妈都会在耳边絮叨都要你小心,然后告诉你每一步的步骤,每一步都要正确,有时候真的很烦,于是我们左耳朵进右耳朵出,就会不耐烦的说“好了,好了,我知道了”;程序员也是一样的,对于很繁琐的一些开发模式他们会糊弄过去,方法之一就是先写完业务代码,完成业务再说测试,写完后再写单元测试,把TDD给搪塞过去。

    可是你知道你妈妈对你是好的,而且她在养你,所以就没说什么;程序员和公司的关系与之很相似,公司也在养你,它希望你写的代码是好的,是可靠的,所以它要求你用TDD的方式编写代码。

    TDD看似有效,但是开发者的普遍不愿意做,并且很容易造假(很多人都是先写完代码,再写测试代码),而且无法监督开发者是否采用TDD这种开发模式,也就是说TDD是理想化的开发模式,如果要执行起来是最好不过的,但是真正严格执行的团队又有多少呢?确定所有的开发人员都严格执行吗?

    由此得知,TDD是非常理想化的开发模式,只有特定的程序员、团队、产品和公司才适合这种理想化的开发模式

    除了TDD,我们还有哪些替代方案?

    有,目前有种开发模式正在被一些公司的部门使用,就是 Test Plan Driven Development,即测试计划驱动开发模式,或是Test Pre-Requisition Driven Development,即测试前提驱动开发。

    TPDD到底是什么?

    相比每次开发之前先写测试代码,我们可以让开发人员参与编写测试计划,也就是说,在收到项目需求时,开发者需要帮助测试人员根据项目需求思考测试计划,并起草 测试计划 A (或者叫做开发承诺-Development Promise),然后再进行开发。

    \"image\"

    由于开发者需要跟测试人员合作,开发者相对于测试人员更加了解项目需求,测试计划更多的依赖于开发者,而测试计划、开发承诺是受到审查的;所以也造不了假,对于团队lead负责人而言是可监控、可调查的。

    适用对象

    • 不喜欢怎么TDD开发模式的开发者,和相关的团队和企业
    • 没有严格要求按照TDD,然而对外声称使用TDD开发模式的开发者,和相关团队和企业
    • 执行了TDD这种开发模式,然而质量没有明显的提高的团队和企业
    • 使用TDD导致开发效率降低的团队和企业
    • 开发者不喜欢TDD这种开发模式,嫌麻烦,但是还想要保证代码质量的团队或企业
    • 开发者没有足够的能力进行TDD的团队和企业
    • 产品的截止日期很紧张的企业
    • 初创团队和企业
    • 正在上升期的团队和企业
    • 还没有应用TDD这种开发模式,但是准备使用TDD的团队或企业

    什么是开发承诺和测试计划A

    开发承诺类似于design doc,不过其中讲述了开发者必须完成的功能,需要做的功能以及可选做的功能,并且还提供了测试人员需要做的事情。

    开发承诺 — 测试计划A 如下所示:

    • Must Have – Critical Check Points
      • 必须要全部完成的功能点,不完成工作没有完成
        • 测试人员重点测试的功能点,并且adhoc test,有能力的团队需要加入自动化测试
    • Need Have – Important Check Points
      • 重要的功能点,必须要完成绝大部分的功能,没有完成绝大部分,工作没有完成
        • 测试人员重点测试的功能点
    • Should Have – Optional Check Points
      • 可选的功能,开发者可选
        • 测试人员手动测试

    开发承诺和测试计划A有什么作用?

    • 开发承诺 测试计划A的第一个作用是,开发者(测试者)对于任务的优先级有很清晰的认识

      • 为了给开发者自己看的(或是其他开发者,假如开发者离职或是请假,其他开发者就可以看测试计划迅速开发),作为开发时的指导手册,这样开发者的头绪就更加清晰,也知道任务的优先级----先做什么,后做什么。

      • 为了给测试人员看的,作为测试的指导手册,这样测试人员就知道什么功能需要重点测试、什么东西需要进行实验性的测试,以及什么功能需要实现测试自动化以便于加入到CI和CD之中。

    • 开发承诺 测试计划A的第二个作用是,承诺使开发者的开发过程更加小心

      • 将测试计划A交给测试人员和开发组长,利用心理学中“承诺”作用,使自己的言行和承诺一致。这样的话,开发人员就知道自己的code至少要满足什么条件,至少要过什么样的测试,所以开发时会更加小心,代码的质量和可靠性也会得到很高的提升。
    • 开发承诺 测试计划A的第三个作用是,促进测试人员的工作进度,使测试人员有更多的时间进行自动化、adhoc测试或是运维方面的工作

      • 测试人员会根据测试计划A起草测试计划B,只需要在测试计划B中添加如何进行测试即可。

    参考:一旦我们做出了某种承诺,或是选择了某种立场,就会在个人和外部环境的压力下,迫使自己的言行与承诺保持一致,尽管这种行为有悖于自己的意愿。

    TDD和TPDD有什么区别?

    TDD的优缺点

    TDD是先写测试代码,判断业务代码是否可以通过测试代码。看似有效,但是开发者的普遍不愿意做,或是完成度很差,或是做了之后导致没有按时完成任务;并且很容易造假,很多人都是先写完代码,再写测试代码;或者测试代码质量不高;或是测试用例不好。

    对于管理者而言,他们无法监督开发者是否有效的沿用TDD这种开发模式,完全体现不了TDD的优势。

    TPDD的优缺点

    1. 提高代码质量

      • TPDD是先写开发承诺,使开发者对测试用例和测试环境有清晰的认识,思维会更加清晰有条理;并且由于承诺的心理作用,开发者会潜移默化的提高代码质量。
    2. 可监控和不可造假

      • 因为测试人员需要根据开发者的开发承诺编写测试计划,可以使管理者很直接的监督开发者是否采用TPDD这种开发模式(通过审查开发承诺),所以不可能造假。
    3. 有时间进行其他方面的提升,例如自动化、运维等

      • 由于开发者和测试者已经将基本的开发承诺—测试计划B写出来了,对于测试者来说将会用更少的时间做功能的理解和测试的准备,这将给测试人员更多的时间进行adhoc测试、自动化测试或是运维功能的开发和维护。
    4. 更好的接受TDD

      • 由于开发者已经接触了测试,使用TPDD后的团队会更好的接受TDD,这时TPDD又可以被称为 Test pre-requisition Driven Development
    5. 对开发者友好

      • 相对于每次开发之前写测试代码,只需要与测试人员想出测试用例,对于开发者来说这是更加容易的
    6. 对测试人员友好

      • 因为与开发者的直接合作,测试的准备的难度大大的降低,测试计划和测试用例的思考时间缩短,并且有时间空余去做一些自动化或是运维方面的工作。
    7. 对管理人员友好

      • 由于开发承诺和测试计划的实体化,管理人员就可以提前进行审查,而不是等待开发结束后进行代码审查(code review)

    参考链接

    TDD is dead. Long live testing.

    Is TDD Dead?

    TDD(测试驱动开发)是否已死?

    TDD并不是看上去的那么美

    心理学参考 之 承诺和一致原理

    作者介绍

    臧嘉玮 Vigor Zang,TPDD的发明者和布道者,主要研究方向为自动化系统和Web Development。曾就职于IBM Watson Commerce组,主要负责自动化测试和前端开发,任职期间受Watson Commerce Insight组的邀请,负责测试流程和测试基础设施的建设,包括测试框架、测试工具和性能检测和预警系统的架构、开发和维护。

    展开全文
  • 如何成为优秀的驱动开发工程师

    千次阅读 2016-08-05 14:28:39
    作者:刘旭晖 Raymond转载请注明出处 Email:colorant@163.com BLOG:http://blog.csdn.net/colorant/ ... 或许这样的标题,应该是由像Linus或Greg KH这样的大师级的高手才有资格写的吧。但是作为我来说,也许

    作者:刘旭晖 Raymond转载请注明出处

    Email:colorant@163.com

    BLOG:http://blog.csdn.net/colorant/

    主页:http://sites.google.com/site/rgbbones/

     

           或许这样的标题,应该是由像Linus或Greg KH这样的大师级的高手才有资格写的吧。但是作为我来说,也许我更想把这个标题作为一个疑问句来使用,整理一下自己的认识,用来勉励自己,和大家一起努力实现这个目标。认识肤浅的地方,还请大家见谅。

     

           何谓优秀的驱动开发工程师
           首先要定义,我所认为的一个优秀的驱动开发工程师,应该具备什么样的能力,这里列一下按照从易到难的顺序,个人认为应该会有几个方面的要求吧:
           1、能够独立完成驱动的功能开发任务
           2、能够分析和优化驱动的性能,针对特定硬件扬长避短
           3、能够充分了解模块相关软硬件能力、发展方向,辅助应用工程师最大化利用硬件能力
           4、能够辅助硬件工程师规划硬件设计,预防问题,谋求功能模块的最佳方案
           5、能够协助定义系统架构,合理规划软硬件,谋求产品实现的最佳方案
     
           作为一个驱动工程师,很多时候不是完全从头开发一个完整的子系统,而是针对特定硬件和平台移植驱动,增加功能,解决Bug等等,如果从这方面外在的表现来看:
     
           解决问题的境界,大概会有这么几个阶段:
           1、不知道哪里存在BUG
           2、不知道如何解决BUG
           3、知道如何解决BUG
           4、 知道如何发现BUG
           5、 知道如何规划BUG
     
           知道如何发现BUG(而不是撞上BUG)其实并不简单,需要你对系统有足够的了解,能够察觉可能出问题的地方。 而规划Bug更难,需要你能对问题的轻重缓急做出准确的判断。没有的完美的世界,只有适当的取舍,规避和预防。
     
    而从解决问题过程的角度来看,我认可以分为几个阶段:
     
           1、BUG发生 -> 大量跟踪调试代码 -> 终于发现并解决BUG
           2、BUG发生 -> 理论推测可能原因 -> 迅速定位并解决BUG
           3、 阅读代码 -> 预测可能出现的BUG -> 证实并解决BUG
     
           号称能光凭瞄一遍代码就找到问题的高手,我想我是没希望了。


          应该具备怎样的素质
          那么要达到上诉最佳境界,需要具备和发展哪些素质和能力呢?
     
           足够的硬件知识
           能看简单的原理图,能够分析硬件异常的可能原因,能够使用常见的硬件调试工具,我想这是做为优秀的驱动工程师,区别与其它软件工程师,所不可避免、必须具备的专业素质。当然取决于你具体从事的工作,对这方面的要求不尽相同。
     
           对于驱动开发者来说,不了解所开发驱动外设的硬件原理和相关背景知识,也许很多时候,也能够完成一些移植,修补的工作任务,但这就好比无源之水,无根之木,我相信是很难走远的。
     
           多多益善的操作系统知识
           做驱动开发,特别是纯粹的外设的驱动移植工作,刚开始的时候,也许你并不需要了解很多操作系统本身的知识(像内存管理,进程调度,锁,各种内核子系统的原理框架等等),也能顺利完成手头的一些工作。
           但是,如果一但需要优化驱动,需要完善软件框架,或者是遇上疑难问题需要跟踪解决,对操作系统,内核本身的了解,就体现出它的价值了。
           对于Linux内核驱动开发者,尤其如此,首先,代码是完全开源的,你有条件去了解背后的运行机制,其次,Linux内核和各个组成子系统总是在迅速的进化发展中,不进则退,你也有必要跟上时代发展的脚步。


           强烈的好奇心,持续的热情
           如果驱动开发不仅仅是你的爱好,更是你养家糊口的途径,我想,很多时候,你大概不会有机会专注于一两个你最有经验的模块的开发和维护。随着能力的成长,势必会要求你接触和掌握越来越多的各式各样的驱动模块的开发。
           对于这件事,包括我自己,有时候大概都会有如下几种反应:
     
           哇,原来的工作做太久了,太乏味了,很高兴能做不同的工作。
           啊?又要做别的模块啊?我手头的工作已经太多了!
           这个模块没意思,我不想做。
     
           相信多数有志青年们都是第一种表现了 8 )不过,有些时候,我发觉,很多人的这种热情其实并不持久,一个新的模块没做多久,就再次厌倦了,是已经炉火纯青了么,未必,或许只是修改了几个BUG以后不甚其烦。很多时候,我面试前来求职的工程师时,发现简历上这个也做过,那个也做过,但是一但问到解决了什么问题,所做过的驱动,框架、流程、原理之类的问题的时候,就一问三不知了。
     
           我觉得如果自己的目标是优秀,那么最起码的标准应该是对具体驱动模块相关的子系统的整体工作流程,框架,具备足够的好奇心,乐于去了解和学习,而不仅仅是为了完成任务而工作,否则的话,很难积累下扎实的经验和技术。


           清晰的逻辑思维能力
           这一点,也许是个软件开发人员都应该具备吧,不过,做为驱动开发工程师来说,有时候,大多数情况下,工作的硬件环境并不是完美的,遇到问题需要分析判断错误的原因是硬件问题还是驱动Bug,这时候,清晰的逻辑思维能力尤其重要。


           良好的工作习惯
           大多数人都不是天才,要成为优秀的开发工程师,一需要持续努力,二需要时间积累经验,而这过程中,很重要的一点,就是要有良好的工作习惯。譬如,注意设计文档的维护,对工作中遇到的问题的记录,过往经验的及时记录,适当的软件开发流程等等。文档工作,可能很多人很不愿意去做,它的确很花费时间。不过,唉。。。老啦,好记性不如烂笔头啊   8 )。 当然,其实设计文档更多的是为你提供思考的机会,而过往经验的总结,也可以起到和大家交流技术,共同进步的目的。
     
           英语
           这个也是必须的啦,没有办法,邮件列表,技术文档,社区,精通英语肯定是很大的优势,做开源项目尤其如此。阅读各种Spec标准文档之类的速度还是很重要的。阅读无障碍是一回事,能和母语一样一目十行,那才爽呀,唉,人生苦短,效率啊!光读文档,就不知道要比老外多花多少时间。。。。

    展开全文
  • =======================================================================               Software Engineering notebook 参考资料: [1]:...

    =======================================================================
                  Software Engineering notebook

    参考资料:
    [1]:https://melsatar.blog/2018/02/16/the-waterfall-model-a-different-perspective/
    [2]:Software Engineering Tenth Edition

    对于软件工程而言,没有放之四海而皆准、适用于所有不同类型软件开发的过程模型。正确的过程取决于客户和管理需求、软件使用所处的环境,以及所开发的软件类型。

    =======================================================================

    在这里插入图片描述
    瀑布模型是一个线性顺序流。在这个过程中,进展被看作是通过软件实现阶段稳定地向下流动(像瀑布一样)。这意味着开发过程中的任何阶段只有在前一个阶段完成时才会开始。瀑布方法没有定义返回到上一个阶段来处理需求变化的过程。

    瀑布模型适合于不注重改变需求的项目,例如:
      1.由提案请求(RFP)发起的项目,客户有非常清晰的文档化需求
      2.关键任务项目,比如航天飞机
      3.嵌入式系统。

    下面是使用瀑布模型时需要考虑的事项:

    • 项目要求是明确的和固定的。
    • 工程团队对于在不同项目中所使用的技术有清晰的认识。
    • 项目不能以迭代的方式交付。
    • 文档是至关重要的。
    • 专业的项目管理技能。
    • 项目成本已定。

    waterfall model的优缺点:

    优点 缺点
    易于向用户解释。 向客户交付可行的解决方案需要完整的生命周期。
    结构方法。 它完成后很难再返回到任何一个阶段
    阶段和活动定义明确。 它假设可以冻结系统的需求而不进行任何更改或增强。
    项目经理更容易计划、安排项目、利用资源和定义项目周期。 一点灵活性和调整范围是困难和昂贵的。
    每个阶段的审批可确保及早发现错误/误解。 它需要更多的时间在项目的前期进行详细的计划,因为需求是清晰的和固定的,并且将详细的计划交付给客户应该是可见的。
    每个阶段都有具体的可交付成果。 它延迟了在需求、设计和实现中发现许多问题的测试阶段。

    原文作者:Mohamed Sami,将waterfall model称为SDLC模型之父,不是因为它是第一次引入的,而是因为所有其他模型都是基于瀑布模型进行设计而设计的,以增强其功能并消除其不足,从而确保更好的交付。

    Mohamed Sami认为瀑布模型的主要缺陷是,它关注的是项目实现,而不是客户,不能实现对客户的快速业务价值。客户应该等待整个生命周期看到结果,这可能是好事,也可能是灾难。我认为我们不需要在开发生命周期的不同角度上达到上面图片中描述的困境,这就是为什么选择合适的模型对于能够根据需要交付预期的业务价值是非常重要的。

    展开全文
  • TDD、BDD、ATDD、DDD 软件开发模式

    万次阅读 2017-04-17 15:50:37
    TDD:测试驱动开发(Test-Driven Development) BDD:行为驱动开发(Behavior Driven Development) ATDD:验收测试驱动开发(Acceptance Test Driven Development) DDD:领域驱动开发(Domain Drive Design) ...

    四个开发模式意思:

    TDD:测试驱动开发(Test-Driven Development)

    BDD:行为驱动开发(Behavior Driven Development)

    ATDD:验收测试驱动开发(Acceptance Test Driven Development)

    DDD:领域驱动开发(Domain Drive Design


    1、TDD:测试驱动开发(Test-Driven Development)

    测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论,TDD首先考虑使用需求(对象、功能、过程、接口等)

    主要是编写测试用例框架对功能的过程和接口进行设计,而测试框架可以持续进行验证。大行其道的一些模式对TDD的支持都非常不错,比如MVC和MVP等


    2、BDD:行为驱动开发(Behavior Driven Development)

    也就是行为驱动开发。这里的B并非指的是Business,实际上BDD可以看作是对TDD的一种补充,让开发、测试、BA以及客户都能在这个基础上达成一致,JBehave之类的BDD框架


    3、ATDD:验收测试驱动开发(Acceptance Test Driven Development)

    通过单元测试用例来驱动功能代码的实现,团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验


    4、DDD:领域驱动开发(Domain Drive Design)

    DDD指的是Domain Drive Design,也就是领域驱动开发,DDD实际上也是建立在这个基础之上,因为它关注的是Service层的设计,着重于业务的实现,将分析和设计结合起来,不再使他们处于分裂的状态,这对于我们正确完整的实现客户的需求,以及建立一个具有业务伸缩性的模型



    展开全文
  • 《Linux设备驱动开发详解:基于最新的Linux 4.0内核》
  • 浅谈TDD、BDD与ATDD软件开发

    万次阅读 2014-03-25 09:16:21
    TDD:测试驱动开发(Test-Driven Development) 测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。...
  • 三种TDD开发模式

    千次阅读 2017-02-08 13:12:11
    首先了解一下这三个开发模式都是什么意思: TDD:测试驱动开发(Test-Driven Development) ...TDD的基本思路就是通过测试来推动整个开发的进行,但测试驱动开发并不只是单纯的测试工作,而是把需
  • 在敏捷开发之旅的第三站,我想要和大家一起分享FDD特征驱动开发方法。 特征驱动开发——Feature Driven Development 还是老规矩,讨论之前,我们先了解一下什么是Feature?什么是FDD? Feature ...
  • 4.8.一些杂散但值得讨论的问题

    千人学习 2018-10-22 21:38:03
    本课程零散讲了一些C语言中值得讨论的知识点。譬如main函数的传参和返回值、void类型、NULL宏定义、debug调试宏等。目的是进一步提升大家对C语言的理解深度,提升大家的实战编程能力。
  • 初次接触自动化测试时,对数据驱动和关键字驱动不甚理解,觉得有点故弄玄须,不就是参数和函数嘛!其实其也体现了测试所不同与开发的一些特点(主要指系统测试),以及和对技术发展的脉络的展现。 1.录制/回放的...
  • TDD:测试驱动开发(Test-Driven Development) 测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码...
  • 敏捷开发方法学及应用

    千次阅读 多人点赞 2013-12-13 00:20:54
    CodeProject 2013年6月最佳博文。敏捷开发,瀑布式开发,XP,TDD,SCRUM,Lean,FDD,DSDM你了解多少?...本文着重于技术团队怎么很好的合作去计划开发并发布软件。本文不着重于编码,技术细节或微软工具。希
  • 先介绍一下最简单的产品驱动模式,demo4~demo9中的缺省配置是驱动模式(两者在主页最左上角很容易切换的)。。以下数据是火星人系统自动生成的,受博客的空间限制可能显示不太完整,也可以在Demo中边阅读边体验。...
  • 行为驱动开发(BDD)全面介绍

    万次阅读 2018-08-11 12:37:02
    行为驱动开发(BDD)全面介绍 作者:杜铁绳  在软件行业中,软件研发项目软件产品交付经常被推迟、研发费用经常超出预算、经常遗漏客户所需的软件功能、有将近20%的项目最终无法交付,或者取消。这些软件研发...
  • Android硬件抽象层(HAL)概要介绍和学习计划

    万次阅读 多人点赞 2017-01-06 14:44:48
    Android的硬件抽象层,简单来说,就是对Linux内核驱动程序的封装,向上提供接口,屏蔽低层的实现细节。也就是说,把对硬件的支持分成了两层,一层放在用户空间(User Space),一层放在内核空间(Kernel Space),...
  • 《Spring注解驱动开发》是一套帮助我们深入了解Spring原理机制的教程; 现今SpringBoot、SpringCloud技术非常火热,作为Spring之上的框架,...
  • 事件驱动模型实例详解(Java篇)

    万次阅读 热门讨论 2011-07-18 16:25:49
    或许每个软件从业者都有从学习控制台应用程序到学习可视化编程的转变过程,控制台应用程序的优点在于可以方便的练习某个语言的语法和开发习惯(如.net和java),而可视化编程的学习又可以非常方便开发出各类人机对话...
  • 数据驱动 优点 > 被测系统/功能还处于开发阶段时,就能开始着手写测试脚本。   > 模块化的脚本设计和数据集的使用可减少冗余的脚本 被测系统功能有变化时,只需修改与此业务功能相关的特定脚本。   >...
  • 1前言从2001年进入工控领域以来,前后7年多的时间开发了诸如二型计量监控系统、焦炉四大机车自动化系统、烧结配水监控系统、隧道广告影像系统、通用组态软件、嵌入式系统组态软件(基于WINCE系统)、LED视频影像系统...
  • 从零开始、深入浅出,内容涵盖:linux系统基础、shell、linux C编程、linux系统编程、网络编程、ARM体系结构及汇编语言、ARM裸机编程、linux系统移植、linux驱动开发等模块。分多个子课程逐步学习。 本课程是全套...
1 2 3 4 5 ... 20
收藏数 102,072
精华内容 40,828
热门标签
关键字:

计划驱动开发