软件工程

我花了一些时间阅读常见的copyleft和许可的软件许可证。是否有许可证允许应用程序或算法的创建者根据自己的个人偏见广泛地指定谁可以使用/分发产品？ 我了解人们使用双重许可来强迫商业实体支付许可许可，或者被迫分发项目的源代码，但是我在想一些类似的事情，例如“可以免费使用该代码，修改并由不涉及Industry x的任何实体分发[我认为我不值得使用我的自由软件]”。 我一直找不到任何这样的许可证或许可证模板，并且我以为至少有些程序员会担心其产品的道德影响。是否可以创建AI寻路算法，并确保最终不会指导武装无人机或北极浮冰模型，并确保最终不会将其用于海上石油钻井，同时仍使用许可式许可证？

43 licensing  ethics  users 

从技术角度来看，可以添加一些前/后推钩，以在允许某些特定的提交合并到远程默认分支之前运行单元测试。 我的问题是-最好将单元测试保留在构建管道中（因此，将损坏的提交引入仓库），还是最好不要允许“不良”的提交发生。 我确实意识到我不受这两种选择的限制。例如，在将合并提交提交到仓库之前，我可以允许所有提交分支和测试。但是，如果您必须在这两种解决方案之间进行选择，那么您将选择哪种解决方案，以及出于哪些确切原因？

43 version-control  continuous-integration  hooks 

在大多数OOP语言中，对象通常是可变的，只有少数例外（例如，python中的元组和字符串）。在大多数功能语言中，数据是不可变的。 可变对象和不可变对象都带来了它们自己的优点和缺点的完整列表。 有一些语言试图将两个概念结合起来，例如scala，其中您拥有（明确声明的）可变和不可变的数据（如果我错了，请更正我，我对scala的了解远远超过了限制）。 我的问题是：在OOP上下文中，完全（原文如此）不变性（即对象一旦创建就不能变异）是否有意义？ 是否有这种模型的设计或实现？ 基本上，（完整的）不变性和OOP是对立的还是正交的？ 动机：在OOP中，您通常对数据进行操作，更改（变异）基础信息，并在这些对象之间保留引用。例如，类的对象Person具有father引用另一个Person对象的成员。如果更改父亲的名字，则该子对象立即可见，无需更新。由于不可变，您将需要为父亲和孩子构造新的对象。但是与共享对象，多线程，GIL等相比，您将减少很多麻烦。

43 object-oriented  immutability 

布尔方法是否应该始终采用肯定形式，即使仅将它们用作否定形式也是如此？ 假设我想在创建实体之前检查一个实体是否存在，我的论点是下面的第一种形式要好于第二种形式，无论该方法是否曾经以肯定形式使用过。 总而言之，我觉得if(!affirmative)比容易阅读if(negative)。我有一个不同意的同事，有何想法？ 第一种形式： int entity_id = 42; if(!entity_exists(entity_id)) create_entity(entity_id); 第二种形式： int entity_id = 42; if(entity_not_exist(entity_id)) create_entity(entity_id);

43 naming  functions 

使用常规的git和github，我可以通过简单地创建我正在处理的功能分支到master分支的拉取请求来进行代码审查。我将如何使用git-flow进行代码审查？使用“ git flow功能完成”之类的工作流程，我对代码审查实际上发生在何处以及git-flow或git如何促进该审查感到困惑。

43 code-quality  git  code-reviews  github  gitflow 

随着时间的推移，我可以理解SOLID的两个部分-“ S”和“ O”。 “ O” –我在继承和策略模式的帮助下学习了开放式封闭原则。 “ S” –我在学习ORM时学会了单一职责原则（持久性逻辑从领域对象中删除）。 以类似的方式，学习SOLID的其他部分（“ L”，“ I”和“ D”）的最佳区域/任务是什么？ 参考文献 msdn-违反C＃中的SOLID原则的危险 channel9-在.NET / C＃中应用SOLID原理 OOPS原则（SOLID原则）

43 object-oriented  solid 

软件开发人员通常不使用日期作为版本号，尽管YYYYMMDD格式（或其变化形式）看起来足够坚固可以使用。该计划有什么问题吗？还是仅适用于有限的“类型”软件（例如内部生产）？

43 versioning 

