Jon*_*eet 363 language-agnostic
这绝对是主观的,但我想尽量避免它变得有争议.我认为如果人们适当地对待它可能是一个有趣的问题.
对这个问题的想法来自评论跟帖从我的回答到:"你恨你喜欢的语言什么的五件事？" 问题.我争辩说C#中的类应该默认密封 - 我不会把我的推理放在这个问题上,但我可以写一个更全面的解释作为这个问题的答案.我对评论中讨论的热度感到惊讶(目前有25条评论).
那么,你持有什么有争议的意见？我宁愿避免那种以相对较少的基础(例如括号放置)而变得非常宗教的东西,但是例子可能包括诸如"单元测试实际上并不十分有用"或"公共领域真的很好"之类的东西.重要的是(对我来说,无论如何)是你有理由支持你的意见.
请提出您的意见和推理 - 我鼓励人们投票支持有争议和有趣的意见,无论您是否恰好同意这些意见.
rus*_*elf 875
那些没有在业余时间进行编码以获得乐趣的程序员将永远不会那样做.
我认为即使是最聪明,最有才华的人也永远不会成为真正优秀的程序员,除非他们把它当作一项工作.这意味着他们在一边做了很少的项目,或者只是在业余时间搞乱了很多不同的语言和想法.
(注意:我不是说优秀的程序员除了编程之外什么也不做,但他们做的不仅仅是编程从9到5)
Ste*_*ins 769
你应该一直使用的唯一"最佳实践"是"使用你的大脑".
太多的人跳过太多的乐队,并试图将方法,模式,框架等强加给那些不能保证的东西.只是因为某些东西是新的,或者因为有人尊重有意见,并不意味着它适合所有人:)
编辑:只是为了澄清 - 我不认为人们应该忽视最佳实践,有价值的意见等.只是人们不应该盲目地跳过一些东西而不考虑为什么这个"东西"是如此伟大,是否适用于我这样做,它带来了什么好处/缺点？
Gen*_*rts 711
"谷歌搜索"是可以的!
是的,我知道它冒犯了一些人,他们多年的紧张记忆和/或光荣的编程书籍开始落入任何人都可以在几秒钟内访问的资源,但你不应该坚持反对人使用它.
我经常听到谷歌搜索批评问题的答案,而且它实在没有意义.首先,必须承认每个人都需要参考材料.你不知道所有事情,你需要重新审视.承认这一点,您获取信息的地方真的很重要吗？如果你在一本书中查找它,在谷歌上查找它,或者从一只说话的青蛙那里听到它你是否幻觉,这是否重要？不是.正确的答案是正确的答案.
重要的是您了解材料,将其用作成功编程解决方案的终结手段,并且客户/您的雇主对结果感到满意.
(虽然如果你从幻觉说话的青蛙那里得到答案,你应该得到一些帮助)
Ed *_*ess 710
代码中的大多数注释实际上都是代码重复的有害形式.
我们花费大部分时间来维护其他人(或我们自己)编写的代码,而不良,不正确,过时,误导性的评论必须接近代码中最烦人的工件列表的顶部.
我想最终很多人都把它们弄掉了,特别是那些花箱怪物.
更好地集中精力使代码可读,根据需要进行重构,并最大限度地减少习语和怪癖.
另一方面,许多课程教导评论几乎比代码本身更重要,导致下一行添加一个到invoiceTotal风格的评论.
小智 693
XML被高估了
我认为在使用他们的大脑之前,有太多人跳到了XML的潮流上......用于网络的XML非常棒,因为它是为它而设计的.否则我认为一些问题定义和设计思想应该优先于任何使用它的决定.
我的5美分
Dmi*_*ruk 678
并非所有程序员都是平等的
很多时候,管理者认为DeveloperA == DeveloperB只是因为他们有相同的经验水平等等.实际上,一个开发人员的性能可能是另一个开发人员的10倍甚至100倍.
谈论这个问题具有政治风险,但有时候我想指出一点,即使有几个团队成员看起来技能相同,但情况并非总是如此.我甚至已经看到了主要开发人员"超出希望"并且初级开发人员完成了所有实际工作的情况 - 但我确保他们获得了信誉.:)
Lea*_*ing 614
我不明白为什么人们认为Java绝对是大学里最好的"第一"编程语言.
首先,我认为第一种编程语言应该强调学习控制流和变量的必要性,而不是对象和语法
另一方面,我认为那些没有调试C/C++中的内存泄漏经验的人不能完全理解Java带给桌面的东西.
自然进展也应该是从"我怎么做到这一点"到"我怎样才能找到那样做的图书馆",而不是相反.
gle*_*ron 541
如果你只懂一种语言,无论你多么了解它,你都不是一个优秀的程序员.
似乎有一种态度说,一旦你真的擅长C#或Java或者你开始学习的任何其他语言,那就是你所需要的.我不相信 - 我所学过的每一种语言都教会了我一些关于编程的新知识,我能够将其与其他所有人一起带回到我的工作中.我认为限制自己使用一种语言的人永远不会像现在这样好.
它也向我表明,某些缺乏审查和实验的意愿并不一定符合我期望在一个真正优秀的程序员中找到的品质.
Dav*_*lle 488
打印语句是调试代码的有效方法
我相信通过乱丢它System.out.println(或者任何适用于您的语言的print语句)来调试代码是完全没问题的.通常,这可能比调试更快,您可以将打印输出与应用程序的其他运行进行比较.
只需确保在开始生产时删除print语句(或者更好,将它们转换为日志记录语句)
Mik*_*fer 467
你的工作就是让自己失业.
当您为雇主编写软件时,您创建的任何软件都应以这样的方式编写,以便任何开发人员都可以使用它,并且只需花费很少的精力即可理解.它设计良好,清晰一致地编写,格式清晰,记录在需要的位置,按预期每天构建,检入存储库,并进行适当的版本控制.
如果你受到公共汽车,下岗,解雇或离职的打击,你的雇主应该能够立即取代你,下一个人可以进入你的角色,拿起你的代码然后起来在一周内运行.如果他或她不能那样做,那你就失败了.
有趣的是,我发现实现这一目标使我对雇主更有价值.我越努力成为一次性用品,我就越有价值.
Dai*_*man 466
1)商业应用闹剧:
我认为整个"企业"框架的事情是烟雾缭绕.J2EE,.NET,大多数Apache框架和管理此类事物的大多数抽象都会产生比它们解决的复杂性更高的复杂性.
采用任何常规的Java或.NET ORM,或任何所谓的现代MVC框架,这些框架可以"魔术"来解决繁琐,简单的任务.您最终会编写大量难以验证和快速编写的丑陋XML样板.您拥有大量的API,其中一半只是为了集成其他API的工作,无法回收的接口,以及仅为克服Java和C#的不灵活性所需的抽象类.我们根本不需要大部分内容.
所有不同的应用程序服务器如何使用自己的darned描述符语法,过于复杂的数据库和组件产品？
这一点的重点不在于复杂性==糟糕,而是不必要的复杂性==糟糕.我曾经在大规模的企业安装中工作,其中一些是必要的,但即使在大多数情况下,一些本土的脚本和一个简单的Web前端就是解决大多数用例所需的全部内容.
我试图用简单的Web框架,开源数据库和简单的编程结构替换所有这些企业应用程序.
2)所需的n年经验:
除非你需要一个顾问或技术人员来处理相关的应用程序,API和框架的一个具体问题,那么你就真的需要有人用5年时间在该应用体验.你需要的是一个开发者/管理员谁可以读取文档,谁拥有什么是你正在做的,谁能够快速学习领域知识.如果你需要用某种语言开发,一个体面的开发人员会在不到两个月的时间内完成它.如果您需要X Web服务器的管理员,在两天内,他应该已经阅读手册页和新闻组,并加快速度.少一点,那个人不值得他付出的代价.
3)常见的"计算机科学"学位课程:
大多数计算机科学和软件工程学位都是公牛.如果你的第一个编程语言是Java或C#,那么你做错了.如果你没有完成代数和数学的几门课程,那就错了.如果你没有深入研究函数式编程,那就不完整了.如果你不能循环不变适用于一个简单的for循环,你不值得您的盐作为一个所谓的计算机科学家.如果你有x和y语言以及面向对象的经验,那就充满了s***.一个真正的计算机科学家看到了语言的概念,术语和语法它使用的,并认为编程方法作为一个中间多,并具有潜在的哲学这样一个很好的了解都采摘新的语言,设计方法,或规范语言应该是微不足道的.
Pab*_*dez 439
吸毒者和二传手严重过度使用
我已经看到数百万人声称公共领域是邪恶的,所以他们将它们变成私人的,并为所有人提供吸气剂和制定者.我相信这几乎与使字段公开相同,如果您使用线程(但通常不是这种情况)或者您的访问者具有业务/表示逻辑(至少是"奇怪的"),可能会有所不同.
我并不赞成公共领域,而是反对为他们每个人制作一个getter/setter(或Property),然后声称这样做是封装或信息隐藏 ......哈!
更新:
这个答案在它的评论中引起了一些争议,所以我会试着澄清一点(我会保留原文,因为那是很多人投票的).
首先:任何使用公共领域的人都应该坐牢
现在,创建私有字段,然后使用IDE 自动生成其中的每一个getter和setter方法是几乎一样糟糕的利用公共领域.
很多人认为:
private fields + public accessors == encapsulation
我说(自动或不自动)为你的领域生成getter/setter对有效地违背了你想要实现的所谓封装.
最后,让我在本主题中引用鲍勃叔叔(取自"清洁代码"第6章):
有一个原因是我们将变量保密.我们不希望任何其他人依赖他们.我们希望自由地以一种心血来潮或冲动来改变他们的类型或实施.那么,为什么这么多程序员会自动将getter和setter添加到他们的对象中,将他们的私有字段暴露为公共？
小智 381
意见:SQL是代码.这样对待它
也就是说,就像您的C#,Java或其他喜欢的对象/过程语言一样,开发一种可读且可维护的格式化样式.
我讨厌看到草率的自由格式的SQL代码.如果你在页面上看到两种花括号样式时尖叫,当你看到隐藏或混淆JOIN条件的自由格式化的SQL或SQL时,为什么或为什么不尖叫呢？
Gre*_*ech 342
如果您是开发人员,那么您应该能够编写代码
去年我做了很多面试,在接受采访时,我应该测试人们的想法,以及他们如何在白板上实现简单到中等的算法.我最初开始时遇到的问题如下:
鉴于Pi可以使用函数4*(1 - 1/3 + 1/5 - 1/7 + ...)进行估算,其中更多项可以提供更高的精度,编写一个函数来计算Pi到5位小数的精度.
这是一个应该让你思考的问题,但不应该让经验丰富的开发人员无法接触(可以在大约10行C#中回答).然而,我们的许多人(据称是由该机构预先筛选过的)候选人甚至无法开始回答它,甚至解释他们如何回答它.所以过了一会儿,我开始问更简单的问题:
给定圆的面积由Pi乘以半径平方给出,写一个函数来计算圆的面积.
令人惊讶的是,超过一半的候选人无法用任何语言编写此功能(我可以阅读大多数流行语言,所以我让他们使用他们选择的任何语言,包括伪代码).我们有"C#开发人员"无法在C#中编写此函数.
我对此感到惊讶.我一直认为开发人员应该能够编写代码.现在看来,这是一个有争议的观点.当然这是面试候选人之一!
编辑:
关于第一个问题是好的还是坏的问题的评论中有很多讨论,以及你是否应该在面试中提出这样复杂的问题.我不打算在这里深入研究这个问题(这是一个全新的问题),除了说你在很大程度上忽略了这个帖子.
是的,我说人们无法取得任何进展,但第二个问题是微不足道的,许多人也无法取得任何进展!任何自称为开发人员的人都应该能够在几秒钟内将答案写入第二个,甚至不用思考.许多人不能.
Mic*_*rdt 287
设计模式比他们帮助它更能伤害好设计.
IMO软件设计,特别是良好的软件设计太多样化,无法在模式中有意义地捕获,特别是在人们实际可以记住的少量模式中 - 而且它们太抽象了,人们不能真正记住多于少数.所以他们没有多少帮助.
而另一方面,太多的人迷恋这个概念,并尝试在任何地方应用模式 - 通常,在生成的代码中,你找不到所有(完全没有意义的)单身人士和抽象工厂之间的实际设计.
Cha*_*ere 262
单元测试不会帮助您编写好的代码
进行单元测试的唯一原因是确保已经运行的代码不会中断.首先编写测试,或者将代码编写到测试中是荒谬的.如果您在代码之前写入测试,您甚至不知道边缘情况是什么.您可以拥有通过测试的代码,但在不可预见的情况下仍会失败.
此外,优秀的开发人员将保持较低的凝聚力,这将使新代码的添加不太可能导致现有的问题.
事实上,我会进一步概括,
软件工程中的大多数"最佳实践"都是为了防止糟糕的程序员造成太大的伤害.
他们在那里亲自抓住糟糕的开发人员并防止他们犯下愚蠢的错误.当然,由于大多数开发人员都很糟糕,这是一件好事,但优秀的开发人员应该获得通过.
Joh*_*ell 235
偶尔编写垃圾代码是可以的
有时,只需要一个快速而脏的垃圾代码来完成特定任务.模式,ORM,SRP,无论如何......抛出一个控制台或Web应用程序,编写一些内联sql(感觉很好),并提出要求.
Jon*_*n B 196
代码==设计
我不喜欢复杂的UML图和无尽的代码文档.在高级语言中,您的代码应该是可读的并且可以理解.复杂的文档和图表实际上不再是用户友好的.
这是一篇关于Code as Design主题的文章.
Gre*_*ech 186
软件开发只是一项工作
别误会我的意思,我喜欢软件开发很多.我在过去的几年里写过一篇关于这个主题的博客.我在这里花了足够的时间来获得超过5000点的声望点.我在一家初创公司工作的时间通常为60小时,而且比我作为承包商所能获得的资金要少得多,因为团队非常棒而且工作很有意思.
但在宏伟的计划中,这只是一份工作.
它在诸如家庭,我的女朋友,朋友,幸福等许多事物中排名很重要,而且如果我有无限量的现金,如骑摩托车,帆船或滑雪板,那么我宁愿做的其他事情.
我认为有时许多开发人员忘记了开发只是让我们能够拥有生活中更重要的东西(并通过做我们喜欢的事情来拥有它们),而不是成为最终目标.
Ste*_*ins 184
我也认为在源代码控制中使用二进制文件没有任何问题.如果它有充分的理由.如果我有一个程序集,我没有源,并且可能不一定在每个开发机器上的相同位置,那么我通常会将它粘贴在"二进制"目录中并使用相对路径在项目中引用它.
相当多的人似乎认为即使在同一句话中提到"源控制"和"二进制",我也应该被焚烧.我甚至知道那些有严格规定的地方,说你无法添加它们.
rus*_*elf 164
软件架构师/设计师被高估了
作为开发人员,我讨厌软件架构师的想法.他们基本上是不再编写全职代码的人,阅读杂志和文章,然后告诉你如何设计软件.只有那些实际上全职写软件的人才应该这样做.5年前,在你成为建筑师之前,我不在乎你是否是世界上最好的程序员,你的意见对我来说毫无用处.
那有争议的怎么样？
编辑(澄清):我认为大多数软件架构师都会成为优秀的业务分析师(与客户交谈,编写需求,测试等),我只是认为他们没有设计软件,高级别或其他方面.
Gre*_*ech 152
没有"一刀切"的发展方法
我很惊讶这是一个有争议的意见,因为在我看来,这似乎是常识.然而,在热门博客上有很多条目推广"一刀切"的发展方式,所以我想我可能实际上是少数.
我所看到的事情被吹捧为任何项目的正确方法- 在了解任何信息之前 - 就像使用测试驱动开发(TDD),域驱动设计(DDD),对象关系映射(ORM)之类的东西,Agile(资本A),面向对象(OO)等等,包括从方法论到架构到组件的所有内容.当然,所有这些都有很好的市场缩略词.
人们甚至似乎甚至将徽章放在他们的博客上,例如"我是测试驱动"或类似的,好像他们严格遵守单一方法无论项目项目的细节实际上是一件好事.
事实并非如此.
选择正确的方法,架构和组件等是应该在每个项目的基础上完成的,不仅取决于您正在进行的项目类型及其独特要求,还取决于规模和能力您正在与之合作的团队.
Sta*_*kii 115
计算机科学学位不是 - 而且不应该 - 教你成为一名程序员.
编程是一种交易,计算机科学是一门研究领域.你可以成为一名优秀的程序员,一名可怜的计算机科学家,一名伟大的计算机科学家和一名可怕的程序员.了解差异很重要.
如果您想成为程序员,请学习Java.如果你想成为一名计算机科学家,至少要学习三种几乎完全不同的语言.例如(汇编程序,c,lisp,ruby,smalltalk)
jav*_*y79 101
SESE(单入单退出)不是法律
例:
public int foo() {
if( someCondition ) {
return 0;
}
return -1;
}
VS:
public int foo() {
int returnValue = -1;
if( someCondition ) {
returnValue = 0;
}
return returnValue;
}
我的团队和我发现,在许多情况下,始终遵守这一点实际上会适得其反.
Hun*_*ods 100
C++是最糟糕的编程语言之一 - 永远.
它具有委员会设计的所有标志 - 它没有做任何给定的工作,并且做了一些工作(如OO)非常糟糕.它有一个"厨房水槽"的绝望,它不会消失.
学习编程是一种可怕的"第一语言".没有优雅,没有帮助(来自语言).相反,你有熊陷阱和矿场(内存管理,模板等).
尝试学习OO概念并不是一门好的语言.它表现为"带有类包装器的C"而不是适当的OO语言.
我可以继续,但现在就把它留在那里.我从来没有喜欢用C++编程,尽管我在FORTRAN上"切了我的牙齿",但我完全喜欢用C语言编程.我仍然认为C是伟大的"经典"语言之一.在我看来,C++肯定不是.
干杯,
-R
编辑:回应关于C++教学的评论.您可以通过两种方式教授C++ - 在类固醇上教授C"(从变量,条件,循环等开始),或者将其教授为纯粹的"OO"语言(从类,方法等开始).您可以找到使用这些方法中的一种或另一种的教学文本.我更喜欢后一种方法(首先是OO),因为它强调了C++作为OO语言的能力(这是C++的原始设计重点).如果你想教C++"作为C",那么我认为你应该教C,而不是C++.
但是,根据我的经验,C++作为第一语言的问题在于,语言在一个学期中过于繁重,而且大多数"介绍"文本都试图覆盖所有内容.根本不可能涵盖"第一语言"课程中的所有主题.你必须至少把它分成两个学期,然后它不再是"第一语言",IMO.
我教C++,但只是作为一种"新语言" - 也就是说,在注册课程之前,你必须精通一些先前的"纯粹"语言(不是脚本或宏).C++是一种非常精细的"第二语言",IMO.
-R
'Nother编辑:(对康拉德)
我完全不同意C++"在各方面都优于C".我花了数年时间编写C程序用于微控制器和其他嵌入式应用程序.这些器件的C编译器经过高度优化,通常可以生成与手动编码汇编器一样好的代码.当您转向C++时,您将获得编译器强加的巨大开销,以便管理您可能不使用的语言功能.在嵌入式应用程序中,通过添加类等IMO可以获得很少的收益.你需要的是严密,干净的代码.你可以用C++编写它,但是你真的只是编写C,而C编译器在这些应用程序中更加优化.
我用C语言编写了一个MIDI引擎,后来用C++(在供应商的要求下)编写了一个嵌入式控制器(声卡).最后,为了满足性能要求(MIDI时序等),我们不得不为所有核心代码恢复为纯C.我们能够将C++用于高级代码,并且使用类非常好 - 但是我们需要C来获得较低级别的性能.C代码比C++代码快一个数量级,但手动编码汇编程序只比编译的C代码略快.这是在20世纪90年代早期,只是为了正确地发布事件.
-R
Rya*_*ndy 94
您必须知道如何键入成为程序员.
在那些不知道如何打字的人之间存在争议,但是他们坚持认为他们可以像任何打字员那样快速地双手狩猎,或者他们并不需要花那么多时间打字,或者说Intellisense减轻了输入...
我从来没有见过任何人谁不知道如何键入,但坚持认为它不会有所作为.
另请参见: 编程的最小的秘密
Mal*_*rap 89
计算机科学或其他IT领域的学位使您成为一个更全面的程序员
我不在乎你有多少年的经验,你读了多少博客,你参与了多少个开源项目.一个资格(我建议超过3年)让你以不同的方式暴露你思考并给你一个很好的基础.
仅仅因为你编写了一些比计算机科学学士学位更好的代码,并不意味着你比他更好.你有什么他可以在瞬间获得,而不是相反的情况.
获得资格证明了您的承诺,事实上您将超越经验,使您成为更好的开发人员.擅长他们所做并且具有资格的开发人员可能非常令人生畏.
如果这个答案被否决,我不会感到惊讶.
此外,一旦你有资格,你就慢慢地停止与那些有资格的人比较(我的经验).你意识到,只要你能在一起工作,这一切都无关紧要.
无论资格如何,始终对其他开发人员仁慈地行事.
Jon*_*son 89
懒惰的程序员是最好的程序员
懒惰的程序员通常会找到减少编写代码所花费的时间的方法(特别是很多相似或重复的代码).这通常转化为公司/团队中的其他开发人员可以从中受益的工具和工作流程.
当开发人员遇到类似的项目时,他可能会创建工具来引导开发过程(例如,创建一个与公司的数据库设计范例一起工作的DRM层).
此外,诸如此类的开发人员经常使用某种形式的代码生成.这意味着所有相同类型的错误(例如,代码生成器未检查所有方法上的空参数)通常可以通过修复生成器来修复,而不是修复该错误的50多个实例.
懒惰的程序员可能需要花费几个小时才能将第一个产品推出门外,但是可以节省数月的时间.
the*_*zer 87
除非您能解释为什么需要它,否则不要使用继承.
Max*_*Max 86
世界需要更多的GOTO
除了"我的教授告诉我GOTO很糟糕"以外,没有任何理由经常避免使用GOTO.它们有一个目的,可以在很多地方大大简化生产代码.
也就是说,在99%的代码编写中,它们并不是必需的.
Jul*_*iet 80
我之前因为公开传播这些意见而受到焚烧,但这里有:
动态类型语言中编写良好的代码遵循静态类型约定
使用过Python,PHP,Perl和其他一些动态类型语言后,我发现这些语言中编写良好的代码遵循静态类型约定,例如:
重新使用具有不同类型的变量(例如,它的错误样式以获取列表变量并分配int,然后在同一方法中将变量赋值为bool)被认为是不好的样式.动态类型语言中编写良好的代码不会混合类型.
静态类型语言中的类型错误仍然是动态类型语言中的类型错误.
函数通常被设计为一次对单个数据类型进行操作,因此接受类型参数的函数T只能合理地用于类型T或子类的对象T.
为许多不同数据类型的操作符设计的函数是以将参数约束到定义良好的接口的方式编写的.一般来说,如果两个类型的对象A和B执行类似的功能,但不是彼此的子类,那么它们几乎肯定会实现相同的接口.
虽然动态类型语言肯定提供了多种方法来破解,但这些语言中大多数编写良好的惯用代码都非常关注类型,就像使用静态类型语言编写的代码一样严格.
动态类型不会减少程序员编写的代码量
当我指出如此多的静态类型约定交叉到动态类型世界时有多奇特时,我通常会添加"为什么要使用动态类型语言开始？".即时响应是能够编写更简洁,更具表现力的代码,因为动态类型允许程序员省略类型注释和明确定义的接口.但是,我认为最流行的静态类型语言,如C#,Java和Delphi,在设计上很笨重,而不是因为它们的类型系统.
我喜欢使用像OCaml这样的真实类型系统的语言,它不仅是静态类型的,而且它的类型推断和结构类型允许程序员省略大多数类型注释和接口定义.
ML系列语言的存在证明了我们可以享受静态类型的好处,并且用动态类型语言编写所有简洁的东西.我实际上将OCaml的REPL用于临时的,一次性脚本,其他人都使用Perl或Python作为脚本语言.
Dan*_*plo 76
花费一整天在Stackoverflow上回答问题的程序员可能没有完成他们付出的工作.
phi*_*red 72
代码布局很重要
也许支撑位置的细节应该仍然是纯粹的宗教观点 - 但这并不意味着所有的布局风格都是平等的,或者根本就没有客观因素!
麻烦的是,布局的超级规则,即:"保持一致",听起来如此,被许多人用作拐杖,从不试图看看他们的默认风格是否可以改进 - 而且,甚至没有关系.
几年前,我正在学习速读技术,我学到的关于眼睛如何在"注视"中获取信息的一些事情,可以最佳地扫描页面,以及潜意识地拾取背景的作用让我思考如何这适用于代码 - 并特别考虑到编写代码.
它使我成为一种倾向于柱状的风格,标识符在可能的情况下进行逻辑分组和对齐(特别是我对每个方法参数都在其自己的行上变得严格).然而,不是长柱不变的结构,改变块中的结构实际上是有益的,这样你最终会得到一个矩形岛,眼睛可以在一个装置中进入 - 即使你没有有意识地阅读每个角色.
最终的结果是,一旦你习惯它(通常需要1-3天),它变得赏心悦目,更容易和更快地理解,并且对眼睛和大脑的负担更少,因为它以某种方式布局这使得它更容易接受.
几乎无一例外,我要求尝试这种风格的每个人(包括我自己)最初都说,"我讨厌它!"但是一两天后说,"我喜欢它 - 我发现很难不回去并用这种方式重写我所有的旧东西!"
我一直希望能找到时间进行更多的对照实验来收集足够的证据来写论文,但一如既往地忙于其他事情.然而,对于那些对有争议的技术感兴趣的人来说,这似乎是一个很好的机会:-)
[编辑]
我终于开始写博客(经过多年停留在"意义"阶段):第一部分,第二部分,第三部分.
Joh*_*ose 71
意见:显式变量声明是一件好事.
我永远不会理解让开发人员浪费昂贵的时间来追踪由变量名称拼写错误引起的运行时错误而不是简单地让编译器/解释器捕获它们的"智慧".
没有人给我一个更好的解释,"因为我不必写'int i',所以它可以节省时间." 嗯......是的,当然,但是需要多少时间来追踪运行时错误？
Cam*_*and 68
意见:"调试"和"发布"版本之间永远不会有不同的代码
主要原因是发布代码几乎从未经过测试.最好在测试中运行相同的代码,就像在野外一样.
Kev*_*vis 64
意见:开发人员应该测试自己的代码
我已经看到太多的废话交给测试只是为了让它没有实际修复有问题的bug,招致沟通开销和培养不负责任的做法.
bmb*_*bmb 63
分页永远不是用户想要的
如果您开始讨论在哪里进行分页,在数据库中,在业务逻辑中,在客户端上等等,那么您提出的问题是错误的.如果您的应用程序回馈的数据超出了用户的需求,请找出一种方法让用户根据实际标准缩小他们的需求,而不是任意大小的块.如果用户确实想要所有这些结果,那么给他们所有结果.你是谁帮助你一次回馈20个？服务器？这比你的用户更重要吗？
[编辑:澄清,基于评论]
作为一个真实世界的例子,让我们来看看这个 Stack Overflow问题.假设我有一个有争议的编程观点.在我发布之前,我想看看是否已经有一个解决同一意见的答案,所以我可以对它进行投票.我唯一的选择是点击每一页的答案.
我更喜欢以下选项之一:
请允许我搜索答案(根据实际标准缩小我需要的方法).
请允许我查看所有答案,以便我可以使用浏览器的"查找"选项(给我所有结果).
如果我只是想找到我之前读过的答案,但同样找不到,这同样适用.我不知道它什么时候发布或者它有多少票,所以排序选项没有帮助.即使我这样做,我仍然需要玩一个猜谜游戏才能找到合适的结果页面.答案是分页的,我可以直接点击十几页中的一页,这根本没有帮助.
-
bmb
Tor*_*ups 62
尊重单一责任原则
乍一看,你可能不会认为这会引起争议,但根据我的经验,当我向另一位开发人员提及他们不应该在页面加载方法中做任何事情时,他们经常会推迟...所以对于孩子们请退出构建我们经常看到的"做一切"方法.
Cam*_*and 60
另外:独家锁定是邪恶的.
我曾经在某个地方工作,他们认为独家锁意味着你保证人们在你办理登机手续时没有覆盖别人的变化.问题是,为了完成任何工作,如果文件被锁定,开发者只会改变他们的本地文件可以在有机会时将源控件与其版本进行可写和合并(或覆盖).
小智 60
不编码的架构师是无用的.
这听起来有点刺耳,但这并非不合理.如果您是系统的"架构师",但没有一定程度的实际参与所使用的技术,那么您如何获得开发团队的尊重？你如何影响方向？
建筑师需要做更多的事情(与利益相关者会面,与其他团队协商,评估供应商,编写文档,进行演示等)但是,如果您从未看到建筑师签入的代码......请小心!
ben*_*ith 60
对象不应该处于无效状态
不幸的是,许多ORM框架为所有实体类强制使用零参数构造函数,使用setter来填充成员变量.在这些情况下,很难知道必须调用哪些setter才能构造有效的对象.
MyClass c = new MyClass(); // Object in invalid state. Doesn't have an ID.
c.setId(12345); // Now object is valid.
在我看来,对象永远不可能发现自己处于无效状态,并且类的API应该在每次方法调用之后主动强制执行其不变量.
构造函数和mutator方法应该将对象从一个有效状态原子转换为另一个有效状态.这要好得多:
MyClass c = new MyClass(12345); // Object starts out valid. Stays valid.
作为某些图书馆的消费者,在尝试使用对象之前跟踪是否已经调用了所有正确的setter是一种愚蠢的痛苦,因为文档通常没有提供关于类合同的线索.
Cam*_*and 58
意见:单元测试不需要预先编写,有时根本不需要.
推理:开发人员都在测试自己的代码.我们的确是.这就是为什么我们通常有测试团队或QA小组.
大多数情况下,我们编写的代码与其他代码交织在一起进行单独测试,因此我们最终跳过图案化的环节以提供可测试性.并不是说这些模式很糟糕,但它们有时会增加不必要的复杂性,所有这些都是为了进行单元测试...
......无论如何往往都行不通.要编写全面的单元测试需要很多时间.通常比我们愿意付出更多的时间.而且测试越全面,如果它测试的东西的界面发生变化就会变得越脆,迫使重写不再编译的测试.
Kon*_*lph 58
默认情况下,所有变量/属性都应为readonly/ final.
这个推理有点类似于sealedJon提出的类的论点.程序中的一个实体应该只有一个工作,而只有一个工作.特别是,对于大多数变量和属性来说,改变价值绝对没有意义.基本上有两个例外.
循环变量.但是,我认为变量实际上并没有改变价值.相反,它在循环结束时超出范围,并在下一轮重新实例化.因此,不变性可以很好地与循环变量一起工作,每个试图手动改变循环变量值的人应该直接下地狱.
蓄电池.例如,想象一下对数组中的值进行求和的情况,或者甚至是累积某些其他信息的列表/字符串.
今天,有更好的方法来实现同一目标.函数式语言具有高阶函数,Python具有列表理解能力,.NET具有LINQ.在所有这些情况下,不需要可变累加器/结果持有者.
考虑字符串连接的特殊情况.在许多环境(.NET,Java)中,字符串实际上是不可变的.为什么然后允许赋值给一个字符串变量呢？一直使用构建器类(即a StringBuilder)要好得多.
我意识到今天的大多数语言都不是为了默许我的愿望.在我看来,出于这个原因,所有这些语言都存在根本缺陷.如果将它们更改为默认情况下将所有变量视为只读,并且在初始化后不允许对它们进行任何赋值,则它们将不会失去它们的表现力,功能和易用性.
Joh*_*yre 52
实现有时足够好就足够了,作为程序员,你的价值会大幅提升.
请注意,当我说"足够好"时,我的意思是"足够好",而不是一些碰巧工作的垃圾.但话说回来,当你处于紧张状态时,"一些恰好有效的废话"可能会被认为是"足够好".
Gar*_*eth 48
如果我有争议,我不得不建议Jon Skeet不是无所不能的......
Geo*_*F67 46
"Java糟透了" - 是的,我知道这个意见绝对不是所有人都持有:)
我有这个意见,因为我见过的大多数Java应用程序都是内存耗尽,运行缓慢,用户界面可怕等等.
G-人
Jon*_*eet 45
好吧,我说我会更详细地介绍一下我的"密封课"意见.我想一种方式来显示我感兴趣的答案就是给自己一个:)
意见:C#默认密封在C#中
推理:
毫无疑问,继承是强大的.但是,它必须在某种程度上受到指导.如果有人以完全出乎意料的方式从基类派生,这可能会打破基本实现中的假设.考虑基类中的两个方法,其中一个方法调用另一个方法 - 如果这些方法都是虚方法,那么必须记录该实现细节,否则有人可以合理地覆盖第二个方法并期望调用第一个方法.当然,一旦记录了实施,就无法改变......所以你就失去了灵活性.
通过默认密封方法,C#向正确的方向迈出了一步(相对于Java).但是,我相信还有一个步骤 - 默认密封课程 - 会更好.特别是,很容易覆盖方法(或者没有明确地密封您不会覆盖的现有虚拟方法),这样您最终会出现意外行为.这实际上并不会阻止你做任何你现在可以做的事情 - 它只是改变默认值,而不是改变可用的选项.这将是一个"更安全"的默认设置,就像C#中的默认访问始终是"此时可用的最私密的可见性".
通过让人们明确表示他们希望人们能够从他们的课程中获得,我们会鼓励他们多考虑一下.它也会帮助我解决我的懒惰问题 - 虽然我知道我应该密封几乎所有课程,但我很少记得这样做:(
相反的观点:
我可以看到一个论点,即没有虚拟方法的类可以相对安全地派生而不需要额外的不灵活性和文档.我不知道如何反击这一个,除了说我相信意外开启的课程的伤害大于意外密封课程的伤害.
Tom*_*ley 42
一个聪明的程序员是危险的
我花了更多的时间来修复"聪明"程序员编写的代码.我宁愿有一个优秀的程序员而不是一个非常聪明的程序员,他想通过编写只有他(或她)可以解释的代码来证明他是多么聪明.
Ant*_*nes 40
如果您有任何想法如何编程,则不适合在表单上放置按钮
这有争议吗？;)
无论我们如何努力,几乎不可能对53岁的Doris表示适当的同情,他必须使用我们的订单输入软件.我们根本无法掌握她想象的在计算机内部的心理模型,因为我们不需要想象:我们知道发生了什么,或者有一个非常好的主意.
交互设计应该由非程序员完成.当然,这实际上永远不会发生.相反,我很高兴; 我喜欢UI设计,即使内心深处,我知道我不适合它.
有关详细信息,请阅读"囚犯正在运行庇护 "一书.请注意,我发现这本书令人不安和侮辱; 如果您是关心用户体验的开发人员,那将是一个难以阅读的内容.
Jon*_*egg 40
避免缩进.
使用提前退货,继续或休息.
代替:
if (passed != NULL)
{
for(x in list)
{
if (peter)
{
print "peter";
more code.
..
..
}
else
{
print "no peter?!"
}
}
}
做:
if (pPassed==NULL)
return false;
for(x in list)
{
if (!peter)
{
print "no peter?!"
continue;
}
print "peter";
more code.
..
..
}
Pau*_*cks 38
我可能会为此烤,但是:
在python中使隐形字符在语法上显着是一个坏主意
它让人分心,给初学者带来许多微妙的错误,在我看来,并不是真的需要.关于我见过的唯一没有自愿遵循某种体面格式指南的代码来自一年级的CS学生.即使代码不遵循"好"标准,也有很多工具可以将其强制转换为更令人愉悦的形状.
Jul*_*iet 37
应从OO语言中删除空引用
来自Java和C#背景,其正常从一个方法返回null以指示失败,我得出结论,null会导致许多可避免的问题.语言设计者可以删除与NullRefernceExceptions相关的整类错误,如果它们只是从代码中消除了空引用.
另外,当我调用一个方法时,我无法知道该方法是否可以返回null引用,除非我真正深入了解实现.我希望看到更多的语言跟随F#的模式来处理空值:F#不允许程序员返回空引用(至少在F#编译的类),相反,它要求程序员表示使用空的对象option类型.这种设计的好处是多么有用的信息,如功能是否可以返回空引用,通过类型系统传播:它返回一个类型的功能'a有不同的返回类型比返回功能'a option.
Ste*_*eve 35
单身人士并不邪恶
在现实世界中有一个单身人士的地方,绕过它们的方法(即单一模式)只是伪装的单身人士.例如,Logger是单身人士的完美候选人.另外,消息泵也是如此.我当前的应用程序使用分布式计算,不同的对象需要能够发送适当的消息.应该只有一个消息泵,每个人都应该能够访问它.另一种方法是将一个对象传递到我可能需要的任何地方的消息泵,并希望新的开发人员不会在没有思考的情况下新建一个,并想知道为什么他的消息无处可去.单身人士的独特性是最重要的部分,而不是其可用性.单身人士在世界上占有一席之地.
ski*_*ppy 34
一张照片是不是胜过千言万语.
有些照片可能胜过千言万语.他们中的大多数不是.对于许多懒惰的经理来说,这种陈旧的格言大多是不真实的,这是一个可怜的借口,他不想仔细阅读创建的报告和文档来说"我需要你在图表中向我展示".
我的妻子攻读语言学专业,并在图片和标识上看到了几个有关传统智慧的有趣证据:它们没有突破语言和文化障碍,它们通常不会在正确文本附近的任何地方进行交流,它们根本无法替代真正的沟通.
特别地,如果线条未标记且无法解释,和/或如果每条线具有不同的含义而不是表示相同的关系(除非以某种方式彼此区分),则与线连接的标记的气泡是无用的.如果你的线条有时表示关系,有时表示行动,有时表明时间的流逝,那么你真的很好.
每个优秀的程序员都知道你使用适合手头工作的工具,对吗？并非所有系统都在图片中得到最佳指定和记录.图形规范语言可以自动转换为可证明正确的可执行代码或任何其他是一个壮观的想法,如果这样的话存在的话.在适当的时候使用它们,而不是在阳光下使用.实体 - 关系图非常棒.但并非所有事情都能在图片中总结出来.
注意:一张桌子的价值可能与黄金相当.但桌子和图片不是一回事.而且,精心设计的短篇散文段落可能更适合手头的工作.
Fer*_*cio 33
你需要注意对象痴迷程序员.
例如,如果你编写一个模拟内置类型(如整数或浮点数)的类,那么你可能是一个痴迷于对象的程序员.
Bri*_*lis 33
那里有很多糟糕的教学.
我们的开发人员喜欢在乔尔说大脑的一部分用于理解某些人刚出生时没有的指针时感到沾沾自喜.我们许多人在这里讨论并热衷于讨论的主题是深奥的,但有时这只是因为我们这样做.
Roc*_*net 32
在开发代码时要牢记优化是个好主意.
每当我这样说时,人们总会回答:"过早优化是万恶之源".
但是在调试之前我不是说优化.我甚至都没有说优化,但是当你设计代码时,请记住这可能成为瓶颈的可能性,并写下它以便可以重新调整速度,而不会撕裂API.
雨果
小智 31
如果开发人员不能写清楚,简洁和语法正确的评论,那么他们应该返回并采取英语101.
我们有开发人员和(恐怖)建筑师,他们不能连贯地写作.当他们的文件被审查时,他们会说"哦,不要担心语法错误或拼写 - 这不重要".然后他们想知道为什么他们错综复杂的垃圾文件变成了错综复杂的错误代码.
我告诉实习生,我指导如果你不能口头或书面地传达你的好主意,你也可以不拥有它们.
jal*_*alf 31
C++是一门很好的语言
我几乎在一两个星期内回答了另一个问题,因为他说C++不是一个非常好的语言.所以现在我会尝试反过来说.;)
不,说真的,我试图制作的那一点,现在又要再试一次,是C++有很多缺陷.很难否认这一点.这是非常复杂的,学习它实际上是你可以献出一生的东西.它使许多常见任务变得非常困难,允许用户首先陷入未定义行为的海洋和不可移植的代码,而编译器没有给出警告.
但这并不是许多人试图制造它的无用,破旧,过时,讨厌的语言.它不应该被扫地并被忽视.没有它,世界将不会是一个更好的地方.它有一些独特的优势,遗憾的是,这些优势隐藏在古怪的语法,遗留问题,尤其是糟糕的C++教师背后.但他们在那里.
在使用C#或其他"现代"语言编程时,C++有许多我非常想念的功能.C#和其他现代语言可以从中学到很多东西.
它不是盲目专注于OOP,而是探索并开创了泛型编程.它允许令人惊讶的表达式编译时元编程,产生极其高效,健壮和干净的代码.在C#获得LINQ或lambda表达式之前差不多十年,它接受了函数式编程的教训.
它允许您通过静态断言和其他元编程技巧在编译时捕获惊人数量的错误,这样可以大大简化调试,甚至可以在某些方面击败单元测试.(我更喜欢在编译时捕获错误而不是之后,当我运行我的测试时).
变量的确定性破坏允许RAII,这是一个非常强大的小技巧,它使得try/finally块和C#using块变得多余.
虽然有些人指责它是"委员会设计",但我会说是的,确实如此,在这种情况下,这实际上并不是件坏事.看看Java的类库.有多少课程已被弃用？不应该使用多少？彼此的功能有多少重复？有多少设计糟糕？
C++的标准库要小得多,但总的来说,它设计得非常好,除了一两个小疣(vector<bool>例如)之外,它的设计仍然很好.当某个功能被添加到C++或其标准库时,它会受到严格的审查.Java不能从中受益吗？.NET也是如此,虽然它更年轻,并且设计起来稍好一些,但仍然积累了一些与现实不同步的好类,或者设计起来很糟糕.
C++有很多其他语言无法比拟的优势.这是一门好语言
Wal*_*t D 31
源文件是SO 20世纪.
在函数/方法的主体内,将过程逻辑表示为线性文本是有意义的.即使逻辑不是严格线性的,我们也有很好的编程结构(循环,if语句等),它们允许我们使用线性文本干净地表示非线性操作.
但是我没有理由要求我在不同的文件中划分我的类,或者在这些文件中按特定顺序对我的函数/方法/字段/属性/等进行排序.为什么我们不能将所有这些东西都放在一个大的数据库文件中,让IDE负责动态地对所有内容进行排序？如果我想按名称对我的成员进行排序,那么我将点击成员表上的成员标题.如果我想通过辅助功能对它们进行排序,那么我将单击辅助功能标题.如果我想将我的类视为继承树,那么我将单击按钮来执行此操作.
也许可以在空间上查看类和成员,就好像它们是虚拟世界中的某种实体一样.如果程序员需要,IDE可以自动定位彼此靠近的类和成员,以便他们很容易找到.成像能够放大和缩小这个虚拟世界.完全放大,你可以用星球中的小类行星命名星系.放大命名空间,您可以看到具有方法大陆和岛屿的类行星以及作为轨道卫星的内部类.放大方法,您会看到...该方法的源代码.
基本上,我的观点是,在现代语言中,您放置课程的文件或您定义课程成员的顺序并不重要,那么为什么我们仍然被迫使用这些古老的实践呢？还记得Gmail何时问世,谷歌说"搜索,不排序"？那么,为什么不能将相同的哲学应用于编程语言呢？
Jas*_*sar 30
我一直在折腾一下:
数据是系统.
流程和软件是为数据而构建的,而不是相反的.
没有数据,流程/软件几乎没有价值.数据仍然具有价值,没有围绕它的过程或软件.
一旦我们理解了数据,它的作用,它如何相互作用,它在不同阶段存在的不同形式,那么就可以构建一个解决方案来支持数据系统.
成功的软件/系统/流程似乎具有敏锐的意识,即使不是在任何特定时刻数据处于"何处"的狂热正念.
dwf*_*dwf 30
设计模式是石器时代编程语言设计的症状
他们有自己的目的.很多好的软件都是用它们构建的.但事实上,需要将这些"食谱"编纂成关于代码如何工作/应该如何工作的心理抽象,这说明缺乏足够表达的编程语言来处理这种抽象.
我认为,补救措施在于允许您将越来越多的设计嵌入到代码中的语言,通过定义可能不存在或可能不具有普遍适用性但在代码处理不断的情况下真正有意义的语言结构..计划人们多年来已经知道这一点,并且有可能使用Scheme宏来使大多数猴子雇佣他们的裤子.
Dan*_*ull 26
当我声称代码只是我设计的一个表达时,我经常会大喊大叫.我非常不喜欢我看到这么多开发人员在编写代码时"动态"设计系统的方式.
当这些牛仔中的一个从他的马上掉下来时所浪费的时间和精力是惊人的 - 并且在10次中他们击中的问题中的9次将仅通过一些前期设计工作被发现.
我觉得现代方法论并没有强调设计在整个软件开发过程中的重要性.例如,当您甚至没有审查过您的设计时,重视代码审查!这很疯狂.
JD *_*ley 25
牛仔编码员做得更多.
我在创业氛围中度过了一生.如果没有牛仔编码器,我们会浪费无休止的周期,确保事情"正确"完成.
我们知道基本上不可能预见所有问题.牛仔编码器直接面对这些问题,并且被迫比那些试图预测它们的人更快地解决它们.
但是,如果你是牛仔编码,那么在其他人不得不维护它之前你最好重构意大利面条.;)我所知道的最好的是使用连续重构.他们完成了大量的工作,不要浪费时间去预测未来,通过重构它可以成为可维护的代码.
无论敏捷程度如何,进程总是妨碍一个好牛仔的方式.
Aus*_*nen 25
用户不是白痴 - 你是.
很多次,我听到开发人员说"某某是一个白痴",我的回答通常是"他可能是个白痴,但你允许他成为一个白痴."
Jac*_*raw 25
应始终使用基于1的数组而不是基于0的数组.基于0的数组不自然,不必要且容易出错.
当我算上苹果或员工或小工具时,我从一开始,而不是零.我教给孩子们同样的东西.没有第0个苹果或第0个员工或第0个小部件.使用1作为数组的基础更直观,更不容易出错.忘记加一 - 减 - 一 - 地狱(就像我们以前称之为).基于0的阵列是由计算机科学发明的非自然构造 - 它们不能反映现实,计算机程序应该尽可能地反映现实.
rus*_*elf 24
编程越多,代码就越糟糕
我在8年左右的编程中注意到了一些东西,看起来很荒谬.这是获得质量的唯一途径,就是聘请优质的开发人员,尽可能多地从他们那里删除流程和形式.单元测试,编码标准,代码/同行评审等只会降低质量,而不会增加质量.这听起来很疯狂,因为相反的情况应该是正确的(更多的单元测试应该会导致更好的代码,优秀的编码标准应该会导致代码更易读,代码审查应该会提高代码质量)但事实并非如此.
我认为这归结为我们称之为"软件工程"的事实,当它真的是设计而不是工程设计时.
一些数字证实了这一说法:
来自编辑
IEEE软件,2001年11月/ 12月
量化软因素
由史蒂夫·麦康奈尔
...
流程成熟度的重要性有限
...在比较中型项目(100,000行代码)时,处理过程最差的项目需要的工作量是具有最佳流程的项目的1.43倍,其他条件相同.换句话说,流程成熟度对项目生产率的最大影响是1.43....
...... Clark没有强调的是,对于一个包含10万行代码的程序,一些以人为本的因素会影响生产力而不是流程....
......仅资历导向因素(AEXP,LTEX,PEXP)的影响力为3.02.七型人才因素统称(ACAP,AEXP,LTEX,PCAP,PCON,PEXP,与本站§)施加的25.8惊人的影响范围! 这个简单的事实解释了非流程导向型组织(如Microsoft,Amazon.com和其他创业强国)可以在看似缩短流程的同时体验行业领先的生产力的大部分原因....
底线
......事实证明,交易流程对员工连续性,业务领域经验,私人办公室以及其他以人为本的因素的复杂性是一个良好的经济权衡.当然,最好的组织同时实现高动力和流程复杂性,这是任何领先软件组织的关键挑战.
§阅读文章以解释这些缩略语.
kem*_*002 23
意见:框架和第三方组件应仅作为最后手段使用.
我经常看到程序员立即选择一个框架来完成一项任务,而不需要学习工作所需的基本方法.某些东西将不可避免地破裂,或者我们会找到一个我们没有考虑到的限制,我们将立即陷入困境,不得不重新考虑系统的主要部分.只要仔细考虑,框架就可以使用.
cha*_*cus 23
生成的文档几乎总是毫无价值.
或者,作为推论:您的API需要维护者和用户的单独文档集.
实际上有两类人需要了解您的API:维护人员,他们必须了解您的实施细节才能在工作中发挥作用,以及需要高级概述的用户,示例以及有关效果的详细信息他们有权访问的每种方法.
我从未遇到过在任何一个领域都取得成功的生成文档.通常,当程序员为工具编写注释以提取和制作文档时,他们的目标是在中间的某个地方 - 只是足够的实现细节来填充和混淆用户但还不足以显着帮助维护者,并且没有足够的概述.对用户的真正帮助.
作为一个维护者,我总是喜欢干净,清晰的评论,不受你的自动文档工具所需的任何奇怪标记的影响,告诉我为什么你用你的方式编写那个奇怪的switch语句,或者这个看似冗余的参数有什么错误检查修复程序,或者我需要知道的任何其他内容,以便在我处理代码时实际保持代码清洁和无错误.我希望这些信息就在代码中,与代码相邻,所以我不必搜索你的网站,以便在一个有助于阅读的状态下找到它.
作为一个用户,我总是宁愿拥有一个完整,组织良好的文档(一组网页将是理想的,但我也会选择一个结构良好的文本文件),告诉我你的API是如何构建的,什么方法做什么,以及如何实现我想用你的API做什么.我不想在内部看到你写的哪些类允许我做什么工作,或者他们为此而写的文件.而且我当然不想下载你的资源,所以我可以弄明白窗帘背后发生了什么.如果您的文档足够好,我就不必这样做了.
无论如何,这就是我的看法.
小智 22
如果您的文本编辑器没有完成良好的代码,那么您就浪费了每个人的时间.
快速记住成千上万的参数列表,拼写和返回值(更不用说类结构和类似的复杂组织模式)是计算机擅长的任务,而人(相对)则不是.我全心全意地购买,放慢自己的速度,避免小工具/功能崇拜是提高效率和避免错误的好方法,但是当你花费零时,通过源代码或文档花费30秒不必要地进行搜索没有任何好处.特别是如果你只需要一个拼写(这比我们想承认的更多).
当然,如果没有一个编辑器为您的语言提供此功能,或者任务很简单,可以在加载较重的编辑器时耗尽,那么没有人会告诉您Eclipse和90个插件是正确的工具.但请不要告诉我,HJKL能够像1999年那样绕行,这样每次你需要一个方法签名时,你可以节省更多的时间,即使你觉得自己不那么"黑客"这样做了.
思考？
Jos*_*ris 22
客户并不总是对的.
在我处理的大多数情况下,客户是产品所有者,也就是"业务".开发人员通常只是编码并且不会尝试提供产品的既得利益.有一种误解,认为IT部门是"公司内部的公司",这是一堆垃圾.
我觉得我的角色是帮助企业表达他们的想法 - 我相互理解,我有兴趣了解业务,以便我可以提供最好的体验.而这条路线意味着产品所有者有时会要求他/她认为是计算机的下一次革命,让某人同意这个事实,或解释为什么没有人做某事某事的更可能的原因办法.这是互利的,因为产品所有者理解产品的思想,开发团队理解他们所做的不仅仅是吊索代码.
实际上,这已经开始引领我们走上提高生产力的道路.怎么样？由于表格双方的分歧导致沟通得到改善,因此我们更有可能在流程的早期阶段走到一起,并找到产品定义的互利解决方案.
Mik*_*vey 22
我最有争议的编程观点是, 发现性能问题不是关于测量,而是关于捕获.
如果你在一个房间里寻找大象(而不是老鼠),你需要知道它们有多大吗？没有!你所要做的就是看.它们的巨大之处在于它们很容易找到!没有必要先测量它们.
至少自从关于gprof的论文 (Susan L. Graham,et al 1982)*以来,测量的概念已经是普遍的看法,在我们的鼻子下,一直是找到值得优化的代码的一种非常简单和直接的方法.
作为一个小例子,这是它的工作原理.假设您采用调用堆栈的5个随机时间样本,并且您碰巧在5个样本中的3个上看到特定指令.这告诉你什么？
............. ............. ............. ............. .............
............. ............. ............. ............. .............
Foo: call Bar ............. ............. Foo: call Bar .............
............. Foo: call Bar ............. ............. .............
............. ............. ............. Foo: call Bar .............
............. ............. ............. ............. .............
............. .............
它告诉你程序花费60%的时间来完成该指令所要求的工作.删除它删除了60%:
...\...../... ...\...../... ............. ...\...../... .............
....\.../.... ....\.../.... ............. ....\.../.... .............
Foo: \a/l Bar .....\./..... ............. Foo: \a/l Bar .............
......X...... Foo: cXll Bar ............. ......X...... .............
...../.\..... ...../.\..... ............. Foo: /a\l Bar .............
..../...\.... ..../...\.... ............. ..../...\.... .............
/ \ .../.....\... / \ .............
大致.
如果你可以删除指令(或者更少地调用它),那么大约是2.5倍的加速.(注意 - 递归是无关紧要的 - 如果大象怀孕了,它不会更小.)然后你可以重复这个过程,直到你真正接近最佳状态.
有些人在遇到性能问题时会使用它,并且不明白什么是重要的.
大多数人从来没有听说过它,当他们听到它时,认为这只是一种低劣的抽样模式.但它是非常不同的,因为它通过给出呼叫站点(以及终端指令)的成本来确定问题,作为挂钟时间的百分比.大多数剖析器(不是全部),无论是使用采样还是仪器,都不会这样做.相反,他们提供各种汇总测量,这些测量充其量只是问题的可能位置的线索.以下是对差异的更广泛的总结.
*事实上,该论文声称gprof的目的是"帮助用户评估抽象的替代实现".它没有声称帮助用户找到需要替代实现的代码,然后在更精细的级别上运行.
我的第二个最有争议的观点是这样,也可能是,如果它不是那么难以理解.
rba*_*all 21
不要评论你的代码
注释不是代码,因此当事情发生变化时,很容易不更改解释代码的注释.相反,我更喜欢将代码中的废话重构为没有理由进行评论的点.一个例子:
if(data == null) // First time on the page
至:
bool firstTimeOnPage = data == null;
if(firstTimeOnPage)
我真正评论的唯一一次是当它是TODO或解释原因时
Widget.GetData(); // only way to grab data, TODO: extract interface or wrapper
小智 21
一个优秀的程序员讨厌编码
类似于"一个优秀的程序员是一个懒惰的程序员"和"少代码更好".但是通过遵循这一理念,我已经设法编写了可能会使用数倍代码的应用程序(并且需要花费数倍的开发时间).简而言之:在编码之前先思考.我自己的程序的大多数部分最后导致问题的部分是我实际上喜欢编码的部分,因此代码太多,因此写得很差.就像这一段.
优秀的程序员是设计师
我发现编程使用与设计相同的概念(如同在艺术中使用的相同设计概念).我不确定大多数其他程序员会发现同样的事情是真的; 也许它是右脑/左脑的东西.从他们的代码到他们的命令行用户界面到他们的图形用户界面,有太多的程序是丑陋的,很明显这些程序的设计者实际上并不是设计师.
虽然相关性可能不是,在这种情况下,暗示因果关系,但我注意到,随着我在设计方面变得更好,我在编码方面变得更好.使事物适合和感觉正确的相同过程可以并且应该在两个地方使用.如果代码感觉不正确,则会导致问题,因为a)它不正确,或者b)你会认为它以一种"感觉正确"的方式工作,然后它将再次不正确.
艺术和代码不在频谱的两端; 代码可以在艺术中使用,并且本身可以是一种艺术形式.
免责声明:不幸的是,并非所有代码都很漂亮或"正确".
Kez*_*zer 20
我经常在ASP.NET/VB.NET中工作,并发现ViewState绝对是一场噩梦.它默认在大多数字段上启用,并在每个网页的开头导致大量编码数据.页面上的控件越大,ViewState数据就越大.大多数人并不关注它,但它会创建大量数据,这通常与页面上执行的任务无关.如果不使用这些选项,则必须在所有ASP控件上手动禁用此选项.它要么是或者有一切的自定义控件.
在我使用的一些页面上,页面的一半是由ViewState组成的,这真是一种耻辱,因为可能有更好的方法.
这只是我在语言/技术观点方面可以想到的一个小例子.这可能是有争议的.
顺便说一下,你可能想在这个线程上编辑投票,它可能会受到一些人的欢迎;)
Bre*_*ton 20
我有争议的观点:面向对象编程绝对是软件工程领域最糟糕的事情.
OOP的主要问题是完全没有严格的定义,每个人都可以达成一致.这很容易导致其中存在逻辑漏洞的实现,或像Java这样的语言,遵循这个奇怪的宗教教条,关于OOP的含义,同时迫使程序员完成所有这些扭曲和"设计模式"只是为了解决特别是OOP系统.
因此,OOP欺骗程序员认为他们正在实现这些巨大的生产力提升,OOP在某种程度上是一种"自然"的思考方式,同时迫使程序员输入大量不必要的样板.
然后,由于没有人知道OOP究竟意味着什么,我们在关于语言X或Y是否是"真正的OOP"的小论点上浪费了大量时间,奇怪的货物文化语言特征绝对是"必不可少"的语言被考虑"真正的OOP".
我们不应该要求这种语言或那种语言是"真正的oop",而应该通过实验来看待哪些语言特征,实际上提高了生产力,而不是试图强迫它成为一些想象的理想语言,或者实际上强迫我们程序符合"真正的面向对象程序"的一些柏拉图式理想.
我们不是坚持我们的程序符合"真正面向对象"的柏拉图理想,而是专注于遵循良好的工程原则,使我们的代码易于阅读和理解,并使用高效且有用的语言功能,无论他们是否足够"OOP".
Chr*_*ris 20
布尔变量用于存储只能采用两个可能值的数据.使用它们引起的问题经常被忽视:
在这些情况下,使用布尔变量会导致混淆代码,这些代码通常可以通过使用枚举来防止.
例
假设程序员正在为仅销售汽车和卡车的汽车经销商编写软件.程序员为他的软件开发了一个完整的业务需求模型.知道所售车辆的唯一类型是汽车和卡车,他正确地确定他可以在车辆类中使用布尔变量来指示车辆是汽车还是卡车.
class Vehicle {
bool isTruck;
...
}
软件是这样编写的,当isTruck车辆是卡车时,如果是真的,那么当车辆isTruck是假车时.这是在整个代码中多次执行的简单检查.
一切都顺利运行,直到有一天汽车经销商购买另一家销售摩托车的经销商.程序员必须更新软件,以便在经销商业务发生变化的情况下正常运行.现在需要确定车辆是汽车,卡车还是摩托车,这三种可能状态.
程序员应该如何实现呢？ isTruck是一个布尔变量,因此它只能保存两个状态.他可以将它从布尔值更改为允许许多状态的其他类型,但这会破坏现有逻辑,并且可能不会向后兼容.从程序员的角度来看,最简单的解决方案是添加一个新变量来表示车辆是否是摩托车.
class Vehicle {
bool isTruck;
bool isMotorcycle;
...
}
代码被改变,以便当isTruck车辆是卡车时isMotorcycle是真的,当车辆是摩托车时是真的,当它们都是假的时,车辆就是汽车.
问题
这个解决方案有两个大问题:
开发人员的错误是他的软件的业务需求发生了变化,要求他修改现有的代码.但是首先使用布尔变量使得他的代码不够灵活,难以修改以满足未知的未来需求(更少"面向未来").当他以最快的方式实现更改时,代码变得更难以阅读.使用布尔变量最终是一个不成熟的优化.
解
首先使用枚举可以防止这些问题.
enum EVehicleType { Truck, Car }
class Vehicle {
EVehicleType type;
...
}
为了适应这种情况下摩托车,所有的程序员必须做的就是添加Motorcycle到EVehicleType,并添加新的逻辑来处理摩托车案件.不需要添加新变量.不应该破坏现有的逻辑.并且不熟悉代码的人可以很容易地理解车辆的类型是如何存储的.
悬崖笔记
不要使用只能存储两种不同状态的类型,除非你绝对确定两种状态总是足够的.如果有任何可能的条件,将来需要两个以上的状态,即使布尔值满足现有要求,也请使用枚举.
has*_*sen 19
C(或C++)应该是第一种编程语言
第一种语言不应该是简单的语言,应该是建立学生思维并为严肃的计算机科学做好准备的语言.
C是完美的,它迫使学生思考内存和所有低级别的东西,同时他们可以学习如何构造他们的代码(它有功能!)
C++具有额外的优势,它真的很糟糕:)因此学生将理解为什么人们不得不想出Java和C#
bmb*_*bmb 19
您并不总是需要数据库.
如果你需要存储少于几千个"东西"并且你不需要锁定,那么平面文件可以工作并且在很多方面都更好.它们更便携,您可以手动编辑它们.如果您在数据和业务逻辑之间进行了适当的分离,则可以轻松地将平面文件替换为数据库(如果您的应用程序需要它).如果您考虑到这一点进行设计,它会提醒您在数据和业务逻辑之间进行适当的分离.
-
bmb
fiz*_*zer 17
这是多年来对我来说显而易见的一个,但对其他人来说NDEBUG却是诅咒:在'release'版本中关闭C(或C++)断言几乎总是错误的.(唯一的例外是时间或空间惩罚是不可接受的).
理由:如果断言失败,您的程序已进入状态
然而,某种程度上"行业最佳实践"是,当涉及到客户数据的实时运行时,事情应该只是糊涂并希望最好.
Sco*_*ott 17
所有源代码和注释都应该用英文编写
使用英语以外的语言编写源代码和/或注释会使其更难以重用,如果您不理解它们所使用的语言,则更难以调试.
SQL表,视图和列也是如此,尤其是在使用缩写时.如果它们没有缩写,我可能能够在线翻译表/列名称,但如果它们是缩写的,我可以做的就是SELECT并尝试解密结果.
Pau*_*oza 16
如果要在以后节省3倍的时间,只写一个抽象.
我看到人们有时会写下所有这些疯狂的抽象,我想,"为什么？"
除非抽象真的会节省你的时间,或者它会节省维护代码时间的人,但似乎人们只是越来越多地编写意大利面条代码.
tui*_*oel 16
这个词"恶"是#2和simular论坛的虐待和过度使用的词.
使用它的人想象力太少.
mar*_*ert 15
我真的不喜欢当人们告诉我使用getter和setter而不是让变量公开的时候你应该能够获得并设置类变量.
如果要改变对象中对象的变量,我完全同意它,所以你不会得到这样的东西:abcde = something; 但我宁愿使用:ax = something; 然后是a.setX(某事); 我认为ax =某事; 实际上更容易阅读,更漂亮然后在同一个例子中设置/获取.
我没有看到原因:
void setX(T x){this-> x = x; }
T getX(){return x; }
这是更多的代码,更多的时间,你一遍又一遍地做,并只是使代码更难阅读.
Jay*_*uzi 15
课程应该适合屏幕.
如果您必须使用滚动条查看所有课程,那么您的课程太大了.
代码折叠和微缩字体是作弊.
Tod*_*ich 15
最好的代码通常是你不写的代码.作为程序员,我们希望通过编写一些很酷的方法来解决每个问题.任何时候我们都可以解决问题并仍然向用户提供他们想要的80%而不需要引入更多代码来维护和测试我们已经提供了更多的价值.
the*_*tor 15
我通常持有相当有争议,强烈和响亮的意见,所以这里只有几个:
"因为我们是微软的服装/合作伙伴/专家"从来都不是一个有效的论据.
我现在工作的公司现在首先认定自己是微软的专家.所以前面提到的论点会被抛出很多,我还没有看到它有效的上下文.
我无法理解为什么在每个适用的角落推广微软的技术和产品,压倒客户和员工的满意度以及一般的语用学.
这只是我对软件业务政治的深刻仇恨的基石.
MOSS(Microsoft Office Sharepoint Server)是一块糟糕的东西.
Kinda回应了第一个意见,但老实说,我认为MOSS应该被淘汰出市场.许可和设置需要花费大量资金,对网络标准采取措施并使开发人员普遍非常不满意.我还没有看到一个总体积极成果的MOSS项目.
然而,一次又一次,客户接近我们并要求提供MOSS解决方案.
Bru*_*eod 14
开发人员不应该测试自己的软件
开发和测试是两个截然相反的学科.发展就是建筑,测试就是拆迁.有效的测试需要一种特定的思维方式和方法,在这种思维方式和方法中,您试图发现开发人员的错误,发现他们的假设漏洞以及逻辑缺陷.包括我自己在内的大多数人根本无法将自己和自己的代码放在这样的审查之下,仍然是客观的.
Otá*_*cio 13
远离Celko !!!!
http://www.dbdebunk.com/page/page/857309.htm
我认为使用代理主键然后使用"自然"主键更有意义.
@ocdecio:Fabian Pascal给出了(在他所链接的页面的第3点引用的数据库管理中的实际问题的第3章)作为选择稳定性密钥的标准之一(它始终存在且不存在)更改).当一个自然键没有这样的属性时,必须使用代理键,原因很明显,你在评论中暗示了这一点.
你不知道他写了什么,你也没有费心去检查,否则你会发现你真的同意他的看法.那里没有任何争议:他说"不要教条,适应环境的一般指导方针,最重要的是,思考,用你的大脑而不是教条/烹饪书/古茹语的方法".
sap*_*nts 13
新的Web项目应该考虑不使用Java.
我已经使用Java进行Web开发超过10年了.起初,与可用的替代方案相比,这是朝着正确方向迈出的一步.现在,有比Java更好的选择.
这实际上只是解决问题的魔锤方法的一个特例,但它真的很痛苦.
ner*_*lly 13
我有一些......所有东西都有例外,所以这些并不是很难和快,但它们确实适用于大多数情况
没有人关心您的网站是否有效,XHTML严格,符合标准,还是拥有W3C徽章.
它可能会从网络开发人员那里获得一些高五,但其他人看着你的网站可能会给你一个废话,无论你是否验证了你的代码.绝大多数网络冲浪者都在使用IE或Firefox,因为这两种浏览器都是宽容的非标准,非严格,无效的HTML,所以你真的不需要担心它.如果您为汽车经销商,机械师,广播电台,教堂或当地小型企业建立了一个站点,那么您认为这些企业的目标受众特征中有多少人关注有效的HTML？我猜测它非常接近0.
大多数开源软件都是无用的,过于复杂的废话.
让我安装一下我发现的这个很好的OSS.它看起来应该完全符合我的要求!哦等等,首先我必须安装其他窗口管理器.好.然后我需要获取此命令行工具并将其添加到我的路径.现在我需要X,Y和Z的最新运行时.现在我需要确保运行这些进程.好的,很棒......全部配置完毕.现在让我学习一组全新的命令来使用它.哦,很酷,有人为它构建了一个GUI.我想我不需要学习这些命令.等等,我需要这个库来使GUI工作.现在要下载了.好的,现在它正在工作...废话,我无法弄清楚这个可怕的用户界面.
听起来有点熟？OSS充满了复杂功能的复杂性,需要成为专家才能执行的棘手安装,以及大多数人不知道该怎么做的工具.这么多项目都被淘汰,其他项目很少,很少有人会使用它们,而一些体面的项目(FlowPlayer,OSCommerce等)有如此荒谬的过于复杂和臃肿的源代码,它无法达到目的.编辑源.您可以编辑源...如果您可以找出400个文件中的哪个包含需要修改的代码.当你得知它的全部400个时,你真的遇到了麻烦.
Eva*_*ran 13
编程还处于起步阶段.
尽管编程语言和方法已经很快发展了很多年,但我们还有很长的路要走.迹象很清楚:
语言文档随意地传播到互联网上(stackoverflow在这里帮助).
在不破坏先前版本的情况下,语言无法在语法上进化.
调试仍然经常使用printf完成.
语言库或其他形式的大规模代码重用仍然非常罕见.
很明显,所有这些都在改进,但如果我们都同意这是开始而不是结束,那将是很好的.
CAD*_*oke 13
如果你想写好的软件,那就离开你的电脑吧
与最终用户以及想要和需要该软件的人一起去聊天.只有他们才能了解您的软件需要完成什么以及它需要如何实现.
最终用户不会给老鼠的代码是多么优雅或者代码是什么语言.如果它适用于他们并且他们喜欢使用它,那么你就赢了.如果它不能让他们的生活更轻松,更好 - 他们讨厌它,你输了.
走一英里 - 然后去写你的代码.
Klu*_*uge 12
SQL可以而且应该做得更好. 由于其原始规格有限,各种供应商多年来一直在不同方向扩展语言.为MS-SQL编写的SQL与用于Oracle,IBM,MySQL,Sybase等的SQL不同.其他严肃的语言(例如以C++为例)是经过精心标准化的,因此在一个编译器下编写的C++通常在未经修改的情况下编译.为什么SQL不能更好地设计和标准化？
HTML作为浏览器显示语言是一个严重破坏的选择. 我们花了数年时间通过CSS,XHTML,Javascript,Ajax,Flash等扩展它,以便创建一个可用的UI,结果仍然不如你的基本胖客户端Windows应用程序.此外,一个称职的网络程序员现在需要知道三种或四种语言才能形成一个像样的用户界面.
哦耶.匈牙利的记法是令人厌恶的.
Kei*_*ams 12
每个开发人员都应该花几周甚至几个月的时间开发基于纸张的系统,然后再开始构建电子系统.然后他们也应该被迫使用他们的系统.
建立一个良好的纸质系统是一项艰苦的工作.它迫使你考虑到人性(繁琐的过程被忽略,太复杂的过程往往会崩溃),并教你欣赏简单的价值(新工作在这个托盘中,QA的工作在这个托盘中进行,归档在这个框中).
一旦你弄清楚如何在纸上构建系统,建立一个有效的计算机系统往往要容易得多 - 人们实际上想要(并且能够)使用这个系统.
我们开发的系统并非由训练有素的自动机系统组成; 真实的人使用它们,真正的人是由经理训练的,他们也是真正的人,并且没有多少时间浪费训练他们如何跳过你的篮球.
事实上,对于我的第二点:
应要求每个开发人员都要运行交互式培训课程,向用户展示如何使用他们的软件.
Joh*_*yre 12
大多数咨询程序员都很糟糕,不应该被允许编写生产代码.
恕我直言 - 可能约60%或更多
Chr*_*ris 12
不应允许非开发人员管理开发人员.
更正:不应允许零开发经验的员工管理开发人员.
Ski*_*izz 12
大多数程序员在编程时都没用
(你确实说'有争议')
我坐在家里的办公室里思考一些编程问题,最后我在书架上查看了我的"完整光谱ROM反汇编"副本并思考:
"今天有多少程序员可以编写Spectrum ROM中使用的代码？"
对于那些不熟悉它的人来说,Spectrum有一种基本的编程语言可以做简单的2D图形(线条,曲线),一种文件IO和浮点计算,包括转换函数,所有这些都在16K的Z80代码中(一个<5Mhz 8bit处理器)没有FPU或整数乘法).如今,大多数毕业生都难以编写一个很小的"Hello World"程序.
我认为问题在于,可以做到这一点的程序员的绝对数量几乎没有变化,但是百分比很快就会接近零.这意味着正在编写的代码质量正在下降,因为更多的低于标准的程序员进入该领域.
在我目前工作的地方,有七位程序员,包括我自己.其中,我是唯一一个通过阅读博客,书籍,这个网站等来保持最新状态并在家里进行"有趣"编程的人(我的妻子一直对此感到惊讶).还有一个程序员热衷于编写结构良好的代码(有趣的是,他使用Delphi做了很多工作)并重构了糟糕的代码.其余的都不是很好.关于它,您可以将它们描述为"暴力"程序员 - 将强制使用不合适的解决方案,直到它们以一种方式工作(例如,使用带有重复array.Resize的C#数组来动态添加项而不是使用List).
现在,我不知道我现在所在的地方是否典型,尽管从我以前的职位我会说它是.事后看来,我可以看到一些常见的模式肯定对任何项目没有帮助(缺乏对一个代码的同行评审).
因此,7名程序员中有5名是垃圾.
Skizz
Mar*_*Ray 12
应弃用大于运算符(>,> =)
我尝试使用优先级低于大于一段时间的编码而且它会卡住!我不想回去,事实上我觉得每个人都应该按照我的方式去做.
考虑常见的数学"范围"表示法:0 <= i <10
现在很容易在代码中进行近似,你习惯于看到变量在中间加入的习惯用法由&&加入:
if (0 <= i && i < 10)
return true;
else
return false;
一旦你习惯了这种模式,你就永远不会看到愚蠢
if ( ! (i < 0 || i >= 9))
return true;
再次以同样的方式.
长关系序列变得更容易使用,因为操作数倾向于非递减顺序.
此外,operator<C++标准中还有一个偏好.在某些情况下operator=是根据它来定义的!(如!(a<b || b<a))
ian*_*sme 12
软件就像卫生纸.你花在它上的越少,它就越痛苦.
也就是说,外包很少是个好主意.
我一直认为这是真的,但直到最近我才真正知道它的程度.我最近一直在"维护"(读取:"修复")一些离线代码,这是一个巨大的混乱.如果我们公司内部开发的差异很大,这很容易使我们公司付出代价.
业务范围之外的人本身就会对您的业务模式了解较少,因此无法为您的业务中的任何系统编程.而且,他们知道他们不需要支持它,所以没有动力做任何事情而不是半屁股.
klo*_*cks 11
在允许初级程序员实际编写或修改代码之前,应指派初级程序员进行几个月的对象/模块设计和设计维护.
太多的程序员/开发人员在没有理解优秀设计元素的情况下达到了5年和10年的标记.当他们想要超越仅仅编写和维护代码时,它可能会瘫痪.
小智 11
随机收集库克的格言......
最难学的语言是你的第二语言.
最难学习的操作系统是你的第二个 - 特别是如果你的第一个是IBM大型机.
一旦你学会了几种看似不同的语言,你终于意识到所有的编程语言都是一样的 - 只是语法上的细微差别.
虽然在没有学习任何装配的情况下,人们可以非常高效和有市场,但如果没有它,没有人会对计算有一种内在的理解.
调试器是程序员的最后避难所,他们一开始并不真正知道他们在做什么.
如果没有使用硬件内存管理,操作系统就不会稳定.
低级系统编程比应用程序编程容易得多.
拥有最喜欢的语言的程序员正在玩.
首先写下用户指南!
政策和程序适用于那些缺乏主动执行的人.
(承包商的信条):告诉他们他们需要什么.Give'em他们想要什么.确保检查清除.
如果你没有找到有趣的节目,那就放弃它或者接受它虽然你可以以它为生,但你永远不会超过平均水平.
就像旧的屁必须学习.NET方法名称一样,你必须学习库调用.但那里没有什么新东西.
程序员的生活是不断适应不同环境的生活方式,你挂在皮带上的工具越多,你就会越多才多艺.
你可能会在开头附近用一点代码块来尝试一些想法,但是,一般来说,在你知道整个程序或应用程序将如何布局之后,你不会开始认真编码,而你知道整件事情会像宣传的那样完全奏效.对于大多数具有至少一定程度复杂性的项目,我通常最终花费60%到70%的时间来预测想法.
理解编程与语言无关,与算法有关.所有这些令人难忘的缩略词都是人们多年来提出的令人难忘的缩略词,这些只是不同的方式来实现实施猫皮.当你剥离所有的OOPiness,RADology,Development Methodology 37和Best Practice 42时,你仍然需要处理以下基本构建块:
一旦你能真正完成这一切,你最终会看到(从编程的角度来看)为汽车零部件公司编写库存应用程序,图形化实时TCP性能分析器,数学之间的差别.恒星核心模型或约会日历.
rba*_*all 11
这个主要是网络相关但...
使用表格进行网页布局
如果我正在开发一个需要压缩性能的巨型网站,我可能会考虑它,但没有什么能让我更方便地在浏览器上看到一致而不是表格.我开发的大多数应用程序大约有100-1000个用户,最多可能有100个用户.表的额外膨胀并没有以任何方式杀死我的服务器.
Mis*_*ble 11
编码不打字
编写代码需要时间.大多数情况下,在编辑器窗口中,您只是查看代码,而不是实际输入.不经常,但经常,你删除你写的东西.或者从一个地方搬到另一个地方.或重命名.
如果你长时间敲击键盘,你做错了什么.
推论:每天编写的代码行数不是程序员生产率的线性度量,因为程序员一天写入100行很可能是一个更好的程序员,然后是编写20行的程序员,但写入5000的程序员肯定是糟糕的程序员
Bil*_*l K 11
90%的程序员都是非常糟糕的程序员,几乎我们所有人都没有工具来评估我们当前的能力水平(虽然我们通常可以回顾并意识到我们用来吮吸的程度有多糟糕)
我不会发布这个,因为它会让所有人失望,而我并没有真正想要得分,但是:
A)不是问题的关键所在,而且
B)这个帖子中的大多数"答案"证明了这一点
前几天我听到了一个很好的类比:编程能力与运动能力差别很大.我们中有多少人可以跳进专业团队并真正提高他们的机会？
Kei*_*ith 11
作为开发线经理,估算对我来说是一个有用的工具,可以计划我的团队正在进行的工作.
它们不是特定日期的功能交付的承诺,它们不是推动团队更努力工作的坚持.
恕我直言,如果你强迫开发人员承诺估计你得到最安全的数字.
例如 -
我认为一个功能可能需要大约5天.问题的可能性很小,需要30天.
如果估算仅用于规划,那么我们将全部工作到5天,并说明问题发生的可能性很小.
但是 - 如果需要满足该估算作为交付承诺,您认为会给出什么估计？
如果开发人员的奖金或工作保障取决于达到估计值,您认为他们会给出最准确的猜测,还是他们最肯定会得到的？
我的这种观点与其他管理层存在争议,并被解释为我试图摆脱正确的目标,或者我试图掩盖糟糕的表现.每次都很难卖,但我已经习惯了.
Kei*_*han 11
我不知道它是否真的有争议,但是这个怎么样:方法和函数名称是你的代码可以有的最好的评论; 如果您发现自己正在编写注释,请将您正在评论的代码片段转换为函数/方法.
这样做有一个令人愉快的副作用,迫使你很好地分解你的程序,避免评论很快就会变得与现实不同步,给你一些你可以grep代码库的东西,并留下你的代码带有新鲜的柠檬气味.
Roa*_*ior 10
创建类似于具有疯牛病的椒盐卷饼的UML图的能力实际上不是有用的软件开发技能.
图表代码的重点是可视化连接,以查看设计的形状.但是,一旦你通过了相当低的复杂程度,可视化对于精神上的处理来说太过分了.如果你坚持使用直线,那么以图形方式进行连接只会很简单,这通常使得图表比连接被巧妙地分组并沿着基本方向布线更难阅读.
仅将图表用于广泛的通信目的,并且仅在它们被理解为谎言时使用.
Kor*_*nel 10
selfPython的方法声明中明确的是糟糕的设计选择.方法调用得到了语法糖,但声明没有.这是一个漏洞抽象(按设计!)导致恼人的错误,包括运行时错误,报告的参数数量中有明显的一个错误.
Jer*_*all 10
我有争议的意见？Java并不吸引Java API.为什么java库坚持要做简单的任务呢？为什么他们不是修复API,而是创建框架来帮助管理样板代码？此意见适用于需要10行或更多行代码才能从文件中读取一行的任何语言.
Sta*_*kii 10
任何具有足够功能的库都太复杂而无法使用,并且任何简单到可用的库都缺乏成为良好通用解决方案所需的能力.
我经常跑到这里.使用起来非常复杂的穷举库我撕掉了我的头发和简单易用的库,这些库不能满足我的需要.
Spo*_*oBo 10
大多数开发人员都没有线索
是的..你去.我说过了.我发现我个人都知道的所有开发人员......实际上只有少数人真的很好.只有少数人明白代码应该被测试......面向对象的开发方法实际上可以帮助你.令我感到沮丧的是,有些人获得了开发人员的称号,而事实上他们所能做的只是复制并粘贴一些源代码然后执行它.
无论如何......我很高兴像stackoverflow这样的计划正在启动.对开发人员来说,这很好奇.有没有更好的办法？我做得对吗？也许我可以使用这种技术加快速度等等......
但是没有......大多数开发人员只是学习他们的工作所需的语言,并坚持使用它,直到他们自己变老,脾气暴躁的开发人员不知道发生了什么.他们所得到的只是一大笔薪水,因为他们只比你年长.
好吧...... IT社区的生活是不公正的,我将在未来采取措施忽视这些人.万岁!
Jon*_*han 10
编码是一门艺术
有些人认为编码是一门艺术,而另一些人则认为编码是一门科学.
"科学"派认为,目标是获得情境的最优代码,然后编码是研究如何获得这种最优的科学.
"艺术"派系认为,有很多方法可以获得最佳的情境代码,这个过程充满了主观性,而根据自己的技能和经验明智地选择是一门艺术.
Mar*_*rkR 10
使软件可配置是一个坏主意.
可配置软件允许最终用户(或管理员等)选择太多选项,可能并非所有选项都已经过测试(或者更确切地说,如果数量非常少,我可以保证不会进行测试).
所以我认为软件的配置是硬编码的(但不一定是回避常量等),只是一个好主意.使用合理的默认值运行,并且不允许改变它们.
一个很好的例子是Google Chrome上的配置选项数量 - 但是,这可能仍然太多了:)
JL.*_*JL. 10
像SharePoint这样的Intranet框架让我觉得整个企业界都是一头巨大的鸵鸟
我不仅在这里谈论MOSS,我还与其他一些企业INTRANET产品合作,绝对不是其中一个很好,但SharePoint(MOSS)是迄今为止最糟糕的.
每个人仍然继续使用和购买SHAREPOINT,管理人员仍然非常难以预防它不是SATANS SPAWN.
微格式
使用最初为可视化布局设计的CSS类 - 现在被分配给可视化和上下文数据是一种破解,充满了模糊性.不是说功能不应该存在,而是修复该死的基本语言.HTML并没有被黑客攻击来生成XML - 而是出现了XML语言.现在我们有这些急切的脚本小子黑客攻击HTML和CSS来做一些它不打算做的事情,那仍然很好,但我希望他们能把这些东西留给自己,而不是制定标准.只是为了一些 - 屠杀!
我的唯一:
长切换语句是你的朋友.真.至少在C#中.
人们倾向于避免和阻止他人使用长切换语句,因为他们"无法管理"和"具有糟糕的性能特征".
好吧,问题是在C#中,switch语句总是自动编译为散列跳转表,因此如果你需要简单的分支到多个分支,实际使用它们就性能而言是最好的东西.此外,如果案例陈述被智能地组织和分组(例如按字母顺序),则它们根本不是难以管理的.
Rob Pike写道:"数据占主导地位.如果你选择了正确的数据结构并组织好的东西,算法几乎总是不言而喻.数据结构,而不是算法,是编程的核心."
从那时起,任何严肃的数据都存在于数百万条记录中,我认为良好的数据建模是最重要的编程技能(无论是使用rdbms还是像sqlite或amazon simpleDB或google appengine数据存储一样.)
当数据(所有数据)存储在这样的数据存储系统中时,不再需要花哨的搜索和排序算法.
Web应用程序很糟糕
我的互联网连接很慢.我对几乎所有非Google网站的体验至少令人沮丧.为什么没有人再写桌面应用程序了？原来如此.没有人想要了解操作系统的工作原理.至少,不是Windows.你最后一次处理WM_PAINT,你的头爆炸了.创建一个工作线程来执行一项长任务(我的意思是,以Windows方式执行)完全超出了你.到底是什么回调？哦,我的上帝!
垃圾收集很糟糕
不,它实际上没有.但这让程序员们别无选择.在大学里,他们教给我们的第一语言是Visual Basic(原始语言).在那之后,还有另一个课程让老师假装他们教我们C++.但损坏已经完成.实际上没有人知道如何使用这个深奥的关键字delete.在测试我们的程序之后,我们得到了无效的地址异常或内存泄漏.有时候,我们都得到了.在我可以实际编程的1%的教师中,只有一个能够自己管理自己的记忆(至少,他假装)并且他正在写这个咆哮.其余的用VB.NET编写程序,根据定义,这是一种糟糕的语言.
动态打字很糟糕
当然,除非你正在使用汇编程序(这种动态类型实际上值得称赞).我的意思是动态的解释语言带来的开销使它们很糟糕.并且不要带着那种愚蠢的论点,即不同的工具对不同的工作有益.C是几乎所有东西的正确语言(它快速,强大和便携),而当它不是(它不够快)时,总是内联汇编.
我可能会提出更多的咆哮,但那将是更晚,而不是现在.
需求分析,规范,设计和文档几乎从不适合"模板". 你可以100%的时间从一个空白文档开始,并开始输入"我将以这样的方式解释这个问题,如果我死了,其他人阅读这个文档,他们会知道我的一切现在知道,看到和理解"然后从那里组织,让章节标题自然地发展并适应你指定的任务,而不是受限于某些企业或学校对你的文档应该是什么样子的想法.如果你必须做一个图表,而不是使用某人的正式和不可理解的系统,你通常最好只绘制一个有意义的图表,带有一个清晰的图例,它实际上指定了你试图指定的系统并传达信息那个开发人员在另一端(通常是你,
[如果必须的话,一旦你写完了真实的文档,你就可以经常将它塞进你的组织对你施加的任何模板紧身衣中.但是,您可能会发现自己必须添加章节标题和复制材料.
这些文档的唯一时间模板是有意义的,当你有大量的任务本质上非常相似,只是细节不同."编写程序以允许通过此调制解调器组进行一次性远程登录访问,使用C-Kermit驱动终端连接nexus,""生成容量使用的历史趋势和预测报告","使用此库为所有报告提供能够传真,""修复2000年问题的代码,"和"在此表中添加数据库触发器以填充由第三方供应商为我们提供的软件产品" 不能无论人们怎么想,都可以用同一个模板来描述.为了记录,我的大学课程试图教我和我的同学的要求和设计图表技术不能用来指定一个简单的计算器程序(每个人都知道它).
对于一个好的程序员来说语言不是问题.
这可能是不太controvertial,但我听到了很多Ø从其他程序员抱怨,如"为什么不都用delphi？","C#很烂",等等"如果他们强迫我用java我会改变公司" .
我认为一个优秀的程序员是灵活的,能够用他生命中可能需要学习的任何编程语言编写好的程序
有时跳上这个潮流是可以的
我厌倦了那些展示"爷爷综合症"的人("你们孩子和你们新奇的测试驱动开发. 过去十年中出现的每一项重大技术都已经糟透了.在我的日子里,我们写了真正的代码!"......你得到了这个想法).
有时,受欢迎的东西很受欢迎是有原因的.
VB 6可以用于善恶.在过度复杂的编码时,它是一个快速应用程序开发环境.
我过去一直非常讨厌VB,并且由于我不喜欢经典的VB,仍然嘲笑VB.NET(可能是开玩笑)作为Fisher Price语言,但在当时,没有什么比完成工作更能打败它.
代码生成很糟糕
我讨厌需要你使用代码生成(或复制和粘贴)来处理简单事情的语言,比如JavaBeans及其所有Getter和Setter.
C#的AutoProperties是朝着正确方向迈出的一步,但对于具有Fields,Properties和Constructor参数的精美DTO,您仍然需要大量冗余.
小智 9
编程既不是艺术,也不是科学.这是一门工程学科.
这不是艺术:编程需要创造力.这不是艺术.代码的设计和编写是为了正常工作,而不是在情感上移动.除了空格外,为了美观原因而更改代码会破坏您的代码.虽然代码可以很漂亮,但艺术不是主要目的.
这不是科学:科学和技术是不可分割的,但编程属于技术范畴.编程不是系统的研究和观察; 它是设计和实施.
这是一门工程学科:程序员设计和构建东西.优秀的程序员设计功能.他们了解不同实施方案的权衡,并选择适合他们所解决问题的方案.
我确信有些人会喜欢解析文字,扩展艺术和科学的定义,包括编程或仅限于机械机器或硬件的工程.检查字典.此外,"计算机程序设计的艺术"是艺术的不同用法,意思是技巧或工艺,如"谈话的艺术".编程的产物不是艺术.
小智 8
我们使用我们构建的模型 - 视图 - 控制器框架在这里进行了大量的开发.我经常告诉我的开发人员我们需要违反MVC设计模式的规则,以使网站运行得更快.对于开发人员来说,这是一个很难卖的东西,他们通常不愿意为任何事情牺牲精心设计的代码.但性能是构建Web应用程序的首要任务,因此有时我们必须在框架中做出让步.
例如,视图层永远不应该直接与数据库对话,对吧？但是,如果要生成大型报告,应用程序将使用大量内存通过模型和控制器层传递数据.如果您有一个支持游标的数据库,它可以使应用程序更快地从视图层直接访问数据库.
性能胜过开发标准,这是我有争议的观点.
我相信使用try/catch异常处理比使用简单的返回代码和相关的常见消息传递结构来传递有用的错误消息更糟糕.
使用try/catch块的乱码代码不是解决方案.
只是将异常传递到堆栈上,希望你上面会做正确的事情或产生信息错误不是解决方案.
认为您有可能系统地验证正确的异常处理程序是否可以解决透明或异常对象中可能出错的任何问题是不现实的.(还可以考虑后期绑定/外部库以及随着系统的发展而在调用堆栈中不相关的函数之间的不必要的依赖性)
返回代码的使用很简单,可以很容易地系统地验证覆盖率,如果处理得当,则迫使开发人员生成有用的错误消息,而不是过于常见的堆栈转储和模糊的I/O异常,这些异常甚至对于"异常"无意义最有感染力的最终用户.
-
我最后的反对意见是使用垃圾收集语言.不要误解我的意思..我喜欢它们在某些情况下,但一般来说,对于服务器/ MC系统,它们在我看来并不存在.
GC不是可以消化的 - 即使是设计得非常好的GC算法也会依赖于它们的依赖图中非显而易见的循环引用而长时间甚至永久地挂起对象.
遵循一些简单模式和使用内存记帐工具的非GC系统没有这个问题,但在设计和测试方面需要比GC环境更多的工作.这里的权衡是在非GC中测试期间很容易发现内存泄漏,同时发现GC相关问题条件是一个更加困难的主张.
内存很便宜但是当您泄漏昂贵的对象(例如事务句柄,同步对象,套接字连接等)时会发生什么.在我的环境中,如果没有软件描述中的重大变化,您可以只是坐下来让语言为您担心这一点是不可想象的.
小智 8
在发现每个缺陷时纠正它们.不只是"严重性1"缺陷; 所有缺陷.
建立一种部署机制,使用户可以立即使用应用程序更新,但允许他们选择何时接受这些更新.与用户建立直接沟通机制,使他们能够报告缺陷,将他们的经验与更新联系起来,并提出改进建议.
通过积极的测试,可以在创建它们的迭代过程中发现许多缺陷; 立即纠正它们可以减少开发人员中断,这是创建缺陷的重要因素.立即纠正用户报告的缺陷,形成建设性的社区,以产品改进取代产品质量作为主要话题.实施与您的愿景和战略一致的用户建议的改进产生了热情的福音传播者社区.
Web服务绝对是糟透了,而不是未来的方式.它们效率低得离谱,并不保证有序交付.永远不要在写入客户端和服务器的系统中使用Web服务.它们主要用于micky mouse mash-up类型的应用程序.绝对不应该用于任何类型的面向连接的通信.
这种立场让我和同事们进行了一些非常激烈的讨论,因为网络服务是一个如此热门话题.任何要求使用网络服务的项目都注定要失败,因为它显然已经从管理层那里得到了荒谬的要求.
小智 8
不断测试
你必须编写测试,你必须先写它们.编写测试会改变编写代码的方式.它让你想到你想要它实际做什么之后,你只需要跳进去写一些除了你想做的事情之外的事情.
它还为您提供了目标.看着你的测试变成绿色,可以让你获得额外的信心,让你获得完美的成就.
它还为您的边缘案例编写测试提供了基础.由于您在开始时编写了针对测试的代码,因此您可能需要在代码中使用一些钩子进行测试.
没有理由不测试你的代码.如果你不这样做,你只是懒惰.我还认为你应该先测试,因为好处超过了这种编码所需的额外时间.
开发人员过度使用数据库
开发人员经常将数据存储在应该在代码或文件中的DBMS中.我已经看到一个存储"系统密码"的单列一行表(与用户表分开.)我已经看到存储在数据库中的常量.我见过数据库会让成年人变得更加困惑.
令人不快的编码员对DBMS有某种神秘的敬畏 - 数据库可以做任何事情,但他们不知道它是如何工作的.DBA实践黑人艺术.它还允许责任转移:"数据库太慢", "数据库做到了" ,其他借口很常见.
如果不加以控制,这些程序员将继续开发数据库 - 系统内系统.(这个反模式有一个名字,但我忘了它是什么.)
编程:这是一项有趣的工作.
我似乎看到两个广义的开发人员组.那些不喜欢它,但他们是有能力的,钱是好的.另一群喜欢它的人有点令人毛骨悚然.这似乎是他们的生活.
我认为这项工作通常很有趣且很有趣.每天都有各种各样的空间来学习新的东西.我想不出我想要的另一份工作.但它仍然是一份工作.妥协将被制定,你生产的东西并不总是那么好.
鉴于我的笨蛋将在海滩上喝啤酒或与我的孩子一起玩.
在我的工作(复制保护系统)中,汇编程序编程是必不可少的,我正在使用许多hll复制保护系统,只有汇编程序才能真正有效地利用代码中隐藏的所有可能性(如代码变异,低级别的东西).
此外,许多代码优化只能通过汇编程序编程,查看任何视频编解码器的来源,使用汇编程序编写源代码并优化使用MMX/SSE/SSE2操作码,许多游戏引擎使用汇编程序优化的例程,甚至Windows内核也是如此SSE优化程序:
NTDLL.RtlMoveMemory
.text:7C902CD8 push ebp
.text:7C902CD9 mov ebp, esp
.text:7C902CDB push esi
.text:7C902CDC push edi
.text:7C902CDD push ebx
.text:7C902CDE mov esi, [ebp+0Ch]
.text:7C902CE1 mov edi, [ebp+8]
.text:7C902CE4 mov ecx, [ebp+10h]
.text:7C902CE7 mov eax, [esi]
.text:7C902CE9 cld
.text:7C902CEA mov edx, ecx
.text:7C902CEC and ecx, 3Fh
.text:7C902CEF shr edx, 6
.text:7C902CF2 jz loc_7C902EF2
.text:7C902CF8 dec edx
.text:7C902CF9 jz loc_7C902E77
.text:7C902CFF prefetchnta byte ptr [esi-80h]
.text:7C902D03 dec edx
.text:7C902D04 jz loc_7C902E03
.text:7C902D0A prefetchnta byte ptr [esi-40h]
.text:7C902D0E dec edx
.text:7C902D0F jz short loc_7C902D8F
.text:7C902D11
.text:7C902D11 loc_7C902D11: ; CODE XREF: .text:7C902D8Dj
.text:7C902D11 prefetchnta byte ptr [esi+100h]
.text:7C902D18 mov eax, [esi]
.text:7C902D1A mov ebx, [esi+4]
.text:7C902D1D movnti [edi], eax
.text:7C902D20 movnti [edi+4], ebx
.text:7C902D24 mov eax, [esi+8]
.text:7C902D27 mov ebx, [esi+0Ch]
.text:7C902D2A movnti [edi+8], eax
.text:7C902D2E movnti [edi+0Ch], ebx
.text:7C902D32 mov eax, [esi+10h]
.text:7C902D35 mov ebx, [esi+14h]
.text:7C902D38 movnti [edi+10h], eax
因此,如果您下次听到汇编程序已经死亡,请考虑您观看的最后一部电影或您玩过的游戏(及其复制保护功能).
自己写它可能是一个有效的选择.
根据我的经验,在使用第三方代码解决问题时似乎有太多的热情.自己解决问题的选择通常不会跨越人们的思想.虽然不要误会我的意思,但我并没有宣传永远不会使用库.我所说的是:在您考虑使用的可能框架和模块中,添加自己实施解决方案的选项.
但为什么要编写自己的版本？
最后一点值得商榷.
关系数据库系统将是切片面包以来最好的事情......
......当我们(希望)得到它们时,就是这样.SQL数据库很难吸收它并不好笑.
我觉得有趣(如果悲伤)是经过认证的DBA,他们认为SQL数据库系统是一个关系型数据库系统.说出所述认证质量的数量.
困惑？阅读CJ Date的书籍.
编辑
为什么它被称为关系,这个词是什么意思？
这些天,具有强大(heck,any)数学背景的程序员(或经过认证的DBA,wink)是一个例外,而不是常见的情况(我也是常见案例的一个例子).SQL及其表,列和行,以及称为实体/关系建模的笑话只会增加对伤害的侮辱.难怪由于实体(表)之间的某些关系(外键？)而被称为关系数据库系统的误解是如此普遍.
实际上,Relational源于关系的数学概念,因此与集合论和函数密切相关(在数学中,而不是任何编程,意义上).
[ http://en.wikipedia.org/wiki/Finitary_relation][2]:
在数学中(更具体地说,在集理论和逻辑中),关系是将真值分配给k个人的组合(k元组)的属性.通常,该属性描述了k元组的组件之间的可能连接.对于给定的一组k元组,根据属性是否成立,将真值分配给每个k元组.
三元关系(即个人,三者之间)的一个例子是:" X被引入到Ÿ由Ž ",其中(X,Y,Z)是人的3元组; 例如,"Beatrice Wood被Marcel Duchamp介绍给Henri-PierreRoché"是真的,而"Karl Marx被维多利亚女王介绍给Friedrich Engels"是错误的.
维基百科非常清楚:在SQL DBMS中,这样的三元关系将是一个" 表 ",而不是" 外键 "(我冒昧地重命名关系的"列":X = who,Y = to,Z = by):
CREATE TABLE introduction (
who INDIVIDUAL NOT NULL
, to INDIVIDUAL NOT NULL
, by INDIVIDUAL NOT NULL
, PRIMARY KEY (who, to, by)
);
此外,它将包含(其中可能),这个" 行 ":
INSERT INTO introduction (
who
, to
, by
) VALUES (
'Beatrice Wood'
, 'Henri-Pierre Roché'
, 'Marcel Duchamp'
);
但不是这个:
INSERT INTO introduction (
who
, to
, by
) VALUES (
'Karl Marx'
, 'Friedrich Engels'
, 'Queen Victoria'
);
关系数据库字典:
关系(数学)给定集合s1,s2,...,sn,不一定是不同的,r是这些集合的关系,当且仅当它是一组n元组时,每个元组都有来自s1的第一个元素,它的第二个元素来自s2的元素,依此类推.(等价地,r是笛卡尔乘积s1 x s2 x ... x sn的子集.)
Set si是r的第i个域(i = 1,...,n). 注意:数学关系和关系模型对应关系之间存在几个重要的逻辑差异.这里是其中的一些:
- 数学关系对其属性有从左到右的排序.
- 实际上,无论如何,数学关系充其量只是一个非常基本的属性概念.当然,他们的属性没有被命名,除了他们的序数位置.
- 因此,数学关系在关系模型意义上并不真正具有标题或类型.
- 数学关系通常是二元的,偶尔也是一元的.相比之下,关系模型中的关系是n阶,其中n可以是任何非负整数.
- 诸如JOIN,EXTEND等关系运算符首先在关系模型的上下文中具体定义; 关系的数学理论包括很少这样的算子.
等等(前面的内容并不是一个详尽的清单).
在我参与的许多项目中,在一开始就花了很多精力在Microsoft Word中编写"规范".当这个大型镜头买进项目时,这个过程最终达成了一个"签署"会议,在那次会议之后,没有人再次看过这个文件.这些文档完全是浪费时间,并不反映软件的实际设计方式.这并不是说应用程序设计没有其他有价值的工件.它们通常包含在索引卡,白板快照,鸡尾酒餐巾纸和其他类似媒体上,为应用程序设计提供了一种时间表.这些通常是应用程序的真实规格.如果你要写一个Word文档,(我并不是特别说你应该)在项目结束时这样做.
大多数编程求职面试问题毫无意义.特别是程序员所想出的那些.
这是一个常见的情况,至少根据我和我的朋友的经验,一个膨胀的程序员,问你一些棘手的wtf他花了几周谷歌搜索.有趣的是,你回家并在一分钟内谷歌.这就像他们经常试图用他们先进的武器来打败你,而不是检查你是否是一个全面,务实的团队合作者.
类似的愚蠢IMO就是当你被要求提供高度可访问的基础知识时,例如:"等等,让我看看你是否可以insert_name_here在一张纸上伪编码 - 算法(原文!)".在申请高级编程工作时,我真的需要记住它吗？我应该有效地解决问题或难题吗？
工具,方法,模式,框架等不能替代经过适当培训的程序员
我厌倦了与人(主要是经理)打交道,他们认为最新的工具,方法,模式或框架是一个银弹,将消除雇用有经验的开发人员编写软件的需要.虽然,作为一名拯救风险项目的顾问,我不应该抱怨.
小智 7
最简单的方法是最好的方法
程序员喜欢解决假定或推断的需求,这些需求会增加解决方案的复杂程度.
"我认为这段代码将成为性能瓶颈,因此我将添加所有这些额外的代码来缓解这个问题."
"我认为用户会想要做X,因此我会添加这个非常酷的附加功能."
"如果我让我的代码解决这个不必要的场景,那将是一个很好的机会,可以使用我一直有兴趣尝试的新技术."
实际上,满足要求的最简单的解决方案是最好的.如果出现新的要求或问题,这也为您提供了最大的灵活性,使您的解决方案朝着新的方向发展.
小智 7
例外情况只应用于特殊情况
在我最近开展的项目中,似乎使用例外情况已经猖獗.
这是一个例子:
我们有拦截Web请求的过滤器.过滤器调用筛选器,筛选器的工作是检查请求是否具有某些输入参数并验证参数.设置要检查的字段,抽象类确保参数不为空,然后调用特定类实现的screen()方法进行更多的扩展验证:
public boolean processScreener(HttpServletRequest req, HttpServletResponse resp, FilterConfig filterConfig) throws Exception{
//
if (!checkFieldExistence(req)){
return false;
}
return screen(req,resp,filterConfig);
}
checkFieldExistance(req)方法永远不会返回false.如果没有任何字段丢失,则返回true,如果缺少字段则抛出异常.
我知道这是糟糕的设计,但问题的一部分是这里的一些建筑师认为每次遇到意外事件时都需要抛出异常.
另外,我知道checkFieldExistance(req)的签名确实抛出了一个Exception,它只是我们几乎所有的方法都做了 - 所以我没有想到该方法可能抛出异常而不是返回false.直到我挖出代码才发现它.
有争议的呃？我认为C++流使用<<和>>这一事实.我讨厌它.他们是轮班经营者.以这种方式重载它们是非常糟糕的做法.这让我想要杀死那些提出这个想法的人,并认为这是一个好主意.哎呀.
"评论是谎言"
评论不会运行,很容易被忽视.最好用单元测试说明的清晰的重构代码来表达意图.(单元测试TDD当然......)
我们不写评论,因为它们冗长而且模糊了代码中真正发生的事情.如果您觉得需要发表评论 - 找出代码中不清楚的内容并重构/编写更清晰的测试,直到不需要评论为止......
...我从极限编程中学到的东西(当然假设你已经建立了清理代码的团队规范......)
Modern C++是一门优美的语言.
在那里,我说了.很多人真的很讨厌C++,但老实说,我发现使用STL/Boost风格编程的现代C++在大多数时候都是一种非常富有表现力,优雅且极其富有成效的语言.
我认为大多数讨厌C++的人都是基于OO的糟糕体验.C++不能很好地执行OO,因为多态通常依赖于堆分配的对象,而C++没有自动垃圾回收.
但是,当涉及通用库和函数编程技术时,C++确实很有用,这使得构建非常大,高度可维护的系统成为可能.很多人都说C++会尝试做所有事情,但最终却什么都不做.我可能同意它不像其他语言那样做OO,但它比任何其他主流的基于C语言更好地进行泛型编程和函数式编程.(C++ 0x只会进一步强调这一事实.)
我也很欣赏C++如何让我在必要时获得低级别,并提供对操作系统的完全访问权限.
加上RAII.认真.当我使用其他基于C语言编程时,我真的很想念析构函数.(不,垃圾收集不会使析构函数变得无用.)
不是真正的编程,但我不能仅仅为了它而忍受css布局.它反效果,令人沮丧,并使维护成为浮动和边缘的噩梦,改变单个元素的位置可能会使整个页面失控.
这绝对不是一个流行的观点,但我已经完成了我的桌面布局在20分钟,而css大师花了几个小时调整行高,边距,填充和浮动只是为了做一些基本的垂直居中的段落.
我坚信非托管代码不值得麻烦.与追踪内存泄漏相关的额外可维护性开支,即使是最好的程序员偶尔引入也远远超过从C++这样的语言中获得的性能.如果Java,C#等无法获得所需的性能,请购买更多的机器.
小智 6
全球和/或单身人士本身并不是邪恶的
我来自更多的sysadmin,shell,Perl(和我的"真正的"编程),PHP类型的背景; 去年我被扔进了Java开发工具.
单身人士是邪恶的.全球是如此邪恶,甚至不被允许.然而,Java有像AOP这样的东西,现在有各种"依赖注入"框架(我们使用的是Google Guice).AOP少了,但DI的东西肯定会给你什么？全局.呃,谢谢.
你不应该满足于找到"有效"代码的第一种方式.
我真的不认为这应该是有争议的,但确实如此.人们在代码的其他地方看到了一个例子,来自在线,或者从1999年开始的一些旧的"自学高级功能SQLJava#BeansServer在3.14159分钟"一书中看到的一个例子,他们认为他们知道一些东西并将它们复制到他们的代码中.他们没有通过示例来了解每条线的作用.他们没有考虑他们的程序的设计,看看是否可能有更有条理或更自然的方式来做同样的事情.他们没有试图保持他们的技能组合最新,以了解他们正在使用在上一个千年的最后一年中弃用的想法和方法.他们似乎没有经验去了解他们的'
事实上,他们似乎甚至没有意识到可能有不止一种方法可以做某事.
我来自Perl世界,其中一个标语是"有多种方法可以做到".(TMTOWTDI)粗略看过Perl的人把它写成"只写"或"不可读",很大程度上是因为他们看过上面描述的思维模式的人编写的糟糕代码.那些人没有考虑设计,可维护性,组织,减少代码重复,耦合,内聚,封装等等.他们写了废话.这些人存在各种语言的编程,易于学习的语言有很多方法可以为他们提供足够的绳索和枪支来自杀.同时.
但是如果你在Perl世界中徘徊的时间超过粗略的外观,并观察社区中的长时间人在做什么,你会看到一个了不起的东西:优秀的Perl程序员花一些时间寻找最好的做某事的方法.当他们命名一个新模块时,他们会四处询问建议并将他们的想法从人们身上反弹.他们将代码交给他们进行查看,批评和修改.如果他们必须做一些令人讨厌的事情,他们会以最小的方式将其封装在一个模块中,以便以更有条理的方式使用.同一个想法的几个实现可能会暂时搁置一段时间,但它们竞争思想共享和市场份额,并且他们通过努力做到最好来竞争,其中很大一部分是通过使自己易于维护.真正优秀的Perl程序员似乎觉得 很难对他们在做什么,并寻求做的事情最好的办法,而不是仅仅抓住通过他们的大脑掠过的第一个想法.
今天我主要在Java世界中编程.我已经看到了一些非常好的Java代码,但是我也看到了很多垃圾,我看到了我在开头描述的更多心态:人们解决了第一个似乎有用的丑陋代码,而不了解它,没有想到是否有更好的方法.
您将在每种语言中看到两种心态.我并不是要特意谴责Java.(实际上我在某些方面非常喜欢它......也许这应该是我真正有争议的意见!)但我相信每个程序员都需要花费几年的时间来使用TMTOWTDI风格的语言,因为即使传统观念认为这导致混乱和蹩脚的代码,它实际上似乎产生了一些人,他们明白你需要考虑你正在做的事情的影响,而不是相信你的语言是为了让你做正确的事情不费吹灰之力.
我认为你可以在另一个方向上走得太远:即完美无视你的真正需求和目标的完美主义(通常是你企业的真正需求和目标,通常是盈利能力).但是,如果没有学会投入一些超过平均水平的努力来考虑寻找最佳(或至少一种最好的)方式来编码他们正在做的事情,我认为任何人都不能成为一个真正伟大的程序员.
意见:不应该有任何编译器警告,只有错误.或者,以不同的方式表达您应始终使用-Werror编译代码.
原因:编译器认为它应该被纠正,以防它应该是一个错误,或者没有必要修复,在这种情况下编译器应该关闭.
VB糟透了
虽然一般来说并不是非常有争议,但当你在VB的房子里工作的时候却是如此
关系数据库是浪费时间.请改用对象数据库!
关系数据库供应商试图欺骗我们相信世界上唯一可扩展,持久和安全的存储是关系数据库.我是经过认证的DBA.您是否曾花费数小时尝试优化查询并且不知道出了什么问题？关系数据库不允许您在需要时创建自己的搜索路径.您可以将对应用程序速度的大部分控制权交给您从未见过的人,而且他们并不像您想象的那么聪明.
当然,有时在维护良好的数据库中,他们会为复杂的查询提供快速答案.但是你付出的代价太高了!每次要读取数据条目时都必须选择编写原始SQL,这很危险.或者使用Object关系映射器,它会增加更多的复杂性和控制之外的东西.
更重要的是,您被积极禁止提出智能搜索算法,因为每次该数据库的往返都需要大约11毫秒.实在是太多了.想象一下,你知道这个超级图算法会在适当的时候回答一个特定的问题,这个问题在SQL中甚至可能无法表达.但即使你的算法是线性的,有趣的算法也不是线性的,忘记将它与关系数据库结合起来,因为枚举大表会花费你几个小时!
与SandstoneDb或Gemstone for Smalltalk相比!如果你是Java,请给db4o一个机会.
所以,我的建议是:使用object-DB.当然,它们并不完美,有些查询会变慢.但是你会惊讶地发现有多少会更快.因为加载对象不需要SQL和域数据之间的所有这些奇怪的转换.如果你真的需要某个查询的速度,对象数据库就有你应该信任的查询优化器:你的大脑.
两个大脑比一个好
我坚信,在提高代码质量和编程效率方面,结对编程是最重要的因素.不幸的是,对于那些认为"更多的手=>更多代码=> $$$!"的管理层来说,这也是一个极具争议性的问题.
由于有数百个答案可能最终未读完,但不管怎样,这是我的宠儿.
这个网站对于程序员来说是一个非凡的资源,但如果您正在寻找XHTML/CSS帮助,这绝对是一个非常糟糕的地方.即使是优秀的Web开发人员也会发布90年代优秀资源的链接!
当然,XHTML和CSS很容易学习.但是,你不只是学习一门语言!您正在学习如何使用它,很少有设计人员和开发人员可以做到这一点,更不用说程序员了.我花了很长时间才成为一名有能力的设计师,甚至更长时间成为一名优秀的开发人 我可以从10岁起编写HTML代码,但这并不意味着我很好.现在我是Photoshop和Illustrator等程序的有能力的设计师,我完全能够在记事本中编写一个好的网站,并且能够用多种语言编写基本脚本.不仅如此,我对搜索引擎优化技术有着良好的认识,并且很容易告诉你大多数人出错的地方(提示:获得一些好的内容!).
此外,这个地方是一个可靠的资源,可以提供有关Web标准的建议.您不应该只编写代码以在不同的浏览器中工作.您应始终遵循标准,以便将来验证您的代码.在下一次浏览器更新出现时,您在网站上使用的修补程序通常会中断.不仅如此,好的浏览器还是遵循标准.最后,IE被允许破坏互联网的原因是因为你允许它通过为IE编码你的网站!如果你要继续为Firefox做这个,那么我们将再次失败!
如果您认为基于表格的布局同样好,如果不比CSS布局好,那么您不应该被允许谈论这个主题,至少在没有我先击败你的情况下.此外,如果您认为W3Schools是送别人的最佳资源,那么您就是完全错误的.
如果您是Web Design/Development的新手,请不要打扰这个地方(它充满了程序员,而不是Web开发人员).去SitePoint这样的网页设计/开发社区.
这不是工具,而是你
每当开发人员尝试做一些新的事情,比如做UML图表,任何类型的图表,项目管理,他们首先寻找解决问题的完美工具.经过无休止的搜索,找不到合适的工具,他们的动机挨饿 剩下的就是关于缺乏可用软件的抱怨.有鉴于此,有组织的计划在没有软件的情况下就会死亡.
嗯,只有你自己处理组织.如果您习惯于组织,您可以在有或没有软件的帮助下(大多数没有)进行组织.如果您不习惯组织,没有人可以帮助您.
所以"没有合适的软件"只是没有组织的最简单的借口.
反射在生产代码中没有位置
反射破坏了静态分析,包括重构工具和静态类型检查.反思也打破了开发人员对代码的正常假设.例如:向类中添加一个方法(不会影响类中的其他方法)应该永远不会产生任何影响,但是当使用反射时,其他一些代码可能会"发现"新方法并决定叫它.实际上确定这样的代码是否存在是难以处理的.
我认为在代码生成器中使用反射和测试很好.
是的,这确实意味着我试图避免使用反射的框架.(Java缺乏正确的编译时元编程支持,这太糟糕了)
垃圾收集被高估了
许多人认为在Java中引入垃圾收集是与C++相比最大的改进之一.我认为介绍最好是非常小的,编写良好的C++代码在适当的位置(使用RAII等技术)完成所有内存管理,因此不需要垃圾收集器.
不要害羞,抛出异常. 异常是一种完全有效的信号失效方式,并且比任何返回代码系统都要清晰得多."Exceptional"与这种情况发生的频率无关,而且与该类认为正常执行条件的内容有关.当除数为零时抛出异常就好了,无论情况发生的频率如何.如果问题可能发生,请保护您的代码,以便不会使用不正确的参数调用该方法.
在许多情况下,使用正则表达式解析HTML很好
每当有人在Stack Overflow上发布一个问题,询问如何使用正则表达式实现一些HTML操作时,第一个答案是"正则表达式是一个不足以解析HTML的工具,所以不要这样做".如果提问者试图建立一个网络浏览器,这将是一个有用的答案.然而,通常提问者想要做一些事情,比如在某个域的所有链接上添加一个rel标记,通常是在可以对传入标记的样式做出某些假设的情况下,这是一个非常合理的事情.一个正则表达式.
手动暂停程序是一种有效且经过验证的查找性能问题的方法.
可信的？不是最重要的.真正？绝对.
程序员比必要的判断更多.
在这些帖子中见证所有被认为是"邪恶"或"可怕"的事物.
程序员对数据结构感到满意.
见证所有关于类,继承,私有 - 公共,内存管理等的讨论,以及如何分析需求.
默认情况下,数组应该是基于1而不是基于0. 这不一定是系统实现语言的情况,但像Java这样的语言吞噬了比它们应有的更多的C奇怪."元素1"应该是第一个元素,而不是第二个元素,以避免混淆.
计算机科学不是软件开发.毕竟,你不会雇用一名只研究物理的工程师.
尽可能多地学习数学.您不会使用大部分内容,但您需要能够以这种方式擅长软件.
标准化的单一最佳编程语言是Common Lisp,即使它很冗长且具有从零开始的数组.这很大程度上来自于被设计为一种编写计算的方式,而不是作为冯·诺依曼机器的抽象.
编程语言的所有比较批评中至少有90%可以简化为"语言A具有特征C,我不知道如何在语言B中使用C或类似的东西,因此语言A更好."
"最佳实践"是我所见过的最令人印象深刻的拼写"平庸"的方式.
转到没关系!(这是有争议的)
有时......所以给我们选择!例如,BASH没有goto.也许有一些内部原因,但仍然.
此外,goto是汇编语言的构建块.不,如果你的声明!:)
意见:数据驱动设计将推车置于马前.它应该从我们的思想中消除.
绝大多数软件不是关于数据,而是关于我们试图为客户解决的业务问题.它涉及一个问题领域,涉及对象,规则,流程,案例和关系.
当我们使用数据开始设计,并在数据和数据(表,外键和x-to-x关系)之间的关系之后对系统的其余部分进行建模,我们将整个应用程序约束为数据的方式存储在数据库中并从数据库中检索.此外,我们将数据库体系结构暴露给软件.
数据库模式是一个实现细节.我们应该可以自由地改变它,而不必显着改变我们软件的设计.业务层永远不必知道如何设置表,或者是从视图或表中提取表,还是从动态SQL或存储过程中获取表.这种类型的代码永远不会出现在表示层中.
软件是关于解决业务问题.我们处理用户,汽车,帐户,余额,平均值,摘要,转移,动物,消息,包裹,购物车,订单以及各种其他真实有形物品,以及我们可以对它们执行的操作.我们需要根据需要保存,加载,更新,查找和删除这些项目.有时,我们必须以特殊方式做这些事情.
但是,没有真正令人信服的理由我们应该在数据库中完成应该完成的工作并将其从数据中移除并将其放入源代码中,可能在单独的机器上(引入网络流量和降低性能).这样做意味着要背弃已经完成的数十年的工作,以提高内置于数据库中的存储过程和函数的性能.存储过程引入"另一个API"的论点是好奇的:当然它确实存在; 该API是一个屏蔽了数据库模式的外观,包括主键和外键,事务,游标等的复杂细节,它可以防止您必须在源代码中将SQL拼接在一起.
把马放回购物车前面.考虑问题域,并围绕它设计解决方案.然后,从问题域派生数据.
不是很有争议的AFAIK,但...... 在这个词被创造出来之前,AJAX已经走了,每个人都需要"放手". 人们把它用于各种各样的事情.但是没有人真正关心它.
然后突然POW!有人创造了这个词,每个人都加入了AJAX的行列.突然之间,人们现在成为AJAX的专家,好像动态加载数据的"专家"之前并不存在.我认为这是导致互联网残酷破坏的最大因素之一.那和"Web 2.0".
原始数据类型是过早优化.
只有一种数据类型,即标量可以获得语言,并且它们可以正常运行.其他语言并不是那么幸运.开发人员只是抛出"int"和"double",因为他们必须写一些东西.
重要的不是数据类型有多大,而是数据的用途.如果你有一个月中的某一天变量,如果它是有符号或无符号的,或者它是char,short,int,long,long long,float,double还是long double,则无关紧要.重要的是它是一个月中的某一天,而不是一个月,或一周中的某一天,或者其他什么.请参阅乔尔的专栏,了解错误的事情; 最初提出的匈牙利符号是一个好主意.在实践中使用它,它几乎没用,因为它说错了.
继承是邪恶的,应该弃用.
事实上,聚合在所有情况下都更好.静态类型的OOP语言无法避免继承,它是描述类型所需方法的唯一方法.但动态语言和鸭子打字可以没有它.Ruby mixins比继承更强大,更可控.
Variable_Names_With_Bloody_Underscores
甚至更糟
CAPITALIZED_VARIABLE_NAMES_WITH_BLOODY_UNDERSCORES
应该全球覆盖......有偏见!CamelCapsAreJustFine.(Glolbal常数不能承受)
GOTO声明供11岁以下的开发人员使用
任何不支持指针的语言都不值得这个名字
.Net = .Bloat微软为网站开发所做的最好的例子(Expressionless Web 2)是有史以来写的慢速膨胀的最好的例子.(尝试使用Web Studio)
回复:好的,让我稍微解决一下Underscore问题.从您提供的C链接:
- 全局常量应该全部带有'_'分隔符.这我真的同意,因为它是如此BLOODY_OBVIOUS
- 例如NetworkABCKey.注意来自ABC的C和来自键的K是如何混淆的.有些人不介意这个,有些人只是讨厌它,所以你会在不同的代码中找到不同的政策,所以你永远不知道该怎么称呼.
我属于前一类.我非常谨慎地选择名字,如果你不能一眼就知道K属于Key那么英语可能不是你的第一语言.
C函数名称
理由
* It makes C functions very different from any C++ related names.
例
int some_bloody_function(){}
这些"标准"和惯例只是随着时间推移而作出的任意决定.我认为,虽然它们具有一定的逻辑意义,但它们会使代码变得杂乱无章,并使一些应该简短易读的东西,笨拙,长篇大论和杂乱无章.
C已被采纳为事实上的标准,不是因为它很友好,而是因为它很普遍.我可以使用语法友好的高级语言在20中编写100行C代码.
这使得程序流程易于阅读,众所周知,在一年或更长时间后重新访问代码意味着在整个地方跟踪面包屑.
我确实使用下划线,但对于全局变量,因为它们很少而且很远,它们很明显.除此之外,经过深思熟虑的CamelCaps()函数/变量名称还没让我失望!
大多数"用户友好的"第四代语言(包括SQL)都是毫无价值的高估垃圾,这些垃圾本来就不应该被普遍使用.
4GL通常具有冗长而模糊的语法.尽管4GL应该允许"非技术人员"编写程序,但仍然需要"技术"人员来编写和维护它们.
一般来说,4GL程序更难编写,更难阅读,更难以优化.
应尽可能避免使用4GL.
调试器是一个拐杖.
它是如此有争议,甚至我不像以前那么相信它.
Con:我花了更多的时间来快速了解其他人的大量代码,所以任何有助于"我是如何到达这里"和"正在发生的事情"的任何事实要么是验尸还是验尸都有帮助.
亲:但是,我很高兴地认为,如果你不理解你自己开发的代码或者你熟悉的代码的那些问题的答案,那么把所有时间花在调试器上都不是解决方案,它是部分问题.
在点击"发布你的答案"之前,我对这个确切的短语进行了快速谷歌检查,结果发现我并不是唯一持有这种观点或使用过这句话的人.我在Fog Creek软件论坛上对这个问题进行了长时间的讨论,该论坛引用了包括Linus Torvalds在内的各种名人作为值得注意的支持者.
小智 5
关注点分离是邪恶的:)
如果你有充分的理由,只能单独关注.否则,请勿将它们分开.
我只是为了分离而遇到过多次分离.Dijkstra的声明"最小耦合,最大凝聚力"的下半部分不应该被遗忘.:)
很高兴再次讨论这个问题.
我讨厌大学和研究所为新来的人提供编程教学的短期课程.对艺术1和编程科学来说,这是完全的耻辱和蔑视.
他们开始向人们教授C,Java,VB(恶心),而没有很好地掌握计算机的硬件和基本原理.应首先通过Morris Mano的计算机系统架构等书籍讲授机器,然后教授指导机器解决问题的概念,而不是蚀刻语义和一种编程语言的语法.
另外,我不了解政府学校,大学教授儿童使用商业操作系统和软件的计算机基础知识.至少在我的国家(印度),没有多少学生购买操作系统,甚至折扣办公套装,更不用说开发软件的主宰(编译器,IDE等).这会引发盗窃和盗版,并使这种从其机构图书馆复制和窃取软件的行为成为合理的行为.
他们再次被教导使用一些产品而不是基本的想法.
想一想,如果你只被教导2x2是4而不是乘法的概念？
或者,如果你现在被教导要测量倾向于学校某些复合墙的杆的长度而不是毕达哥拉斯定理
在软件设计和开发方面,设计模式是浪费时间.
不要误解我的意思,设计模式很有用,但主要是作为通信载体.他们可以非常简洁地表达复杂的想法:工厂,单件,迭代器......
但它们不应该作为一种发展方法.开发人员经常使用一系列基于设计模式的类来构建他们的代码,在可读性和性能方面,更简洁的设计会更好.所有这些都表明个别类可以在其域外重用.如果一个类不是为重用而设计的,或者不是接口的一部分,那么它就是一个实现细节.
应该使用设计模式将名称放在组织特征上,而不是指定必须编写代码的方式.
(这应该是有争议的,还记得吗？)
Microsoft Windows是软件开发的最佳平台.
推理: 微软以优秀且廉价的开发工具破坏其开发人员,该平台及其API已有详细记录,平台正以惊人的速度发展,为开发人员创造了大量机会.操作系统拥有庞大的用户群,这对于明显的商业原因,有一个很大的Windows开发者社区,我还没有因为选择微软而被解雇.
保持业务逻辑不受数据库限制.或者至少保持它非常精益.让DB做它想做的事情.让代码执行代码的目的.期.
如果你是一个男人的表演(基本上,傲慢和自负,不仅因为你在控制中不听别人的智慧),你可以按照自己的意愿行事.因为你要求开始,我不相信你是那样的.但是在涉及这个主题时我遇到了一些,并且觉得有必要指明.
如果您使用DBA但您自己的数据库工作,请在业务对象,它们与数据库之间的网关以及数据库本身之间保持明确定义的分区.
如果您与DBA一起工作并且不允许执行您的数据库工作(无论是通过策略还是因为它们都是premadonnas),您就非常接近于成为一个傻瓜,依赖于它们来完成任何工作数据库实体中的业务逻辑(sprocs,函数等).
如果您是DBA,请让开发人员保持他们的数据库实体清洁和精益.
BAD IDE使编程语言变弱
良好的编程IDE确实能够更容易地使用某些语言并且更好地监督.我的职业生涯中有点被宠坏了,我工作的公司总是有最新的Visual Studio可供使用.
大约8个月,我在我的工作旁边做了很多Cocoa,Xcode编辑器使用这种语言太困难了.超载很难找到,处理打开文件的总体方式只会让你的屏幕变得非常麻烦,非常快.这真是一种耻辱,因为Cocoa是一种很酷且功能强大的语言.
当然顽固的Xcode粉丝现在会投票支持我的帖子,但是有很多IDE真的好多了.
人们转向IT,谁不应该
这是我去年发布的博客文章的复制/粘贴.
我的经验主要是关于荷兰市场,但它们也可能适用于任何其他市场.
我们(因为我将所有软件工程师组合在一起)目前处于一个对我们来说非常好的市场.无论价格如何,公司都在拼命地试图获得软件工程师(从现在开始的SE).如果您现在切换工作,您可以要求几乎任何您想要的东西.在荷兰,现在有一种趋势,就是让2辆租赁汽车找到工作,只是为了让你为他们工作.这有多奇怪？我怎么能同时驾驶2辆车？
当然这对我们来说听起来很不错,但这也造成了一种非常不健康的情况.
例如:如果你目前正在为一家快速发展的公司工作而你正在努力吸引更多的同事,最终从地面开始进行一些严肃的软件开发,那么在没有提供高薪的情况下就找不到任何人.试图找到优质的同事是非常困难的.由于工资很高,很多人都被我们的工作所吸引,但这也意味着很多没有正确激情的人正在进入我们的市场.
激情,是的,我认为这是正确的词.当你对工作充满热情时,你的工作不会在05:00 PM停止.您将整夜刷新所有开发RSS源.您将在互联网上搜索可能在工作中使用的最新技术.你将在一个月内开始大约十几个新的"有前途"的项目,看看你是否可以掌握几周前你刚刚阅读的最新技术(并找到实际使用该技术的有用方法).
如果没有这种激情,市场可能看起来非常好(因为汽车,金钱,当然还有我们吸引的辣妹),但我认为它不会那么有趣,让我们说:消防员或战斗机飞行员.
听起来我想在这里保护自己的工作,部分原因是这样.但我也试图保护自己免受我不想与之合作的人的伤害.我想就我读到的内容进行激烈的讨论.我希望能够和那些对我的工作具有同样"热情"的人保持激情.我希望有正确理由与我合作的同事.
我在找那些人在哪里!!
小智 5
没有人关心你的代码
如果您没有参与政府安全检查项目并且您没有融资,那么很可能没有人关心您在公司/客户群之外的工作.没有人嗅探包或试图入侵你的机器来阅读你的源代码.这并不意味着我们应该对安全性轻率,因为肯定会有许多人只是想要造成一般性破坏并破坏您的辛勤工作,或者访问贵公司可能拥有的存储信息,例如信用卡数据或身份数据.块.但是,我认为人们过分关注其他人访问您的源代码并采纳您的想法.
记事本是一个完美的文本编辑器.(有时用于非Windows换行的键盘)
我知道真正相信这一点的人!然而,他们将使用IDE进行开发,但继续使用记事本来完成其他任务!
应要求所有项目经理都有编码任务
在我工作过的团队中,项目经理实际上是一名程序员,他能够很好地理解代码的技术问题以完成编码任务,所做出的决策缺少通信在项目经理不参与的团队中发生的情况.在代码中.
从长远来看,开源软件的成本更高
对于常规的业务线公司,开源看起来是免费的,但隐藏成本.
当您考虑到质量,可变可用性和UI/UX的不一致性,互操作性和标准的困难,增加的配置,相关的培训和支持需求增加时,开源的总体拥有成本远高于商业产品.
精通技术的程序员类型解放开源并随之运行; 他们"得到它"并且可以采用它并根据他们的目的进行定制.另一方面,主要是非技术性但需要软件来运行其办公室,网络和网站的企业面临着一个自己痛苦的世界的风险,以及在时间,生产力和(最终)支持方面的巨大成本费用和/或放弃体验的费用.
编写广泛的规范是徒劳的.
编写正确的程序非常困难,但编译器,调试器,单元测试,测试器等可以检测并消除大多数错误.另一方面,当您编写具有与程序(即伪代码,UML)相当的详细程度的规范时,您大多数都是您自己的.如果您有一个可以帮助您正确理解语法的工具,请认为自己很幸运.
广泛的规范很可能是错误的.
作者在第一次尝试时得到它的机会大致相同,就像一个类似的大型程序在没有经过测试的情况下无错误的机会.同行评论消除了一些错误,就像代码审查一样.
较低的camelCase是愚蠢和无意义的
使用较低的camelCase使名称/标识符(从这一点使用的"名称")看起来像一个由两部分组成的东西.然而,Upper CamelCase清楚地表明所有单词都属于一起.
匈牙利表示法是不同的 ...因为名称的第一部分是类型指示符,因此它与名称的其余部分具有不同的含义.
有些人可能认为较低的camelCase应该用于函数/过程,特别是在类内部.这在Java和面向对象的PHP中很流行.然而,没有理由这样做,表明他们是类方法,因为BY THE WAY访问它们就变得比明确的多,这些都是这一点.
一些代码示例:
# Java
myobj.objMethod()
# doesn't the dot and parens indicate that objMethod is a method of myobj?
# PHP
$myobj->objMethod()
# doesn't the pointer and parens indicate that objMethod is a method of myobj?
Upper CamelCase对类名和其他静态名称很有用.所有非静态内容都应该通过访问它们的方式来识别,而不是通过它们的名称格式(!)来识别
这是我的同源代码示例,其中名称行为由除名称之外的其他内容指示...(另外,我更喜欢使用下划线来分隔名称中的单词).
# Java
my_obj = new MyObj() # Clearly a class, since it's upper CamelCase
my_obj.obj_method() # Clearly a method, since it's executed
my_obj.obj_var # Clearly an attribute, since it's referenced
# PHP
$my_obj = new MyObj()
$my_obj->obj_method()
$my_obj->obj_var
MyObj::MyStaticMethod()
# Python
MyObj = MyClass # copies the reference of the class to a new name
my_obj = MyObj() # Clearly a class, being instantiated
my_obj.obj_method() # Clearly a method, since it's executed
my_obj.obj_var # clearly an attribute, since it's referenced
my_obj.obj_method # Also, an attribute, but holding the instance method.
my_method = myobj.obj_method # Instance method
my_method() # Same as myobj.obj_method()
MyClassMethod = MyObj.obj_method # Attribute holding the class method
MyClassMethod(myobj) # Same as myobj.obj_method()
MyClassMethod(MyObj) # Same as calling MyObj.obj_method() as a static classmethod
所以,我对camelCase的完全ob主观意见.
程序员需要与客户交谈
一些程序员认为他们不需要与客户交谈.对于贵公司而言,这是一种肯定的方式,可以写出一些绝对精彩的东西,没有人可以解决它的用途或者如何使用它.
您不能指望产品经理和业务分析师做出所有决策.实际上,程序员应该在创建模块或功能的1000个(通常很小的)决策中做出990,否则产品将永远不会发货!因此,请确保您的决定得到通知.了解您的客户,与他们合作,观看他们使用您的软件.
如果你要编写最好的代码,你希望人们使用它.感兴趣的是你的用户群,并从那里的"愚蠢的白痴"中学习.不要害怕,他们真的会爱你.
| 归档时间： |
|
| 查看次数： |
285409 次 |
| 最近记录： |