软件工程

我对此很困惑。我相信，我获得的经验越多，我越会成为发现错误并迅速解决错误的专家。 现在我的老板从一个程序员那里获得了一个网站，他的代码编写得非常非常糟糕。现在，他发送了要修复的问题列表。 假设这是样式表问题，而老人不知道如何解决，但是根据我的经验，我很快就知道了问题所在，我可以在两分钟内解决它，并且可以解决许多类似的问题。 但是在解决所有问题之后，我意识到我在15分钟内解决了其他人无法解决的所有问题。 我每小时能得到25美元，所以我为这笔花费6年的事情收费6美元，这让我非常难过。 可以收取6美元吗，还是应该有某种收费方法？

127 freelancing 

这有点花哨，但我已经看到有人使用Id了： private int userId; public int getUserId(); 其他使用： private int userID; public int getUserID(); 其中一个比另一个更好吗？为什么？我在大型项目中看到这种做法非常不一致。如果我要设定一个大多数人会熟悉的标准？哪个是常规标准？

126 coding-style  naming  variables 

有时使用递归比使用循环更好，而使用循环比使用递归更好。选择“正确”的代码可以节省资源和/或减少代码行数。 在任何情况下，只能使用递归而不是循环来完成任务吗？

126 recursion  loops 

如果在软件工作面试中（或作为面试前的筛选问题）要求您输入Stack Exchange用户名，您认为合适吗？ 对我来说，这似乎是一个非常合理的要求，而且这将是非常有益的-我敢肯定，通过查看他们在Stack Exchange上发布的问题和答案，我可以在五分钟内了解更多关于候选人的信息，而不是通过30分钟的采访。但是这样的问题会不好吗？是“太个人化”了吗？ （对于GitHub或其他公共/在线代码共享论坛也是如此。）

126 interview 

在软件行业中，最普遍的虚假经济状况是最糟糕的（即节省金钱的方法最终花费的成本要大于储蓄所造成的费用），您如何与之抗衡？

126 programming-practices  project-management 

