我对软件工程有错误的想法吗?[关闭]


26

我最近的工作(而不是实习生)提出了一个问题。

只是为了说明背景-我21岁,我已经完成了第二年的大学学习,在此之前,我拥有大约2年的从事系统管理员/质量检查工作的经验,基本上我可以说我已经看到了与众不同IT部门运作。回顾现在,这是我在英国一家主要研究机构之一从事实习工作。

我要做的是使用多种技术(主要是AWS / Java / Bash)创建一些内部工具,您就会明白。一切都很好,我正在做我的工作,但我不高兴。为什么会这样-因为希望我可以临时工作。那就是快速创建事物,而无需花费时间进行设计。我的经理明确表示,希望从出现的问题中“匆忙”解决,而本质上是我们。结果,结果是必须重新做事和重新设计,它们仍然不是完美的。就测试而言-将其保持在最低水平,只要看起来可行,就可以了。

我是否有责任不同意这种工作方式?想对整个系统进行思考,然后关注不同的组件并了解它们如何互操作,将不同的“关键点”归零,这在将来会带来问题,这是错误的吗?做好工作而不是“快速工作”是犯罪吗?想要研究适用于问题的数据结构,以便您可以根据特定问题集选择最佳方案,这是错误还是错误的态度?据我所知,“软件工程”中的“工程”部分与此完全相关-研究您的问题领域并提出一个明智的解决方案,然后根据需要进行改进?

我去过英国某军械库办公室的一次采访,他们给我看了他们的SCRUM室,看起来他们对如何管理他们的项目有很好的主意-他们积压,他们有关于每个人待多长时间的指标这个问题可能需要解决-SCRUM的常规操作-与“在这里”运行的方式完全不同

我对软件行业总体上是否建立了错误的观念?我想听听您的意见。我的意思是说我“进入”软件开发纯粹是因为我想创建简单而简单的东西,但我想创建高质量的东西。我想查看我的软件在各种情况下使用的情况,我想查看它的防弹功能-这不是所有软件工程师的动力吗?我认为每个人都可以通过学习语法来成为一名程序员/编码器,但对我而言,真正的乐趣始于当您实际上不得不提出一种在现实世界中可行的设计时。

我过去只是看大学就直接做编码,然后很容易就获得了75%以上的分数,而且从来没有真正欣赏过“软件开发生命周期”模块。但是现在,当我看到在现实世界中,没有任何正式流程就工作有多么糟糕,以及在明天不知道需求是否会改变的情况下固有的沮丧感(哦,我是否说我们不没有明确定义的需求分析?)

我真的很想相信我刚刚担任的职位,有些人只需要一个代码猴子来完成他们的肮脏工作,而软件世界的运作情况却并非如此。


13
研究是与许多其他领域不同的野兽。这确实是一场比赛。
CaffGeek


18
because I'm expected to work in an ad-hoc matter. That is create things quickly, without spending time on designing-欢迎来到The Real World™,在那里有截止日期,并且期望公司产生成果。
罗伯特·哈维

1
在我的上一份工作中,我们将其称为“镀金”,就像“退出该东西的镀金,然后完成!”一样。但是,说实话,要创建一个好的产品,您确实需要花一些时间来计划它。请参阅programmers.stackexchange.com/questions/97985/…–
罗伯特·哈维

1
@Tyler仅仅因为该产品将不会商业化,并不意味着没有最后期限取决于该产品的完整性和可操作性(或接近它)。
肯尼思

Answers:


33

使软件可重用和防弹并不是软件工程的驱动力。工程是要在现实世界中的约束条件下最佳地解决现实世界中的问题。大多数工程师更喜欢在法拉利上工作-但旅行车需要同样多的工程设计,旅行车表现不佳(在某些方面)的原因是由于设计上的困难,而不是由于工程设计不佳。

当您说您想做一个“好的工作”而不是“快速的工作”时,大多数工程师都会这样做,但是有时候,定义好工作的部分原因是完成工作有多快。因此,将“好”和“快速”视为对立的选择是不对的。或者认为您做的不好,或者仅仅是“代码猴子”,以在可用的时间里做最好的工作。

