软件工程

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

3
当您无法重现环境时,如何进行测试和优化?
过去,我曾在多种环境中工作过。桌面应用程序,游戏,嵌入式内容,Web服务,命令行作业,网站,数据库报告等。所有这些环境都具有相同的特征:无论它们的复杂性如何,无论它们的大小如何,我都可以始终在我的机器上或开发环境中对应用程序的子集或分片进行测试。 今天我没有。今天,我发现自己处于主要关注可伸缩性的环境中。复制环境的成本过高。截取一部分环境,虽然很合理(某些部分需要模拟,或者不能在单实例模式下使用),但由于破坏了并发性和负载真正的系统遇到。即使是小的“测试”系统也有其缺陷。当您有2个节点和64个节点时,事情的表现会有所不同。 我通常的优化方法(度量,尝试某些操作,验证正确性,度量差异,重复)在这里不起作用,因为我无法有效地对问题的各个部分(并发鲁棒性和性能降低)进行第2步和第3步加载)。这种情况似乎并不独特。在这种环境下执行此类任务的常用方法是什么? 有一些相关的问题: 这个问题与硬件(如频谱分析仪)不可用有关,可以(相对)轻松地进行仿真。 这个问题是关于追踪仅存在于生产环境中的错误,这很有帮助-但是是另一种活动。

4
数据库设计-每次都存储状态还是计算状态?
假设我有一个关系数据库应用程序,一个“用户”对象和一个“消息”对象。现在,我想向该用户显示未读邮件的数量。 存档的最佳方法是什么?我是否在用户中引入一个字段并在用户收到消息时对其进行计数,并在他阅读消息时减少计数?还是我每次都执行查询以计算标记为未读的用户消息数? 我认为第一种方法更复杂且容易出错,但是会比第二种方法表现更好。 这通常是如何完成的,或者有什么更好的方法?

3
吉特:树枝还是叉子?
我有一个游戏项目,它将有两个版本: 游戏的一个简单版本,核心。 游戏的高级版本。 我的公共存储库中有第一个版本,只有我会进行处理。至于第二版,我的两个朋友将与我合作。关键部分是我希望这两个版本保留在我的存储库中。 我以为可以为此使用分支,但是考虑到这个问题及其答案,就版本控制而言,这不是一个好习惯。据我所知,不可能分叉自己的存储库。 我在这里有什么选择?如何将两个版本都保存在存储库中?

4
开发人员因等待代码使用GitFlow从另一个分支合并而受阻
我们的团队刚刚从FogBugz&Kiln / Mercurial转到了Jira&Stash / Git。我们使用Git Flow模型进行分支,从功能分支添加子任务分支(与Jira功能的Jira子任务有关)。当我们创建一个合并到父分支的拉取请求时,我们使用Stash来分配一个审阅者(通常是开发,但是对于子任务来说是返回到功能分支)。 我们发现的问题是,即使对功能用例进行了最佳的规划和分解,当多个开发人员一起使用同一个功能时,例如在前端和后端,如果他们正在使用相互依赖的代码,在一个单独的分支中,一个开发人员最终阻止了另一个。 随着我们的发展,我们尝试在彼此的分支机构之间拉动。我们还尝试了创建本地集成分支,每个开发人员可以从多个分支中提取它们以在开发时测试集成。最后,这似乎到目前为止对我们来说是最好的,尽管开销更大,我们尝试立即从功能分支创建一个集成分支。当子任务分支(不在功能分支中)准备好进行拉取请求和代码检查时,我们还将手动将这些更改集合并到此功能集成分支中。然后,所有感兴趣的开发人员都可以从该集成分支拉到其他依赖的子任务分支。这样可以防止任何人等待他们依赖的任何分支通过代码检查。 我知道这不一定是Git问题-它与在多个分支中处理相互依赖的代码有关,并与我们自己的工作流程和文化相结合。如果我们没有用于开发的严格代码审查策略(真正的集成分支),则开发人员1可以合并以进行开发,以供开发人员2退出。另一个复杂的问题是,在将功能交付给QA之前,我们还需要在代码审查过程中进行一些初步测试,这意味着即使前端开发人员1正从后端开发人员2的分支直接拉出如果后端开发人员2完成并且他/她的拉取请求在代码审查中待了一周,那么前端开发人员2从技术上讲就无法创建他的拉取请求/代码审查,因为他/她的代码审查者无法测试,因为后端开发人员2' 最重要的是,在这种情况下,我们发现自己采用的是串行方式而不是并行方式,这取决于我们走的路线,并希望找到一种避免这种情况的过程。 我要提到的最后一件事是,我们通过在尚未经过代码审查和定稿的分支之间共享代码来实现,但实际上我们是在使用其他Beta代码。在某种程度上,我认为我们无法避免,并且愿意在一定程度上接受这一点。

