软件工程

为什么今天看起来很容易盗版？ 似乎有点难以相信，随着我们的所有技术进步以及在工程上花费了数十亿美元用于开发最令人难以置信的令人兴奋的软件，我们除“序列号/激活密钥”外，没有其他方法可以防止盗版。 ”。我敢肯定，创建Windows 7或Office甚至是Snow Leopard花费了大量资金，甚至数十亿美元，但我可以在不到20分钟的时间内免费获得它。所有Adobe产品都一样，这可能是最简单的。 可以存在一种防呆和防黑客的方法来保护您的软件免遭盗版吗？如果不现实，理论上可能吗？还是不管这些公司采用什么机制部署，黑客都能找到解决方法吗？

76 security 

在开始提问之前，这里有一些关于我的信息。 我是计算机科学专业的本科生，Java是我的主要编码语言。 我大学的基本问题是教学水平。没有人关心向学生教授编码知识，而不仅仅是理论知识。 结果是，我的大多数大学同学根本都不了解编程。 甚至我还无法脱离传统的编程环境，这在一定程度上限制了我的编码。 有哪些可能的方法可以发展和扩展我的编程/编码技能。 另外，您可以建议相同的来源吗？ 编辑：资料来源提示编码技巧的发展。

76 coding 

我有一个需要生成临时文件的程序。它是为集群计算机编写的。 如果我将这些文件保存到系统范围的临时目录（例如：）/tmp，则一些用户抱怨该程序失败，因为他们没有对/ tmp的正确访问权限。但是，如果我将这些文件保存到工作目录中，这些用户还抱怨说，他们不想看到那些神秘的文件。 哪个是更好的做法？我是否应该坚持认为保存/tmp是正确的方法，并以“按预期方式工作”来捍卫任何失败（例如，请问您的管理员适当的许可/访问权）？

76 data  file-handling 

曾经尝试用您喜欢的编程语言对1到2,000,000之间的所有数字求和吗？结果很容易手动计算：2,000,001,000,000，比无符号32位整数的最大值大900倍。 C＃打印出来-1453759936-负值！而且我猜Java也是如此。 这意味着有一些通用的编程语言默认情况下会忽略算术溢出（在C＃中，存在用于更改该值的隐藏选项）。在我看来，这是一种非常冒险的行为，难道不是由这样的溢出导致Ariane 5崩溃吗？ 那么：如此危险的行为背后的设计决策是什么？ 编辑： 这个问题的第一个答案表示检查的过度成本。让我们执行一个简短的C＃程序来测试此假设： Stopwatch watch = Stopwatch.StartNew(); checked { for (int i = 0; i < 200000; i++) { int sum = 0; for (int j = 1; j < 50000; j++) { sum += j; } } } watch.Stop(); Console.WriteLine(watch.Elapsed.TotalMilliseconds); 在我的计算机上，选中的版本需要11015毫秒，而未选中的版本需要4125毫秒。即检查步骤几乎花了两倍的时间（总共是原始时间的三倍）。但是，有了10,000,000,000次重复，检查所花费的时间仍不到1纳秒。在某些情况下，这很重要，但是对于大多数应用程序而言，这并不重要。 编辑2： 我使用/p:CheckForOverflowUnderflow="false"参数（通常，我打开了溢出检查功能）重新编译了服务器应用程序（Windows服务，该服务分析从多个传感器接收的数据，涉及很多数字运算），并将其部署在设备上。Nagios监控显示，平均CPU负载保持在17％。 这意味着在上面的虚构示例中发现的性能下降与我们的应用完全无关。

76 language-design  exceptions 

在Python的教程中，可以看到Python的原始实现是在C中实现的； 另一方面，用C编写的Python实现（...） 我很好奇为什么Python是用C而不是C ++编写的？ 我想知道此决定的原因，答案应以历史参考为依据（而非基于观点）。

76 python  c++  history  implementations 