当然,该过程很有可能不是最佳的,并且通过预先进行一些设计会更好。严峻的考验是,当前的处理方式是否会给用户带来更多的问题,还是只是在困扰必须采用这种方式的开发人员?如果这实际上是在给用户带来问题,那么您的工作之一就是尝试证明情况确实如此,并试图使人们赢得一个稍微受控制的过程。


我完全同意,但是我想说,他们似乎给了他很多独立性。他们希望他做最少的测试,但是他可以决定实际是什么。此外,快速做好工作的一部分是找到合适的工具来减少他的工作量,包括花费时间来构建框架项目和设置适当的文本编辑器。
Spencer Rathbun

7
对于将项目约束带入讨论的+1,对于来自学术界的任何遇到现实世界约束的人来说,通常都是一脸冷水=)
Patrick Hughes

2
-1“创建比用户要解决的问题更多的问题”显然不是何时应该停止工作并开始仔细设计代码的好标记。您可以完美地构建一个大的泥球,而用户不会意识到。唯一会注意的是开发人员(很难维护),而客户购买部门则要支付维护费。我不知道会告诉许多购买产品的客户的消息:“您可以很快得到,但是由于我们产生的技术债务,这意味着将来的功能将变得越来越昂贵”。
guillaume31

1
(在5分钟的编辑窗口后,编辑至上方)-泥泞的大球会给用户带来比解决的问题更多的问题。而且,如果它不会带来更多的问题(很难举一个例子,也许是一个扔掉的东西实际上被扔掉了吗?),那么创建一个大泥巴实际上将是一个很好的解决方案。或者,至少应该如此。
psr

1
如果工程学只在完美时才完成产品,那么发明的第一辆汽车将是喷气式喷气式飞机,而我们都将骑马,因为它尚未被发明。
Jimmy Hoffa 2014年

17

其实,这困扰着我。您从事的行业是为研究科学家开发工具的方法。但是,系统会告诉您使这些程序快速运行,并使它们看起来工作最少。惊喜惊喜。这只是研究人员的典型编程方法,而实际的费用却落到了真正的程序员身上。

这里主要关注的是,如果工具具有重要目的,则缺乏测试尤其会在道德上令人怀疑。如果由于一个人只能在最短的测试时间内不确定该软件是否有缺陷,则意味着没有人对软件的工作状况负责,Atlas耸了耸肩。

让我们停下来思考一下。您正在开发哪种工具?如果您正在开发用于对数据进行建模的软件,则这里存在很大的道德困境。在某些情况下,科学研究会导致影响大批人的决策。

假设一下,这个有争议的人为气候变化话题。假设他们在建模软件上使用了相同的标准,以得出他们今天的结论。该主题对我们正确处理环境和国际政策的方式有很大影响。

确保建模软件的预测没有重大问题是否不道德?

整个问题不是温室气体使地球变暖。问题是反馈效应的最终结果是否是温度的加速增加,超过阈值后将不再可逆。

如果发生上述收益,则净结果的证据将是微不足道的,可能在错误范围内。

因此,轻微的错误计算,甚至是后端涉及数据存储和检索的方法,都可能导致要么在故障的一端忽略一个严重的环境问题,要么导致影响很多人的国际政策(破坏工作,破坏养老金等)。 ) 在另一。

所以,是的,你是对的。我不在乎研究的步伐是什么...如果研究人员想依靠软件工具来管理数据并为它们执行计算,他们需要学习等待正确完成软件。否则,该软件将成为其理论中不负责任的漏洞点,从而导致道德不端行为。


完全有效的一点!尽管值得庆幸的是,在这种情况下这不是问题!
泰勒·德登

我对其余答案的态度更加关注,没有其他人注意到这一关注。
李·路维耶

2
我的经验是,研究实验室确实非常担心其软件的核心是否正确,并且确实花费大量时间来验证结果并证明可重复性。但是,他们更倾向于跳过用户界面,高效的文件格式以及易于维护。可以说这是适当的,因为在许多情况下,一旦发布结果,该软件就永远不会再次运行或扩展。
Charles E. Grant

8

您对什么是软件工程没有错误的认识。但是,您缺少其中一个非常重要的方面:这是一个服务行业。我们中的一些人开始从事产品工作多年,经过设计,然后进行多次迭代,然后才发布到v1中。其他人必须在3小时内生产出一些东西。这取决于您为谁服务以及目的是什么。

