每个程序员应该知道什么?


245

无论使用哪种编程语言或操作系统,或使用何种操作系统开发,每个程序员都应该知道什么?

一些背景:

我有兴趣成为最好的程序员。作为此过程的一部分,我试图了解我不知道的内容,如果这样做的话,我会受益匪浅。尽管有很多列表围绕着“每个[插入编程语言]开发人员都应该知道的n件事”,但我还没有找到类似的东西,但不仅限于特定的语言。

我也希望这些信息对其他人有好处并从中受益。

Answers:


636

如何在不亲自面对的情况下吞并骄傲和承认错误。


60
这是每个人不论其工作(性别,宗教,文化,社会地位...)都应该做的事情,您不认为吗?;)

3
哦是的 但是我们程序员(至少我是这样)倾向于比大多数人拥有更多公开的骄傲:-)

17
我希望我能两次投票赞成你。

4
我认为这是我在大学中学到的一件事。在高中时,我一直是聪明的孩子之一。如果我不上大学,我会以为我很聪明,并且有很大的自我。去大学学习,和真正熟练的人互动,我得到了帮助,让我看到自己是多么愚蠢
Kibbee

4
尽管这确实是事实,但问题并不总是否认或自负,而是公开承认犯错误的潜在后果,至少不是没有先进行某种自我防御/破坏控制的情况。有时,这是一种文化上的事情。:)

309

如何像用户一样思考,而不像技术怪胎程序员那样思考。


2
我总是觉得具有讽刺意味的是,业内大多数人似乎缺少的东西可能是最重要的技能之一:沟通技巧。

无法同意这一点。这应该是#1。

23
我实际上不同意。那就是你雇用人的目的。您将永远无法像用户一样思考,但是您肯定可以让人们告诉您用户对建议的看法并采取行动。只是不要问用户他们的想法!那是最糟糕的选择。

1
您可以雇用其他人来做到这一点,但是如果您的开发团队可以理解用户的想法,那么在正确之前,您将拥有更少的参数和迭代。另外,如果开发人员可以像用户一样思考,谁知道他们会想到什么新功能

3
用户很可能是一名极客程序员,但也不太可能是同时实现了代码的极客程序员。如果应用程序具有非常微妙和复杂的语义/行为,那么编写代码的人可能是唯一可以理解如何使用应用程序的人……
Reuben

244

什么时候寻求帮助,什么时候不寻求帮助。


2
如此真实。最近,当我问某人时,答案突然浮现在我的脑海。:(
kevindaub

所以,答案是什么?)

28
先问你的橡皮鸭。如果他不能帮助您,请问其他人...
Dean Rather

3
之所以投票,是因为当我刚开始时,我一直不停地问他们一些简单的东西,却没有意识到自己让其他开发人员感到烦恼,我应该弄清楚自己,直到我得到一些帮助。

1
我总是问自己一个问题:“如果我要问他们,我的同事会怎么说?”。通常,这可以帮助我进一步解决问题,然后才真正提出问题。

184

如何阅读别人的代码。


102
附录:如何编写其他人可以阅读的代码

42
附录2:六个月后如何阅读自己的代码

10
@Nathan Koop:最好是“如何编写代码,以便六个月后可以自己阅读”。
布朗

4
六个月后,它已经成为别人的代码了。从某种意义上说,您已经发展了,变得更好了,并且它可能也应该是其他人一开始编写的,因此应这样对待。
MPelletier 2010年

7
附录3:6分钟后如何阅读代码。
mpen

152

熟悉版本控制系统。它不一定是每个,但是应该知道可应用于所有这些概念的基本概念。


那个版本控制不是软件
jrhicks

4
我还要补充说,集中式SCM(例如,subversion,CVS)和分布式SCM(例如,git,mercurial,义卖市场)之间存在足够大的区别,因此学习其中的每一个很重要。
直觉

128

这是我的10位:

  • 如何谦虚。我们都在这里学习。您可能比其他人更聪明,但是很多人都比您聪明。
  • 如何学习/消费信息。我不认识你,但我会永远学习!书籍,互联网等等!
  • 什么是词典,如何使用词典,以及如何快速找到首字母缩写词。
  • 交易的基本工具是什么以及它们的作用(IDE,CVS等)。
  • 了解通用术语及其含义:设计模式,可用性,测试(ha!),堆栈等。
  • 了解OOP。
  • 具有至少一种语言的“能力”,没有什么惊奇的,只知道如何识别变量和方法等。从这里您可以学习FAST。
  • 了解人们最终会使用软件并希望使他们感到高兴。

38
这必须是八进制帖子。
甚至Mien