我在理解如何将camelCase语法应用于某些变量名时遇到问题。 例如，在驼峰式的情况下，我应该如何正确写出“ phonenumber”之类的词？是phoneNumber还是phonenumber？与“用户名”类似，是username还是userName？ 我认为它看起来不正确的骆驼一样的情况下motorCycle，passWord，sunDay，setUp或waveLength因为这些都是每个只有一个字。我认为这可能是为什么它被调用的原因，hashMap但是hashtable在驼峰的情况下也没有大写的原因，因为哈希表是一个单词，而哈希映射是两个单词。 但是，如果摩托车有颜色，那是motorcycleColor因为单词被串联了吗？那是正确的还是应phoneNUmber，waveLength，sunBlock甚至sunDay一周的星期天？ 例如为什么为什么getISOCountries在说“ HttpHeaders例如”的情况下调用该方法，例如，如果我们有类似String camelCaseString = dog.toCamelCase()或的方法，则不清楚什么会变成小写interface CamelCase。 相关：https：//english.stackexchange.com/questions/889/when-should-compound-words-be-write-as-one-word-with-hyphens-or-with-spaces

75 notation  camelcase 

我是一个拥有大量非技术用户群的项目的维护者。我已经将其维护了大约4年，并根据需要添加了新功能。 我现在想继续进行其他项目，并停止为此应用程序开发。由于用户的非技术性，过去几乎没有代码贡献。我不相信我会找到其他人来接手该项目。 错误，问题和功能请求-这些仍然存在。我仍在回复电子邮件以寻求帮助，因为我不确定是否应该忽略它们，告诉他们我不在使用该应用程序，还是应该响应仅在某些情况下才能发送电子邮件。 什么是“放弃”该项目但仍让用户使用该应用程序的最佳方法？ 更新（2016年7月）-它没有按计划进行。我在自述文件中发布了一个公告，不久之后，我开始收到更实质性的文稿。通过错误修复，功能，文档和问题活动拉取请求。从那时起，该项目感到“焕然一新”，我现在很高兴与新项目一起维护它。我也有合作者。猜测可能是那种影响我对项目的看法的贡献，并且随着贡献质量的提高，它再也感觉不到杂事了。

75 open-source  project  maintenance 

OO编程文献中充满了设计模式。大多数有关面向对象程序设计的书都专门用一两章来设计诸如工厂和装饰器之类的模式。那么功能语言中的等效模式是什么？为什么还没有人写过有关它们的书？关于功能语言，有什么特别的东西可以消除对设计模式的需求？

75 books  design-patterns  functional-programming 

您是否只需要用Expression s 来展示新技巧或将三个不同的过程归纳起来就知道吗？这并不一定要达到宇航员的规模，实际上可能会有所帮助，但是我不禁注意到其他人将以更清晰，直接（有时很无聊）的方式实现相同的类或程序包。 我注意到我经常通过过度解决问题来设计程序，有时是故意的，有时是出于无聊。无论哪种情况，我通常都会诚实地相信我的解决方案是清晰而优雅的，直到我看到相反的证据，但通常为时已晚。我中还有一部分人喜欢无证假设而不是代码重复，而更喜欢简单性。 我该怎么做才能抵制写“聪明的”代码的冲动，什么时候我应该做错了？ 当我现在与一个经验丰富的开发人员团队一起工作时，问题变得更加严峻，有时我写智能代码的尝试即使是我自己，经过一段时间消除优雅的幻想似乎也是愚蠢的。

75 architecture  programming-practices  language-agnostic  code-smell 

我的印象是，版本控制系统消除了将“更改日志”粘贴到代码各处的需要。我经常看到更改日志的继续使用，包括存储过程开始时的长块大块，其中很大一部分被挡住以更改文件，并用诸如此类的代码乱码： // 2011-06-14 (John Smith) Change XYZ to ABC to fix Bug #999 和： // 2009-95-12 (Bob Jones) Extracted this code to Class Foo // <commented-out code here> 正如我向我解释的，这样做的原因是，花很长时间浏览我们的VCS日志，试图找出谁更改了内容和原因，同时将其保存在代码文件本身的顶部或附近。更改，可以轻松查看谁更改了内容和时间。尽管我明白了这一点，但似乎有些多余，只是有些“语：“嗯，我们不太了解如何正确使用VCS，因此我们根本不会理会这些东西。” 你怎么看？您是否同时使用注释和日志？只是日志？您是否发现，在代码块上方看到约翰·史密斯一周前更改了检查XYZ的方法，而不必在Diff工具中搜索日志并比较代码文件时，是否更容易编写代码？ 编辑：使用SVN，但基本上只是作为存储库。没有分支，没有合并，除了日志和存储之外什么也没有。

