最被低估的编程工具


35

我们有许多很棒的工具,对程序设计有很大帮助,例如优秀的程序员,文本编辑器,IDE,调试器,版本控制系统等。其中一些工具或多或少是完成工作的“必备”工具(例如,编译器) 。

仍然总是有很多工具可以提供很多帮助,但仍然没有得到太多关注,例如由于各种原因,例如,当它们发布时,它们已经超前了,现在或多或少被遗忘了。

你觉得什么类型的编程工具是最被低估呢?激励你的答案。


3
我们的大脑?---
Trufa

好的,谁想要添加Lisp条目?*咧嘴*
马克C

Answers:


70

橡皮鸭。对真的。

http://en.wikipedia.org/wiki/Rubber_duck_debugging

橡皮鸭调试橡皮橡皮鸭测试是软件工程中使用的非正式术语,用于指代调试代码的方法。该名称是对一个可能的伪经故事的引用,在该故事中,一位未具名的专家程序员将橡皮鸭一直放在桌子旁,并强迫他自己逐行向鸭子解释,从而调试代码。

为了使用此过程,程序员会向无生命的对象(例如橡皮鸭)解释代码,并期望在到达一段不正确的代码并尝试解释它时,程序员会注意到该错误。在描述代码应该执行的操作并观察其实际执行的操作时,这两者之间的任何不一致都变得很明显……


6
我一直和丈夫在一起。作为仅具有少量编程能力的技术支持人员,他了解我所说的内容的60%,但迫使我解释我也不了解的40%。它起作用的次数确实非常可观。
Ethel Evans

1
你笑。我有一个同事,实际上她的桌子上有一只橡皮鸭。
Berin Loritsch 2011年

57
我尝试过,但是我的橡皮鸭似乎无法集中精力解决这个问题。在哪里可以找到对编程真正感兴趣的合格鸭嘴?
Steve314 2011年

3
我为此使用日记。有时我和我自己进行了很长时间的讨论。我希望有时能让自己明白我的意思。后来,当我想知道编写我正在编写的代码的白痴在想什么时,将其写入日记有时会很有帮助。
Lars Wirzenius

1
:@Steve:日本研究人员正在研究它,但我不认为他们是望其项背youtube.com/watch?v=3g-yrjh58ms
丽宫坂

42

笔和笔记本。

  1. 不用电即可工作。
  2. 随身携带。
  3. 在会议中无聊时涂鸦
  4. 存储有用的信息。
  5. 如果将其写下来,人们将更加重视它。
  6. 其他人可以阅读并学习。

在大公司的过去,工程师和技术人员会得到空白的工程笔记本,他们可以将所有我们倾向于填充的东西写到硬盘上的各种文件中。笔记本装满后,它们将被发送到安全且防火的存储库中。如果有人需要访问这些笔记,他们可以签出笔记本。
oosterwal

3
俄国人用铅笔。
工作

@Job Hah,我还是用一瓶墨水!(...嗯,仅适用于书法,但仍然适用。:))
Mateen Ulhaq 2011年

平板电脑呢?
Mateen Ulhaq 2011年

1
@Job:…还有伏特加!
Spoike

38

比较平面文本文件中的日志输出或数据时,似乎未充分使用Diff工具。也许那只是一个利基?我似乎发现它对于调试比较程序执行的大量日志并查明已更改的一两个细节非常有用且很有帮助。

性能分析工具也非常有用,尤其是当您遇到严重的僵局时,但是似乎很少有人对此感到熟悉(我承认自己在这个类别中有一定的学历)。

好的XML工具至关重要-如果您使用的XML文件有十几行或多行模式。有时,您不仅需要突出显示其他编辑器提供的基本语法。同样,在使用XML时,学习XSL可能非常有用。很多次,我看到在应用程序代码的多行中完成的简单XSL转换中可以完成的工作。尽管要澄清一下:我并不是XML本身是一个“被低估的编程工具”。我建议,根据我所看到的,好的XML编辑器的价值被低估了。


1
++绝对diff未被重视。关于概要分析,并不是只有您一个人认为它们必须有用,但是您自己却不知道如何使用。检查一下。
Mike Dunlavey

是的,我曾经考虑过要实际学习配置文件工具,但从未做到这一点
Anto

23
+1用于性能分析,+ 1用于差异工具,-1用于XML工具。有些人在遇到问题时会想到“我知道,我将使用XML”。<Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription></ProblemWorsening>
梅森惠勒

2
@梅森:可爱的XML。
Mike Dunlavey

10
@Mason Wheeler:我不建议将XML 作为解决问题工具,而是建议使用好的XML工具 -当您必须使用XML时,请确保您拥有非常擅长的编辑器/工具。可以执行Xpath查询,模式验证,转换,值与结构比较(我猜是一种特殊的diff工具)等功能的东西……具有突出显示的简单编辑器在事情变得混乱时就无法将其剪切掉-它们经常使事情变得简单更糟糕的是(我喜欢您的XML代码;))。
FrustratedWithFormsDesigner

