软件工程

将该原理定义为具有更改理由的模块。我的问题是，在代码实际开始更改之前，这些更改原因肯定是未知的吗？几乎每一段代码有许多原因，它可能会可能改变，但肯定尝试预见所有的这些设计和代码考虑到这一点最终会很差代码。仅在开始请求更改代码时才真正开始应用SRP，这不是一个更好的主意吗？更具体地说，当一段代码由于多个原因而多次更改时，因此证明它具有多个更改原因。尝试猜测更改的原因听起来很反敏捷。 一个示例是一段打印文档的代码。提出了将其更改为打印为PDF的请求，然后再次请求将其更改为对文档应用某些不同的格式。在这一点上，您有证据证明有多个原因需要更改（并且违反了SRP），并且应该进行适当的重构。

20 design-patterns  single-responsibility 

我想知道Bootstrap决定在v3.0中将所有驼峰案例名称更改为带连字符的名称的原因是什么。我在Google上搜索，看了几本书，但我只能以一种或另一种方式找到意见-没有硬数据。 是否有任何研究表明驼峰变量名比破折号更易读，或者这仅仅是个人喜好问题？

20 coding-standards  readability 

在《Noda Time用户指南》中，基本原理部分指出： 公共API已被大量重写，以提供对.NET更惯用的API，并纠正Noda Time团队认为“不幸”的一些Joda Time决定。（其中一些仅仅是由于具有不同的目标；我认为其他一些确实是错误。） 这些不同/更好的决定是什么？这将不仅仅考虑语言语法的差异，而是将包括所有使用户不太可能发生编程错误（库可用性）的工作。

20 libraries  time  joda-time 

拥有许多敏捷Scrum团队的组织也只有一小部分人被任命为“企业架构师”。EA小组充当质量和对决策的坚持和控制者。这导致团队决策和EA决策之间出现重叠。 例如，团队可能要使用库X或要使用REST而不是SOAP，但是EA对此不赞成。 现在，当团队决策被否决时，这可能会导致挫败感。言归正传，它有可能导致EA人员“抢夺”所有权力，并且团队最终感到动力不足，甚至一点也不敏捷。 在Scrum的导游有这样一段话吧： 自组织：没有人（甚至不是Scrum Master）告诉开发团队如何将产品待办事项转换为潜在可发布功能的增量。 那合理吗？EA团队应该解散吗？车队应该拒绝还是仅仅遵守？

20 agile  scrum  teamwork  architect 

此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 6年前。 根据ECMA-262，第11.13部分，以下是复合赋值运算符的详尽列表：*= /= %= += -= <<= >>= >>>= &= ^= |=。 据部分11.11，var c = a || b将会把a价值成c，如果ToBoolean(a)是真实的，将把b价值为c其他。这样，逻辑“或”通常用作合并运算符，例如 function (options) { options = options || {}; } 通常，使用合并来指定变量的默认值，如上所示：a = a || b。 复合赋值运算符似乎||=很有用，它允许以更短，更简洁的方式编写上述代码：a ||= b。然而，它不存在（虽然*=，+=和其它复合赋值运算符是）。 问题是，为什么？

20 javascript  language-design  history 

