软件工程

继承，多态性和封装是OOP的三个最不同的重要特征，从它们来看，继承如今具有很高的使用统计。我正在学习JavaScript，在这里，他们都说它具有原型继承，而且各地的人们都说它与经典继承大不相同。 但是，从实际使用的角度来看，我不明白它们有什么区别？换句话说，当您定义基类（原型）然后从中派生一些子类时，您都可以访问基类的功能性对象，并且可以在派生类上扩展功能。如果我们认为我所说的是继承的预期结果，那么为什么我们要使用原型还是经典版本呢？ 为了使自己更加清楚，我认为原型继承和经典继承的有用性和使用方式没有区别。这导致我没有兴趣去了解它们为何不同的原因，因为它们都导致同一件事，OOAD。原型继承实际上（不是理论上）与经典继承有何不同？

27 design  object-oriented-design  inheritance 

我听说过很多关于使方法简短的知识，而且我听过很多程序员说，在方法中使用#region标记是一个确定的信号，即它太长了，应该重构为多个方法。但是，在我看来，在许多情况下，在方法中使用#region标签分隔代码是重构为多个方法的绝佳解决方案。 假设我们有一种方法，其计算可以分为三个相当不同的阶段。此外，这些阶段中的每个阶段仅与该方法的计算有关，因此将它们提取到新方法中不会获得代码重用。那么，将每个阶段提取到自己的方法中有什么好处？据我所知，我们获得的是每个阶段都有一定的可读性和单独的变量范围（这将有助于防止对特定阶段的修改意外破坏另一个阶段）。 但是，这两种方法都可以实现，而无需将每个阶段提取到自己的方法中。区域标签使我们可以将代码折叠成可读性强的形式（其附加好处是，如果我们决定扩展和检查代码，则不再需要在该文件中保留位置），并且只需将每个阶段包装在{}创建自己的工作范围。 这样做的好处是，我们不会使用实际上仅与第四个方法的内部工作相关的三个方法来污染类级别的范围。在我看来，立即将长方法重构为一系列短方法似乎是等同于过早优化的代码重用。您正在引入额外的复杂性以解决在许多情况下永远不会出现的问题。如果有出现代码重用的机会，您以后总是可以将阶段之一提取到其自己的方法中。 有什么想法吗？

27 c#  coding-style 

自从我在有争议的编程观点线程中阅读此答案以来，我一直在思考以下问题： 你的工作是使自己失业。 在为雇主编写软件时，所创建的任何软件都应以任何开发人员都可以选择并以最小的努力理解的方式编写。它经过精心设计，清晰一致地编写，清晰地格式化，记录在何处，按预期每日生成，检入存储库并进行适当版本控制。 如果您遇上公共汽车，下岗，解雇或下班，您的雇主应该能够在短时间内通知您，然后下一个人可能会担任您的职务，接管您的代码，并做好准备。一周之内就可以跑步了。如果他或她做不到，那您就惨败了。 有趣的是，我发现有了这个目标使我对雇主更有价值。我越努力成为可抛弃型产品，我对他们就越有价值。 而且在其他问题（例如这个问题）中也进行了讨论，但是我想再次提出来从更空白的角度讨论“ 这是代码的味道！ ”的观点-尚未真正涵盖深入。 我从事专业开发已经十年了。我曾经做过一项工作，代码编写得足够好，可以被任何体面的新开发人员相对迅速地拿到，但是在行业中的大多数情况下，似乎拥有很高的所有权（个人和团队所有权）规范。大多数代码库似乎都缺乏文档，流程和“开放性”，而这将使新开发人员可以选择它们并快速使用它们。似乎总是有很多不成文的小技巧和黑客，只有非常了解代码库的人（“拥有”它）才知道。 当然，明显的问题是：如果该人退出或“被公交车撞上”怎么办？还是在团队层面上：如果整个团队在团队午餐时外出时食物中毒，而他们全都死了怎么办？您是否可以相对轻松地用一组新的随机开发人员代替团队？-在过去的几份工作中，我完全无法想象这种情况的发生。这些系统充满了诡计和技巧，以至于您“ 只需要知道 ”，以至于您雇用的任何新团队所花费的时间远远超过可盈利的业务周期（例如，新的稳定版本）才能使事情恢复正常。简而言之，如果不得不放弃该产品，我不会感到惊讶。 显然，一次输掉整个团队是很少见的。但是我认为所有这一切中还有一个更微妙和危险的事情-这就是让我开始思考这个话题的要点，因为我以前从未看到过这些术语的讨论。基本上：我认为对代码所有权的高度需求通常是技术债务的指标。如果您“必须知道”系统中缺乏流程，沟通，良好的设计，许多小技巧和小技巧，等等-这通常意味着系统正在逐渐陷入越来越深的技术负担。 但是问题是-代码所有权通常被表示为对项目和公司的“忠诚”，是对工作“承担责任”的积极形式-因此，完全谴责它是不受欢迎的。但是，与此同时，等式的技术债务方面通常意味着代码库变得越来越不开放，并且使用起来更加困难。特别是随着人们的前进和新开发人员的到位，技术债务（即维护）成本开始飙升。 所以从某种意义上说，我实际上认为，如果对代码所有权的高度需求被公开认为是一种工作气味（在流行的程序员想象中），这对我们的职业而言将是一件好事。与其将其视为工作中的“承担责任和自豪感”，不如将其视为“通过技术债务巩固自己并创造人为的工作保障”。 我认为测试（思想实验）基本上应该是：如果这个人（或者实际上是整个团队）明天要从地球上消失，该怎么办？这是否会对项目造成巨大的伤害甚至是致命的伤害，还是我们可以招募新人员，让他们阅读doccos和帮助文件并使用代码几天，然后再返回在几周内完成业务（一个月左右即可恢复全部生产力）？