75 version-control  coding-standards  maintenance 

我事先知道人们会看到这个问题并认为“免费的红牛”。但是，我实际上是在寻找将开发人员的奖励与公司的长期目标联系起来的最佳方法。 例如，假设一个团队正在开发相同的软件产品，是否最好根据最终产品的条件来奖励每个开发人员？毕竟，他们是一个团队，这将确保他们都朝着实现产品推出的共同目标而努力。但是，这忽略了以下事实：有些开发人员比其他开发人员更强大，而有些开发人员则比其他人更努力。 根据您的经验，激励开发人员团队的最佳方法是什么？ **更新 我真的很感谢我对这个问题的强烈回应。我想问一下看完电影《Inside Job》之后，是否与最近的经济危机有关。这部电影援引的主要因素之一是，华尔街的激励机制不佳。即使短期内投资者的举动可能会造成灾难性的损失，他们也会在短期内获利。 我认为相同的概念也适用于开发人员。尽快推出产品会有短期收益，但是如果该产品存在故障或无法很好地移植到其他环境中，则可能会造成长期的头痛。 理想情况下，任何行业中的任何公司都应该想要一个激励机制，以确保其产品的长期稳定性。

75 management 

“过早的优化是万恶之源”，这几乎是我们所有人都听过/读过的。我很好奇什么样的优化不是过早的，即在软件开发的每个阶段（高级设计，详细设计，高级实现，详细实现等），我们可以考虑的优化程度是什么，而不必跨入阴暗面。

75 optimization 

我最近被一家大公司录用（数千人，以提供有关规模的信息）。他们说，由于我的严谨性，并且因为我年轻（25岁），我还是一名C / C ++程序员，因此聘请了我。 现在，我可以看到整个系统很旧并且经常使用过时的技术。没有命名约定（文件，函数，变量等），它们不使用版本控制，不使用异常或多态性，并且似乎几乎每个人都失去了激情（其中一些人只有30岁） ）。 我想提出一些建议，但我不想成为“只是因为他不想适应而想改变一切的新人”。我试图“适应”，但实际上，由于我们被迫使用的工具太差，我花了一周的时间才能完成一个下午的工作。我的许多同事从未看过当今人们使用的新“事物”和技术。就像他们刚刚放弃了。情况确实令人沮丧。 您是否遇到过类似情况？如果是，您会给我什么建议？是否有改变的事情，而不成为一个微妙的方式败家子吗？还是我也应该放弃自己的激情和精力？ 谢谢。 更新 遵循您的宝贵建议，我能够提出变更建议，现在负责必须创建和部署Subversion：D的团队。谢谢大家！ 6个月后 我辞职后，发现了一个更有趣的环境，薪水更高，挑战也更有趣。我什么也不会回去。

75 development-environment 

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

74 design  object-oriented  javascript  reactjs  upgrade 

在Stephendevgins在linuxdevcenter.com上的2003年这篇文章中，Bram Cohen的BitTorrent被描述为使用了“修复一切”设计模式。 Cohen使用幂等性是一种较不常见的方法，这两种方法都使BitTorrent较难掌握，但值得研究。多次应用一个过程是幂等的，不会导致任何进一步的更改。科恩说，他使用一种称为“固定一切”的设计模式，该功能可以对许多更改做出反应，而无需真正注意所有更改。他解释说：“您注意到发生的事件，然后调用以这种完全幂等的方式编写的fix all函数，然后清除可能发生的一切并从头开始重新计算。” 幂等使某些困难的计算变得容易，但使事情有些混乱。通话发生什么变化并不总是很清楚，如果有的话。您不需要事先知道。您可以自由调用该函数， 听起来很不错。 但是，在我看来，调用幂等“修复所有问题”功能将以提高效率为代价提高系统的鲁棒性，并有可能搞砸包含系统（可能更喜欢仔细计划和执行的过程）。 不过，我不能说我曾经使用过它。我也无法在线找到他的应用程序的来源（但是我确实找到了一个声称基于它的应用程序。）。在本文之外也找不到参考（我认为我的google-fu很好），但是我确实在SOApatterns.org上找到了“幂等能力”条目。 这个想法被另一个名字更好地了解吗？ 什么是“修复一切”设计模式？它的优缺点是什么？

74 design-patterns