it-swarm.cn

为什么TDD在大学中不受欢迎?

最近,有人在这里问一个基本问题,即如何在列表中计算Python)元素的所有排列。对于大多数学生提出的问题,我没有在其中提供实际的源代码。我的回答是,而是解释了如何解决该问题,该问题基本上以测试驱动开发的基本介绍结尾。

考虑问题本身,我想起了我在大学学习编程时必须解决的所有类似问题。我们从来没有被教导测试驱动开发,也没有任何类似的方法,但是仍然不断被要求编写算法,以从列表中对元素进行排序,或者解决塔塔河内难题,等等。SoftwareEngineering.SE上的所有学生似乎也没有知道TDD(测试驱动开发)如何帮助他们解决所遇到的问题:如果是这样,他们将以不同的方式提出问题。

事实是,没有TDD,所有这些问题的确具有挑战性。我认为自己是一名专业的开发人员,但是如果被问到,我仍然会花一些时间编写没有TDD的列表排序算法,并且如果我被要求计算列表中元素的所有排列,而仍然没有,我将一无所知。使用TDD。另一方面,使用TDD时,在将答案写给学生时,我可以在几分钟内解决排列问题。

是什么原因导致TDD要么根本没有被教授,要么至少在大学里很晚才被教授?换句话说,解释TDD方法before要求学生编写列表排序算法和类似的东西会不会有问题?


遵循以下两个问题的评论:

在您的问题中,您似乎将TDD表示为“问题解决装置” [...]过去,TDD被表示为“解决方案发现机制”,但即使鲍勃·马丁(TDD的主要倡导者)也承认:您必须为该技术带来大量先验知识。

特别是:

我很好奇为什么您认为TDD使具有明确定义规范的棘手算法问题变得更加容易。

我认为有必要进一步解释什么是解决问题时TDD如此神奇的东西。

在高中和大学里,我没有解决问题的任何特定技术,这既适用于编程又适用于数学。回顾过去,我认为这样的技术之一是复习当前/最后的课程/讲座并寻求与练习的联系。如果课程是关于积分的,则老师要求解决的问题很可能需要使用积分。如果讲座是关于递归的,那么有可能使用递归来解决给学生的难题。我也肯定有解决数学问题的形式化方法,这些方法也可以应用于编程。但是,我从未学过任何东西。

这意味着在实践中,我的方法仅仅是解决周围的问题,尝试guess应该如何解决。那时,如果我面临着从列表中生成元素置换的挑战,那么我就不会以空列表作为输入,而是一个说明性的示例,例如[4, 9, 2],试图找出为什么有六个可能的排列,以及如何通过代码生成它们。从那里开始,我需要进行很多思考,以找到解决问题的可能方法。这本质上是 原始问题 中的作者所做的,最后使用random。同样,当我还是学生时,我这个年龄的其他学生都不会以[]:所有人都会立即使用两个或三个元素来处理这种情况,然后停留半个小时,有时结果是无法编译或无法运行的代码。

对我而言,TDD方法似乎是违反直觉的。我的意思是,它工作得很好,但是在阅读一些有关TDD的文章之前,我永远不会弄清楚自己(1)我应该以最简单的情况开始,(2)在编写代码之前编写测试,以及(3 )从不急于尝试实现代码中的几种方案。看着初学者程序员的想法,我有一个印象,我并不是唯一发现它违反直觉的人。我认为,对于对功能语言有很好理解的程序员来说,它可能会更直观。我猜想,例如在Haskell中,自然会通过首先考虑一个空列表的情况,然后考虑一个包含一个元素的列表的情况,然后考虑一个包含多个元素的列表的情况来处理置换问题。在可以使用递归算法但不像Haskell那样自然的语言中,这种方法自然就不那么自然了,除非当然要实践TDD。

123
Arseni Mourzenko

我是当地社区大学的兼职编程老师。

这所学院教授的第一门课程是Java编程和算法。这是一门以基本循环和条件开始,以继承,多态性和集合简介为结束的课程。在一个学期中,对于从未写过任何代码的学生来说,这是对他们中的大多数人完全陌生的一项活动!

我曾经被邀请参加课程审查委员会。董事会确定了大学CS课程的一些问题:

  1. 教授了太多的编程语言。
  2. 没有关于软件开发生命周期的课程。
  3. 没有数据库课程。
  4. 很难将学分转移到州立大学和地方大学,部分原因是这些学校无法就“计算机科学”,“信息技术”和“软件工程”这两个术语达成统一的定义。

