我最近读了http://simpleprogrammer.com/2013/02/17/principles-are-timeless-best-practices-are-fads/,它引起了我的共鸣。我发现更有经验的程序员/架构师违背了当前的最佳实践,他们的借口是一些最佳实践不适用于他们的问题领域。例如,我刚开始作为程序员为一家新公司工作,我的架构师在UI层中编写他的nhibernate查询,而不是在一个单独的层中编写它。我有一部分人知道这一点,因为这与我5年来在互联网上读到的所有东西都不一样,但我很愿意尝试这种方法,权衡正反两方面。谁知道呢,也许他是对的。我确实发现他是一个非常组件的程序员。
原则与最佳实践的区别(如果有的话)是什么?如何区分两者,以及如何确定什么时候忽略两者都是合适的?
发布于 2013-03-15 15:49:08
不要把它看作是原则和最佳实践。在我写关于MVVM的书的过程中(我可以说它是一个无耻的插件,但它还没有出来),我想出了一个类推。就像在艺术中,从古至今都有各种各样的运动,在软件工程中也有一定的运动。就像你可以通过飞行的支撑和玫瑰花窗户识别一个哥特式大教堂,或者通过它的可见的笔触和开放的构图来识别印象派绘画,这样你就可以通过寻找特定的元素来识别跟随某种软件运动的代码。
MVVM运动以视图模型为核心,后面的代码最少,函数封装在命令中,并通过事件聚合器将消息解耦。这些组件的结构方式有一种美。
那些遵循领域驱动设计的人创建了丰富的域对象,并且在对象的核心中嵌入了持久性、无知和逻辑。
CQRS的支持者将他们的域模型分离成一个查询和命令模型,也称为读模型和写模型。他们喜欢通过消息总线同时更新事务存储和查询存储来使用异步调用。更喜欢一个叫做“最终一致性”的概念。
这些运动的“最佳实践”并不是在全球范围内适用的,而是或多或少与运动相一致的属性。当新的运动上升到支配地位,旧的运动逐渐消失,它们将不再突出,但这并不意味着一个运动的技术将不会对后续的运动有用。
的原理是什么?
正如这篇文章所说,无论发生什么运动,原则都是在全球适用的。想想鲍勃叔叔 固体原理吧。或者“四人帮”的组合重于继承。这些原则几乎适用于任何地方。几乎成了关键词。
当然,您不能将OO原则应用于函数式编程。你可以,但它们有不同的形式。一旦你有了足够的经验,你就会知道什么时候一个原则不适用。(如果你不需要问“它在这里适用吗”,你就会知道如果你有足够的经验,你就会知道它不看专家级的德雷福斯技能获取模型,你不需要这些原则.它们在那里,但你不依赖它们来做决策)。
同样,一旦你使用某种方法或编程风格获得了专业知识,你就会开始在这种风格中添加你自己的触觉。例如,我和其他一些MVVM先驱同时和独立“发现”了代表命令模式 (我们都称它为同一件事,除了乔希史密斯,他称他的RelayCommand,这实际上是代表的同义词)。
摘要中的
原则是对缺乏经验的开发人员的指导,以帮助他们通过规则进行决策。
“最佳实践”或代码样式是为遵循这种风格的人提供一致性和熟悉性的开发方法。
当你“不知道而知道”时,你就会知道什么时候忽略每一个都是合适的。
发布于 2013-03-15 15:45:04
原则与最佳实践的区别(如果有的话)是什么?
实践通常是具体而具体的,文章中的例子将包括源代码控制、单元测试、持续集成和其他一些想法,虽然概念可能是抽象的,但有一些具体的工具可以用来演示正在使用的工具。例如,Subversion可用于源代码管理,nUnit用于单元测试,Cruise Control.Net用于持续集成。
另一方面,一项原则则比较模糊,因而不那么有形。列出以下四个想法的敏捷宣言:
因此,虽然我们可以举一个具体的例子,看看这些文件是否被应用,但是没有足够的工具来显示,“嘿,我们使用的是全面的文档,因为我们使用X!”尽管我上面提到的实践都有一些工具,但这些工具可能是试金石。
如何区分两者,以及如何确定什么时候忽略两者都是合适的?
在我看来,这是一个层次的细节。在应用一个想法时,一个人想要的具体程度是多少?高层次有原则,低层次有实践。
至于当它是适当的忽略任何一个,这是你必须看一个案件的基础上。例如,如果我正在编写一个脚本,用于生成一些我可能只使用一次的测试数据,那么我是否值得花费几个小时来规划它、构建单元测试和应用大量额外的开销,而我所能做的就是花半个小时来编写这个脚本,运行它,然后在我完成之后提交数据。这将更多地关注实践,因为这些实践更容易看出哪些地方值得应用,因为有时在小事情上,设置在其他环境中有用的各种实践可能不值得。原则可能更难给出一个具体的例子。
在本文中,如何赢得朋友和影响他人被引用为有原则的,这里有一些要考虑的问题,通过这些方法来赢得人们的思考:
12种方法来赢得人们对你的思维方式
虽然这是一个很好的清单,但值得注意的是,这里的一些想法可能有点矛盾。例如,是否有一种友好的方式来拒绝挑战?也许有更友好的方法,但在试图让一个人接受挑战的过程中,有一些话可以让人舒展一下自己。这本书中还有一套可能也值得回顾的观点:
做领导:如何在不冒犯或不引起怨恨的情况下改变人
请注意其中一些是如何相似的。第七条,“给别人一个好名声”,类似于第一张单子中的第12条,“放下挑战”,这可能证明了大多数人都有一种内在的战斗本能,有时也可以使用。同样,注意每个列表中的数字3是关于承认一个人的错误,这可能是关于谦逊的原则。
https://softwareengineering.stackexchange.com/questions/190686
复制相似问题