如果您可以在3个小时(或几天)内完成应用程序的准备工作,为什么还要花更多的时间进行前期设计?你只是在浪费钱。浪费金钱通常不是一个好主意。


+1 有些是多年的产品,有些则需要3个小时才能产生:D
Karthik Sreenivasan 2012年

5

正如其他人已经说过的那样,软件工程所涉及的很大一部分是“外部约束”。例如。时间,预算,服务,支持,满足非理性的白痴需求等。

我们中的许多人(包括我本人在内)都以编程本身为主要思想,即在真空中(或至少在相对真空中)编码美观而精美的软件。很少有。可能有一些稀有的学术或R&D软件工作接近它,但是在大多数情况下,绝大多数软件开发工作并非如此。特别是在维护阶段(通常占产品寿命的90%以上),以及大多数永久性商业软件工作的日常工作。

长期以来,我对此感到内在冲突,这常常使我对自己的工作感到不满(这是去年最终导致职业倦怠的一部分)。我总是觉得,如果不只是创建漂亮的代码并花时间正确地完成工作,那么工作就很糟糕。但这确实是现实-有些人实际上非常注重面向服务的工作流程。这就是使他们感到务实和有用的原因。即使项目的实际“纯软件工程”方面相对匆忙而草率。

无论如何,现在您对此提出质疑是件好事。这是他们在学校从未真正正确解释过的事情之一。公司喜欢假装他们遵循非常好的工程实践,即使他们没有这样做。提示:大多数都不是。

综上所述,情况各有不同。某些公司(主要是那些以软件为核心业务的公司,以及那些使用对安全性要求很高的软件(例如医疗设备)的公司)确实遵循非常严格的工程流程。但是总的来说,是的,现在我要告诉您的是空白,因为大多数商业软件的工作都比较草率。通常会有一些正式的程序,但是严格遵守它几乎总是在对客户输入和其他商业压力做出反应时退居二线。本质上,这并不是真正的“草率”,而只是实用的用途。诀窍是找到自己的细分市场,并从其提供的服务的角度来考虑角色,而不是其“纯编程”方面有多酷。

编辑:我认为我在初步评估中听起来过于偏颇。我想补充一点,就是经常也存在一些真正的问题,即事情过于草率,缺乏良好的流程,以至于将项目推向技术债务,实际上对企业不利。但是看到这一点是有经验的。最初的观点基本上仍然成立:当今大多数商业软件的工作并不像纯粹主义者所希望的那样严格地面向工程。


好答案!明智的声明- “维护阶段-通常占产品寿命的90%以上,是大多数永久性商业软件工作的日常工作”。
Karthik Sreenivasan 2012年

2

多么好的问题!有时,您可以通过快速做出有价值的事情。在研究实验室中,情况通常是这样,我们越快了解到不了解的内容,我们的生活就会越好。您生产的软件仅用于回答问题。这是“扔掉代码”。不知道客户真正想要什么的初创公司也是如此。另外,第一次做某事时会很烂。阅读《神话人月》

有时候你可以通过做一个好事来创造有价值的东西。像Adobe Photoshop这样的收缩包装软件通常就是这种情况。这项研究已经在数年前完成,现在的问题是如何以不引入错误的方式添加客户所需的功能列表。这是体系结构,设计以及测试,测试,测试的问题。代码本身就是有价值的东西,而不是您从中学到的东西。

如果您对研究不满意(首先做某事,学习以前没人知道的新事物),请尝试使用收缩包装软件。实际上,在您这样的年龄,您应该尝试尽可能多的事情。去冒险!您将学到很多东西,从长远来看,您会变得更好。


1

我认为您在职业生涯的早期就已经注意到,在没有适当设计或测试的情况下快速做事往往会再次咬住您。您显然不喜欢这样,并且您有充分的理由不这样做。期望“匆忙解决问题”是荒谬的,特别是如果您在以后最初的解决方案不正确或不完整时必须重新访问它们时,尤其如此。只有完全理解问题,您才能提供解决方案,这需要时间和仔细的计划。

