软件工程

开源社区中的许多人说，他们在招聘时强烈考虑候选人的Github个人资料。 我活跃在Github上，有一些我自己的项目，也有一些对其他项目的贡献。但是，如果以我自己的身份查看自己的个人资料，就会发现很多杂音：我克隆但从未参与过的项目等等。我引以为傲的项目和补丁并没有脱颖而出。 如果您评估人们的Github个人资料，该如何做？作为开发人员，我应该做些其他事情吗？例如，删除我不积极从事的克隆存储库？

54 open-source  github 

一位开发人员已经着手开发新的Drupal项目，并且sysadmin建议他们只应将sites / default子目录放在源代码管理中，因为它“将使更新易于编写脚本”。撇开这个有点可疑的说法，这又引出了另一个问题：哪些文件应在源代码控制下？是否存在应排除一些大文件的情况？ 我的观点是，该项目的整个树都应受到控制，这对于Drupal项目，Rails或其他任何项目都是正确的。这似乎不费吹灰之力-您显然需要为框架编写版本控制，以及为编写的任何自定义代码所做的操作一样多。 也就是说，我很乐意就此发表其他意见。是否有任何理由不控制一切？

54 version-control  drupal 

我仍在Microsoft TechEd上，对于如何有效利用我在软件会议上的时间的问题，我的回答是绝大多数“网络是软件会议中最有用的部分”。 问题：我不知道该如何完成这项任务。我一直都很内向。在学校和工作场所，我通常不会遇到任何问题，因为围绕这种方法我有很多外向的人，这些年来我结识了一些很棒的朋友。但是，在会议上，似乎大多数人都像我一样内向，而那些似乎不是销售人员的人。 有几次我感觉可以和人打交道，这是在一个会议之后，整个房间里都进行了健康的讨论，而当我有勇气与某些人交谈时，他们离开并继续其他事情。 我应该阅读特定的书籍吗？咨询我可以接受吗？就接近人而言，什么都不知道？因为每次我尝试时，我都会感到尴尬。:( （奇怪的是，我与一群人交谈没有问题-这是一对一的事情让我绊倒了：P）（哦，顺便说一句，如果这里有人来了，我会喜欢见面谈论事情，我是游戏：P） 那么，像我这样的内向型程序员如何在软件大会上有效地结网呢？

54 career-development  social-networks 

我遇到的许多程序员总是说“他不是UI专家”。事实是，当今的开发，无论是Web，Windows，Linux，OSX还是任何其他类型的开发，现在都包含具有漂亮UI的软件。为什么这么多开发人员似乎不喜欢UI工作？

54 user-interface 

您认为哪种语言可使普通程序员输出具有最少数量的难以发现的错误的功能？当然，这是一个非常广泛的问题，我对非常广泛和笼统的答案和智慧感兴趣。 我个人发现我花很少的时间在Java和C＃程序中寻找奇怪的错误，而C ++代码具有其独特的重复性错误集，而Python /类似的语言具有其自己的一组常见和愚蠢的错误，编译器可以检测到它们用其他语言。 同样，我发现在这方面很难考虑函数式语言，因为我从未见过用完全函数式代码编写的大型复杂程序。请输入您的意见。 编辑：完全任意地澄清难以发现的错误：花费15分钟以上才能重现，或者花费1小时以上才能找到原因并修复。 如果这是重复的内容，请原谅我，但是在这个特定主题上我什么都没找到。

54 programming-languages  bug  problem-solving  functional-programming 

我已经看到一些程序员一遍又一遍地调整他们的代码，不仅使它“运行良好”，而且使它“看上去良好”。 IMO，“干净代码”实际上是对您代码的优雅，完美理解和可维护性的一种称赞。而且，当您不得不在美观的代码和压力很大的代码之间进行选择时，就会出现区别。 那么，你们当中有多少人实际编写了“干净的代码”？这是一个好习惯吗？这样做的其他好处或缺点是什么？

54 productivity 

除了不喜欢空白作为语法之外，我并不讨厌，只是对Python不感兴趣。 我欣赏Perl的诗歌，并用bash＆korn和shebang编写了漂亮的Web服务gnuplot。我写文件，troff不介意REXX。几年前没有发现tcl有用，但是关于Python的最大臭味是什么？我在简历中看到工作清单和许多应聘者，以此作为奖杯和奖杯。 我想实际上，我想以此为卖点，我只是找不到原因。

54 python  perl  bash 

C ++具有简单的多重继承，许多语言设计都将其视为危险。但是某些语言（例如Ruby和PHP）使用奇怪的语法来完成相同的操作，并将其称为mixin或traits。我多次听说，mixin /特性比普通的多重继承更难滥用。 是什么使它们危险性降低了？是否有不能用mixins / traits来实现，但是可以用C ++风格的多重继承来实现？他们有可能遇到钻石问题吗？ 似乎我们在使用多重继承，但只是借口说它们是混合/特性，因此我们可以使用它们。

54 object-oriented  inheritance  multiple-inheritance  mixins 

TDD的红色-绿色-重构周期已经建立并被接受。我们编写一个失败的单元测试，并使其尽可能简单地通过。与为一个类编写许多失败的单元测试并使它们全部一次性通过相比，这种方法有什么好处。 测试套件仍可保护您避免在重构阶段编写错误的代码或犯错误，那么这有什么危害呢？有时，首先以“大脑转储”的形式首先编写一个类（或模块）的所有测试会更容易，以便一次编写所有预期的行为。

54 unit-testing  development-process  tdd 

在为期2周的冲刺结束时，一个任务进行了代码审查，在审查中我们发现了一个功能正常，可读性强的功能，但它相当长且有一些代码异味。轻松的重构工作。 否则，该任务将符合完成的定义。 我们有两个选择。 代码审查失败，因此该票证不会在此Sprint中关闭，并且我们在士气上受到了一些打击，因为我们无法通过该票证。 重构只是一小部分工作，并且将在下一个冲刺（甚至在开始之前）中完成，只是一个很小的半点故事。 我的问题是：从审阅的背后提出票证而不是通过失败有任何内在的问题或考虑吗？ 我可以找到并已阅读详细代码评论的资源通常为100％或什么都没有，但是我发现这通常是不现实的。

53 agile  code-reviews 

我有一个朋友说： Docker很棒。您可以使用它在本地计算机上复制生产及其所有怪癖。然后，您可以超快速地通过所有登台工作流直接部署该实例。 现在，如果开发人员正在编写Ruby，PHP或Go（存在指向操作系统的定向二进制链接），这将是正确的。 但是当使用Java时 - 操作系统和语言之间已经存在一个虚拟层，无论底层操作系统如何，都可以确保操作的一致性。 可以说，在这种情况下，否定了为本地开发人员运行Docker来复制生产环境的好处。（与Ruby，PHP或Go相比）。 我愿意就此进行讨论，并热切希望听到持异议的观点（有证据）。 与其他更接近Unix二进制语言的语言相比，使用Java时使用Docker的开发优势是否被否定？

53 java  deployment  jvm  docker 

我最近刚从大学毕业，开始从事程序员工作。我发现解决“技术”问题或用我说有1个解决方案的东西进行调试并不困难。 但是似乎有一类问题没有一个明显的解决方案，例如软件体系结构。这些事情使我困惑，使我感到极大的困扰。 我花了数小时的时间来尝试确定如何“架构”我的程序和系统。例如-我是否将此逻辑划分为1或2个类，如何命名这些类，是否应该将其设为私有或公开类，等等。这些问题占用了我很多时间，这使我感到非常沮丧。我只想创建程序-该死的体系结构。 我如何才能更快地完成架构阶段并进入自己喜欢的编码和调试阶段？

53 design  architecture 

我想知道我处理需要从版本控制中删除的源文件的方式是否被视为不良做法。 我想根据该示例向您解释： 最近我非常生气，因为我必须在程序中将Java类繁琐地整理出来，这些类基本上是无效的代码，但是在这些Java类中都没有文档记录和注释。当然，需要删除它们，但是在删除这些多余的东西之前，我有一个-有些人可能说奇怪-习惯： 我不会立即通过SVN-> Delete（用您选择的版本控制系统的delete命令替换）来删除这些冗余文件，而是将注释放置在这些文件中（这些文件的开头和结尾处都是引用）被删除+我的名字+日期，以及-更重要的是- 为什么被删除（在我的情况下，因为它们已经死了，代码令人困惑）。然后保存并提交给版本控制。下次当我必须在项目中提交/签入版本控制时，我按SVN-> Delete，然后最终将它们在版本控制中删除-当然仍然可以通过修订来恢复，这就是为什么我采用了这种习惯。 为什么要这样做而不是立即删除它们？ 我的理由是，我至少要在存在那些冗余文件的上一个修订版本中要有显式标记，为什么应该删除它们。如果我立即删除它们，它们将被删除，但是没有地方记录为什么删除它们。我想避免这样的典型情况： “嗯...为什么删除了那些文件？我以前工作得很好。” （按“还原”->还原然后再消失的家伙将在下个星期永远消失或不可用，下一位受让人必须像我一样单调乏味地找出这些文件的内容） 但是您没有注意到为什么这些文件在提交消息中被删除了吗？ 我当然可以，但是同事有时看不到提交消息。在您试图理解（在我的情况下为死机）代码时，首先使用所有关联的提交消息检查版本控制日志的情况并不常见。与其查看日志，不如立即看到该文件无用。这样可以节省她/他的时间，并且她/他知道此文件可能已恢复为坏文件（或至少引起了一个问题。）

53 version-control  svn  evidence-based 

为什么这样可以正常进行并且通常可以预期： abstract type Shape { abstract number Area(); } concrete type Triangle : Shape { concrete number Area() { //... } } ...虽然这还不行，但是没有人抱怨： concrete type Name : string { } concrete type Index : int { } concrete type Quantity : int { } 我的动机是最大限度地使用类型系统进行编译时正确性验证。 PS：是的，我已经读过这篇文章，并且包装是一个棘手的解决方法。

53 type-systems  static-typing  strong-typing 

似乎总是/经常提到线程安全是使用不可变类型（尤其是集合）的主要好处。 我有一种情况，我想确保方法不会修改字符串字典（在C＃中是不可变的）。我想尽可能地约束事物。 但是，我不确定将依赖项添加到新程序包（Microsoft不可变集合）是否值得。性能也不是大问题。 因此，我想我的问题是，在没有硬性能要求且没有线程安全问题的情况下，是否强烈建议使用不可变集合？考虑一下值语义（在我的示例中）可能是也可能不是要求。

53 immutability  semantics  collections  mutable