我对他们的建议?在课程中增加一个为期两个学期的课程,学生可以编写一个全栈应用程序,该课程涵盖从收集需求到部署的整个软件开发生命周期。这将使他们可以在当地雇主那里(在学徒级别)被雇用。

那么TDD在所有这些方面适合什么呢?老实说我不知道​​。

在您的问题中,您似乎将TDD表示为“问题解决工具”;我主要将TDD视为改善代码设计和可测试性的一种方式。过去,TDD曾被视为一种“解决方案发现机制”,但即使鲍勃·马丁(TDD的主要倡导者)也承认,您必须为该技术带来大量先验知识。

换句话说,您仍然必须首先知道如何解决代码中的问题。 TDD只是在与软件设计细节相关的正确总体方向上推动您。这使其成为一门高层次的课程,而不是一门低层次的课程。

135
Robert Harvey

首先,我们必须从根本上区分计算机科学软件工程。)(或者在较小程度上,软件工程和编程或“编码”)。

正如我的一位CS教授所说:如果您需要键盘,那么您就不用CS了。

TDD非常是一种软件工程实践。它实际上与计算机科学关系不大。因此,如果您问为什么CS学生不学习TDD,那是因为TDD与CS并没有太大关系。

现在,软件工程完全不同。我非常同意TDD 应该应该在那里教。我参加了软件工程课程(一个学期每周90分钟),在这一课程中,我们学习了Waterfall,V-Model,RUP,CMM, CASE,RAD,Spiral,Iterative和其他一些我可能忘记的东西当然,在TDD中肯定会有挤的空间,特别是如果您将其与其余课程集成在一起并将TDD应用于所有家庭作业和课堂作业中需要编程的课程。

公平地说,在我的案例中,尚未编写《敏捷宣言》,而TDD是一种晦涩的利基技术。

如果您看一下我个人最喜欢的编程教学 如何设计程序 ,您会发现他们很早就开始讲授函数应该带有使用示例和只是在稍后,本书介绍了自动化单元测试,并建议应将这些用法示例以测试的形式编写。它们还教导了这些用法示例及其所谓的“目的陈述”(您可以将其视为JavaDoc注释的摘要行)应写在代码之前。

他们没有明确地教TDD(他们有自己的方法),但这至少有点接近。 HtDP是为高中生设计的,不到一年的教学时间,因此,我认为在大学的一个学期中教授HtDP是可行的。

不过,老实说,简单地教学生可以用不同的输入实际run)他们编写的代码(换句话说,就是粗略的手动测试),这已经是一个巨大的胜利。让学生惊讶的是,他们多久没有采取这种心理步骤。

例如,我在Stack Overflow上看到了多个问题,这些问题实质上等于“我需要实现哪种方法才能使此代码正常工作”。注意,这是不是关于方法的代码(询问者知道如何实现该方法),纯粹是关于名称。但是,不是一个的询问者出现了其想法只是运行代码并查看NoMethodError异常中将始终引发的缺少方法的名称。

97
Jörg W Mittag

TDD是“现实世界”编程中的一个不错的过程,因为问题通常会出现在我们指定的办公桌上。 “添加一个执行X的功能”,“修复在执行Y时显示错误的错误”,等等。TDD迫使我们在开始编程之前就创建了一个规范。

在CS /编程类中,问题通常是非常明确的。 “编写一个函数,该函数接受一个整数数组,并返回一个以非降序排列的具有相同整数的数组”。规格已交给我们。

我很好奇为什么您认为TDD使具有明确定义规范的棘手算法问题变得更加容易。具体来说,我想请您解释一下:

如果仍然要求我在不使用TDD的情况下计算列表中元素的所有排列,我将一无所知。另一方面,使用TDD时,在将答案写给学生时,我可以在几分钟内解决排列问题。

我怀疑您会说,因为您编写了断言P([]) -> [[]]P([1]) -> [[1]]P([1, 2]) -> [[1, 2], [2, 1]]等的测试用例,这使您看到了递归应该如何工作。但这不是TDD,而只是...思考问题。您可以考虑问题而无需编写失败的实际单元测试的过程。

53
MattPutnam

我怀疑这主要是因为编写自动化测试比编写要测试的代码更加困难。当您仍在努力解决基本机制时,很难添加另一层。而且,正如其他答案所指出的那样,TDD被视为一种软件工程过程,即使其从业人员更多地将其视为教学手段。而且,知道首先要编写哪些测试本身就是一项技能。