10
关于第一点……。“不要那么谦虚,你不是那么好”。
Magnus

@TheOtherScott,很好听,但我实际上是在说2位:D;)

3
关于要点3:www.acronymfinder.com
贾斯珀·贝克斯

1
@ jasper / intuited:只需在Google中键入首字母缩写词,它就会拉一个或另一个……答案通常还是在前10个结果之一中。点击获取更多信息!
mpen

104

也许它太微妙了,但我认为它是“知道要解决的问题 ”。很多程序员(和普通人)都花了很大的精力来解决根本不是很重要的事情。或者他们创建了一个解决方案,需要大量额外的工作,而这并不是完全需要的。


4
达成共识,担心只有少数用户会遇到而不是更多核心功能的附带用例,这是一个太常见的陷阱!我仍然很难学习这一点……
伊恩·罗宾逊

我应该在前任队长的主页上链接到您的答案。你是对的。

4
我爱你说“很多程序员(和普通人)” :-)

95

如何放松。这是生产力的秘诀。

最终,意志力和咖啡因还不够。我们的这种持续收缩非常有害。

这是一个大问题。


1
收缩是什么意思?

4
@Egg:有时候,当我工作时,我会变得完全放松,非常有生产力。在我糟糕的日子里,我使用肾上腺素和咖啡因,身体感觉非常紧张。如果我密切注意,我实际上会收缩一些肌肉。我一直在别人身上发现这种紧张感。不幸的是,它可能导致诸如倦怠和心脏病之类的各种问题,并且还可能导致生产力的净损失,因为它只能在有限的时间内冲刺。那就是我在说的收缩。
Brian MacKay 2010年

@Egg,他的意思是未使用的肌肉收缩。

2
说到咖啡和收缩,您是否知道咖啡会收缩向大脑供血的动脉。那会使大脑醒来。毕竟咖啡不是一件好事。tl; dr饮用水
Reno

83

基本数据类型和算法理论。诸如Big O符号,数组,队列等之类的东西。


如果您所做的只是为Web内容管理系统设计模板,那么对您完全没有帮助。

3
好了,现在标准算法在库/框架实现,但我同意有些硬算法样的想法是有用的,但不是很经常

7
仅仅因为它们已经被实现并不意味着您不必了解何时使用什么,复杂性保证等。这是算法背后的重要内容。

3
与格雷格·罗杰斯(Greg Rogers)达成协议。您可能需要实现算法,但是您可以更好地了解它们的复杂性和权衡。例如。一些算法占用更多内存,但速度更快。

6
如果您不了解它们,则不会知道要使用哪个。算法非常重要。

60

如何为正确的任务选择合适的工具,而不是参加有关他最喜欢的编程工具的傻瓜大战。


+1,以使该位不停留在42 :)
CharlesB 2010年

54

好吧,这是我的.02 $:

  • 学习永无止境。不管您认为自己有多好,总会有比您更好的人,而且总有您可以改善自己的地方。如果停止学习,您将不可避免地沦为程序员。看书。阅读博客。与其他程序员交谈。
  • 尝试学习几种语言。其中至少有一个是面向对象的。另外,您应该了解与所学语言有关的各种技术(例如,如果您学习Java,那么如果您对Spring有所了解,那将是很好的,依此类推。)。
  • 重构。迟早您将需要这些知识。
  • 了解如何处理遗留代码。
  • 编写单元测试。了解TDD。
  • 学习团队合作。
  • 编写优雅且易读的代码。俗话说:“编写您的代码,就像要维护它的人是知道您的住所的精神病连环杀手。”
  • 了解如何同时懒惰和纪律。优秀的程序员同时具备这两种素质。看起来很奇怪,它们彼此并不矛盾,而是互补的。

那是您的.02美元或.02美分?大声笑!:-D

“编写您的代码,好像要维护它的人是知道您的住所的精神病连环杀手。” +1

50

您无法测试产品的质量。


2
因此,“质量保证”专业人员的名称错误。

1
从技术上讲,质量检查和测试不是一回事,尽管就您的观点而言,我不确定大多数组织是否实际实践了差异。
高杰夫

5
最近遇到-并坚持认为:“测试的结果不是质量,而是知识”。
peterchen'4

richdiet:SQA专家James Bach认为SQA / QA中的“ A”应代表“协助”。我非常同意他的意见和你的发言。

44

每个程序员都应该了解设计模式


13
我还要补充一点,他们还需要了解并非并非所有事情都可以变成给定的设计模式。
tloach

10
我还要补充一点,并不是每个程序员都应该了解设计模式。遥远的地方有语言,它们的其他功能是如此强大,以至于思想直接从程序员那里流到工作程序中。在这些语言中,故意的模式是一种误导。
阿里

