软件工程

我想知道为什么下划线没有markdown语法？我知道可以嵌入基本的html标签来实现这一点，但是我试图理解为什么underline在存在粗体和斜体时为什么会省略

133 syntax  editor 

我看过推荐过几次《有效使用旧版代码》的书。本书的重点是什么？ 除了添加单元/集成测试然后进行重构之外，处理遗留代码还有更多的事情吗？

133 books  testing  refactoring  legacy 

我是一名高级前端开发人员，使用Babel ES6进行编码。我们的应用程序的一部分进行了API调用，根据我们从API调用获得的数据模型，需要填写某些表格。 这些表格存储在一个双向链接的列表中（如果后端说某些数据无效，我们可以通过简单地修改清单。） 无论如何，有很多用于添加页面的函数，我想知道我是否太聪明了。这只是一个基本概述-实际的算法要复杂得多，有大量不同的页面和页面类型，但这将为您提供示例。 我认为，这是新手程序员处理该问题的方式。 export const addPages = (apiData) => { let pagesList = new PagesList(); if(apiData.pages.foo){ pagesList.add('foo', apiData.pages.foo){ } if (apiData.pages.arrayOfBars){ let bars = apiData.pages.arrayOfBars; bars.forEach((bar) => { pagesList.add(bar.name, bar.data); }) } if (apiData.pages.customBazes) { let bazes = apiData.pages.customBazes; bazes.forEach((baz) => { pagesList.add(customBazParser(baz)); }) } return pagesList; } …

133 coding-style  functional-programming  teamwork  senior-developer  leadership 

我对整个NoSQL之类的东西有些困惑。您何时选择在Oracle或MySQL上使用MongoDB之类的东西？就它们之间的用法而言，我并不真正理解“差异”。 从我的理解来看，NoSQL类型数据库不是要取代RDBMS，而是它们到底要做什么？

133 database  nosql  rdms 

有人将如何作为单独开发人员实施敏捷流程概念？敏捷似乎有助于加快应用程序的开发速度，但似乎也非常面向团队。

133 agile  solo-development 

我在家照顾自己的生意，妻子来找我说 亲爱的..您可以在控制台中打印2018年全球所有的日光节约时间吗？我需要检查一下。 我非常高兴，因为那是我一直在等待一生的Java经验，并提出了： import java.time.*; import java.util.Set; class App { void dayLightSavings() { final Set<String> availableZoneIds = ZoneId.getAvailableZoneIds(); availableZoneIds.forEach( zoneId -> { LocalDateTime dateTime = LocalDateTime.of( LocalDate.of(2018, 1, 1), LocalTime.of(0, 0, 0) ); ZonedDateTime now = ZonedDateTime.of(dateTime, ZoneId.of(zoneId)); while (2018 == now.getYear()) { int hour = now.getHour(); now = now.plusHours(1); …

133 design  programming-practices  clean-code 

使用DTO的意义何在？它是过时的概念吗？我在视图层中使用POJO来传输和保留数据。可以将这些POJO视为DTO的替代方法吗？

132 java  design-patterns 

我是一个单独的开发人员，拥有一个受时间限制的漂亮工作环境，每个项目的开发时间通常为1-4周，具体取决于需求，紧迫性或两者兼而有之。在任何给定的时间，我都会处理大约3-4个项目，其中一些时间表彼此重叠。 预期，代码质量会受到影响。我也没有正式测试；它通常会涉及到遍历整个系统，直到出现故障为止。结果，大量的错误逃逸到了生产环境中，我必须修复这些错误，然后又使我的其他项目受挫。 这是进行单元测试的地方。正确完成后，应该将错误（更不用说那些逃到生产环境的错误）保持在最低限度。另一方面，编写测试可能要花费大量时间，对于像我这样的时间受限制的项目来说，这听起来并不好。 问题是，与未经测试的代码相比，编写经过单元测试的代码要花多少时间差？随着项目范围的扩大，时间差如何扩大？

132 unit-testing  productivity  solo-development 

在敏捷方法（例如SCRUM）中，用户故事所需的复杂性/工作量是在故事点中衡量的。故事点用于计算团队在一次迭代中可以获取多少个用户故事。 引入一个抽象概念（故事点）有什么好处，在这里我们可以使用一个具体的度量，例如估计的工时？我们还可以使用估计的工时来计算速度，估计迭代的覆盖范围等。 相反，故事点更难使用（因为概念很抽象），也很难向涉众解释。它提供什么优势？

132 agile  scrum  estimation  user-story 

我正在考虑学习C。 但是，如果人们可以“危险地”使用C（或C ++），为什么还要使用它呢？ 危险是指指针和其他类似的东西。 就像堆栈溢出问题一样，为什么gets函数如此危险以至于不应该使用它？。为什么程序员不仅仅使用Java或Python或其他编译语言（如Visual Basic）？

132 c++  c 

我使用高级语言（Python，C＃，VBA，VB.NET）编程已有大约10年的时间，而对于“幕后”所发生的事情，我完全不了解。 我想知道学习汇编的好处是什么，对作为程序员的我有什么帮助？您能否提供给我一个资源，向我展示我在高级代码中编写的代码与汇编中发生的代码之间的确切联系？

132 assembly 

假设我们有一个Task实体列表和一个ProjectTask子类型。任务可以随时关闭，除非ProjectTasks状态为“已启动”的任务无法关闭。用户界面应确保关闭启动选项ProjectTask永远不会可用，但是域中存在一些保护措施： public class Task { public Status Status { get; set; } public virtual void Close() { Status = Status.Closed; } } public class ProjectTask : Task { public override void Close() { if (Status == Status.Started) throw new Exception("Cannot close a started Project Task"); base.Close(); } } 现在，在调用Close()Task时，如果调用ProjectTask处于启动状态，则有可能失败，而如果它是基本Task，则调用不会失败。但这是业务需求。它应该失败。可以认为这违反了Liskov替代原则吗？

132 design  object-oriented-design  solid  liskov-substitution 

我的组织正在考虑从SVN迁移到Git。反对搬迁的一种论据如下： 我们如何进行版本控制？ 我们有一个基于NetBeans平台的SDK发行版。由于SVN修订版是简单的数字，因此我们可以使用它们来扩展我们的插件和SDK构建的版本号。转移到Git时如何处理？ 可能的解决方案： 使用Hudson的内部版本号（问题：您必须检查Hudson才能将其与实际的Git版本相关联） 手动升级版本以保持夜间稳定（问题：学习曲线，人为错误） 如果其他人遇到了类似的问题并解决了该问题，我们将很乐意听听如何解决。

131 version-control  git  svn  builds  versioning 

在我当前的项目（一个用C ++编写的游戏）中，我决定在开发过程中将100％使用“测试驱动开发”。 就代码质量而言，这很棒。我的代码从未设计得那么好或没有漏洞。当我查看一年前在项目开始时编写的代码时，我并不畏缩，而且我对如何组织事物有了更好的了解，不仅可以更容易测试，而且可以更容易实现和使用。 。 但是...我开始这个项目已经一年了。当然，我只能在业余时间处理它，但是与我以前相比，TDD仍然使我的速度大大降低。我读到，随着时间的流逝，开发速度的降低会越来越好，而且我确实确实比以前更容易进行测试，但是我已经进行了一年，而且我仍在努力。 每当我考虑需要执行的下一步时，就必须每次都停下来思考如何为它编写测试，以便允许我编写实际的代码。有时我会被困上几个小时，确切地知道我要编写什么代码，却不知道如何将其分解得足够细致，以至于无法完全被测试覆盖。其他时候，我会迅速考虑十几个测试，并花一个小时编写测试，以覆盖一小部分真实的代码，而这些代码原本要花几分钟才能编写。 或者，在完成第50次测试以涵盖游戏中的特定实体及其创建和使用的各个方面之后，我查看了我的待办事项清单，看到了下一个要编码的实体，并为写作而大吃一惊。另进行50次类似测试以使其得以实施。 到了关键点，回顾去年的进展，我正考虑放弃TDD，以“完成该死的项目”。但是，放弃它随附的代码质量并不是我所期望的。恐怕如果我停止编写测试，那么我将失去使代码如此模块化和可测试的习惯。 我是否可能在做错事而仍然如此缓慢？是否有其他选择可以在不完全丧失收益的情况下提高生产率？TAD？较少的测试范围？其他人如何在不破坏所有生产力和动力的情况下在TDD中生存？

131 unit-testing  tdd 

我们公司正在寻找新的程序员。问题出在这里-有很多开发人员在面试中看起来非常出色，似乎知道您需要的技术并且拥有良好的工作背景，但是经过两个月的工作，您发现他们无法在其中工作。一个团队，编写一些代码需要很长时间，而且结果并不理想。 那么，您是否使用任何形式化的测试（有吗？）？您如何认识一个好的程序员-一个好的人？有没有简单的“好”问题可以揭示未来的问题？...或者仅仅是您对这个人的“感觉”（即主要是您的经历），然后尝试他/她？ 编辑：根据Manoj的回答，这是与面试中的编码任务有关的问题。

131 interview  recruiting