由于我对所有变量都使用了完全正确的大小写形式，因此引起了其他程序员的大量批评。例如，您的典型程序员将使用employeeCount变量名，但我使用EmployeeCount。我对所有内容都使用完全正确的大小写，无论是void方法，return方法，变量，属性还是常量。我什至在Javascript中都遵循此约定。最后一个确实震撼了人们的傻瓜。 关于为什么我不应该遵循这种“非标准”大写字母约定的典型原因是，应为属性和void方法保留完整的适当大小写。局部变量和返回值的方法的首字母应小写，例如int employeeCount = getEmployeeCount()。 但是，我不明白为什么。 当我对此提出疑问时，似乎只能得到一个任意的答案，那就是标准。不管答案是什么，它通常总是归结为这就是它的样子，我对此并不怀疑。我只是跟随它。。任意答案对我来说永远不够好。 自从使用Office IDE对Excel 97宏进行编程的早期开始，我就不需要用大小写约定来告诉我某些东西是局部变量还是属性。这是因为我一直使用非常直观的命名约定。例如，GetNuggetCount()很明显地提出了一种方法，该方法可以计算所有矿块的数量。 SetNuggetCount(x)建议您为块数分配一个新值。 NuggetCount所有这些本身都暗示了仅包含值的属性或局部变量。对于最后一个，可能会想说：“啊哈！这是问题。属性或变量？这是什么？” 为此，我会回答：“这真的重要吗？” 因此，这就是tl; dr ;：在变量或return方法中的第一个单词使用小写字母的客观，逻辑，非任意原因是什么？ 编辑： 对于MainMa 将此代码替换为答案中的第一个代码示例，然后查看您的论点是否成立： public void ComputeMetrics() { const int MaxSnapshots = 20; var Snapshots = this.LiveMeasurements.IsEnabled ? this.GrabSnapshots(MaxSnapshots, this.cache) : this.LoadFromMemoryStorage(); if (!Snapshots.Any()) { this.Report(LogMessage.SnapshotsAreEmpty); return; } var MeasurementCount = Measurements.Count(); this.Chart.Initialize((count + 1) …

20 variables  methods  naming-standards 

我正在编写一个简单的小程序来通过网络传输MIDI。我知道程序会遇到传输问题和/或其他无法预测的异常情况。 对于异常处理，我看到两种方法。我应该编写程序以便它： 发生问题时失败并发出爆炸声， 或者 它是否应该忽略错误并继续进行，以牺牲数据完整性为代价？ 用户合理地期望哪种方法？ 有没有更好的处理异常的方法？ 另外，我是否处理网络连接（即，我可以合理预期出现问题的地方）是否会影响我处理异常的决定？

20 exception-handling 

在一本OS书中，我刚刚读到“公共API永远存在：只有一次实现它的机会”。是真的吗 它仅适用于操作系统的API还是其他API？例如，对于Tasker，Locale和Pushover等Android应用程序的API，这是否正确？

20 android  api  api-design 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 人们建议我“找一份做自己擅长的工作”，但事实是我不相信我会擅长于仅编写代码。我不认为我可以设计或构造程序。 不要误会我的意思，我不是那种不能编写嘶嘶声程序的程序员。我更像是那种除了完成工作之外不能做很多事情的程序员。这并不是说我有“做到最低限度”的态度。那是我很痛苦地意识到自己作为程序员的局限性。 例如，实现快速排序算法是我只能依靠死记硬背才能做到的（也就是说，如果我发现有动机花费大量时间尝试将整个算法提交到内存中，而不仅仅是就像“嗯，我明白了，这很有意义，我可以看到逻辑...”）。 当涉及到结构化和设计应用程序时，我感到无助。由于一开始我看不到正确的答案，所以我只打了个判断电话，十分之九的事我后来都后悔。 我仍然设法从同事那里获得工作晋升和称赞，因此其他人不一定会分享我的观点。客观地说，我只是没有学习能力，也没有纯粹的脑力去现实地追求成为“略高于平均水平”的程序员。 我想知道我是否真的有道德义务为更多有才华的人腾出空间并找到另一种工作，即使我非常有信心自己不会找到我所能胜任的其他角色。那么我的问题是“普通程序员是否在团队中占有一席之地？”

20 skills  ethics 

最近，我一直在阅读“ 学习Haskell以获得卓越成就”指南，并且作为练习，我想用它来解决Euler问题5，该问题指定了： 能被1到20的所有数均分的最小正数是多少？ 我决定首先编写一个函数，以确定给定数字是否可被这些数字整除： divisable x = all (\y -> x `mod` y == 0)[1..20] 然后，我使用计算了最小的head： sm = head [x | x <- [1..], divisable x] 最后写一行来显示结果： main = putStrLn $ show $ sm 不幸的是，这花了大约30秒才能完成。用数字1到10进行相同的操作几乎会立即产生结果，但是结果又比1到20的解小得多。 我在C中较早地解决了该问题，并且几乎立即就可以计算出1到20的结果。这使我相信我误解了如何为Haskell解释这个问题。我查看了其他人的解决方案，发现了以下几点： main = putStrLn $ show $ foldl1 lcm [1..20] 公平地说，这使用了内置函数，但是为什么自己动手最终结果会这么慢？那里的教程告诉您如何使用Haskell，但是在将算法转换为快速代码方面我没有看到太多帮助。

20 haskell 

尽管人们普遍认为计划扑克可以提高项目估计的准确性（在这个问题上证明了其中的一小部分），但是是否对此主题进行了明确的研究？ 更具体地说，我正在寻找非偶然的信息，以表明计划扑克将是对传统估算技术的一种改进。

20 agile  estimation  planning  research 

我知道许多版本控制系统：CVS，SVN，TFS等... 我已经在Google上搜索了第一个“版本控制/版本控制系统”，并看到了各种矛盾的答案。 源代码控制是什么时候发明的？谁发明的？那叫什么

20 version-control  history  scm 

我知道Haskell已经可以对另一个类型进行参数化（类似于C ++中的模板编程），但是我想知道Haskell是否也可以对值进行参数化-是否支持依赖类型。使用从属类型，您可以拥有在整数上参数化的类型，例如大小为n的向量，大小为n×m的矩阵等。 如果没有，为什么不呢？将来是否有可能获得支持？

20 haskell 

我最近想知道为什么auto在C ++ 11中选择了关键字来标记必须由编译器推断类型的变量，例如 auto x = 1; 以来 var 在其他编程语言（例如C＃，Scala，JavaScript）中似乎更常见，并且 据我所知，autobreaks向后兼容的新语义（它很少使用，但在以前的C ++版本中具有不同的含义，请参见例如此处）。 我想问一下是否有一个特殊的原因选择auto（赞成var或其他任何关键字）。在C ++ 11标准发布之前是否有关于此问题的特定讨论？ 另外，在使用C ++ 11编译器重新编译旧版C ++代码时，是否应该注意任何可能的不兼容性？

20 c++  c++11  type-systems 

F＃中Y组合器的定义是 let rec y f x = f (y f) x f希望将递归子问题的某些延续作为第一个论点。使用yf作为延续，我们可以看到f将应用于后续调用，因为我们可以开发 let y f x = f (y f) x = f (f (y f)) x = f (f (f (y f))) x etc... 问题是，先验的是，该方案无法使用任何尾部调用优化：的确，f中可能存在一些待处理的操作，在这种情况下，我们不能仅仅改变与f相关联的本地堆栈帧。 因此： 一方面，使用Y组合器需要一个与函数本身截然不同的延续。 在其他方面要应用TCO，我们希望f中没有待处理的操作，而仅调用f本身。 您知道这两者可以和解的任何方式吗？就像带累加器技巧的Y或CPS技巧的Y一样？还是有论据证明不可能做到这一点？

20 f#  recursion  tail-call  continuation