Questions tagged «design»

我正在阅读“编码员在工作”，并且面对这样一个事实，书中接受采访的一些专业人员对设计模式并不那么热心。 我认为有两个主要原因： 设计模式迫使我们以其术语进行思考。换句话说，几乎不可能发明新的东西（也许更好）。 设计模式不会永远持续下去。语言和技术日新月异；因此，设计模式最终将变得无关紧要。 因此，也许更重要的是学习如何在没有任何特定模式的情况下正确编程，而不要学习它们。 重点还在于，通常当人们遇到问题并且没有太多时间时，他们会尝试使用一种模式。这意味着只需稍作更改即可将现有代码复制并粘贴到您的项目中，以使其正常工作。当需要更改或添加某些内容时，开发人员不知道从哪里开始，因为这不是他的代码，而且他对代码也不是很熟悉。

107 design  design-patterns 

我试图养成定期用我的代码编写单元测试的习惯，但是我已经读过第一件事，编写可测试的代码很重要。 这个问题涉及编写可测试代码的SOLID原则，但是我想知道这些设计原则是否有益（或至少无害），而根本不计划编写测试。需要澄清的是-我了解编写测试的重要性；这不是它们有用性的问题。 为了说明我的困惑，在启发这个问题的那篇文章中，作者给出了一个检查当前时间并根据时间返回一些值的函数示例。作者指出这是错误的代码，因为它会产生内部使用的数据（时间），因此很难进行测试。但是，对我而言，将时间作为争论似乎有点过头了。在某个时候需要初始化值，为什么不最接近消耗量呢？另外，在我看来，该方法的目的是基于当前时间返回一些值，通过将其设为参数，您可以暗示可以/应该更改此目的。这个问题以及其他问题使我想知道可测试的代码是否与“更好的”代码同义。 即使在没有测试的情况下，编写可测试的代码是否仍然是一种好习惯？ 可测试的代码实际上更稳定吗？建议重复。但是，这个问题与代码的“稳定性”有关，但是我在更广泛地询问代码是否由于其他原因（例如可读性，性能，耦合性等）是否优越。

103 design  unit-testing  testing  tdd 

在第25页的“代码完成”中，据说可以用命令行轻松替换常规用户界面类是一个好主意。 知道其测试优势，它可能带来什么问题呢？ 这项额外的工作真的能为Web和移动项目带来回报吗？中小型项目呢？相同的规则适用吗？如果这会使您的设计更复杂怎么办？

92 design  architecture  user-interface  command-line 

例如，过去的SysInternals工具“ FileMon”具有内核模式驱动程序，其源代码完全位于一个4,000行文件中。有史以来第一个ping程序也是如此（〜2,000 LOC）。

88 design  c  source-code 