如果我要教入门课程,我会提供以TDD顺序进行一些测试,并指示学生按该顺序一次通过一项测试。将编程与经验丰富的导师配对非常相似。就个人而言,我认为这将使算法之类的课程更易于教授,由于逐步进行,这将抵消在该技术上花费的时间。这将使学生思考以下问题:“我有一些行之有效的代码,可以找到包含两个元素的列表的所有排列。如何重用尽可能多的代码以使其适用于3个以上的元素?”

33
Karl Bielefeldt

基本问题是TDD流程中的发明测试与计算机科学或软件工程无关。它要求了解应用程序域。

当然,这就是TDD在实际应用中的优势:您无法逃避思考所要构建的系统将实际用于什么系统。但是在典型的CS和SE活动中,给学生的任务具有最小的上下文,并且仅用于测试或说明一些学习目标。

例如,如果学习目标是证明对编程语言中“案例”结构的理解,则TDD无关紧要:您可以编写通过所有TDD测试的软件,而根本不使用“案例”。如果该示例是人为的,则实际上,不使用“案例”可能是解决该问题的更好解决方案,但是就预期的学习目标而言却并非如此。

一定要鼓励学生发明自己的测试用例并运行它们,但是要尝试使用正式的TDD流程是没有意义的。

第二个问题可能与CE和SE的教学方式有关,但仍然是一个实际的问题:如何在使用TDD时给学生的测试集评分?没有明显的方法可以自动化该过程。

即使您生成的模型解决方案说“您应该已经针对以下15种或20种情况进行了测试”,您仍然必须手动识别学生的哪些测试(全部或部分)对应于模型答案的每个部分。而且,除了琐碎的情况以外,学生可能已经制作了一套很好的测试,这些测试的逻辑结构与模型答案的方式不同。

9
alephzero

普通学生确实对他们应该知道的知识和做的事情没有很好的了解。要教TDD,他们需要了解:

  1. 如何解决技术问题。一开始,他们认为代码是一次性编写的。只有在他们意识到基本的调试策略之后,才转向更多的增量编写。即使您事先告诉他们,他们仍然会这样做,因为他们认为事情就是这样做的(这也是为什么人们不知道如何绘画,弹钢琴,做数学等的原因)。 )

  2. 如何自省自己的行为,以便可以在自己的行为中找到可重复的模式。一旦可以执行此操作,就可以自动化您自己的工作。但这对大多数人来说是完全陌生的,直到他们达到一定水平。

  3. 如何编写要求。

  4. 了解问题空间的极端情况。

  5. 了解风险管理的工程哲学。 (哈,但您甚至都不知道自己是一名工程师)

  6. 了解代码的重构和维护。

  7. 了解编程在实际公司中如何工作。

实际上,我的同事们对TDD的了解还为时过早,他们并没有真正从中受益。但是,仍然有可能朝着这个目标迈出一步。只是人们需要大量的经验支持才能受益。

因此,您可以教书,但不能开始。尤其是因为有些代码不太容易将其引入TDD。

8
joojaa

TDD在大学中并不流行,因为(通常来说)大学在确保提供给学生的知识可以转化为现实环境方面做得很差。

可以说,这首先不是大学的角色,而是更多地讲授CS的基础知识和核心概念。如果学生对在学术界从事职业感兴趣,那将是有启发性,重要且必不可少的,但是当学生完成学位并进入行业,并跟随团队发展,并进入该行业时,这是不够的最佳做法,CI/CD等.

显然,存在交叉路口,并且两者都可以互惠互利,但是,最终,大学根本还无法满足需要的工作,以使能力更强,相关性更高且最新的软件工程师毕业。

6
Bruno Oliveira

要直接回答问题:

正如有人建议的那样,整个学期都有足够的学习机会。一个单独的课程?也许。我可以看到TDD与软件设计主题结合在一起。 IMO TDD的最大价值是锁定现有行为,因此我们以后可以添加新行为,并更改设计以使其适合这些新行为。那么软件设计课呢?

很高兴看到TDD背后的思考过程(名字不好,我曾经问过Kent Beck是否会重新考虑;他说“火车已经离开车站”了)要尽早引入。自1976年以来,我就一直在编写代码,我知道TDD起初感觉很不自然。但是现在感觉很自然。编写测试代码并不能挽回我的时间,后来我只需每年修复一次严重的缺陷就可以重新获得回报(UofM Transplant Center的OTIS2软件完全由测试驱动编写,在2004年发生了最后一次“软件紧急情况” )。