37

常用表达

它们是如此有用。它们在搜索日志文件,解析文本等时会有所帮助。它们非常有用。

我感到奇怪的是,我知道有多少人从未使用过它们,因为与它们相关的学习曲线有些许。很多时候,我看到人们用一个简单的正则表达式就可以迅速解决问题时,人们会用困难的方式做事(注:在regex之前我就用困难的方式做事)。


8
请记住,即使正确使用正则表达式,它也不是瑞士军刀。
安托

10
极其有用-但经常被滥用,导致代码难以维护。古老的“现在有两个问题”这句话在现实中确实有一定依据。
Steve314 2011年

4
RegExes是瑞士的一把军刀:虽然可能不是建造整栋房屋的正确工具,但它是许多快速工作的合适工具。
JasonTrue 2011年

4
嗯,出于某种原因,我总是对正则表达式印象深刻。我经常看到人们寻求一个正则表达式,而简单的split / for循环就足够了,或者正则表达式根本不能解决问题(例如,解析xml / html)。
MAK

我见过两种现象:正则表达式?这些东西在这里是不可读/缓慢/插入贬义的,“用一个正则表达式解析(插入完全非正则语法)的最佳方法是什么?”
JasonTrue 2011年

24

您的队友。当您没有某个热门话题而忘了组建团队时,您将永远不会听到他们的担忧或想法,因为它为什么行不通或为什么会变得更好。

我之所以这样说,是因为人们很容易认为编程是一些反社会的事情,人们以其绝妙的想法而放弃了。认为这一点的人低估了团队及其队友在帮助使想法/项目沉入/畅游中的价值。


优秀的队友永远都不会被高估。大多数软件和硬件都可以。
匿名类型

19

谷歌。很少有尚未解决和记录的问题。精心调整的Google查询可以为每个人节省很多时间。


13
一个很好的工具,但是我不确定是否会低估它,至少现在不会了(也许我会在9或10年前就同意了)。
FrustratedWithFormsDesigner

12
对不起,但是Google低估了吗?至少Google被高估了:)
eestein 2011年

2
我知道我知道!但是,我认为这是被低估的理由是,我怀疑您会同意这一点:至少有75%的StackOverflow提出的问题很容易由Google回答,是吗?显然,如果很多人不使用它,一定程度上被低估了。如果我的理由有误,我将删除答案。
亚当·克罗斯兰

3
@亚当·克罗斯兰(Adam Crossland):75%的人很友善。我认为它比那更高。
S.Lott

1
@adam @ s.lott,所以我想关键是Google使用不正确。我同意。如果人们知道如何正确使用Google,那么可以回答很多问题(不需要问)。问候。
eestein 2011年

16

在调试器中,查找“瓶颈”最不为人知的工具是Ctrl+ C或“暂停”按钮。

检查的最后一段这篇文章,和这个职位,而这个职位,对于初学者。

我经常听到/听到有人说“程序太慢了!我该怎么办?我尝试了探查器(如果他们这样做了),但我听不懂它的意思。有人猜到了吗?帮助! ” 好吧,猜测仅仅是这样。我一直做着的,其他人也做了,就是去做,打断它,并检查调用堆栈。如果问题真的很严重,那么bingo就在您的面前。如果问题只是轻微的,请重复几次。您可以避免的一个以上示例中出现的任何问题都是可以解决的瓶颈。

是的,这是诱饵,但可以。


一个人不应该低估钝器。显然,这并不总是正确的答案,但是可以。称其为一阶近似值,如果需要,可以由真实的探查器进行细化。
克里斯托夫·普罗沃斯特

@Kristof:这么想很诱人,并且存在无法解决的问题,并且在某些情况下样本不容易获取,但探查器也无法处理这些情况,除了某种类型(例如Zoom) ,即使这样,从引导您正确解决问题的角度来看,它们实际上也并不好。
Mike Dunlavey

@Kristof:这是随机暂停不擅长的问题-如果您及时拍摄快照并进行研究,您将无法确定其原因。例如:消息驱动的处理,您无法分辨消息的发送来源,原因或发送频率。另一个例子:异步协议,正在交换消息,似乎我们一直在等待另一个人。对于同步处理,分析器可能会更好地进行测量,但是随机暂停会更易于发现
Mike Dunlavey

14

您认为哪种编程工具是最被低估的?激励你的答案。

编译器。