我对您的建议是让您的上司知道这会困扰您,并向他们建议一种更好的工作方式。如果他们不同意并希望您继续“匆忙”完成工作,我将开始在其他地方寻找工作。以不符合您自己的标准的方式行事是没有意义的,更不用说业界期望的软件开发质量标准了。


1

这是根据我的经验提出的建议,我今年20岁,目前正在英国一家大型金融机构工作,与您几个月前的感觉相同,我注意到这可能是由于您正在做的工作。

我的意思是说:

“我要做的是使用多种技术(主要是AWS / Java / Bash)创建一些内部工具”

我还必须创建内部工具来帮助管理和自动化某些流程,事实是,在快速发展的环境中,“小”的事情需要快速实施。我并没有奢侈地使用第二年学到的大多数软件工程或算法以及数据结构原理,因为在几周内需要使用该工具的工作版本,但对此我感到非常沮丧。并非全都是坏事,因为我确实学会了如何编写更好的可读性更好的代码。

我必须耐心等待,最近我转到了一个新团队,该团队正在研究10K +用户使用的内部构建系统的新版本,并且我可以向您保证,它将非常重视软件工程方面。有人告诉我,从需求捕获/分析一直到实施和测试,我将接触到整个软件生命周期。我相信我将获得这种经验,因为我不是在使用内部工具,而是在拥有大量用户的完整规模的系统上工作。

我建议您要有耐心,完成工具的编写并做得很好,以便您的主管对您有更多的信任,并为您分配更具挑战性的任务,这些任务需要使用软件工程原理。通过做一些额外的阅读来获得更多的知识,并将这些知识应用到您当前正在做的事情中,我记得我在公司里洗劫了整个电子书库,只是为了进一步扩大我的知识,从我阅读的所有书中我都觉得有效的Java是非常好的书,对我有很大帮助。

请耐心等待,对您自己的知识进行大量投资,并在可能的情况下应用该知识。如果您做得很好,很快就会有人注意到。


0

我同意您当前的工作方式不是很理想,是的。但是,如果您想说它根本不起作用,那么我会不同意您的看法,因为有各种各样的结果,而且该机构还在附近。

我要回答的主要问题是,您在多大程度上处理需要立即迅速解决的火灾(类似于为医护人员提供急救),而可以设置为项目并以与医护人员相似的不同规模处理的请求必须安排不必要的测试和各种程序,而这些操作和程序无需立即执行,而是在近期内完成。

花时间做好工作,在一定程度上取决于组织的成熟度,以及做好某件事而不是完成某件事的重要性。

研究数据结构的问题是要执行多长时间。如果您想花十年的时间来研究与需要几个小时完全不同的数据结构。虽然我能体会到获得最佳答案的渴望,但是在花一些时间解决问题后,还有一些可以说减少回报的方法,例如,您是否可以花数小时来寻找FizzBu​​zz的解决方案,因为您可以尝试以各种语言解决问题。各种硬件来优化其运行速度。

虽然研究很重要,但提供某些东西也很重要。如果您不交付东西,您真的有多好? 管道胶带编程器将是在此处完成工作的更多示例。

Scrum是一种特定的方法,您可以尝试在当前的工作场所采用。但是不要以为Scrum是灵丹妙药。 在什么情况下Scrum和敏捷项目会失败?可能是有关该主题的博客文章。

我的猜测是,您不会看到当前场所的流程有多非正式,而是认为在有正式方法论的另一端,草变得更加绿色。尽管那里可能会更好,但有些人可能更喜欢牛仔,而您现在拥有的自由。


0

我认为您的情况仍在现实世界范围内,而对质量方面的重视程度则有所降低。您的偏好位于现实世界的另一端。规格改变,克服它。事情需要完成。

在申请下一份工作时,请考虑识别这些公司类型的方法。很少有地方有商业模式可以负担得起,让开发人员永远分析他们的设计(甚至教授也要教)。如果您的工作没有离开干擦板,客户很少会付钱。讨厌看到你这么早就让自己发疯。


3
我想你误会了我。我深知需要在设计工作之间取得平衡的事实,但是当完全缺乏设计时,我相信这在现实世界中将没有价值。
泰勒·德登

您是否有机会重新设计问题以使其更清楚?有几个答案得出相同的结论。
JeffO 2011年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.