27 development-process  code-quality  source-code  code-smell  code-ownership 

根据Martin Fowler的说法，代码重构是（强调我的）： 重构是一种用于重组现有代码主体，在不更改其外部行为的情况下更改其内部结构的规范技术。它的核心是一系列小的行为保留转换。每个转换（称为“重构”）几乎没有，但是一系列转换可以产生显着的重组。由于每个重构都很小，因此出错的可能性较小。每次进行少量重构后，系统也可以保持完全正常工作，从而减少了系统在重组期间可能严重损坏的机会。 在这种情况下，什么是“外部行为”？例如，如果我应用move方法重构并将某个方法移动到其他类，则看起来我在更改外部行为，不是吗？ 因此，我有兴趣弄清楚变更在什么时候停止成为重构并变成更多。“重构”一词可能会被误用于较大的更改：它是否有不同的词？ 更新。关于接口的很多有趣的答案，但是不会通过方法重构来改变接口吗？

27 refactoring 

显然，某些旧应用程序不能或非常难以进行单元测试，因为它是最初编写的方式。 但是在某些地方，例如一些可能经过单元测试的辅助方法，我是否应该为它们编写单元测试呢？ 我的意思是，它们可以像狗一样书写，但是无论逻辑多么脆弱，时间的考验都证明了它可以按预期的方式工作。如果我说要进行重构，我应该只打扰单元测试吗？还是应该在有空的时候为它们编写单元测试？ 这样做有什么价值吗？ 还应考虑到方法定义可能含糊不清，我可能需要研究在给定条件下某些方法应实际执行的操作。

27 unit-testing 

我一直-std=c++0x在用GCC中的标志编译自己的代码，因为我想隐约地跟上所有年轻人的行为（前提是他们留在草坪上），最后我得到了很多警告关于auto_ptr被弃用 当然，我知道auto_ptr在C ++ 0x 中已弃用，但是... 弃用不是浪费时间和精力吗？不弃用的原因（以auto_ptr为例）： 仍然有大量代码需要得到支持，产生数百万条警告只会诱使人们关闭警告。 auto_ptr 是个小问题，但实际上确实可以做到。 如果我们真的想弃用东西，我提名printf()。但是，请想象将会发生的尖叫声。auto_ptr没有太多的朋友，但是至少在我的C ++代码中，它的使用量大于printf，根本没有使用。 该委员会对此有不好的记录-他们在名称空间范围内弃用了static，现在似乎已经弃用了-如果auto_ptr做出类似的复出，我不会感到惊讶 最后，无论委员会怎么说，编译器实施者都不会理ignore它们-他们根本不能冒险破坏客户代码，他们所能做的就是发出令人讨厌的警告。 所以我的问题是-您是否认为弃用（任何东西，不仅是auto_ptrs，而且不只是C ++）是个好主意，如果可以，为什么？

27 c++  c++11  standardization 

我想学习（和掌握）TDD。什么是最好的： 图书 网站 影片 练习清单 个人智慧的话 学习，欣赏和使用TDD？

27 books  tdd 

