软件工程

针对在系统开发生命周期中工作的专业人士,学者和学生的问答

2
总结Git中的更改(插入和删除)
我想看看我的代码库是如何随着时间增长的。GitHub +/-在签入列表中显示得很好,这给人一种感觉。我可以在Google Code托管存储库或脱机存储库中使用类似的东西吗?
47 git 

5
如果我已经有集成测试,是否需要单元测试?
如果我已经对我的程序进行了集成测试,并且都通过了测试,那么我有很好的感觉,它可以工作。那么编写/添加单元测试的原因是什么?由于无论如何我都必须编写集成测试,所以我只想为集成测试未涵盖的部分编写单元测试。 我知道单元测试优于集成测试的好处是 体积小,因此运行速度快(但是,通过集成测试已经测试了添加新单元以测试某件东西,这意味着我的总体测试服变得越来越大,并且运行时间更长) 由于只测试一件事,因此更容易找到错误(但是,当我的集成测试失败时,我可以开始编写单元测试来验证每个单独的部分) 查找集成测试中可能未捕获的错误。例如掩盖/抵消错误。(但是,如果我的集成测试通过了所有测试,这意味着即使存在一些隐藏的错误,我的程序也可以运行。因此,找到/修复这些错误并不是真正的高优先级,除非它们开始破坏未来的集成测试或引起性能问题) 而且,我们总是希望编写更少的代码,但是编写单元测试需要更多的代码(主要是安装模拟对象)。我的一些单元测试和集成测试之间的区别在于,在单元测试中,我使用模拟对象,而在集成测试中,我使用真实对象。其中有很多重复项,即使在测试中,我也不喜欢重复的代码,因为这会增加更改代码行为的开销(重构工具无法始终保持所有工作)。