5
不知道总数的百分比算法
假设有n热线电话。 每当客户致电热线时,该呼叫就会被转接到其中一条n线路。我想将呼叫百分比分配给n行中的每行。假设有两条线路,一条线路分配了60%,另一条线路分配了40%,呼叫总数为10,因此第一行将收到6个呼叫,第二行将收到4个呼叫。 我知道提前拨打每条线路的百分比,但是问题是我不知道一天会收到多少次电话。 如何在不知道总呼叫数的情况下分配呼叫数?

3
按更改风险对任务/错误进行分类
我当前正在从事的项目存在一个问题:错误和任务通常分配给新手或经验不足的人,而他们的工作最终会产生更多错误。问题在于,由于代码质量问题,我们的软件某些部分比其他部分更“危险”地工作。我一直在通过估计与任务相关的风险并密切关注哪些开发人员被分配了哪些任务来解决此问题。 我们使用JIRA,因此我开始标记问题以跟踪此估计。我注意到我最终使用了多个指标来对错误/任务进行分类: 它有多清晰/简单。例如,这是否需要大量的设计工作,还是仅需要简单的UI错误修复。 代码受影响区域的可维护性。是设计合理的区域还是大泥球。 我认为有多少程序会受到所需更改的影响。 我的标签有点乱,因为当我开始时可能的类别是什么,但现在仍然不知道,我并不清楚。我正在考虑请求添加一个新字段(例如“风险”),以便我们可以在将工作分配给某人之前进行估算。 以前有人处理过这种事情吗?

3
修改第三方代码后,我是否应该将自己纳入作者范围?
在第三方代码(无论是简单的要领还是整个库)中进行一些调整或修正是一种常见的做法。但是,其中许多代码都有自己的许可规则,并最终在每个文件上带有版权信息的标头上也很常见。 进行了这些修改之后,下一步该怎么做?保持许可证信息不变,还是尝试使用诸如@author或@revision标签之类的内容来更新它? 另一个常见的问题是更改第3方名称空间/程序包以使其适合您的项目约定。某些许可证类型在其许可证栏中包含此类信息,我可以自由更改吗? 我知道这些问题的答案取决于每种许可证类型,因此让我的问题更具体... 考虑到通用许可规则(通常它们在次要方面是不同的,对吗?),在道德上(或至少允许)我自由地向许可块添加有关修改的信息,也许还修改了我在代码中如何引用它(例如YACorp.YALib用作Utils.YALib)?

4
函数式编程会增加代码的复杂性吗?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 在过去的一年中,我一直在编写Scala代码(来自Java背景)。我真的很喜欢如何使用val,case类,map / filter / lambda函数,隐式函数和类型推断来创建更简单,更简洁的代码。我主要将其用于基于Akka的应用程序。 今年,我和一个新团队一起在Scala项目中,他们非常喜欢函数式编程。他们大量使用Scalaz,并且代码到处都是应用程序,上下文边界,读取器/写入器/状态monad,甚至是将主要方法“包装”在I / O monad中。他们的理由是,这使编译器在断言代码正确且每个函数都没有副作用的情况下“为我们工作”。 即便如此,从我的角度来看,所有这些语法确实确实妨碍了业务逻辑。例如,可以使用“ MyBusinessObject”类型,也可以使用“ List [MyBusinessObject]”,“ Option [MyBusinessObject]”或“ Future [MyBusinessObject]”类型。它们都有明确的含义和目的。另一方面,代码如下: def method[M[_]: Applicative] = { case (a, b) => (ca[M](a) |@| cb[M](b)) { case t @ (ra, rb) => if (ra.result && rb.result) t.right else t.left } } 它会增加程序的复杂性吗?还是我不习惯这种编程方式?

6
是什么使BASIC盈利?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 1970年代,一个叫Bill Gates的人为BASIC开发了一种解释程序:Altair BASIC。据我了解,他能够说服一家负责微型计算机公司的家伙在他出售的每台微型计算机上都包括口译程序,我认为这为盖茨和他的工作人员带来了一定的特许权使用费。显然,这使盖茨发了大财。我不明白的是,为什么编程语言今天没有那么赚钱。过去有哪些因素使它们盈利,而今天却没有?