我到处都使用unsigned int，但不确定是否应该这样做。可以是从数据库主键ID列到计数器等。如果数字永远不能为负，那么我将始终使用无符号整数。 但是我从其他人的代码中注意到，似乎没有其他人可以这样做。我忽略了一些关键的事情吗？ 编辑：由于这个问题，我也注意到在C语言中，返回错误的负值是司空见惯的，而不是像C ++中那样引发异常。

43 c++  c  programming-practices 

if尽可能避免长绕组条件，但有时我们最终都会编写它们。即使这是一个非常简单的条件，有时所涉及的语句也很罗condition，因此整个条件最终变得非常冗长。格式化这些格式最可读的方式是什么？ if (FoobarBaz::quxQuux(corge, grault) || !garply(waldo) || fred(plugh) !== xyzzy) { thud(); } 要么 if ( FoobarBaz::quxQuux(corge, grault) || !garply(waldo) || fred(plugh) !== xyzzy ) { thud(); } 要么 if (FoobarBaz::quxQuux(corge, grault) || !garply(waldo) || fred(plugh) !== xyzzy) { thud(); } 要么 thudable = FoobarBaz::quxQuux(corge, grault); thudable ||= !garply(waldo); thudable …

43 coding-style  conditions 

函数长度会影响程序员的生产率吗？如果是这样，为避免生产率损失，最大的最大行数是多少？ 由于这是一个高度自以为是的主题，请备份索赔并提供一些数据。

43 programming-practices  coding-standards 

控制器调用存储库而不是服务是不好的做法吗？ 解释更多： 我发现，在好的设计控制器中，可以调用服务和服务使用存储库。 但有时在控制器中，我不需要任何逻辑，只需要从db中获取并将其传递给视图即可。 而且我可以通过调用存储库来做到这一点-无需调用服务-这是不好的做法吗？

43 design-patterns  object-oriented  mvc  repository 

如果我定义某种类型的变量（据我所知，只是为变量的内容分配数据），它如何跟踪它是哪种类型的变量？

42 c++  variables  data-types 

刚接到一个电话，开发人员对每个sprint中将其故事集成到master分支表示担忧。开发人员所有代码都在自己的分支中，并且在冲刺结束时，他们都合并到一个主分支中。 然后，让一名开发人员（通常是同一位开发人员）负责确保所有内容都与其他开发人员的代码很好地集成在一起（大多数更改都在同一页面上。例如，数据显示故事，数据过滤故事和SLA指标）。 我们如何减轻这种负担并使我们的代码更容易合并在一起？从我的角度来看，让PO或SM以更有效的方式对故事进行优先级排序，以便我们在同一sprint中没有此类依赖关系可能会解决某些问题。其他人如何解决呢？还是这只是过程的一部分？

42 agile  scrum  branching  stories 

几年前，我根据MIT许可编写并发布了一些软件。 最近，我注意到其中一个（或某些？）分支已更改了许可证顶部的主要版权声明，即 Copyright (c) 2014 <my name> MIT License Permission is hereby granted, free of charge, to any person obtaining a copy of this software... 至 Copyright (c) 2019 <new author> MIT License Permission is hereby granted, free of charge, to any person obtaining a copy of this software... 这只是一个小工具，但是把我的名字从我的大部分工作中删除了，确实让我感到很难过。 …

42 licensing  mit-license 

根据什么时候原始的迷恋不是代码气味？，我应该创建一个ZipCode对象来代表一个邮政编码而不是一个String对象。 但是，根据我的经验，我更喜欢看到 public class Address{ public String zipCode; } 代替 public class Address{ public ZipCode zipCode; } 因为我认为后者需要我转到ZipCode类才能理解该程序。 而且我相信如果每个原始数据字段都被一个类替换，那么我需要在许多类之间移动以查看定义，这感觉就像是在遭受溜溜球问题（一种反模式）。 因此，我想将ZipCode方法移到新类中，例如： 旧： public class ZipCode{ public boolean validate(String zipCode){ } } 新： public class ZipCodeHelper{ public static boolean validate(String zipCode){ } } 因此只有需要验证邮政编码的人才能依赖ZipCodeHelper类。而且我发现保持原始痴迷的另一个“好处”是：它使类看起来像其序列化形式（如果有），例如：带有字符串列zipCode的地址表。 我的问题是，“避免溜溜球问题”（在类定义之间移动）是否是允许“原始痴迷”的有效理由？

42 object-oriented  coding-style