1
为什么.Net世界似乎包含魔术字符串而不是静态类型的替代字符串?
因此,我在.Net中工作。我在.Net中制作开源项目。我最大的问题之一不是.Net的必要性,而是它周围的社区和框架。似乎到处都有神奇的命名方案和字符串被视为做所有事情的最佳方法。大胆的声明,但看看它: ASP.Net MVC: 您好世界路线: routes.MapRoute( "Default", // Route name "{controller}/{action}/{id}", // URL with parameters new { controller = "Home", action = "Index", id = "" } // Parameter defaults ); 这意味着ASP.Net MVC将以某种方式HomeController在您的代码中查找。以某种方式创建它的新实例,然后Index 显然使用某种id参数调用该函数。然后还有其他类似的东西: RenderView("Categories", categories); ...or.. ViewData["Foobar"]="meh"; 然后XAML也有类似的事情。DataContext被视为一个对象,您必须希望并祈祷它可以解析为所需的类型。DependencyProperties必须使用魔术字符串和魔术命名约定。像这样的事情: MyData myDataObject = new MyData(DateTime.Now); Binding myBinding = new Binding("MyDataProperty"); myBinding.Source = …

8
类型系统的安全益处是什么?
在道格拉斯·克罗克福德(Douglas Crockford)的《JavaScript:The Good Parts》中,他在继承章节中提到: 经典继承的另一个好处是它包括类型系统的规范。这主要使程序员不必编写显式的转换操作,这是一件非常好的事情,因为在转换时,类型系统的安全性丧失了。 那么首先,安全到底是什么?防止数据损坏,黑客或系统故障等? 类型系统的安全益处是什么?是什么让类型系统与众不同,才能提供这些安全优势?

9
如何以及为什么在带有“ get”和“ find”前缀的命名方法之间做出决定
我总是很难确定是否应该以getSomethingvs 开头的某个方法findSomething。 问题在于为设计不当的API 创建帮助程序。当从对象获取数据时通常会发生这种情况,这需要对象作为参数。这是一个简单的示例: public String getRevision(Item item) { service.load(item, "revision"); // there is usually more work to do before getting the data.. try { return item.get_revision(); } catch(NotLoadedException exception) { log.error("Property named 'property_name' was not loaded", exception); } return null; } 如何以及为什么要在将此方法命名为getRevision()or时做出决定findRevision()?
47 naming  methods 

14
业界对文档的厌恶是什么?
即使编写最基本的文档,似乎也存在反感。我们的项目自述文件是相对裸露的。在文档中甚至没有更新的依赖项列表。 我在行业中没有意识到让程序员不喜欢编写文档的东西吗?如果需要,我可以键入文档的段落,那么为什么其他人那么讨厌呢? 更重要的是,我如何使他们相信写文档会为我们节省时间和日后的挫败感?

3
写入临时位置,然后将其复制到目标位置有什么好处?
我正在编写一个可处理卫星图像的应用程序,老板要求我研究一些商业应用程序,并观察它们的表现。我发现了一个奇怪的行为,然后在寻找时,我也在其他标准应用程序中发现了它。 这些程序首先写入temp文件夹,然后将其复制到预期的目标位置。 示例:7zip首先提取到temp文件夹,然后将提取的数据复制到您要求其将数据提取到的位置。 我看到这种方法的几个问题: 临时文件夹可能没有足够的空间,而预期的位置可能有那么多的空间。 如果文件很大,则复制操作可能会花费很短的时间。 我考虑了很多,但是我看不出这样做有什么积极的意义。我是否缺少某些东西,或者这样做真的有好处?

3
什么是构造函数注入?
在浏览有关(服务定位器)设计模式的文章时,我一直在研究构造函数注入和依赖注入这两个术语。 当我搜索构造函数注入时,我得到的结果不清楚,这促使我在这里进行检查。 什么是构造函数注入?这是一种特定类型的依赖项注入吗?一个典型的例子将有很大的帮助! 编辑 一周的时间后,我又重新审视了这个问题,我看到自己迷失了……万一其他人突然出现在这里,我将通过一点我的学习来更新问题的正文。请随时发表评论/纠正。 构造函数注入和属性注入是两种类型的依赖注入。

3
使用C和C ++进行Android开发[关闭]
我是C,C ++开发人员。我对移动开发感兴趣。我想知道如何使用C和C ++开发Android应用程序,我已经读到它们为C,C ++开发人员提供了一个工具包,但是它不具备Java工具包的所有功能。我应该选择C / C ++开发套件还是最好学习Java,因为它们将来可能无法提供所有功能?
47 c++  c  android 

5
Haskell是否有缺点或问题?
我正在考虑进入Haskell进行下一个(相对琐碎的)个人项目。我处理Haskell的原因是: 让我沉迷于纯粹的功能语言 速度。虽然我可以肯定这是有争议的,但分析表明我发现Haskell接近C ++(并且似乎比Erlang快很多)。 速度。与几乎所有其他服务器相比, Warp Web服务器似乎快疯了。 因此,鉴于此,我正在寻找的是Haskell带来的弊端或问题。Web上有大量有关Haskell为什么是一件好事的信息,但是我没有找到很多有关其丑陋方面的主题(除了对语法的牢记,我根本不在乎)。 我正在寻找的示例可能像Python的GIL。直到我真正开始考虑在CPython环境中使用并发性时,这些事情才浮出水面。
47 haskell 

4
代码混淆的情况?
从对开发代码的人和运行该代码的企业的真正好处(如果所讨论的代码实际上是商业代码)的角度而言,编写混淆的代码的首要原因是什么?是否有记录在案的案例(可在某些地方在线获得)描述混淆的好处多于坏?是否有众所周知的例子,例如,证明混淆处理会有意义地延迟恶意的第三者获取代码?看来,就像卷起车窗并不会阻止人们打破它们并窃取您的立体声音响一样,混淆代码只会使诚实的人保持诚实。 ========= 背景: 这是有意挑战我关于该主题的假设的一种尝试。 我通常反对使用代码混淆,但是我很好奇我是否缺少某些东西。我明白了为什么在JavaScript之类的情况下,缩小可以帮助事情更快地加载并且全部(在那里有真正的,功能上的好处),但是我似乎无法提出代码混淆的单一原因,从而成为障碍。发现一段代码/算法的作用实际上对于任何目的都是有效的。 随着开源软件的疯狂流行,问题似乎是“共享代码,还是专有?” 在商业代码方面,我能理解为什么您不能共享所有内容,并且您有法律来打击盗窃。 顺便说一句,如果有人编写混淆代码的原因是“工作安全性”,那么我将解雇任何被发现是一致的程序员,并故意使用混淆的唯一目的是帮助保持他们的工作,除非他们可以合理地证明它有一些保留。商业利益。它是如此的反团队,以至于很荒谬,它指向的是一个更关心通过误导的做法来保持工作,然后再因为编写出色的软件而保持工作的人。 我仅提及此特定案例,因为尽管我意识到人们通常在开玩笑,但我想阻止任何以其基本目的是仅对工作安全进行迷惑是一个好主意的答案。

4
为什么#include <iostream.h>不好?
我正在阅读另一个线程,一个人向初学者询问有关C ++的书籍,一个回答的程序员写道: 警告:请避免所有带有“ hello world”字样的书都标明 #include &lt;iostream.h&gt; 我打开了我的C ++书,并确定它像上面的示例一样包含iostream标头。 为什么这么糟?学习C ++时,我还应牢记其他哪些指针? 背景:我精通C语言,下学期将开始学习C ++。

3
与基于类的OOP相比,基于原型的OOP有何优势?
当我主要在基于类的语言的上下文中处理OOP之后第一次开始对Javascript进行编程时,我对为什么基于原型的OOP会比基于类的OOP更为困惑。 使用基于原型的OOP的结构优势是什么?(例如,在某些应用程序中,我们希望它更快或更省内存吗?) 从编码人员的角度来看,优点是什么?(例如,使用原型制作某些应用程序或扩展其他人的代码是否容易?) 请不要把这个问题看做是关于Javascript的问题(多年来存在很多与原型无关的错误)。相反,请结合原型与类的理论优势来研究它。 谢谢。

2
如何组织C ++单元测试代码以实现最大的单元测试效率?
这个问题与单元测试框架无关。 这个问题与编写单元测试无关。 这个问题是关于在哪里放置UT代码以及如何/何时/在哪里编译和运行它。 在有效地使用旧版代码中,迈克尔·费瑟斯断言 良好的单元测试...运行速度快 然后 运行1/10秒的单元测试是缓慢的单元测试。 我认为这些定义确实有意义。我还认为,这意味着您必须分别保留一组单元测试和一组代码测试,这些测试需要更长的时间,但是我想这就是您仅在运行(非常快)时才调用单元测试的价格。 显然,问题在C ++中是“跑”单元测试(小号),你必须: 编辑代码(生产或单元测试,具体取决于您所在的“周期”) 编译 链接 启动单元测试可执行文件(小号) 编辑(经过奇怪的近距离表决):在进入细节之前,我将尝试在此处总结要点: 如何有效地组织C ++单元测试代码,这样既可以有效地编辑(测试)代码又可以运行测试代码? 然后,第一个问题是确定将单元测试代码放在哪里,以便: 结合相关的生产代码进行编辑和查看是“自然的”。 轻松/快速地为您当前更改的单元开始编译周期 在第二个的话,相关的,问题是什么来编译,这样的反馈是瞬时的。 极端的选择: 每个单元测试-测试单元都位于一个单独的cpp文件中,并且此cpp文件被单独编译+链接(连同它测试的源代码单元文件)到单个可执行文件,然后该可执行文件运行此一个单元测试。 (+)这样可以最小化单个测试单元的启动(编译+链接!)时间。 (+)测试运行非常快,因为它仅测试一个单元。 (-)执行整个套件将需要启动大量流程。可能是一个管理难题。 (-)流程启动的开销将变得可见 另一面将是-仍然-每个测试一个cpp文件,但是所有测试cpp文件(以及它们测试的代码!)都链接到一个可执行文件中(每个模块/每个项目/选择您的选择)。 (+)编译时间仍然可以,因为只有更改的代码才能编译。 (+)执行整个套件很容易,因为只有一个exe可以运行。 (-)套件将花费很多时间进行链接,因为任何对象的每次重新编译都会触发重新链接。 (-)(?)套装将花费更长的时间运行,尽管如果所有单元测试都很快,则时间应该可以。 那么,现实世界中的C ++ 单元测试如何处理?如果我只是每晚/每小时运行一次,那么第二部分并不重要,但是第一部分,即如何将UT代码“耦合”到生产代码,这样对于开发人员来说,将两者保持一致是“自然的”我认为专注始终很重要。(如果开发人员将UT代码作为重点,他们将要运行它,这将使我们回到第二部分。) 欣赏真实世界的故事和经验! 笔记: 该问题有意离开了未指定的平台和品牌/项目系统。 问题带有标记的UT&C ++是一个很好的起点,但是不幸的是,太多的问题(尤其是答案)过于注重细节或特定框架。 前一阵子,我回答了关于升压单元测试的结构的类似问题。我发现这种结构对于“真实的”快速单元测试是缺少的。我发现另一个问题过于狭窄,因此提出了这个新问题。

9
为什么不可能产生真正的随机数?
我试图解决一个爱好问题,该问题需要生成一百万个随机数。但是我很快意识到,使其变得独特变得越来越困难。我阅读了《算法设计手册》,以了解有关随机数生成的信息。 它有以下一段我完全无法理解。 不幸的是,生成随机数看起来比实际要容易得多。实际上,从根本上不可能在任何确定性设备上产生真正的随机数。冯·诺依曼[Neu63]最好说:“任何考虑产生随机数的算术方法的人,当然都处于犯罪状态。”我们所能期望的最好是伪随机数,它像一串数字如果它们是随机生成的。 为什么在任何确定性设备中都不可能产生真正的随机数?这句话是什么意思?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.