有没有人想过为什么我们中的很多人使用相同的变量名重复相同的模式？ for (int i = 0; i < foo; i++) { // ... } 看来我曾经看着用途大多数代码i，j，k等为迭代变量。 我想我是从某个地方捡来的，但是我想知道为什么这在软件开发中如此普遍。是我们所有人都从C中获得的东西还是类似的东西？ 我的脑后已经痒了一段时间。

126 programming-practices  coding-style  coding-standards 

在我今天有关Unity的演讲中，我们讨论了通过检查用户是否按下按钮的每一帧来更新播放器位置。有人说这效率低下，我们应该改用事件监听器。 我的问题是，无论使用哪种编程语言或应用哪种情况，事件监听器如何工作？ 我的直觉是假定事件侦听器不断检查事件是否已被触发，这意味着，在我的情况下，与检查事件是否被触发的每个帧没有什么不同。 根据课堂讨论，事件监听器似乎以不同的方式工作。 事件监听器如何工作？

125 event-programming 

这是我遇到过几次的问题。假设您有一条要存储到数据库表中的记录。该表具有一个名为“ date_created”的DateTime列。这项特别的记录创建于很久以前，您不确定确切的日期，但知道年份和月份。您只知道年份的其他记录。您知道日，月和年的其他记录。 您不能使用DateTime字段，因为“ 1978年5月”不是有效的日期。如果将其分成多列，则会失去查询能力。有没有其他人遇到过这个问题，如果是这样，您是如何处理的？ 为了阐明我正在构建的系统，它是一个跟踪档案的系统。一些内容是很久以前制作的，我们所知道的只是“ 1978年5月”。我可以将其存储为1978年5月1日，但是只能以某种方式表示该日期仅对月份准确。这样，几年后，当我检索该存档时，当日期不匹配时，我不会感到困惑。 对我而言，将“ 1978年5月的未知日期”与“ 1978年5月1日”区分开是很重要的。另外，我也不想将未知数存储为0，例如“ 1978年5月0日”，因为大多数数据库系统都会将其作为无效的日期值来拒绝。

125 database  date-format 

您已经找到了一些看起来多余的代码，而编译器没有注意到这一点。您要做什么以确保（或尽可能接近地确保）删除此代码不会导致回归。 想到两个主意。 根据代码是否看起来应该执行来“简单地”使用推论。但是，有时这可能是一项复杂，耗时的工作，并且风险很小（您的评估容易出错），并且没有实质性的业务回报。 将日志记录在该代码部分中，并查看实际输入的频率。执行完足够的代码后，您应该有足够的信心删除代码是安全的。 是否有更好的主意或类似的规范方法？

125 clean-code 

每当我发现自己多次编写相同的逻辑时，我通常会将其粘贴在一个函数中，因此在我的应用程序中只有一个地方需要维护该逻辑。副作用是我有时会遇到一两个函数，例如： function conditionMet(){ return x == condition; } 要么 function runCallback(callback){ if($.isFunction(callback)) callback(); } 这是偷懒还是不好的做法？我之所以只问是因为这会导致大量的函数调用需要非常小的逻辑。

125 programming-practices  coding-standards 

由于该公司是私人公司，所以股票期权没有多大意义。[如果您是某种类型的facebook，并且监管系统允许使用诸如secondmarket之类的网站，那么我仍然会这样做。] 我可以想到一些： 对父母和岳父母的健康利益 赞助一辆省油的自行车开车去办公室 礼品卡，用于完成1、3、5年服务 我真的可以在这里提供更多建议。 编辑： 谢谢大家的答复。总结一下，这是我的人力资源可以做的其他事情： 员工缴纳的退休金等额供款 资助继续教育，专业课程等 公司订阅ACM，IEEE，Safari图书等 餐券 参加体育馆 在办公室托管娱乐室 现货奖金 认可个人贡献的代码高峰时间 休假者

125 management 

假设我有一个具有“类型”属性的实体。可能有20多种可能的类型。 现在，我被要求实现一些允许从A-> B更改类型的方法，这是唯一的用例。 那么，我应该实现一些允许对类型进行任意更改的方法吗，只要它们是有效的类型？或者我应该只允许它根据要求从A-> B更改而拒绝其他任何类型的更改，例如B-> A或A-> C？ 我从双方都可以看到优缺点，在将来出现类似要求的情况下，通用解决方案意味着工作量会减少，但这也意味着出错的可能性更大（尽管我们100％控制着调用方点）。 一种特定的解决方案不太容易出错，但是如果出现类似的要求，将来需要做更多的工作。 我一直在听到，优秀的开发人员应该尝试预期变化并设计系统，以便将来轻松扩展，这听起来像是通用解决方案？ 编辑： 在我不太具体的示例中添加更多详细信息：在这种情况下，“通用”解决方案比“特定”解决方案需要的工作更少，因为特定解决方案需要对旧类型和新类型进行验证，而通用解决方案只需要验证新类型。

124 programming-practices  api-design  requirements 

我经常使用非常数值/数学的程序，其中函数的确切结果很难预先预测。 在尝试将TDD与此类代码一起应用时，我经常发现编写被测代码比编写该代码的单元测试要容易得多，因为我知道找到预期结果的唯一方法是应用算法本身（无论头，纸上或通过计算机）。感觉不对，因为我正在有效地使用被测代码来验证单元测试，而不是相反。 当难以预测被测代码的结果时，是否存在用于编写单元测试和应用TDD的已知技术？ 难以预测结果的（真实）代码示例： 返回weightedTasksOnTime给定每天workPerDay在（0，24]范围内完成的工作量，当前时间initialTime> 0和任务列表的函数taskArray；每个任务的完成属性时间time> 0，到期日due和重要性值importance；返回[0，1]范围内的标准化值，表示due如果每个任务按taskArray，给出的顺序完成，则可以在其日期之前完成的任务的重要性initialTime。 实现此功能的算法相对简单：对中的任务进行迭代taskArray。对于每个任务，添加time到initialTime。如果新时间< due，则添加importance到累加器。时间是通过反向workPerDay来调整的。返回累加器之前，请除以任务重要性之和以进行归一化。 function weightedTasksOnTime(workPerDay, initialTime, taskArray) { let simulatedTime = initialTime let accumulator = 0; for (task in taskArray) { simulatedTime += task.time * (24 / workPerDay) if (simulatedTime < task.due) { accumulator += task.importance } } return accumulator / totalImportance(taskArray) } 我相信可以通过删除workPerDay和规范化要求来简化上述问题，同时保持其核心，从而得出： …

124 unit-testing  tdd 

自从学习（并喜欢）自动化测试以来，我发现自己几乎在每个项目中都使用了依赖注入模式。在进行自动化测试时，使用这种模式是否总是合适的？您是否应该避免使用依赖注入？

124 design-patterns  dependency-injection 

我们是一家只有一种产品的小型软件公司。 我们使用scrum，我们的开发人员选择他们想要包含在每个sprint中的功能。不幸的是，在过去的18个月中，该团队从未交付过他们致力于冲刺的功能。 我已经读过很多帖子/答案，它们都说“软件完成后立即完成工作，这无助于……给团队施加压力，让更多人参与其中， ……”我已经收到一位开发人员针对如何提高冲刺成功率提出的类似反馈。哦，是的，我们确实使用回顾。 我的问题基本上是： 寻找开发人员质量问题的公平时间是什么时候？ 我开始认为，如果您选择自己的工作/功能并且仍然无法使每个冲刺都失败，则-您将无法监督自己代码的复杂性；-或代码是如此复杂，以至于没有人能够监督复杂性。 我想念什么吗？

124 scrum  planning