软件工程

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

4
甚至值得检查一下Guid.NewGuid()是否为Guid.Empty吗?
在其中一个项目中,我经常遵循以下模式进行工作: var guid = Guid.NewGuid().ToString(); while (guid == Guid.Empty.ToString()) { guid = Guid.NewGuid().ToString(); } 虽然我知道不能保证 GUID是唯一的,并且根据MSDN文档,生成的GUID可能为零,但这是否是一个实际的考虑因素,实际上值得在计算意义上以及针对开发人员的角度进行周期测试?
28 .net  security 

2
为什么选择百分号(%)作为printf系列功能的格式说明符?
每个人都知道,至少在C语言中,您使用printf函数族来打印格式化的字符串。这些函数使用百分号(%)表示格式说明符的开头。例如,%d表示打印一个int和,%u表示打印一个unsigned int。如果您不熟悉printf函数和格式占位符的工作方式,或者只是需要复习,则Wikipedia文章是一个不错的起点。 我的问题是,这是最初还是将来会被选作格式说明符的原因是否特别引人注目? 显然,该决定是在很久以前做出的(很可能是C语言的前身),从那时起,它或多或少成为“标准”的(不仅在C语言中,而且在许多其他语言中,已经在不同程度上采用了它的语法),所以现在改变为时已晚。但是我仍然很好奇,是否有人对为什么首先要做出这种选择有任何见解,以及如果人们正在设计一种具有类似功能的新语言,是否仍然有意义。 例如,对于C#(和其他.NET语言家族),Microsoft在字符串格式化功能的操作方面做出了稍有不同的决定。尽管可以在此处强制执行某种程度的类型安全(与printfC中的实现不同),因此没有必要包含相应参数类型的指示,但他们决定使用零索引的花括号对({})作为格式说明符,例如: string output = String.Format("In {0}, the temperature is {1} degrees Celsius.", "Texas", 37); Console.WriteLine(output); // Output: // In Texas, the temperature is 37 degrees Celsius. 该String.Format方法的文档包含更多信息,就像这篇文章有关复合格式的一般说明一样,但是确切的细节并不重要。关键是他们放弃了%用于指示格式说明符开始的长期实践。C语言本来可以轻松使用{d}和{u},但事实并非如此。任何人都对以下原因有任何想法:为什么要回想起这个决定,以及是否应该遵循新的实现方式? 显然,没有可以不必逃避的字符可以选择,以便可以将其包含在字符串本身中,但是仅使用两个就可以很好地解决该问题。还有哪些其他考虑因素?
27 c  history 

4
除了男性和女性以外,是否存在性别模型的行业标准?
我正在建模一个数据库,该数据库应该用作启动公司的所有服务(如人员,用户,服务和商业数据,如优惠券,签名包等)的通用非功能性要求。 我正在考虑性别模型。在当今时代以及各国关于主观身份的法律不同的情况下,我是否应该考虑这一点,并为我的“个人”实体建模,而不仅仅是男性和女性选择? 选项包括:未定义,未回答,其他,跨性别...或我不知道的任何其他行业标准 ... 还是说LGBT人不是真正的男性或女性而冒犯了他们?