2
设计模式是针对设计者而非“程序员”的-程序员将需要知道,当他/她成为“设计师”时

10
有两种类型的人..喜欢编码的人和喜欢谈论编码的人。设计模式是第二组必须..
比约恩Reppen

1
这种模式是克服语言限制的一种方式。程序员应该理解它们仅仅是因为他应该理解并能够克服其语言的弱点。

44

我对此有些迟,但是我将继续使用Edsger Dijkstra的知识:

除了数学上的偏爱之外,对母语的掌握也非常出色,这是一名合格的程序员的最重要资产。

如果您不能写出好的段落,则很可能您也不会写出好的代码。


8
但是,我对某些程序员在自然语言编写中使用的可怕的拼写,语法和标点感到惊讶。您会认为每天使用对拼写错误和无效语法具有零容忍度的系统都会产生有益的影响……

1
@cheduardo,这是因为在大多数语言中,一旦编译或运行程序,就会告诉您所有拼写,语法或标点错误,然后可以轻松地对其进行更正。逻辑错误不是这样。
Inshallah,2009年

@Inshallah:除非您做类似的事情if (BlowUpTheSystem = 1)。当然,给定适当的单元测试,您可能仅节省时间。但是时间很重要。
直觉

2
同意..嗯...减去“母语”部分,我们中的某些人(不幸地是?)使用我们的非母语进行的交流更好/更清晰。

39

对于任何给定的技术,操作系统或语言,不要过于情绪化地归属,痴迷或虔诚-都不是完美的-从长远来看,您可能最终希望自己可以根据自己的想法创建自己的菜谱像每个不同的人一样

可以将其视为汽车-您以前可能没有驾驶过特定的汽车,但是它们都具有钥匙,方向盘,油门和制动器-一旦您弄清了什么地方,就应该能够融入其中并迅速开车。像对待操作系统和语言一样对待它们,并着重于学习它们背后的基本概念,即使您处于任何给定实例的细节之中。

随着时间的流逝,尝试理解和欣赏各种技术的血统,传承和共性,这将有助于您保持洞察力。例如,请意识到,尽管进化树正在活跃地分支并且充满了死胡同,但随着时间的流逝,技术趋向于反复地围绕“最佳实践”和“规模经济”进行融合(例如,注意Mac与Mac并没有什么不同)这些天在机子下的PC ...)。

最后,请记住,无论您对这一切有多开心,技术本质上都代表着您的思维可以想象到实际生产之间的不完美镜头。尽力,学会学习并保持适应能力...



35

停止学习的那一天应该成为不再是程序员的那一天。


如果我有一个愿望,那就是圣诞老人是我的父亲。

因为圣诞老人...?

1
停止学习的日子应该是死亡的日子。:)无论如何+1
ShdNx

因此,要永远生活,您必须始终学习吗?现在有一个我可以支持的想法!
canadiancreed

34

单元测试和调试。


第一个消除了对第二个的需要。;-)

4
否,当单元测试失败时,需要调试。两者在一起。
Zan Lynx

压力不够大。
fastcodejava

33

之前已经提到过,但是我认为这应该是自己的答案。


我越来越多地使用它,我在这里和那里捡拾东西,但我仍然不是业余爱好者。

我完全同意。当您不理解它时,它看起来很奇怪且很困难,但是当您理解它时,它比一吨子字符串/ indexof函数调用要容易得多,否则将需要执行相同的操作。我将确保您的模式得到很好的注释。
Kibbee

9
有些人遇到问题时会认为“我知道,我会使用正则表达式”。现在他们有两个问题。-“ Jamie Zawinski”:jwz.livejournal.com,在comp.lang.emacs中
Bjorn Reppen

使用基本上围绕它们构建的编辑器是学习讨厌的坚韧不拔的好方法。我的经验是vim(它使用了与事实上的标准PCRE几乎可比的等同物),但是我给人的印象是,同样的规则适用于emacs世界。
直觉

1
有些人面对正则表达式时会想:“我知道,我会引用杰米·扎温斯基。”现在,他们有两个问题(其中一个是他们可能一开始就不知道自己在做什么) 。
Donal Fellows 2010年

29

没有人想要使用软件。他们想解决问题。


7
究竟。当我听到开发人员试图向最终用户解释数据库,以回答他们为什么无法完成某件事时,我感到非常恐惧。他们不需要知道我们怎么做。他们只是想要它工作。这就是应该的方式。
凯文·费尔柴尔德

我喜欢相信人们可以编写使用乐趣的软件。