我通常会阅读很多有关编程的资料。当我阅读的主题与我的工作没有直接关系时（例如阅读一些我在日常工作中不使用的算法），我会忘记它们。 加强已学知识的一种方法是编写博客。我是写博客的初学者。当我开始写作时，我发现这很艰难。即使简单地复制内容也需要大约两个小时。写一篇关于博客的好书通常需要一整天，有时甚至是一个周末。 这正常吗？有编写技术教程/技术博客的提示吗？

27 writing 

程序员之间普遍认为，语言越动态和松散地键入，它将使程序员的工作效率越高。Guido van Rossum于1998年撰写了有关使用python进行编程提高生产力的文章，并在网上搜索时，我仍然看到人们引用了这个确切的说法： 从语法上讲，Python代码看起来像可执行的伪代码。使用Python进行程序开发比使用C / C ++快5-10倍，比使用Java快3-5倍。在许多情况下，可以使用Python编写应用程序的原型，而无需编写任何C / C ++ / Java代码。通常，原型具有足够的功能，并且性能足以作为最终产品交付，从而节省了可观的开发时间。在其他时候，原型可以部分或全部转换为C ++或Java-Python的面向对象特性使转换成为一个简单的过程。 这个问题是否经过科学评估？如果不适合python，那么也许适合同级脚本语言（如ruby，perl或php）？ 我不是在寻找合理化，类比或解释的理由，否则可能很难回答，除非研究人员或专家的意见花了一些时间来研究这个问题。 我最初是在skeptics.SE上提出这个问题的，有人建议我也在这里提出这个问题。

27 programming-languages  java  productivity  python  scripting 

我想为客户网站重新编写我的登录脚本，以使其更加安全。我想知道我可以在其中实施哪些最佳实践。受密码保护的控制面板数量众多，但是似乎很少有人在代码编写，速度和安全性方面暗示最佳实践。 我将使用PHP和MYSQL数据库。 我曾经使用md5，但我发现sha256或sha512会更好（以及安全的哈希和盐）。 一些登录脚本会在整个会话甚至用户代理中记录IP地址，但是我想避免这种情况，因为它与代理服务器不兼容。 我在使用PHP 5中的会话的最佳实践（最后一次阅读的是PHP 4）方面也落后了一些，因此一些最佳实践可能会有所帮助。 谢谢。

27 web-development  php  security 

关于编写可能必须了解用户界面的类的最佳实践是什么？知道如何绘制自身的类不会因为依赖于用户界面（控制台，GUI等）而打破了一些最佳做法吗？ 在许多编程书籍中，我都遇到了显示继承的“ Shape”示例。基类形状具有一个draw（）方法，该方法会覆盖每个形状，例如圆形和正方形。这允许多态性。但是draw（）方法不是非常依赖于用户界面是什么吗？如果我们将此类写为Win Forms，则不能将其用于控制​​台应用程序或Web应用程序。它是否正确？ 这个问题的原因是，我发现自己总是陷入困境，并且挂在如何归纳类上，因此它们是最有用的。这实际上对我不利，我想知道我是否在“努力”。

27 design 

我正在寻找一个很好的类比或隐喻，可以向非程序员说明复制粘贴编程的问题。我偶尔会为潜在客户进行代码/系统审查，而我看到的常见问题之一是在他们的代码库中有大量的复制粘贴代码。我经常在评论中提到这一点，每次我都必须解释为什么这是一个问题（对于那些只了解编程才能理解重用是一件好事的客户而言，这尤其困难，但不足以理解为什么会这样）复制粘贴不是很好的重用形式）。显然，我可以（并且确实）通过代码维护来解释该问题，但是对于这个非程序员会遇到的问题，有一个很好的，简洁的类比会很好。如果类比说明了为什么“搜索替换”不是此问题的有效解决方案，那将是一个好处。有什么建议么？ 只是为了澄清一下（基于下面的Jaroslav的回答）-我不是在这里使用代码段。我看到的（经常是令人不安的）是大量代码的复制和粘贴，或者是十行代码的代码，用于将一些用户数据（使用内联SQL查询完成）粘贴到数十个PHP或ASP.NET页面中。因此，从同一项目中其他地方重复代码。 更新：这里有几个非常好的答案。我已经在评论中解释了为什么我选择Scott Whitlock的答案，但是如果您要与完全熟悉制造的客户打交道，我也强烈建议您使用whatsisname的答案。

27 code-reviews  copy-paste-programming 