2
如果在业务逻辑更改时失败,则单元测试是否被认为是脆弱的?
请参见下面的代码;它会测试以查看具有性别的女性是否有资格接受要约1: [Fact] public void ReturnsFalseWhenGivenAPersonWithAGenderOfFemale() { var personId = Guid.NewGuid(); var gender = "F"; var person = new Person(personId, gender); var id = Guid.NewGuid(); var offer1 = new Offer1(id,"Offer1"); Assert.False(offer1.IsEligible(person)); } 此单元测试成功。但是,如果将来向女性提供“ Offer1”,它将失败。 可以接受的说法是-如果围绕报价1的业务逻辑发生了变化,那么单元测试就必须发生变化。请注意,在某些情况下(对于某些商品),业务逻辑会在数据库中更改,如下所示: update Offers set Gender='M' where offer=1; 在某些情况下,在域模型中如下所示: if (Gender=Gender.Male) { //do something } 另请注意,在某些情况下,背后的域逻辑会定期更改,而在某些情况下则不会。

5
从整数转换为单精度时可能会失去精度
当我进入该部分时,我正在阅读Microsoft的一篇有关扩大转换和严格选择的文章。 以下转换可能会失去精度: 整数到单 长到单或双 小数到单或双 但是,这些转换不会丢失信息或幅度。 ..但根据另一篇有关数据类型的文章, 整数类型可以存储-2.147.483.648至2.147.483.647和 单一类型可以存储 1,401298E-45到3,4028235E + 38(正数), 和-3,4028235E + 38到-1,401298E-45(对于负数) ..因此Single可以比Integer存储更多的数字。我不明白在什么情况下从Integer转换为Single可能会失去精度。有人可以解释一下吗?

2
纯抽象类和接口的实现
尽管在C ++标准中这不是强制性的,但例如,GCC似乎通过在每个相关类的实例中都包含指向该抽象类的v表的指针来实现父类(包括纯抽象类)的方式。 自然,这通过其具有的每个父类的指针使该类的每个实例的大小膨胀。 但是我注意到许多C#类和结构都有很多父接口,它们基本上是纯抽象类。如果对say的每个实例Decimal都充满了指向所有各种接口的6个指针,我会感到惊讶。 因此,如果C#确实使用不同的接口,至少在典型的实现中,它如何实现它们(我知道标准本身可能没有定义这种实现)?在将纯虚拟父代添加到类时,是否有任何C ++实现都可以避免对象大小膨胀?

3
电梯使用哪种算法来找到最短的下单路径?
我一直在尝试模拟一个电梯,就像往常一样,我一次只做一个简单的命令就非常简单,然后以队列的形式向电梯添加内存,以便按压下的顺序移动地板,这显然不是最佳方法。 因此,目前我使用的是一种非常简单且“近视”的逻辑,即对于当前楼层,找到离我最近的楼层并将其设置为我的下一个目的地,然后循环直到列表中没有更多的楼层。 但这并不总是有效,例如,电梯位于5层建筑的3层,并获得订单4,5,2,最短路径为2-> 4-> 5,花费4层,但是使用此逻辑根据代码的不同,花费5的4-> 5-> 2有相同的机会被选中。 如何找到最短的路径并使电梯更高效?

6
无需单元测试即可敏捷
如果您正在使用的代码库的单元测试覆盖率为0%,那么谈论“敏捷开发”或声称您正在应用“敏捷方法论”是否有意义?(而且,作为一个团队,您对此没有做任何事情)。 明确一点:对我来说,这没有任何意义。根据我的个人经验,我发现单元测试是使您真正“敏捷”(即响应更改,改进设计,共享知识等)的唯一工具,而TDD是使您达到目标的唯一实践。 。 也许还有其他方法,但是我仍然看不到它们如何工作。

8
是否可以静态地预测何时仅从源代码中释放内存?
在程序执行期间,确定性的时间将内存(和资源锁)返回给OS。程序本身的控制流足以知道可以在哪里释放给定资源。就像人类程序员fclose(file)在程序完成后如何知道在哪里写一样。 GC通过在执行控制流时在运行时直接解决问题来解决此问题。但是,有关控制流的真实性的真正来源是来源。因此,从理论上讲,应该可以free()通过分析源(或AST)来确定在编译之前将调用插入到哪里。 引用计数是实现此目的的一种明显方法,但是很容易遇到仍然引用指针(仍在范围内)但不再需要指针的情况。这只是将手动分配指针的职责转换为手动管理这些指针的作用域/引用的职责。 似乎可以编写一个可以读取程序源代码的程序,并且: 预测程序控制流的所有排列-达到与观看程序实时执行类似的准确性 跟踪所有对分配资源的引用 对于每个引用,遍历整个后续控制流,以找到保证绝对不会取消引用的最早点 在这一点上,在源代码的那一行插入一个delocation语句 那里有什么已经做到了吗?我不认为Rust或C ++智能指针/ RAII是同一回事。
27 parsing  memory 

6
修复错误是否有边际收益[关闭]
我从一位前同事那里听说,并不是所有的bug都需要修复,因为当您按优先级排列bug时,导致该bug变得更加模糊的用例,或者获得的客户满意度降低了。但是您仍然必须花费大量时间来修复该错误。 为了使我们的产品所有者相信这一概念,我找不到任何好的资源。我所能找到的只是关于软件开发是否存在边际成本的讨论。 修复错误真的有边际收益吗?是否有其他术语解释这个概念?


7
对等/代码审查失败
我不会称自己为超级巨星开发者,而是相对经验丰富的开发者。我试图将代码质量保持在较高水平,并且一​​直在寻求对我的编码样式的改进,试图使代码高效,可读性和一致性,并鼓励团队遵循一种模式和方法来确保一致性。我也了解在质量和速度之间取得平衡的必要性。 为了实现这一目标,我向我的团队介绍了同行评审的概念。在github pull-request中两个竖起大拇指以进行合并。很好-但是我认为没有打cc。 我经常看到来自相同同事的同行评论,例如- 在之后添加一个空格会很好 <INSERT SOMETHING HERE> 方法之间多余的多余线条 在文档块中的注释末尾应使用句号。 现在,从我的角度来看-审阅者只是从表面上看待代码美观性-并没有真正执行代码审阅。化妆品规范审查以傲慢/精明的心态传给我。它缺乏实质性内容,但是您不能对此进行过多辩论,因为审阅者在技术上是正确的。我宁愿看到较少的上述评论,而更多评论如下: 您可以通过以下方式降低圈复杂度: 提早离开,避免如果/其他 将数据库查询抽象到存储库 这种逻辑并不真正属于这里 不要重复自己-抽象和重复使用 如果X将其作为方法的参数传递将会怎样Y? 单元测试在哪里? 我发现提供修饰类型评论的总是同一类型的人,而我认为给出“基于质量和逻辑”的同行评论总是相同类型的人。 什么是同行评审的正确方法(如果有)。我是否对同一个人感到沮丧,因为他们基本上都是在浏览代码以寻找拼写错误和美学缺陷而不是实际的代码缺陷? 如果我是正确的-我将如何鼓励同事在建议进行外观修饰的同时找到代码中的错误呢? 如果我不正确-请赐教。对于真正构成良好的代码审查,是否有任何经验法则?我是否错过了什么代码审查的要点? 在我看来,代码审查与代码的共同责任有关。如果不解决/检查逻辑,可读性和功能性,我会不愿意给代码竖起大拇指。如果我发现有人在文档块中省略了句号,那么我也不会为可靠的代码块而阻塞合并。 当我检查代码时,每500 Loc可能花费15-45分钟。我无法想象这些简短的评论要花超过10分钟的时间,如果那是他们正在执行的评论的深度。此外,浅薄评论者的赞许是多少?当然,这意味着所有人的拇指都不一样,并且可能需要进行两遍审核。一个拇指要进行深度评价,第二个拇指要进行“抛光”?

5
捕获/抛出异常是否会使原本纯净的方法不纯?
以下代码示例为我的问题提供了上下文。 用委托初始化Room类。在Room类的第一个实现中,没有防范引发异常的委托的措施。此类异常将上升到North属性,在该North属性上评估委托(请注意:Main()方法演示了如何在客户端代码中使用Room实例): public sealed class Room { private readonly Func<Room> north; public Room(Func<Room> north) { this.north = north; } public Room North { get { return this.north(); } } public static void Main(string[] args) { Func<Room> evilDelegate = () => { throw new Exception(); }; var kitchen = new Room(north: …

2
基于角色的REST API?
我正在构建一个REST API,具有不同角色的多个用户将可以访问它所包含的资源。 为了简化范围,让我们采用“学生/教师/班级”域: GET /students 是要访问的资源。 用户可能具有学生和/或老师之类的角色 学生将只能访问其班级的学生。老师将有机会接触所教课程的学生。一些用途可能是学生,也可能教其他课程。他们必须有权访问班级的学生和所教课程的学生。 理想情况下,我希望将其实现为两个功能-每个角色一个,如果用户具有多个角色,则“工会”。 我的问题是:我应该使用哪种模式来实现这一目标? 在外部 我应该按角色划分API吗?GET /teacher/students而GET /student/students这似乎并不合适的给我。 保留所有这些,我是一种资源(首选) 内部地 应该如何在内部实施? 每种方法都应该以BIG开关/如果每个角色开头吗? 我应该为每个角色实现一个存储库吗? 有没有一种设计模式可以帮助我实现这一目标? 附带说明一下:我正在使用ASP.NET Web API和Entity Framework 6,但这对于概念性实现来说并没有关系。

3
如何有效地存储大时间序列数据?
我需要存储并能够查询一些非常大的时间序列数据。 数据的属性如下: 系列数:约12.000(1.2万) 全球数据点数量:每月约5000亿(五亿) 混合值类型:大多数数据点为浮点值,其余为字符串 采样周期:系列之间以及系列内的变量 时间戳:毫秒精度 数据保留期:数年,无衰减或下采样 数据存档需要近乎实时地构建,但是可以接受合理的延迟(〜1小时) 如果需要,可以重建过去的数据,但是成本很高 有时(但很少),需要更新一些过去的数据 预想查询的属性: 针对数据的大多数查询将是基于时间戳的查询;从一天到几个月/年不等。90%以上将是对最新数据的查询 其他需求: 解决方案必须像免费啤酒一样免费,最好是开源的 我最初的想法是将带有HDF5文件的 PyTables / Pandas 用作存储后端,而不是SQL数据库。 问题: 假设PyTables / Pandas是“最佳”途径,将数据拆分成多个HDF文件,每个文件跨越一个给定的时间,还是将所有内容都放入一个单独的文件中,然后再变得庞大会更好吗? 我应该选择固定格式还是表格格式?对我来说,如果我每月保留一个HDF文件,则固定格式看起来还可以,因为这样一来,整个系列就可以放入RAM中,并且可以在内存中切片而不需要表格式索引。我对么 ? 如果那不是最好的方法,那么我应该如何构造该数据存储或应该考虑哪些技术?我不是第一个处理存储大量时间序列数据的人,解决此难题的一般方法是什么? 我考虑过的其他方法: 数组数据库:它们非常适合具有恒定采样周期的时间序列,因为您只需要存储数组的开始和结束时间以及采样周期,然后只需要数组本身中的值和索引即可。但是,由于序列本身具有可变的采样周期,因此我需要保持更紧密的timestamp-> value关系,我认为这不太适合数组DBMS。 标准SQL数据库,其中带有时间戳,paramID,值作为列,但根据其性质,它们为任何查询都请求大量磁盘I / O

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.