4
关于功能的这些答案中哪一个是不正确的?
因此,当我进行长时间的编译时,我决定对ODesk进行C ++通用测试,并遇到了这个问题。 如果我没记错的话,考虑到措辞(或缺乏措辞),所有这些都是正确的。 一种。 int Foo() { } int Foo(int bar) { } b。 嗯,return void;在语义上会不正确,但是函数显然可以具有void返回类型。 void Foo() { } C。这是内联函数的定义,是的。 d。 在不详细说明以下元素的位置的情况下, typedef void (*Func)(int); Func functions[2]; void Foo(int bar) { } void Bar(int foo) { } functions[0] = &Foo; functions[1] = &Bar; 此外,您始终可以使用lambda和functors进行此操作。 e。 void Foo(int& bar) { …
17 c++ 

4
在不同项目之间共享类或接口
我一直在寻找SO或此处的一些答案,但是没有任何结果,这就是为什么我要问你。 假设我有两个不同的项目-例如应用程序的服务器部分和客户端部分。我正在开发自己的部分,而我的朋友正在制作第二部分。但是我们两个都应该使用一些通用接口,例如Useror AccountInfo或ChangableAccount...,以确保兼容性。例如,如果客户端将用户数据发送到服务器,则服务器应在同一类上运行。接口等也是如此。此外,如果公共接口中有任何更改,则两个项目都应根据新情况调整其代码。 我现在看到的唯一解决方案是,创建一个额外的项目,在其中定义所有常见的事物。我们和我的朋友应该将此项目添加为对主项目(客户端或服务器)的依赖项。共享项目可以通过某些版本控制系统进行管理,因此我们始终处于最新状态。 您还建议什么其他解决方案?在专业应用中如何解决此类问题?

4
将类似C ++的const引入语言有什么问题?
我对C ++的想法感兴趣,而const不是特定的执行(例如Castingaway const)。 以C#为例-它缺少类似于C ++的const,其原因是通常的-人员和时间。在这里,另外,似乎C#团队研究了C ++的const市场营销CLR 执行情况,并且在这一点上已经足够了(请参阅为什么在c#和const参数中没有const成员方法;谢谢Svick)。如果我们走得更远,还有其他吗? 还有更深的东西吗?以多重继承为例-通常(对于用户)它很难理解,因此没有添加到语言中(例如钻石问题)。 在《自然》杂志中是否存在某种const问题,那就是让语言最好避免这种问题?像确定const是深还是浅之类的东西(有了const容器,这意味着我也不能添加新元素或更改现有元素;如果元素属于引用类型怎么办)? 更新:虽然我提到C#,因此从历史的角度出发,但我对const语言潜在问题的性质感兴趣。 这不是语言的挑战。请忽略当前趋势或受欢迎程度等因素-我只对技术问题感兴趣-谢谢。

4
声称自己不“多核”友好的程序
您会时不时看到这个短语或类似词,通常指的是声称它们并非旨在充分利用多核处理器的程序。这在视频游戏编程中尤其常见。(当然,许多程序没有并发并且不需要它,例如基本脚本等)。 怎么会这样?许多程序(尤其是游戏)固有地使用并发性,并且由于OS负责CPU上的任务调度,那么这些程序是否固有地没有利用可用的多个内核?在这种情况下,“利用多核”意味着什么?这些开发人员实际上是在禁止OS任务调度并强制进行亲和力还是自己进行调度?(听起来像是主要的稳定性问题)。 我是Java程序员,所以也许由于抽象或其他原因我不必处理这个问题。

4
允许用户定义字段是不好的做法吗?
一般来说,允许用户在Webapp数据库中创建用户创建的字段是否被认为是不好的做法? 例如,我正在为妻子制作一个房屋库存网络应用程序,而她将要为不同的项目定义自己的字段。我打算允许她创建商品类别,并在这些类别中添加“功能”。功能只是将键/值存储为字符串。这样,例如,如果她有一个名为“音频CD”的类别,则可以为“艺术家”,“曲目”等内容添加功能。但是在另一个“家具”类别中,她可以为诸如“材料”之类添加功能”(木材,塑料等)。然后,任何项目都可以属于一个(或多个)类别,将那些功能添加到该项目中。 我看到的问题是,通过这些功能进行搜索需要字符串比较,没有数据验证等。按照敏捷的方法,也许最好是让她提出新的类别和属性,而我只需要创建新表当我们去。在我的示例中,这是一个很小的用户群(我们当中有2个),并且创建的记录量很小,因此也不错。 一般来说,人们在“现实生活”中如何处理这样的事情?

4
Java-使用多态或有界类型参数
假设我有这个类层次结构... public abstract class Animal { public abstract void eat(); public abstract void talk(); } class Dog extends Animal { @Override public void eat() { } @Override public void talk() { } } class Cat extends Animal { @Override public void eat() { } @Override public void talk() { } …

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.