完全同意。但是,这也适用于API。没有人想学习新的API,因为它真是太好笑了。我们需要API的功能,而不是它代表的代码。
Blub 2010年

凯文(Kevin),我希望我们的“实现程序员”(为测试人员写个名词)会读懂。我也坐在办公桌后面,希望当他开始谈论循环和最终用户的if语句时,世界将吞噬他。

27

Coffee和IntelliSense是您最好的朋友。


希望我能给我超过1票赞成!
黛娜

我希望多喝咖啡!!!ñ_ñ–

我想我比其他任何事情都同意这一点。
Unkwntech

我几乎从不喝咖啡,除非我绝对需要在X个小时内完成一个项目,这是:一天的用完小时数+ X> 8。
Blub 2010年

咖啡不会给您任何能量。它只是从您的内部储备中挤出了一部分。不好/不健康。
Andrei Rinea


18

永远不要信任用户(特别是如果应用是公开的!),他们通常会尽其所能来破坏您的应用。

使它面向未来并可扩展–您永远都不知道要在几年后何时对其进行扩展,并意识到重新编码不良创建的代码将花费多少精力。


1
这太笼统了。一些实用主义也是很好的。
mafu 2010年

18

程序员不是一无所知,应该始终尝试学习新的语言/技术等。


16

良好的UI设计和沟通(即图形)设计的基础

我看到如此多的应用程序和项目被不良的设计或易用性破坏了。只需学习基础知识,就可以改变世界。加上视觉问题解决技术(即,如何在视觉上传达概念)是一个刺激性的挑战,应使您对新的观察方式睁开眼睛,这反过来又会对代码产生影响。

推荐的书是罗宾·威廉姆斯(Robin Williams)的《非设计师的设计书》

这是Joel Spolsky所说的

哇!每个人都必须进行一些图形设计,并非每个软件团队都拥有专业设计师。这本出色的薄书将带您了解页面布局,字体等的基本原理。好消息是,您可以在水变冷之前在浴中阅读它,第二天,可以看到对话框,PowerPoint和网页将开始看起来更好。


1
其次,我还要对“日常用品的设计”表示感谢。 amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746
Stimul8d

14

每个程序员都应该知道如何快速学习。很多时候,您开始工作,并会被要求开发从未使用过的技术。在要求您编写生产质量的代码之前,他们可能会给您一个星期左右的时间(如果您很幸运的话)。


我开始了我的第一个编程工作,并在一周之内编写了最终可以上线的代码。幸运的是我是一个快速学习者,并且拥有过编程经验。在6个月内,我重组了客户端与服务器的连接,以将性能提高了三倍。这是我以前从未使用过的语言。

14

版本控制。并引用我的女朋友的话:“我不仅要你洗碗,我要你喜欢!”



10

从我的头顶上:

  1. 除了加,减,乘,除运算法则,很少有编程问题需要数学运算。如果您想使用微积分解决问题,请在进行此操作之前详尽研究替代方案。

  2. 每当您发现自己在猜测某事应该如何工作时,您就在做错事情。心灵感应不是你的工作。

  3. 给您规格的人很少了解他想要的一切,直到您将其散列出来。

  4. 成为优秀程序员的一半以上来自与人打交道。与您的团队互动,管理您的经理以及对最终用户进行罚款是工作的一半。

  5. 编写好的代码可以被人们阅读,也可以被编译器阅读。

  6. 最佳实践和实践现实之间的冲突比程序员想的要多,但比经理想的要少。当他们看起来有冲突时,由您来描述和理解冲突,然后屈服于实践。如果从长远来看它更具成本效益,那么微妙而巧妙的解决方案仅比丑陋,残酷的解决方案更好。

  7. 好的工具不能造就出优秀的程序员,但是坏的工具会让我们同样糟糕。

  8. 永远不要轻视一项技术,而总会寻找最佳的选择。

  9. 您知道的语言越多,使用的语言就会越好。

  10. 不要被面向编程的思想慢慢渗透到您的日常生活中。即使我们不在计算机旁,我们也会遭受带宽限制,任务切换会降低性能,并需要从备份存储中加载内容。计算机应该模仿人类的思想,类似物无处不在。


10号让我发笑。很多次我会在工作中处理问题,但直到晚上10点才躺在床上,我最终想出了答案!

9

阅读别人的代码不会破坏您的大脑,而是弄清楚为什么您不会那样做(如果更好或不是,这是另一个问题)。

这使您可以编程gedankenexperiment,有时您会发现有人实现了更好的方法!喜欢方式更好。

该答案自然扩展为阅读您自己的代码,因此扩展为使用版本控制和DIFF,因此扩展为42。

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.