软件工程

针对在系统开发生命周期中工作的专业人士，学者和学生的问答

4
是否有必要遵循该标准，并采用C标准？
Stack Overflow上有一些非常有经验的人，他们总是谈论C标准。人们似乎不喜欢非便携式解决方案，即使他们为我工作。好的，我知道需要遵循该标准，但是它不会给程序员的创造力带来束缚吗？ 遵循标准有什么具体好处？特别是因为编译器可能会稍微不同地实现标准。
5
何时使用接口（单元测试，IoC？）
我怀疑我在这里犯了一个小学生错误，正在寻求澄清。我的解决方案（C＃）中有很多类-敢于说大多数-我最终为之编写了相应的接口。例如，即使我永远不可能用其他实现替换该计算器，也可以使用“ ICalculator”接口和实现该接口的“ Calculator”类。而且，这些类中的大多数与其依赖项都位于同一个项目中-实际上，它们仅需为internal，但最终成为public实现其各自接口的副作用。 我认为这种为所有内容创建接口的做法源于一些谬误： 1）我本来以为创建单元测试模拟必须有一个接口（我使用的是Moq），但是后来我发现，如果类的成员为virtual，则可以模拟该类，并且该类具有无参数的构造函数（如果我错了）。 2）我本来以为必须要有一个接口才能向IoC框架（Castle Windsor）注册一个类，例如 Container.Register(Component.For<ICalculator>().ImplementedBy<Calculator>()... 实际上，我可以针对自身注册具体类型： Container.Register(Component.For<Calculator>().ImplementedBy<Calculator>()... 3）使用接口（例如，用于依赖项注入的构造函数参数）会导致“松散耦合”。 那我对接口发疯了吗？！我知道您通常会“使用”接口（例如公开公共API）或“可插入”功能之类的场景。我的解决方案只有少数适​​合此类用例的类，但我想知道是否所有其他接口都是不必要的，应该删除？关于上述第3点，如果这样做，我是否会违反“松散耦合”？ 编辑：-我只是在玩Moq，它似乎要求方法是公共的和虚拟的，并具有公共的无参数构造函数，以便能够模拟它们。这样看来我不能拥有内部类了吗？
4
非功能语言中持久数据结构的使用
纯粹的功能或近乎纯功能的语言会从持久性数据结构中受益，因为它们是不可变的，并且非常适合无状态编程功能。 但是，我们不时看到用于Java等（基于状态的OOP）语言的持久数据结构库。人们经常听到有人主张使用持久性数据结构，因为它们是不可变的，因此是线程安全的。 但是，持久性数据结构是线程安全的，原因是，如果一个线程将一个元素“添加”到持久性集合中，则该操作将返回一个新集合，就像原始集合一样，但是添加了元素。因此，其他线程将看到原始集合。当然，这两个集合共享许多内部状态-这就是为什么这些持久性结构有效的原因。 但是，由于不同的线程看到的数据不同的状态，它似乎是持久数据结构是不是本身足以处理的情况，其中一个线程进行更改，对于其它线程是可见的。为此，似乎我们必须使用诸如原子，引用，软件事务性存储器乃至经典锁和同步机制之类的设备。 那么为什么PDS的不变性被吹捧为有利于“线程安全”的东西呢？在PDS协助同步或解决并发问题方面，有没有真实的例子？还是PDS只是一种为对象提供无状态接口以支持功能编程风格的方式？
5
用代码存储数据
我过去几次想将数据存储在代码中。这将是很少更改的数据，并用于不可能，不实际或不希望访问数据库的地方。一个小例子是存储国家列表。为此，您可以执行以下操作： public class Country { public string Code { get; set; } public string EnglishName {get;set;} } public static class CountryHelper { public static List<Country> Countries = new List<Country> { new Country {Code = "AU", EnglishName = "Australia"}, ... new Country {Code = "SE", EnglishName = "Sweden"}, ... }; public …
17 c# 
5
在C ++中为所有对象使用对象（而不是原始类型）是否有意义？
在我最近从事的项目中，我不得不使用很多看起来像这样的函数： static bool getGPS(double plane_latitude, double plane_longitude, double plane_altitude, double plane_roll, double plane_pitch, double plane_heading, double gimbal_roll, double gimbal_pitch, double gimbal_yaw, int target_x, int target_y, double zoom, int image_width_pixels, int image_height_pixels, double & Target_Latitude, double & Target_Longitude, double & Target_Height); 所以我想重构它看起来像这样： static GPSCoordinate getGPS(GPSCoordinate plane, Angle3D planeAngle, Angle3D gimbalAngle, PixelCoordinate …
7
对于浏览器中的客户端而言，Python会太慢吗？
我听到过这样的说法：Python太慢了，无法在浏览器中使用。 我认为JavaScript仅在这方面具有优势，因为Google之类的公司之所以需要它（并且使其变得很快）是因为他们需要它才能生存，但是我可能错了。 Python和Javascript的设计方式是否存在差异，从而影响它们（将）在浏览器中的执行方式？ 由于到目前为止还没有客户端Python实现，所以我的问题来自某人发表的声明，因此也许它与语言本身有关（尽管我不相信）。
9
用于访问计量单位的数据结构
TL; DR-我正在尝试设计一种最佳的数据结构，以定义度量单位内的单位。 A Unit of measure本质上是value与关联的（或数量）unit。 SI单位有七个基准或尺寸。即：长度，质量，时间，电流，温度，物质量（摩尔）和发光强度。 这足够简单，但是我们经常使用许多派生单位和费率。示例组合单位为牛顿：kg * m / s^2示例比率为tons / hr。 我们的应用程序严重依赖隐含单位。我们将把单元嵌入变量或列名中。但这在我们需要指定具有不同单位的度量单位时会产生问题。是的，我们可以在输入和显示时转换值，但这会生成很多开销代码，我们希望将其封装在自己的类中。 在Codeplex和其他协作环境上有许多解决方案。项目的许可是可以接受的，但是项目本身通常最终会变得太轻或太重。我们正在追逐自己的“正当”独角兽。 理想情况下，我可以使用以下方法定义新的度量单位： UOM myUom1 =新的UOM（10伏）; UOM myUom2 =新的UOM（43.2，牛顿）; 当然，我们会根据客户的需求混合使用英制和SI单位。 我们还需要使这种单位结构与将来的数据库表保持同步，以便我们也可以在数据中提供相同程度的一致性。 定义创建计量单位类别所需的单位，派生单位和费率的最佳方法是什么？我可以看到使用了一个或多个枚举，但这对于其他开发人员可能会感到沮丧。一个单一的枚举包含200多个条目，将是巨大的，而基于SI与英制单位的多个枚举可能会造成混淆，而基于单位本身的分类的其他细分可能会造成混淆。 枚举示例显示了我的一些担忧： myUnits.Volt myUnits.Newton myUnits.meter SIUnit.meter ImpUnit.foot DrvdUnit.Newton DrvdUnitSI.Newton DrvdUnitImp.FtLbs 我们正在使用的单位集非常明确，而且空间有限。当我们有客户需求时，我们确实需要能够扩展和添加新的派生单位或费率。尽管我认为更广泛的设计方面适用于多种语言，但是该项目使用C＃。 我看过的一个库允许通过字符串自由输入单位。然后，他们的UOM类解析该字符串，并相应地添加内容。这种方法的挑战在于，它迫使开发人员思考并记住正确的字符串格式是什么。如果我们不在代码内添加其他检查以验证在构造函数中传递的字符串，则会冒运行时错误/异常的风险。 实质上，另一个库创建了太多开发人员必须使用的类。随着等效值单位它提供了一个DerivedUnit和RateUnit等。本质上，对于我们要解决的问题，代码过于复杂。该库实际上允许任何组合（在单位世界中是合法的），但是我们很高兴通过不允许所有可能的组合来扩大问题范围（简化代码）。 其他库非常简单，甚至都没有考虑过运算符重载。 另外，我也不担心尝试进行错误的转换（例如：伏特到米）。开发人员是目前唯一可以在此级别访问的人员，我们不一定需要防止这些类型的错误。
5
我可以使用MIT许可证将以前的部分书面代码提供给雇主，以保护自己并不会失去版权吗？
我的情况： 在开始新工作之前，我已经编写了一个框架。我拥有版权。 像任何软件一样，它内部有很多样板逻辑。（du！） 我不想在我的新工作中使用整个框架，但是我确实需要在为我的新工作建立的类似框架中重用其中的某些部分。 从头开始重新实现/重新考虑所有逻辑是不切实际的。逻辑很多，逻辑就是逻辑，你不能做太多不同。例如，您可以编码多少个不同版本的HashMap？我敢打赌，它们将非常相似，并且第三版可以声称您侵犯了第一版的版权。:( 尝试重新发明API是不切实际的。您可以重新发明HashMap的API吗？也许您可以更改put(k,v)为add(k,v)，但仅此而已。 我保护自己的想法和以前的代码： 我将告诉我的雇主，我正在基于我根据MIT许可编写的先前框架构建新框架。因此，将来如果我在其他地方使用我以前的框架，甚至使用它的另一个派生版本，该框架中的一些代码与我现在为雇主建立的新框架相似，他们将无法说我是使用他们为我编写的代码。 我的问题： 我不会将代码分发给任何人。如果我拥有版权，我不必将我的MIT许可代码分发给任何人，对吗？我的意思是，有人可以要求我发布我现在声称已获得MIT许可的代码吗？这不是世界末日，我当然会同意在法律威胁下这样做。 这个策略有意义吗？我的最终目标是能够使用以前的编码框架的派生版本而不会失去版权。同时，我不想将此代码作为开源项目分发给任何人。我还有其他开放源代码项目，我可以自由分发，但是我希望自己保留这个项目，以便可以在我的工作中使用（而不是承包商的工作）。 就像声称您拥有MIT许可下的框架，而没有实际向任何人分发和/或展示给任何人一样。如果它在那里，免费且容易获得，我的雇主不再需要我。他们只需要获取代码并将其交给其他人使用即可。 笔记： 在开始工作之前，我已将此框架列为以前的发明。 我没有在任何地方发布此代码。它位于我在私有服务器中托管的私有SVN存储库中。 我的想法是： 我的计划是将以前的代码保留给我自己，在我为雇主建立的这个新框架中使用它的一部分，并告诉雇主这是我以前编码的MIT许可框架的工作，并且没有分发给任何人。我没有被迫分发我根据MIT许可证编码的软件，对吗？如果以后发生一些法律声明（希望不是），我可以立即将许可证粘贴到所有源上并显示/发布代码。
4
用于衡量代码稳定性的源代码指标？
考虑到在发行周期（实现，测试，错误修复，发行）中软件的开发方式，我认为人们应该能够看到在代码库中更改过的代码行中的某种模式。例如，在项目结束时，如果代码变得更稳定，则应该看到每单位时间修改的代码行更少。 例如，可以看到在项目的前六个月中，平均每天200行代码，而在上个月中，每天平均50行代码，而在最后一周（就在产品DVD发行之前）已发货），根本没有更改任何代码行（代码冻结）。这只是一个例子，根据特定团队采用的开发过程，可能会出现不同的模式。 无论如何，是否有任何代码度量标准（有关其文献资料？）使用每单位时间的代码修改行数来衡量代码库的稳定性？如果项目到达某个地方或者距离发布尚很遥远，它们是否对感觉有用？是否有任何工具可以从版本控制系统中提取此信息并生成统计信息？
6
大量使用缓存的单元测试方法的最佳做法？
我有许多业务逻辑方法，用于存储和检索（通过过滤）对象以及来自缓存的对象列表。 考虑 IList<TObject> AllFromCache() { ... } TObject FetchById(guid id) { ... } IList<TObject> FilterByPropertry(int property) { ... } Fetch..并Filter..会调用AllFromCache它来填充缓存，如果不存在则返回，如果存在则从其返回。 我通常回避对这些单元进行测试。针对此类结构进行单元测试的最佳实践是什么？ 我考虑过在TestInitialize上填充缓存，并在TestCleanup上删除缓存，但这对我来说并不对，（很可能）。
5
描述性命名与80个字符行的比较[关闭]
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 6年前关闭。 我经常听到这两种有价值的编程实践：（1）代码行应少于80个字符，并且（2）为变量，方法，类等使用描述性名称。我理解这两个建议的含义，它们似乎常常是彼此权衡的。如果我将代码的字符数保持在80个字符/行以下，那么最终我将使用较少的描述性名称（特别是在Python中，每个缩进均计为4个字符），但如果使用的描述性名称较多，则最终将使用80个字符以上的行。 因此，我的问题是，如果必须做出选择，那么遵循这两个建议中哪个更重要？我想作为一个独立的（业余爱好者）程序员来这件事，但更重要的是，从一个为大公司工作的软件工程师的角度来看。
3
检测IEnumerable“状态机”
我刚刚读了一篇有趣的文章，《用C＃收益回报变得太可爱了》 这让我想知道最好的方法是检测IEnumerable是否是实际的可枚举集合，或者它是使用yield关键字生成的状态机。 例如，您可以将DoubleXValue（来自本文）修改为以下内容： private void DoubleXValue(IEnumerable<Point> points) { if(points is List<Point>) foreach (var point in points) point.X *= 2; else throw YouCantDoThatException(); } 问题1）有更好的方法吗？ 问题2）创建API时，我应该担心这一点吗？
17 c#  api-design 
4
质量检查与迭代的困境
在我的公司中，我们成功地采用了敏捷实践，但没有使用迭代。主要原因是我们找不到在迭代周期中适合QA的干净方法。 我们认为质量检查是对特定版本（候选版本）进行额外验证的一部分，然后再将其部署到客户。关键是要避免单个恶意提交会损坏整个发行版。由于您永远都不知道它是哪一个，因此质量检查人员必须等到该版本的所有功能/提交都在构建中。（不允许使用著名的最后一句话“这只是微小的变化”。） 如果质量检查人员在候选发行版中发现错误，则开发人员会在相应的发行分支中修复这些错误（并将其合并到主干中）。修复所有错误后，将部署新版本以进行质量检查以进行重新测试。仅当在某个发行候选版本中未发现错误时，才将其提供给客户进行验证。 每次发布通常需要大约2-3个候选人，大约一周。编写修补程序的时间通常比测试工作要少得多。因此，为了让开发人员忙，他们在版本N + 1上工作，而质量检查则在N上工作。 不使用迭代，这没问题，因为我们可以将版本N和N + 1的工作重叠。但是，据我了解，这与Scrum或XP等基于迭代的方法不兼容。他们要求在迭代结束时发布一个迭代，并将所有测试工作都包含在迭代中。 我发现这必然导致以下不良结果之一： （A）开发人员在迭代结束时处于闲置状态，因为质量检查需要时间来验证发布候选版本，并且错误修复工作并未完全使开发人员处于忙碌状态。 （B）质量保证在准备好第一个候选版本之前就已经开始工作。这是Stack Exchange上最推荐的方法。但这不是我公司所理解的质量检查，因为没有经过测试的特定候选发布版本。破坏一切的“微小变化”仍然可以被忽略。 （C）错误将继续进行下一次迭代。在Stack Exchange上也建议这样做。我认为这根本不是解决方案。从根本上讲，这意味着我们永远不会获得经过验证的内部版本，因​​为只要进行了错误修复，就会将未经验证的新提交也添加到同一分支中。 有没有办法摆脱这种困境？
17 agile  teamwork  qa  sdlc 
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.