在Alex Papadimoulis的这篇文章中，您可以看到以下片段： private void attachSupplementalDocuments() { if (stateCode == "AZ" || stateCode == "TX") { //SR008-04X/I are always required in these states attachDocument("SR008-04X"); attachDocument("SR008-04XI"); } if (ledgerAmnt >= 500000) { //Ledger of 500K or more requires AUTHLDG-1A attachDocument("AUTHLDG-1A"); } if (coInsuredCount >= 5 && orgStatusCode != "CORP") { //Non-CORP orgs …

87 design 

我已经进行了9年以上的编程工作，并且根据我的第一位编程老师的建议，我始终将我的main()函数保持得非常简短。 起初我不知道为什么。我只是听从而不理解，这让我的教授们非常高兴。 在获得经验之后，我意识到，如果我正确地设计了代码，则具有短main()函数的情况就会发生。编写模块化代码并遵循单一职责原则，使我的代码可以“分批”设计，并且main()无非是推动程序运行的催化剂。 快到几周前，我正在查看Python的源代码，然后找到了该main()函数： /* Minimal main program -- everything is loaded from the library */ ... int main(int argc, char **argv) { ... return Py_Main(argc, argv); } 是的python。短main()函数==良好的代码。 编程老师是对的。 想深入了解一下，我看了一下Py_Main。整个定义如下： /* Main program */ int Py_Main(int argc, char **argv) { int c; int sts; char *command = NULL; char …

87 design  code-quality 

人们常常可以听到，OOP自然对应于人们对世界的思考方式。但是我强烈不同意这种说法：我们（或者至少我）根据我们遇到的事物之间的关系来概念化世界，但是OOP的重点是设计各个类及其层次结构。 注意，在日常生活中，关系和动作主要存在于对象之间，这些对象本来是OOP中无关类的实例。这样的关系的示例是：“我的屏幕在桌子的顶部”；“我（一个人）坐在椅子上”；“道路上有汽车”；“我正在键盘上打字”；“咖啡机煮水”，“文本显示在终端窗口中”。 我们以二价（有时是三价，例如“我给你送花”一词）动词来思考，其中动词是对两个对象进行操作以产生某种结果/动作的动作（关系）。的焦点是关于动作，两个（或三个）[语法]对象具有同等的重要性。 与OOP相反，在OOP中，您首先必须找到一个对象（名词），并告诉它对另一个对象执行某些操作。思维方式从对名词进行操作的动作/动词转变为对名词进行操作的名词-好像一切都是被动或反身的声音所说的，例如，“文本正在终端窗口中显示”。或者也许是“文本在终端窗口上绘制自身”。 不仅焦点转移到了名词上，而且一个名词（我们称其为语法主语）比另一个名词（语法对象）具有更高的“重要性”。因此，必须决定是说terminalWindow.show（someText）还是someText.show（terminalWindow）。但是，当一个人真正表示show（terminalWindow，someText）时，为什么要给这些琐碎的决定加重负担却又没有任何操作后果呢？[结果在操作上无关紧要-在两种情况下，文本都显示在终端窗口上-但是在类层次结构的设计中可能非常严重，并且“错误”的选择可能导致复杂的代码和难以维护的代码。] 因此，我要指出，进行OOP（基于类，单派遣）的主流方法很困难，因为它是不自然的，并且与人类对世界的看法不符。CLOS的通用方法更接近于我的思维方式，但是，可惜，这不是普遍的方法。 鉴于这些问题，为什么/为什么发生当前流行的OOP方式如此流行？可以采取什么行动来废除王位呢？

86 design  design-patterns  object-oriented 

您在所建议的软件设计中始终从根本上正确吗？当您给出一些根本上是错误的设计时，您往往会失去团队成员的尊重。无论您做什么，之后都会对您在事件发生后提出的所有建议进行交叉检查。当您刚加入团队并且他们不知道您的过去并取得了一些成功的故事时，情况尤其糟糕。 也许您设计不好的原因是由于在该领域缺乏经验或知识或两者都不是。面对这种情况的您如何处理？这就像是您职业生涯中的一回事吗？是将其抛在后面还是在这种情况下需要寻找新的工作方式？请提供一些诚实的反馈... 谢谢。

84 design 

DRY是软件开发中最基本且被广泛接受的原则之一（请不要重复自己）。同样清楚的是，大多数软件项目都需要某种管理。 现在有哪些易于管理的任务（估算，计划，控制）？正确的重复性任务，正是按照DRY应该避免的任务。 因此，从项目管理的角度来看，最好通过将现有代码复制100次并根据需要对每个副本进行一些较小的改动来解决任务。在任何时候，您都确切知道您已经完成了多少工作，还剩下多少。所有的经理都会爱你。 相反，如果您应用DRY原理并尝试找到某种或多或少消除重复代码的抽象，则情况有所不同。通常情况下有很多可能性，您必须做出决定，进行研究，发挥创造力。您可能会在较短的时间内提出更好的解决方案，但是您也可能会失败。大多数时候，您无法真正说出还剩下多少工作。您是项目经理的噩梦。 我当然在夸张，但显然存在两难选择。我的问题是：决定开发人员是否过度使用DRY的标准是什么？我们如何找到一个妥协的解决方案？还是有一种方法可以完全克服这一难题，而不仅仅是找到折衷方案？ 注意：此问题基于与我上一个主题相同的思想，即软件开发中的日常工作量及其对估计的影响，但我认为这使我的观点更加清楚，非常抱歉重复我的一遍:)。

83 design  project-management  estimation  technical-debt 

我觉得我擅长一点一点地编写代码，但是我的设计确实很糟糕。问题是，我该如何改善设计，进而成为更好的设计师？ 我认为学校在教授人们如何善于解决数学问题方面做得很好，但让我们承认一个事实，即在学校创建的大多数应用程序的长度通常约为1000-2000行，这意味着这大部分是学术活动并不能反映现实世界软件的复杂性-大约几十万到几百万行代码。 在这里，我认为，即使像topcoder / project euler这样的项目也不会有太大帮助，它们可能会提高您的数学问题解决能力-但您可能会成为一名学术程序员；对精美，干净的东西更感兴趣的人，对大多数应用程序程序员处理的日常琐事和毛茸茸的东西完全不感兴趣。 所以我的问题是如何提高我的设计技能？也就是说，设计中小型应用程序的能力是否会涉及几千行代码？如何学习设计技巧，以帮助我构建更好的html编辑器套件或gimp等图形程序？

83 design  skills 

在设计系统时，我经常面临使其他模块使用大量模块（日志记录，数据库访问等）的问题。问题是，如何将这些组件提供给其他组件。似乎有两个答案可能是依赖注入或使用工厂模式。但是，两者似乎都错了： 工厂使测试变得痛苦，并且不允许轻易交换实现。它们也不会使依赖关系变得明显（例如，您正在检查一个方法，而忽略了它调用的方法会调用使用数据库的方法的事实）。 Dependecy注入使构造函数的参数列表大量膨胀，并且在代码的所有部分涂上了污点。典型情况是一半以上类的构造函数如下所示(....., LoggingProvider l, DbSessionProvider db, ExceptionFactory d, UserSession sess, Descriptions d) 这是我遇到的一个典型情况：我有异常类，这些异常类使用从用户数据库中加载的错误描述，并使用在用户会话对象中具有用户语言设置参数的查询。因此，要创建一个新的异常，我需要一个描述，它需要一个数据库会话和一个用户会话。因此，我注定要在所有方法中拖动所有这些对象，以防万一我可能需要引发异常。 我该如何解决这个问题？

81 design  dependency-injection  dependencies 

当我刚开始学习PHP时（大约5或6年前），我了解了Ajax，并且经历了“阶段”： 您的服务器返回HTML数据，并将其放入DOM的 innerHTML中 您将了解诸如XML之类的数据传输格式（然后说“噢，这就是它的用途”），然后是JSON。 您返回JSON并使用原始JavaScript代码构建UI 您移至jQuery 您将了解API，标头，HTTP状态代码，REST，CORS和Bootstrap 您将学习SPA和前端框架（React，Vue.js和AngularJS）以及JSON API标准。 您会收到一些企业旧代码，并在对其进行检查后发现它们执行了步骤1中所述的操作。 当我使用此旧版代码库时，我什至都不认为它可以返回HTML（我的意思是，我们现在是专业人员，对吗？），所以我很难寻找要返回数据的JSON端点。 Ajax调用会填充。直到我问“程序员”，他才告诉我它正在返回HTML，并使用innerHTML直接附加到DOM。 当然，这很难接受。我开始考虑将其重构为JSON端点的方法，并考虑对端点进行单元测试等等。但是，此代码库没有测试。没有一个。超过20万行。当然，我的任务之一是提出测试整个事物的方法，但是目前我们还没有解决。 因此，我无处不在，想知道：如果我们没有任何测试，那么就没有创建此JSON端点的特殊理由（因为它不是“可重用的”：它从字面上返回仅适合该部分的数据）应用程序，但是我认为这已经隐含了，因为它返回HTML数据）。 什么究竟是错这样做呢？

77 design  ajax 

简而言之，为了整个系统的利益，我们是否应该将死亡设计在较低的程序，进程和线程中？ 失败发生。进程死亡。我们计划灾难，并偶尔从灾难中恢复。但是我们很少设计和实现无法预测的程序终止。我们希望我们的服务正常运行时间只要我们愿意保持它们正常运行即可。 Netflix的Chaos Monkey是该概念的一个宏观示例，它在某些情况下会随机终止AWS实例。他们声称这有助于他们发现问题并构建更多的冗余系统。 我在说的是较低的水平。这个想法是让传统上长时间运行的进程随机退出。这将迫使冗余进入设计并最终产生更具弹性的系统。 这个概念已经有名字了吗？它已经在行业中使用了吗？ 编辑 根据评论和答案，恐怕我不清楚我的问题。为了清楚起见： 是的，我的意思是随机的， 是的，我的意思是在生产中，并且 不，不仅用于测试。 解释一下，我想比喻多细胞生物。 在自然界中，生物由许多细胞组成。这些单元自行分叉以创建冗余，然后最终死亡。但是，应始终有足够种类的正确细胞供生物体发挥功能。这种高度冗余的系统还有助于在受伤时进行康复。细胞死亡，生物体得以生存。 将随机死亡纳入程序中将迫使更大的系统采用冗余策略以保持生存。这些相同的策略是否可以在遇到其他无法预测的故障时使系统保持稳定？ 而且，如果有人尝试过这种方法，那叫什么呢？如果它已经存在，我想了解更多。

76 design 

为什么许多软件开发人员通过修改诸如重命名功能之类的东西在升级后会破坏应用程序而违反了开放/关闭原则？ 在React库中出现快速和连续版本之后，这个问题就跳到了我的头上。 每隔一小段时间，我就会注意到语法，组件名称等方面的许多更改。 即将发布的React版本中的示例： 新的弃用警告 最大的变化是我们将React.PropTypes和React.createClass提取到了自己的包中。两者仍然可以通过主React对象访问，但是在开发模式下，使用其中任何一个都会将一次性弃用警告记录到控制台。这将使将来的代码大小优化成为可能。 这些警告将不会影响您的应用程序的行为。但是，我们意识到它们可能会引起一些挫败感，特别是如果您使用将console.error视为失败的测试框架。 这些更改是否被视为违反该原则？ 作为React之类的初学者，我如何通过库中的这些快速更改来学习它（这是如此令人沮丧）？

74 design  object-oriented  javascript  reactjs  upgrade 

当问到Murray Gell-Mann时，Richard Feynman如何解决了这么多难题时，Gell-Mann回答说Feynman有一个算法： 写下问题。 认真思考。 写下解决方案。 盖尔曼（Gell-Mann）试图解释说，费曼是另一种类型的问题解决者，研究他的方法没有任何见识。对于管理中型/大型软件项目的复杂性，我有点相同的感觉。优秀的人天生就是擅长的，并且设法以某种方式分层和堆叠各种抽象，以使整个事物易于管理，而不会引起任何不必要的麻烦。 那么，费曼算法是管理意外复杂性的唯一方法，还是软件工程师可以始终如一地应用实际方法来应对意外复杂性？

74 design  project-management  software  complexity