大多数人不花时间去了解他们选择的编译器的功能。他们只是觉得这使代码成为一个可运行的程序,这是他们所能做到的。在大多数现代配置中,您可以将几种配置添加到其中,以使其按需完成。这是一个示例,我敢打赌,您办公室中的一半开发人员都不知道如何将警告设置为错误级别(假设警告实际上有一个)。您必须输出输出调试符号的哪些选项?您希望它进行哪些优化(或优化的级别)。清单继续。


3
@Kevin:并且我将添加编写代码的方法,以使编译器实际为您执行检查(对于静态类型的语言)。大多数开发人员使用现成的类型(例如字符串)来表示任何类型的信息,他们可以在其中为不相关的数据定义简单但不兼容的类型...并使编译器在传递参数时不会弄乱。
Matthieu M.

@Matthieu M这也是一个好点。许多人忘记了它可以帮助您的简单方法。
kemiller2002 2011年

3
每个编译器警告都是宝贵的礼物。不要忽略他们!要求更多!-错误应该是强制性的。
克里斯托弗·普罗沃斯特

@Kristof:-pedantic -Wall -Wextra -Werror...虽然可能很难构建任何东西,然后:p
Matthieu M.

也许这只是我,但如果“的开发者的一半”不知道是关于调试符号”什么也不为过,这是相当艰巨的。
kizzx2

10

你的脑。没有它,其他工具将没有太多意义。


4
我有时使我的大部分时间都无法使用。
David Thornley

3
“或多或少被遗忘”:-S

5
我会说它被低估了。太多的人总是在寻找捷径,以至于他们不需要思考。常识和逻辑无法替代,而工具也无法替代。
jnevelson 2011年

2
我同意乔纳森(Jonathan)的观点,大脑经常被低估。实际上,太多的程序员依赖于他们所知道的一些技巧,而不是走出困境,偶尔编写定制的(便宜又脏的,扔掉类的)测试用例和测试工具来研究当前的问题。在很多情况下,我都给开发人员提供了超越他们的思维状态并解决他们所遇到的问题的方法。
2011年

1
一些评论使我改变了看法,+ 1 :)
Anto

10

好老:

print

有时,调试器或探查器或UML流程图很有用。有时它们会让您发疯。我总是发现自己不愿意使用打印语句(或trace或NSLog或您拥有什么),只是为了确保我的代码在做自己想做的事情。


我认为这取决于语言和调试器。当今大多数流行的IDE为流行语言提供的调试器种类,使您做事比打印语句容易得多。
Billy ONeal

8

普通的旧脚本 ...无论我们开发多少种下一代语言,我们仍然严重依赖脚本,而且大多数日常任务都可以通过编写几行脚本来完成。


1
看..我不同意这一点。是的,脚本可以自动执行某些任务。但是,通常它们被带到了某种意义上,甚至远不止于成为意大利面条的一大派。
Billy ONeal

1
的确,大型脚本看起来很可怕,并且可能会使用perl或python。尽管他们仍然擅长完成小工作。
Gaurav Sehgal

@Billy使用python。意大利面条问题已解决:)
Evan Plaice



5

Perl和其他脚本语言。对于像Agent Ransack这样的GUI工具来说有点太复杂的任务非常适合。


1
我不确定他们是否被低估了……
安托

3
绝对被低估了……尤其是Perl。这是一个郎。保持简单的座右铭设计得非常好...这样,对于只需要完成的快速任务来说,它是无价的。
Rook

@Rook:我不确定具有100个以上运算符的语言如何被视为“简单”语言。可能有用。但不是“简单”。
Billy ONeal

@Billy-简单并不排除功能强大。我发现计算器很简单。我不知道我的300个函数中有一半是做什么的,但这并没有降低其简单性。
Rook

4

键盘快捷键,可快速,频繁且安全地进行重构。通过按一些键来学习如何提取(或内联等)变量,方法,常量或类,从根本上改变了我的编码方式。您只会在成本最小的情况下频繁(即足够)进行重构,因此就我而言,使这些快捷方式具有第二性对于编写和维护良好的代码至关重要。

因此,通常,使用好的工具(IDE /编辑器)并学习如何充分利用它们提供的功能。

接下来是单元测试和TDD,以保持您的代码可测试并避免担心重构。

使用这些内容,您将轻松地编写符合DRY原理并且具有自我记录能力的正确可维护代码。


4

单元测试具有以下优点:

  • 开发人员成为代码的第一个客户。发现漏洞的速度越快,修复它的成本就越低。在构建,安装或部署之前,可能会发现错误。
  • 测试改变了您对代码的看法。设计清晰吗?它可以处理极端情况吗?
  • 霍桑效应可以通过简单地宣布团队正在发布质量/测试指标来提高质量。
  • 即使未将测试检查到源代码管理中,它们也可能是探索和学习新地形的好方法。
  • 减少错误的可能性很高!

4

代码生成器

