软件工程

例如，我有以下实体：客户，报告。客户可能有很多报告，我认为单个报告管理的端点应该像这样嵌套： /clients/{client_id}/reports/{report_id} 至于一位客户的所有报告，预期会： /clients/{client_id}/reports 但是应该如何寻找一个端点来获取所有客户端的所有报告，以保持API的一致性和良好的设计。 我的方法： （我在某些Google API中看到了它）使用“-”代替它，并将其解析为“全部”： /clients/-/reports 这使端点格式保持不变，但看起来有点不正常，找不到任何以此方式建议的rfc。 为所有报告创建一个单独的端点： /reports 但是要获得客户报告，它仍然是： /clients/{client_id}/reports 重构端点以使“客户端”不是父代，而只是一个过滤器参数： /reports?client={client_id} -一位客户的报告 /reports -所有客户的报告 如果添加新的端点以发布特定客户端的报告，则该外观可能很难看，因为它将是带有URL中参数的POST请求。 还有其他建议吗？

12 rest  api  api-design 

在阅读有关ACL和RBAC的信息时，我似乎很容易理解-可以使用用户名或角色来访问资产。我还可以看到如何实现这些目标。 即，此图像为我提供了ACL和RBAC的清晰视图（如上图所示，我可以继续设计数据库表）：（ 图像由pressbooks提供） 我正在努力的是ABAC。到目前为止，我发现的各种图像都是手工绘制的，或者过于复杂，或者建议使用第三方外部实体进行授权。还是给出奇怪的属性示例，我并不完全确定该如何使用。 起始范例 因此，让我从现实生活中入手。假设我有一家拥有70-200人的公司。我要保护的资产是一个包含许多不同页面的网站。我希望允许某些人使用某些资产。 例如，我希望某人Leslie可以访问名为的网页Price Manager，并只允许该人管理Travel该页面上价格组的价格，而不能管理Product同一页面上组的价格。我将如何使用ABAC实施此操作？ 到目前为止，我猜测是我可以分配Leslie一些属性（但是哪些属性是什么？这些属性是什么？），然后有一个存储这些属性的数据库表。然后，我可以设计一个引擎，查看这些属性（但不像LeslieRBAC那样将其视为“角色”），并从中决定是否授予对该页面的访问权限。该引擎的外观如何？这是一个简单的if / else块吗？还有吗 如果莱斯利后来改变立场，而有人需要更改访问权限，会发生什么情况？如果她需要转移访问权限Product并撤消访问权限，将会是什么样Travel？如何将它，如果她需要访问撤销的编码Price Manager页共，因此没有再访问没有Travel，或者Product？ 在我的案例中，资产只是为了重述Price Manager，而用户可以访问该页面上的各种价格组，例如Travel定价，Product定价等。 我正在寻找的是一个合理的完整路线图，以澄清细节并实现实现，我可以不加猜测地实施它。也就是说，它可以在概念上完成和/或具有我可以可视化数据库结构的特定示例，等等。 好处：ABAC是否是满足相对较小的许可需求（例如，管理70-200个人并访问约150-450资产）的正确方法？坚持使用ACL / RBAC会更好吗？

12 permissions  access-control  abac 

在TFS中，当我们在接受请求之前在“拉取请求”中对要修复的问题进行注释时，是否应将其标记为“拒绝”或“等待作者”？哪个更好？

12 team-foundation-server  pull-requests 

