小编Ric*_*man的帖子

这是我组织中的一位软件工程师提出的问题.我对最广泛的定义感兴趣.

如果我从Java命令行中省略-Xmxn选项,则使用默认值.根据Java文档 "默认值是在运行时根据系统配置选择的".

哪些系统配置设置会影响默认值？

是否可以编写与未出现次数的嵌套模式匹配的正则表达式？例如,当外括号内嵌有未知数量的打开/关闭括号时,正则表达式是否可以匹配开括号和右括号？

例如:

public MyMethod()
{
  if (test)
  {
    // More { }
  }

  // More { }
} // End

应该匹配:

{
  if (test)
  {
    // More { }
  }

  // More { }
}

RDP客户端可以启动远程应用程序,然后只显示该应用程序(而不是桌面)吗？应用程序将在客户端中显示为全屏,如果应用程序已关闭,则会话将结束.

我遇到过许多反对在C#中包含多重继承的论据,其中一些包括(除了哲学论证):

• 多重继承过于复杂,而且往往含糊不清
• 这是不必要的,因为接口提供类似的东西
• 如果接口不合适,组合是一个很好的替代品

我来自C++背景,错过了多重继承的力量和优雅.虽然它不适合所有软件设计,但在某些情况下很难否认它在接口,组合和类似的OO技术上的实用性.

是否排除了多重继承,说开发人员不够聪明,不能明智地使用它们,并且在它们出现时无法解决这些复杂问题？

我个人欢迎将多重继承引入C#(也许是C##).

附录:我很想知道来自单一(或程序背景)与多重继承背景的回复.我经常发现,没有多重继承经验的开发人员通常会默认使用多继承是不必要的参数,因为他们没有任何关于范例的经验.

对Python使用nosetests时,可以通过将test function的__test__属性设置为false 来禁用单元测试.我使用以下装饰器实现了这个:

def unit_test_disabled():
    def wrapper(func):
         func.__test__ = False
         return func

    return wrapper

@unit_test_disabled
def test_my_sample_test()
    #code here ...

但是,这会产生调用包装器作为单元测试的副作用.包装将始终通过,但它包含在nosetests输出中.是否有另一种构造装饰器的方法,以便测试不会运行并且不会出现在nosetests输出中.

这是一个经常被问到的问题,双方都有意见.赞成的人会争辩说:

• 要为编码器设计系统,您必须了解如何编码(并进行编码)
• 如果不了解地面发生的情况,就无法设计系统
• 架构不仅涉及宽中风设计,还涉及适应代码级别不断变化的需求

另一方面,

• 架构是一个高级角色,不应该关注实现细节
• 编码是一种详细的,低调的功能,与风险管理,建筑的广阔视野不一致
• 架构是关于技术风险管理而不是实施
• 建筑是关于领导力的.从后面领导很难

根据我的经验,架构师不应该花费大量时间编写代码,但必须主要通过主要的开发人员沟通,审查和站立来与代码库保持联系.如果您花费大量时间进行编码,则会忽视高级别问题,并无法有效管理技术风险.

以下两个C#代码片段产生不同的结果(假设在递归调用之前和之后都使用变量级别).为什么？

public DoStuff(int level)
{
  // ...
  DoStuff(level++);
  // ...
}

,

public DoStuff(int level)
{
  // ...
  DoStuff(level+1);
  // ...
}

在阅读了下面的一些回复后,我认为值得发布级别++,++级别和级别+ 1的堆栈跟踪以突出显示欺骗这个问题的方式.

我已经为这篇文章简化了它们.递归调用序列以DoStuff(1)开始.

// level ++

DoStuff(int level = 1)
DoStuff(int level = 2)
DoStuff(int level = 2)
DoStuff(int level = 2)

// ++级别

DoStuff(int level = 4)
DoStuff(int level = 4)
DoStuff(int level = 3)
DoStuff(int level = 2)

// level + 1

DoStuff(int level = 4)
DoStuff(int level = 3)
DoStuff(int level = 2)
DoStuff(int level …

我目前正在研究一个已经生产了两年多的项目.该项目广泛使用单元测试和脚本UI测试.最初的单元测试涵盖了系统框架,业务规则和状态转换(或工作流).测试脚本用于黑盒测试.然而,随着时间的推移,维持我们全套单元测试的成本变得越来越昂贵,特别是那些与国家相关的成本.

经过一些调查后,我们发现测试脚本更有效(即提供更好的覆盖率),并且维护成本低于与工作流相关的单元测试.这并不是说单元测试的价值已被完全否定了,但它确实提出了这个问题,是否可以放弃某些类型的单元测试以支持测试脚本.

我们的项目是在迭代增量模型上运行的.

鉴于编码新功能的估算,编码单元测试的典型估计是什么？对于维护代码的估计,这是不同的吗？