我鼓励应届毕业生尝试一个月。但是,如果他们更早地接触TDD,对他们来说会容易得多。当我学习一种新语言时,我发现使用单元测试框架很有用(真实的故事:“现在如何通过Ruby通过此测试?也许这可以工作... HEY IT WORKED!”),或进行探索一个新的库(“文档对返回的顺序含糊不清...我将编写测试...”)。

我发现TDD在实现算法时很有价值(不要发明一个……我会去做的),或者从头开始构建任何稍微复杂的业务规则。所有通过的测试都会永久锁定。如果测试足够离散,则无需更改(但是that要花费一个多月才能熟练掌握)。

因此将TDD合并到较早的编程类中会很有趣。改进三点:

  1. 我们可以将精力放在调试和中断修复上,而大多数开发人员认为这只是他们工作的本质。不是。不必那么痛苦或费时。
  2. 单元测试框架是#ifdef DEBUG/printf(“ ...”)/ #endif的简单替代-因此,自从开始以来,我们就一直在做类似的事情(但风险更大)。
  3. 当我们听到“您必须首先编写测试”时,我们被误导了。我想要写下我对我将要编写的代码的期望。我希望在继续关注下一个行为或清理设计时保持运行状态。

可能有用的另一件事是一本教科书,或者至少是一个精简的非废话课程,其实验室旨在传达TDD实践的各个方面。我对此有一个建议(请参阅以后的经验/免责声明)。

回答批评家:

我是新来的,但我注意到有些“答案”不能回答问题,但是对TDD提出了合理的批评。所以我想可以解决其中的一些问题吗?

  1. 的确,将TDD与之后的单元测试(UTA?)进行比较的研究表明,TDD最初速度较慢。但是,UTA组的测试覆盖率低得多,缺陷更多。我认为这是这项研究: 在行业中使用测试驱动的开发实践的纵向研究

如果开发人员在产品上工作了几个月以上,而实际上却将大部分时间花在编写新功能上,那么这将是负面的。但是我作为开发人员工作的六个TDD团队确实花了他们的时间,而我在TDD之前花了10年时间来执行代码吊装工作的十年大部分时间都花在了调试器上,或者是谨慎地复制/粘贴/修改,所以我不会老/其他人的代码。 TDD的优势并非一instant而就,但是通过降低开发人员的加班时间(和压力)和[增加收入。底线:我一直很期待与这些TDD团队合作。 (一旦我喝茶。)

  1. TDD不能发明一种新算法也是事实。我认为是Ron Jeffries尝试使用TDD创建Sudoku求解器,并试图不让他自己的Sudoku技能干扰实现。他失败了。我不惊讶。 TDD有助于分解,简化和实施业务规则;帮助确认我们正确使用了算法(例如,可能无法归约的复杂加密算法);帮助我们稍后重塑代码,以便我们可以安全地添加新功能;并通过限制我们已经在产品行为方面进行的投资来做到这一点。

当您编写“测试”(又称为规范,又称为场景)时,您必须知道答案!此外,您还想编写一个测试方案,该测试方案对解决方案的影响很小,您已经对如何实现该方案有了一定的了解(先验知识)。

令人惊讶的是,如果我们关注代码的气味,并且只要与该代码相关的所有测试通过,我们就会根据需要进行重构,那么设计可以变得多么清晰和简单。

没有人建议我们抛弃对设计模式或语言习语或SOLID原理,如何玩Sudoku或如何编写堆排序)的深入了解。

TDD旨在创建一个安全网,使我们有信心迅速添加新功能并更改设计以适合这些新功能,而不会破坏其他功能。

在有人跌倒致死后,UTA正在修补安全网。 (有趣的旁注:OTIS2项目是一个至关重要的系统,因此患者死亡的风险对我们而言不是开玩笑。现在,在10分钟内运行了20,000多项测试- that是一个安全网!)

经验/免责声明:

从1998年到2004年,我几乎全职参加了TDD,与大约6个不同的团队合作。所有这些都至少需要6个月的开发时间。在那之前,我花了13年时间以另一种方式编写软件,并开始讨厌使用printf()进行调试和手动测试。

我从2001年开始教授软件开发实践,现在包括TDD,BDD和SA-CSD课程。当然,这是一种美好的生活,但我也知道TDD是使以团队为中心的软件开发理智又令人愉快的一种直接方法。所以...

我正在写我希望能成为一本大学或高中教科书的课程(当然还有在线回购,实验室,视频等): 基本测试驱动开发

4
user30938