借助AOP，我可以从业务逻辑中删除日志记录代码。但是我认为它只能用于记录简单的事物（即记录方法的进入/退出和参数值）。 但是，如果我需要在业务逻辑中记录一些内容，该怎么办？例如 public void SomeDomainMethod(string id) { //Get user by Id User user = Users.Get(id); if (user == null) { Log.Warn("user is not existed"); //<----------------- Log A throw new InvalidOperationException("user is not existed"); } //Step 1 while(true) { //do something } Log.Info("Step 1 is completed"); //<----------------- Log B //Step 2 …

12 c#  logging  separation-of-concerns 

面向对象编程中的重要概念之一是封装。但是，最近，软件世界似乎倾向于使用其他范例，例如函数式编程。 这让我思考，封装和其他OOP原则如何？他们错了吗？ OOP应用错误吗？例如，艾伦·凯（Alan Kay）在OOPSLA'97主题演讲中说：“我发明了术语面向对象，我可以告诉你我没有C ++。” 乔·阿姆斯特朗（Joe Armstrong）-“对象将功能和数据结构以不可分割的单位绑定在一起。我认为这是一个根本性的错误，因为功能和数据结构属于完全不同的世界。”

12 object-oriented  functional-programming 

我看到很多问题都与访问使用连字符（kebab-case）的JSON密钥有关，但是现在我发现自己想知道应该在我的密钥中坚持使用camelCase还是snake_case。我知道连字符在语言之间移植时也会产生复杂的映射。我已经看到一些JSON反序列化库将这些键转换为camelCase样式。 例： var something = { "some-value": 'thing' } VS var something = { "someValue": 'thing', "some_other_value": 'thing_two' }

12 javascript  api  api-design  json  web-api 

这一直困扰着我一段时间。 例如，我们有一个REST API，它为系统提供基本内容，并使用和生成JSON。在此终结点处，它会生成指向图片和描述的URL，并且可以这样找到：// localhost / myApi / pictures / 1 { id: 1, description: "This is a pretty picture of a daisy", URL: <OUR URL> } 现在，OUR_URL应该指向API上的某个位置，例如// localhost / myApi / files / pictures / 1，该位置返回JPG（API后面的应用程序读取文件的物理内容，然后将其流回客户端）。显然，这与生成JSON响应的其余API不同，并且读取和流式传输实际文件会产生开销。 另外，OUR_URL应该指向REST服务范围之外的URL，因此//localhost/files/pictures/1.jpg可以直接在其中读取文件。 所以问题是： RESTful API应该能够返回文件还是仅返回一个位置？

12 rest  patterns-and-practices 

我是一名电气工程师，我不知道自己在做什么。请保存我的代码的未来维护者。 最近，我一直在研究一些较小的程序（在C＃中），其功能在逻辑上是“过程的”。例如，其中之一是一个程序，该程序从不同的数据库收集信息，使用该信息生成某种摘要页面，将其打印出来，然后退出。 所有这些所需的逻辑约为2000行。我当然不想像以前的开发人员所做的那样将所有内容全部填充到一起main()，然后用来“清理” #region（颤抖）。 这是我已经尝试过但不太满意的一些事情： 为每个粗略的功能（例如DatabaseInfoGetter，SummaryPageGenerator和PrintUtility）创建静态实用程序。使主要功能看起来像： int main() { var thisThing = DatabaseInfoGetter.GetThis(); var thatThing = DatabaseInfoGetter.GetThat(); var summary = SummaryPageGenerator.GeneratePage(thisThing, thatThing); PrintUtility.Print(summary); } 对于一个程序，我什至使用了接口 int main() { /* pardon the psuedocode */ List<Function> toDoList = new List<Function>(); toDoList.Add(new DatabaseInfoGetter(serverUrl)); toDoList.Add(new SummaryPageGenerator()); toDoList.Add(new PrintUtility()); foreach (Function f in toDoList) f.Do(); …

12 c#  object-oriented  code-quality  code-smell  procedural 

我正在处理仅需要从其本地安装的本机应用程序浏览器获取的数据的Web应用程序。 您如何绕过浏览器沙箱，以便可以与本机应用程序通信（安全，因为数据可能是敏感的）。 在我发现的唯一示例中，用户手动在两者之间移动了一些令牌和文件，这是我想避免的可怕的用户体验。

12 web-applications 

最近，我接受了工作面试，其中一个问题是“ HTML 5文档是否需要doctype？”。我回答“否”，但有种感觉，我可能错了。从w3看来，这绝对是必需的，但是如果我输入一个简单的HTML <html> <body> <input type="color" disabled/> </body> </html> 将其另存为HTML并尝试在Chrome中打开-使用新的颜色输入（已禁用），它将可以很好地工作。该输入是HTML5以及属性。 所以问题是-是否需要指定doctype？面试的正确答案是什么？

12 html  w3c 

我刚开始阅读O'Reilly的《Learning Perl，第6版》，当我看到此摘录时感到惊讶。 #!/usr/bin/perl print "Hello, world!\n"; 假设您已经在文本编辑器中输入了该内容。（不必担心这些部分的含义以及它们如何工作。稍后您会看到它们的意思。）通常，您可以将该程序保存为所需的任何名称。Perl不需要任何特殊的文件名或扩展名，最好不要使用任何扩展名。 为什么没有扩展更好？想象一下，您已经编写了一个计算保龄球得分的程序，并且已经告诉所有朋友它的名称为bowling.plx。有一天，您决定用C重写它。您是否仍用相同的名称来命名它，这意味着它仍然是用Perl编写的？还是您告诉所有人它都有一个新名称？（请不要把它叫做Bowling.c！）答案是，如果他们只使用它，用什么语言写的与他们无关。因此，它首先应该只是被称为保龄球。 这是我从该视图看到的唯一资源，我阅读的所有其他内容都支持.pl扩展名。我还不是Perl程序员，所以在养成习惯之前，我想知道社区对此的看法。

12 perl 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 对于一个项目，我需要使用一些旧游戏和相关软件中的各种文件类型-配置文件，保存，资源档案等。这些文件的大部分尚未记录，也没有与之配合使用的工具，因此我必须对这些格式进行反向工程并构建自己的库来处理它们。 尽管我认为大多数需求不大，但我打算发表自己的努力成果。是否有记录文件格式的公认标准？环顾四周，有几种正在使用的样式：有些样式（如.ZIP文件格式规范）非常罗;；有些样式则非常冗长。其他的，例如XentaxWiki上的，则更为简洁-我发现其中一些难以阅读；我个人最喜欢的是对PlayStation 2存储卡文件系统的描述，其中包括详细的描述性文字和一些带偏移量的“内存映射”等，它也与我的用例最匹配。对于不同的格式，它会有所不同，但是似乎应该有一些我应该遵循的一般原则。 编辑：我似乎没有很好地解释我想做什么。让我构造一个例子。 我可能有一些旧软件，将其配置存储在一个“二进制”文件中-一系列位域，整数，字符串以及所有这些东西被粘在一起并被程序理解，但不是人类可读的。我破译了。我希望以一种人类可读的方式准确记录该文件的格式，作为实现库以解析和修改此文件的规范。此外，我希望其他人可以轻松理解这一点。 可以使用多种方法来编写此类文档。上面的PKZIP示例非常冗长，主要以自由文本形式描述文件格式。PS2示例提供了值类型，偏移量和大小的表，并对它们的含义进行了广泛注释。许多其他变量（例如XentaxWiki上的变量）仅列出变量类型和大小，几乎没有注释。 我问是否有类似于编码样式指南的标准，该指南提供了有关如何编写此类文档的指南。如果没有，那么有没有我应该效仿的著名例子？如果不是，那么至少有人可以总结一些有用的建议吗？

12 documentation  reverse-engineering 

到目前为止，git最令人困惑的部分是重新部署到另一个分支。具体而言，令人困惑的是命令行参数。 每次我想将一个分支的一小部分重新建立到另一个分支的尖端时，我都必须查看git rebase文档，这大约需要5到10分钟的时间来理解这三个主要参数的含义。 git rebase <upstream> <branch> --onto <newbase> 有什么好的经验法则可以帮助我记住给任何其他基础重新设置到另一个分支时应将这三个参数分别设置为什么？ 请记住，我已经一遍又一遍又一遍（一遍又一遍）遍历了git-rebase文档，但是它总是很难理解（像无聊的科学白皮书之类的东西）。因此，在这一点上，我觉得我需要让其他人参与以帮助我掌握它。 我的目标是，我永远都不必阅读这些基本参数的文档。到目前为止，我还无法记住它们，而且我已经做了很多调整工作。因此，到目前为止，我已经能够记住其他所有命令及其参数，但是却没有使用rebase进行存储，这有点不寻常--onto。

12 git 

在下面的代码中，我将内部样式表放置在body标签中，而不是放在头部。对于单页应用程序，我正在考虑对仅适用于该页面的样式进行此操作，而不要使用单独的pagespecific.css文件。 是否存在一个不利之处，因为我没有在头部提到相同内容？ <!-- myPartial.html starts here --> <!-- Like to keep styles unique to this html right here in this file --> <div> <style> body { background-color: red; } #myText { color: white; } </style> <span id='myText'>Hello</span> </div> <!-- myPartial.html ends here -->

12 html  css 

假设我们正在做一个解析器。一种实现可以是： public sealed class Parser1 { public string Parse(string text) { ... } } 或者我们可以将文本传递给构造函数： public sealed class Parser2 { public Parser2(string text) { this.text = text; } public string Parse() { ... } } 在两种情况下用法都很简单，但是与另一种相比，启用向的参数输入是什么意思Parser1？当他们查看API时，我向同一个程序员发送了什么消息？此外，在某些情况下是否存在任何技术优势/劣势？ 当我意识到接口在第二种实现中将变得毫无意义时，又出现了另一个问题： public interface IParser { string Parse(); } ...第一个接口上的接口至少可以达到某些目的。这是否特别表示某类是“可接口的”？

12 object-oriented  interfaces  methods  construction