代码生成器可以通过简单的定义创建大量高效且无错误的代码。对于创建数据访问类,ORM类型的使用最为明显,但是还有更多的潜在用途。

从程序员和框架的角度来看,代码生成支持似乎仍处于起步阶段,但是我相信我们会越来越多地看到它。在.NET中,您可以开始涉猎CodeDOM


我喜欢编写代码生成器,不是最简单的方法,但是它是如此有用。
Zachary K

3

我大量使用AgentRansack。这是非常有用的帮助,可以快速搜索成千上万个文件。它为我节省了很多时间,但是我不了解很多了解或使用它的程序员。


3

正式方法。

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

很难夸大其重要性。每个循环和每个if语句都以需要某种“证明”的想法开始。大多数程序员大部分时间都是在脑海里做这种证明。您问if语句做什么,并且它们可以(从逻辑上和逻辑上)阐明选择是什么,以及为什么选择是完整,一致和排他的。

但是有些似乎只是随机猜测。他们需要更多帮助,而正规方法可能是他们需要的那种帮助。

它只是代码的代数(和微积分)。没有什么太复杂或复杂的。


我发现它们经常对正确使用简单的东西有用,因此我可以在调试更复杂的东西时依靠它。我的经验是,形式化方法很好地消除了细微的错误,只留下了显而易见的明显易于被测试捕获的错误。
David Thornley

3

物理设计模式(例如,离开椅子在阳光和新鲜空气中快速慢跑)使我们的大脑处于极佳的状态。


3

好吧,这是《半条命2》(在这里插入您喜欢的游戏)。如果遇到问题,我无法解决,我就退出并开始玩自己喜欢的游戏,然后突然想到了解决方案。因此,说实话,这不是游戏或类似的事情,而是其他的事情。我经常看到人们在一个问题上坐了几个小时而没有解决它,而他们所要做的就是让大脑在短时间内脱机。


3

堆栈溢出 -卡住时快速提供专家帮助

专业和发烧友程序员的问答网站。它是由您构建和运行的,是Q&A站点的Stack Exchange网络的一部分。在您的帮助下,我们将共同努力,为有关编程的每个问题建立详细的答案库...


+1,但现在并没有被低估
MAK

4
甚至可能被高估了,或者至少被过度使用了
Anto

3

我认为它是记事本 / TextPad /简单文本编辑程序。每个人都有时间需要快速修复,而无需打开IDE,而只需快速编辑。而且所有计算机都有某种简单的文本编辑程序。


2

断言和良好的alwaysAssert()功能。恕我直言,这些比单元测试更重要,因为单元测试只能在您认为要测试的特定情况下找到错误。如果同一位程序员编写代码和测试,则他/她可能会错过这两种情况。此外,有时单元测试是不切实际的,因为组件功能和/或其上运行的数据所处的环境太复杂而无法提出人为的测试用例。

断言的美丽之处在于它们能够记录假设并在非人为的输入上对其进行测试。如果这些假设中的任何一个错误,您的代码都会大声失败,而不是“有效”,但会产生不正确的结果。与没有断言相比,它更接近问题的根源。实际上,如果您明确声明了一段代码的假设,而所有这些假设都是正确的,则该代码通常是正确的。

关于断言的一个常见抱怨是可以将其关闭。恕我直言,每种语言或标准库都应具有与该alwaysAssert()功能相同的功能或大致等效的功能,assert但不能将其关闭。这可用于检查非性能关键代码区域中的假设,在这些区域中,关闭断言的好处可忽略不计。


同意 但是不幸的是,像这样的简单但有效的工具常常未被重视。
Peter Mortensen 2014年

2

F1键。-对于您不知道的程序和正在使用的程序很有用。(假设它是一个大型应用程序。)

用户可以根据对软件应如何工作的解释来报告错误,从而有力地过滤出问题。当然,这可能是设计本身存在缺陷。但这是另一个故事。


2
既低估又未实现。
匿名类型,

您正在使用的应用程序的开发人员非常低估了它;因此,帮助中包含的信息很少甚至没有。

2

各种UNIX核心实用程序,但主要find(偶尔)greped。在文件的深层嵌套中查找内容的能力非常宝贵,尤其是当您突然继承代码库并必须对其进行修复时。即使上述代码有据可查,您也可能不得不搜寻,并且find对它的深入了解会杀死它。


2

好奇心

称之为“编程之谜”。与使用工具的人相比,什么是工具?知道某事如何以及为什么起作用或不起作用的渴望比任何特定工具都扩展了自己的知识,这超出了编程的范围。



1

尾巴

尾部可用于实时监视程序日志输出文件。在为不提供其他方式读取日志的系统进行开发时,它提供了很大的帮助。

示例程序是;


Mac OS X是UNIX系统。无需单独提及。
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.