我从未认为TDD可以作为解决问题的有效方法,但在阅读了您的问题后我仍然没有帮助。

TDD只是强迫您从一个方面(客户的角度)着眼问题。这可以帮助您避免提出与客户的问题不符的解决方案。通常这是一件好事,尽管它也可能会限制您,但使您无法从更广的角度看问题,对于您的客户未考虑的问题,可能会有更好,更通用的解决方案。

另一种看待它的方法是它是最终的自上而下的方法。 TDD可以代表自顶向下开发。您可以从最高级别的课程开始进行开发,然后逐步放大。

无论哪种方式,它都是一个抽象的概念。您可以告诉学生,提供定义,但是仅此而已。您在考试中不能问那么多问题。因此,在任何SE或CS类中,尽管在SE上下文中很有用,但它永远不过是附带说明。

4
Martin Maat

在1970年代TDD(首字母缩写词)的发明被发明之前,我就曾在计算机科学领域任教,当然,我们从来没有明确地教过该技术。但是对于我们给出的一个编程练习,我们提供了一组测试用例,并被告知我们的解决方案必须通过测试。因此,我在没有明确地学习它的情况下就了解了该方法的价值,并从此使用了它。

4
Michael Kay

尽管编写测试是软件开发的一项基本技能,但科学证据并未表明TDD最终会生产出比迭代测试-最后(ITL)开发更好的软件(OTOH,但不是更差)。

作为证据,您可以参阅Davide Fucci等。 “使用多站点盲分析方法对测试驱动开发的效果进行外部复制”( link )和Turhan等人在制作软件中进行元分析( link )。

因此,除非我们开始看到相反的证据表明TDD确实提供了可衡量的收益,否则教授TDD作为一种特定的实践就没有那么重要了,而不是在开发过程中的某个时候简单地灌输测试写作的良好习惯。

3
Anzel

但是如果被问到,我仍然会花一些时间来编写没有TDD的列表排序算法,而且如果我被要求计算列表中元素的所有排列,而仍然不使用TDD的话,我几乎一无所知。另一方面,借助TDD,我可以在几分钟内解决排列问题

这让我很困惑。
对我来说,测试驱动开发意味着更早考虑测试并花时间实施测试并使它们与代码保持最新。
当然,思考要测试的内容是阐述要解决的问题的好机会,并且在某些情况下,可以很好地了解存在的陷阱。
但是,如果不做TDD,首先不专注于测试,无论如何也不会禁止考虑潜在的问题。无论您是否想进一步采取行动并立即实施测试,您都应该考虑自己的工作并弄清楚情况。

在要求学生编写列表排序算法和类似内容之前解释TDD方法会不会有问题?

这取决于您在何种程度上解释TDD。
了解某些信息会很有帮助。但是学生会听到很多无法解释的内容,因为其他基本知识仍然缺失。因此,您不应该深入了解这样一个概念,即如果不了解基础知识,对他们来说是毫无用处的和疏远的未知术语。
除此之外,如果您正在寻找有关某个问题的方法,并找到确实显示了解决方案的示例,那么许多程序员可能会感觉如何,但首先您必须对所有其他不相关的内容进行分类作者补充说。

因此,要回答这个问题,如果我是一名学生,我想把事情分开。如果您宣布要解释我们如何对列表进行排序,那么请告诉我们如何进行此操作,但不要留下填写测试内容的路径。如果您想开始解释测试,请不要宣布实施排序,因为这种情况很长时间都不会发生。
同样,在开始编写排序或测试之前,需要先进行一些思考。列表在排序前后会显示什么?举例说明,考虑陷阱,为避免在列表为空时失败而必须考虑的因素,等等。必须考虑所有这些,但尚未编写测试行。

通常,我会说您正在混淆两件事,应该分开保存。

  • 考虑您要解决的问题的性质。
  • 考虑代码的输入以及应该给出的输出。

关于问题的思考与专注于编写测试用例完全不同。

怎么做不好

一旦我遇到一个痴迷于TDD的人,就发现了TDD的一个例子。
很不幸,在我看来作者似乎太喜欢他的教程了,所以他没有意识到它实际上是什么废话。

作者only专注于测试用例,而不是他们的代码应处理的问题。由于您永远找不到所有输入排列,因此必须对实际操作有一个总体了解,您必须了解整个问题。您不能总是从空输入开始,然后再添加一些输入,并总是追加代码以正确处理新输入。
您必须大致了解自己实际要处理的内容。但是作者没有。