通过C ++模板和C＃/ Java泛型之间的不同比较，例如： /programming/31693/what-are-the-differences-between-generics-in-c-and-java-and-templates-in-c/31929#31929 我感觉到，C ++模板是通过某种预处理（在解析之前替换纯文本）而不是通过编译实现的。因为C ++模板中的类型检查类似于C宏。我的意思是，如果存在一些错误，它们是处理模板代码块后生成的代码中的错误，而不是模板本身中的错误。换句话说，它们只是C语言中宏的一种上层版本。 然后我发现了其他一些事实支持这一点- 我认为，如果C ++模板通过预处理实现，则动态链接（使用.dll）会出现问题。快速搜索支持了这一点。 另一点是，整数常量可以作为参数传递给模板。而且它甚至支持某种递归。但是在编译的汇编/机器代码中找不到此递归。通过为每个递归调用生成函数，可以在编译时管理递归对象，因此具有更大但更快的可执行二进制文件。 尽管与C宏不同，但它具有一些优越的功能。但是C ++模板不是通过某种预处理实现的吗？如何在不同的C ++编译器中实现？

27 c++  c  compiler  templates  macros 

我了解SOLID在模块化很重要且其目标显然有用的情况下应定期完成并使用的功能。但是，有两点使我无法在代码库中一致地应用它： 我想避免过早的抽象。以我的经验，绘制没有具体用例（现在或可预见的将来）的抽象线会导致将它们绘制在错误的位置。当我尝试修改此类代码时，抽象行会妨碍您的工作，而不是有所帮助。因此，我倾向于不画任何抽象线，直到我对它们的用处有了一个很好的认识。 我发现很难证明增加模块化本身是合理的，如果它使我的代码更冗长，更难理解等，并且不能消除任何重复。我发现有时，简单，紧密耦合的过程或God对象代码比构造良好的馄饨代码更易于理解，因为流程简单且线性。编写起来也容易得多。 另一方面，这种心态常常导致神的对象。我通常会保守地重构它们，仅在看到清晰的模式出现时才添加清晰的抽象线条。如果您显然不需要更多的模块化，没有大量重复且代码可读性强，那么上帝对象和紧密耦合的代码怎么办？ 编辑：就个别SOLID原则而言，我想强调的是，Liskov Substitution是IMHO的常识形式化，应在所有地方应用，因为如果不是这样的话，抽象是没有意义的。同样，每个类都应该在某个抽象级别上担负单个责任，尽管这可能是一个很高的级别，将实现细节都塞进一个庞大的2,000行类中。基本上，您的抽象应该在您选择抽象的地方有意义。在模块化不是很有用的情况下，我所质疑的原则是开放式，接口隔离，尤其是依赖关系倒置，因为这些都是关于模块化的，而不仅仅是让抽象有意义。

27 design  object-oriented  solid 

哪种方法似乎最能哄骗非技术业务人员的需求？ 我正在与一个团队一起努力为项目制定规格。每次我们见面时，都达到下次会议的期望，我们要求业务人员重新提出他们的要求。他们通常会这样回答：“好吧，您认为你们可以提出一个原型，以便我们下周看到我们喜欢的东西吗……您知道，因为它是一个原型，所以没有任何数据或任何东西，只有功能。”这是一个耗时6个月的项目，因此这显然是不可行的（我们将不得不开发整个产品！），而且，如果没有某种规范，我们甚至不知道要原型制作什么。坦率地说，我认为像大多数人一样，他们对自己想要的东西有所了解，只是他们没有以收集真正需求所必需的集中方式进行思考。除了简单地告诉他们，“给我们您想要的东西，或者我们不能/不会做任何工作”（我们希望他们对结果满意），有没有办法帮助他们决定他们想要什么？例如，我们可以告诉他们： “绘制一些屏幕（在Powerpoint中，在餐巾纸上，等等），显示想要的用户界面以及所有要查看的数据，并在页边空白处描述功能。由此，我们将完善它，并根据这组行为要求构建后端。” 要么 “不必担心它现在的外观（数字1会挂断）。只要给我们列出您想要的有关程序跟踪的每件事的所有数据的列表。因此，对于“客户”，您可以列出：名称，地址，电话号码，订单等。它不一定是完美的数据库结构，但是我们可以从中得出一些信息，并了解您的需求” 这些替代方法中的任何一种都可以使业务人员专注于他们想要的东西是否有意义？您在行动中是否有其他选择？

27 design  business  requirements