如果我尝试将其转换为对列表进行排序,我们将从一个空列表开始,然后可以按原样返回一个元素,一个包含两个元素的列表可能需要交换,并且可能以递归结束,因为三个元素就像两个(我们已经解决了)一样,加上一个步骤又增加了一个...
排序算法的可怕选择-但没人会意识到,因为我们只专注于测试用例。

结论

这些评论使我对自己的看法多了一些。

我认为“测试驱动的开发”一词是错误的。它应该是“受测试支持的开发”,这意味着我们不仅要编写代码并希望如此,而且我们也考虑进行测试,并且我们知道尽早发现问题出在哪里总是件好事。

如果通过测试将开发命名为驱动,则可能意味着一切仅取决于测试,并且只要满足几个测试用例,我们便会完成。即使是非常不足的代码(从未尝试从整体上看待问题,但却被来回破解),直到所有测试用例都变成绿色为止,然后在实际操作中失败,这些代码才能满足这一要求。

2
puck

您已将问题更新为更多的“为什么不将TDD不作为核心学习工具来教授?”。其他答案已经很好地解释了为什么TDD并不是编码101的好话题,但是主要的答案实际上只是TDD本身并不是解决问题的工具。它可以用于此目的,但是像任何工具一样,您必须首先了解何时以及如何使用它。

TDD是一个测试过程,因此最自然地将其作为“开发过程”课程的一部分或作为“软件测试”课程的一部分进行教授。在编写101门课程的编码中,目标不是让学生解决问题,而是教他们如何使用各种编程概念。通常,大多数编码101和102项目将非常明确地说明如何解决问题,学生只需要了解他们所学到的以非复制粘贴方式完成任务的内容即可。

每个学生都以不同的方式学习。有些学生需要阅读它,其他一些学生则需要对他们进行口头解释,而另一些学生则除非他们精通代码,否则永远不会得到它。教TDD以帮助学习过程实际上并不会帮助大多数学生,而确实有帮助的学生呢?教师将不得不决定时间教学TDD是否值得额外的学习速度。从总体上看,教授任何一种学习方法都不值得花在课堂上的实际时间上。 (通常,学习和解决问题的能力通常留给学生学习,因为只有学生才能确定最适合自己的方法)

TL:RD;不同的人有不同的有效过程。大学没有规定您应该做什么。只要给您工具,您就可以做最适合您的事情。

1
Tezra

TDD是一种出色的实现工具,我认为您是正确的,因为它有益对于希望编写软件的人而言

是什么原因导致TDD要么根本没有被教授,要么至少在大学里很晚才被教授?换句话说,在要求学生编写列表排序算法和类似内容之前解释TDD方法是否会有问题?

可能的最大原因是教授这些程序的教授很少知道如何开发软件,因为那不是他们的专业领域。正如其他答案所提到的那样,计算机科学和软件工程是不同的学科,我将计算机科学专业的学生学习软件工程的期望与物理学专业的学生学习如何设计汽车的期望进行比较。 TDD是一项需要大量实践才能真正有效教授的技能,计算机科学教授将其职业生涯的大部分时间都用于计算机科学,因此期望计算机科学系的老师真的能够以某种方式教授TDD在我看来,这不仅会使他们的学生困惑,这是不现实的。

我们需要将计算机科学和专业软件开发视为各自独立的领域。如果您的目标是学习计算机科学,那么您不应该为学习如何在React)中错误地创建网站而付出数千美元的负担同样,如果您的目标是成为一名软件工程师,我不知道您为什么要花费4年和数万美元来学习本质上仅是特定数学领域的知识。拥有该领域的基础知识,就像设计排气歧管的人需要了解多少物理原理一样,但是设计排气歧管的人并不需要太深入地了解量子力学,狭义相对论,和电磁来完成他们的工作。

如果您想成为一名会计师,则可以获取会计学位,而您的教授很可能都曾在某一点上成为过注册会计师。如果您想成为机械工程师,则可以获取机械工程学位,而您的教授很可能都在某一方面获得了许可工程师的资格。但是,如果您想成为一名软件工程师,则任何软件工程学位实际上都将是计算机科学学位,并且已经为您选择了一些选修课,并且几乎没有您的教授会成为专业软件开发人员。会计学位不是数学系的一部分,机械工程学位不是物理系的一部分,但是软件工程学位几乎总是属于计算机科学系的一部分。在整个学术界将这两个领域完全划分为由不同人员管理的不同部门之前,我认为总会有一长串诸如TDD之类的东西不被那些渴望成为软件工程师的学生所教。

1
Dogs