软件工程

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

5
使用常见的嵌套子模块组织Git存储库
我是Git子模块的忠实粉丝。我希望能够跟踪依赖关系及其版本,以便您可以回滚到项目的先前版本,并具有相应版本的依赖关系,以安全,干净地进行构建。此外,将我们的库作为开放源代码项目发布更容易,因为库的历史记录与依赖于它们的应用程序的历史记录是分开的(并且不会公开)。 我正在为工作中的多个项目设置工作流程,我想知道如果我们采用这种方法有点极端,而不是拥有一个整体项目会怎么样。我很快意识到,在真正使用子模块时,可能存在蠕虫病毒。 假设有一对应用程序:studio和player,以及依赖库core,graph和network,其中依赖关系如下: core 是独立的 graph取决于core(的子模块./libs/core) network依赖于core(的子模块./libs/core) studio取决于graph和network(位于./libs/graph和的子模块./libs/network) player取决于graph和network(位于./libs/graph和的子模块./libs/network) 假设我们正在使用CMake,并且每个项目都有单元测试和所有工作。每个项目(包括studio和player)都必须能够独立编译以执行代码指标,单元测试等。 事情是,递归的git submodule fetch,然后您将获得以下目录结构: studio/ studio/libs/ (sub-module depth: 1) studio/libs/graph/ studio/libs/graph/libs/ (sub-module depth: 2) studio/libs/graph/libs/core/ studio/libs/network/ studio/libs/network/libs/ (sub-module depth: 2) studio/libs/network/libs/core/ 注意core在studio项目中克隆了两次。除了浪费磁盘空间之外,我还有一个构建系统问题,因为我要构建core两次,并且有可能获得的两个不同版本core。 题 如何组织子模块,以便获得版本化的依赖关系和独立的构建,而无需获取公共嵌套子模块的多个副本? 可能的解决方案 如果库依赖关系只是一个建议(例如,以“已知可与版本X一起使用”或“仅正式支持版本X”的方式),并且潜在的依赖应用程序或库负责使用其喜欢的任何版本进行构建,则我可以想象以下情形: 让构建系统知道graph并network告诉他们在哪里core(例如,通过编译器包含路径)。定义两个构建目标:“独立”和“依赖”,其中“独立”基于“依赖”,并添加包含路径以指向本地core子模块。 引入额外的依赖性:studio上core。然后,studio建立core,设置包括它自己的拷贝路径core子模块,然后建立graph与network在“依赖”模式。 生成的文件夹结构如下所示: studio/ studio/libs/ (sub-module depth: 1) studio/libs/core/ studio/libs/graph/ studio/libs/graph/libs/ (empty folder, sub-modules not …
50 git  cmake  submodules 

3
为什么异常规范不好?
大约10年前回到学校时,他们正在教您使用异常说明符。由于我的背景是其中的一位Torvaldish C程序员,他们顽固地避免使用C ++(除非被迫这么做),所以我只会偶尔散布C ++,并且当我这样做时,我仍然使用异常说明符,因为这就是我所教的。 但是,大多数C ++程序员似乎并不喜欢异常说明符。我已经阅读了各种C ++专家的辩论和论点,例如这些。据我了解,它可以归结为三点: 异常说明符使用与其余语言不一致的类型系统(“影子类型系统”)。 如果您的带有异常说明符的函数抛出了除您指定的内容以外的其他任何内容,则该程序将以不良的意外方式终止。 即将在即将发布的C ++标准中删除异常说明符。 我在这里错过什么还是所有这些原因吗? 我个人的意见: 关于1):那又如何。就语法而言,C ++可能是有史以来最不一致的编程语言。我们有宏,goto /标签,未定义/未指定/实现定义的行为的部落(ho?),定义欠佳的整数类型,所有隐式类型升级规则,特殊情况下的关键字,例如friend,auto ,注册,显式...等等。有人可能会写几本关于C / C ++怪异故事的厚书。那么,人们为什么要对这种特殊的矛盾做出反应呢?与语言的许多其他更危险的特征相比,这是一个较小的缺陷? 关于2):这不是我的责任吗?我可以用C ++编写致命错误的方法有很多,为什么这种特殊情况会更糟?除了编写throw(int)然后抛出Crash_t之外,我还可以声明我的函数返回一个指向int的指针,然后进行一个狂野的,显式的类型转换,然后返回一个指向Crash_t的指针。C / C ++的精神始终是将大部分责任留给程序员。 那优势呢?最明显的是,如果您的函数尝试显式抛出除指定类型之外的任何类型,则编译器将给您一个错误。我认为有关此标准很明确。仅当您的函数调用其他函数而又抛出错误的类型时,才会发生错误。 来自确定性的嵌入式C程序世界,我当然希望更确切地知道函数会给我带来什么。如果有某种语言支持该功能,为什么不使用它呢?替代方案似乎是: void func() throw(Egg_t); 和 void func(); // This function throws an Egg_t 我认为在第二种情况下,调用者有很大的机会忽略/忘记实现try-catch,而在第一种情况下则更少。 据我了解,如果这两种形式之一决定突然引发另一种异常,则程序将崩溃。在第一种情况下,因为不允许它抛出另一个异常,在第二种情况下,因为没有人期望它抛出SpanishInquisition_t,因此该表达式不会在应有的位置被捕获。 如果是后者,在程序的最高级别进行一些最后的捕获似乎并没有比程序崩溃更好的方法:“嘿,程序中的某处引发了一个奇怪的,未处理的异常”。一旦远离异常引发的地方,您将无法恢复程序,唯一可以做的就是退出程序。 从用户的角度来看,如果他们从操作系统中收到一个错误消息框,说“程序终止。地址为0x12345的Blablabla”,或者从您的程序中获得一个错误消息框,指出了“未处理的异常:myclass。 func.something”。该错误仍然存​​在。 随着即将到来的C ++标准,我将别无选择,只能放弃异常说明符。但是,我宁愿听到一些可靠的论据,说明它们为什么不好,而不是“圣洁已经说过了,事实就是如此”。也许对他们的争论比我列出的要多,或者对他们的争论比我所意识到的还要多?


5
什么时候不应该使用正则表达式?[关闭]
正则表达式是程序员的强大工具,但是-在某些情况下,它们不是最佳选择,甚至是完全有害的。 简单的示例1是使用regexp解析HTML-已知的众多错误之路。通常,这也可能归因于解析。 但是,还有其他显然不能使用正则表达式的区域吗? ps:“ 您要提出的问题似乎是主观的,很可能已经解决。 ”-因此,我想强调一点,就是我对使用正则表达式会导致问题的示例感兴趣。

1
使用script标签包含JavaScript文件的最佳方法是什么?
我通常使用如下脚本标签包含JavaScript文件。 <script type="text/javascript" src="somefile.js"></script> 我也看到一些人也使用language属性。 如今,我发现许多人都忽略了type属性。我开始感觉到,如果JavaScript是默认的脚本语言,那么即使我也应该忽略type属性。忽略type属性会好吗?会引起什么问题吗?
50 javascript 


13
*代码所有者*系统:这是一种有效的方法吗?[关闭]
我们团队中有一位新开发人员。我们公司正在使用一种敏捷方法。但是开发人员还有另一种经验:他认为必须将代码的特定部分分配给特定的开发人员。因此,如果一个开发人员创建了一个程序过程或模块,则认为该过程/模块的所有更改仅由他自己进行是正常的。 从好的方面来说,据推测,使用提议的方法可以节省通用的开发时间,因为每个开发人员都非常了解自己的代码部分,并且可以快速进行修复。缺点是开发人员并不完全了解该系统。 您认为该方法对于中等规模的系统(社交网站的开发)是否有效?

2
启动开源项目的清单[关闭]
启动一个开源项目不仅是将源代码丢到某个公共存储库中,然后对此感到满意。您应该拥有技术(除用户之外)文档,有关如何贡献的信息等。 如果创建一份重要任务清单,您将包括哪些内容?

16
每次更改的版本控制和错误跟踪开销是否过多?
我在一个CVS疯狂和Bugzilla坚果的地方工作。 每个发行版都有太多分支,以至于无法计数。每个人都在不断地自动合并。 这项工作没有流动性。一切都感觉锁步。即使是简单的事情,也需要25个步骤。这不像是在工厂生产线上,而是每天自己建立工厂。 情况示例: 要修复一个错误,首先我要获得一个干净的新虚拟机。然后,根据Bugzilla报告中描述的另一个分支,为该单个错误修复程序创建一个分支。我将分支安装在计算机上,进行设置。我修复了错误。我将其检入,将其和机器留给其他人进行测试。然后,我必须进入错误控制软件,并解释我的工作并编写测试用例以及所有步骤。最终,其他人将其与发行版合并。 无论错误有多微小,我都必须做所有这些事情。有时人们将多个错误的工作结合在一起,但是正如我所说的那样,分支太多了,这几乎是不可能的。 在其他任何工作中,我只想修复该错误即可。我什至不记得使用SCM,尽管我曾经做过的每一项工作都使用过SCM:这是因为在其他每项工作中,他们都以某种方式使其无法使用。 在这个过程中是否有障碍,并成为自身的终结?这甚至是工程吗?

11
您如何向“敏捷”团队说明他们仍然需要计划编写的软件?
这一周的工作中,我又变得敏捷了。经历了标准的敏捷,TDD,共享所有权,临时开发方法,从未计划过一张卡片上的几个用户故事,口头上嚼了一个第三方集成广告恶心的技术,却从未真正做过思考或应尽的努力,并将所有生产代码与过去几个月来遇到的第一个测试在体系结构上耦合起来,我们到达了发布周期的结尾,并且发现我们一直在开发的主要外部可见功能太慢而无法使用,越野车,迷宫般变得复杂而完全不灵活。 在此过程中,“尖刺”完成了,但从未记录下来,也没有生产出任何单一的建筑设计(没有FS,所以,如果您不知道自己在开发什么,该如何计划或研究它? ?)-项目是成对进行的,每个人一次只专注于一个用户故事,结果是不可避免的。 为了解决这个问题,我放弃了雷达,去了(可怕的)瀑布,进行了计划,编码,基本上并没有放弃这一对,并尝试了我一个人尽可能多的工作-专注于坚实的体系结构和规范,而不是单元测试。一切确定后,我们将在以后发布。该代码现在更好,并且实际上完全可用,灵活且快速。某些人似乎真的很讨厌我这样做,并且竭尽全力破坏我的努力(可能是无意识地),因为这违背了敏捷的神圣过程。 因此,作为开发人员,您如何向团队解释计划他们的工作并非“不敏捷”,您如何使计划适合敏捷过程?(我不是在谈论IPM;我是在谈论坐着一个问题,并草拟一个端到端设计,该设计说出应该如何充分详细地解决问题,以便从事该问题的任何人都知道他们应该使用的架构和模式,以及新代码应集成到​​现有代码中的位置)
50 agile  planning 

11
为什么Lisp不会更普及?[关闭]
我开始通过SICP视频学习Scheme,接下来我想转到Common Lisp。 这种语言似乎非常有趣,并且大多数人为此写书都主张它具有无与伦比的表达能力。CL似乎有一个不错的标准库。 为什么Lisp不会更普遍?如果确实如此强大,人们应该到处使用它,但要找到Lisp招聘广告几乎是不可能的。 我希望这不仅是括号,因为一段时间后它们不是一个大问题。

10
毕业生期望与现实[关闭]
当选择我们想要学习的东西,以及我们的职业和生活时,我们都对它会是什么样子抱有一些期望。现在我从事该行业已经有近十年了,我一直在反思自己的想法(当时我在学习计算机科学时),编程的工作生活将是什么样子,以及它实际上如何变成是。 到目前为止,我的两个最大的震惊(或者应该说是打破期望)是软件涉及的大量维护工作以及总体上缺乏专业精神: 维护:在uni,我们都被告知大多数软件工作是对现有系统的维护。因此,我知道可以抽象地期望这一点。但是我从未想过这到底会是多么令人难以置信。也许这是我精神上的困惑,并希望我能从头开始构建更多新颖的东西。但是,实际上大多数工作都是以维护,错误修复和支持为导向的。 缺乏专业素养:在uni,我始终给人以商业软件工作非常注重流程和严格设计的印象。我有ISO流程的图像,大量技术文档,严格记录了每个功能和错误以及普遍专业的环境。震惊的是,意识到大多数软件公司的运作方式与一个为期一个学期的大型项目的学生团队没有什么不同。我曾经在小型敏捷黑客商店和中型企业中工作过。虽然我不会说它一直都是完全“不专业”的,但绝对可以感觉到软件行业(总体上)与我期望的强大工程学相去甚远。 其他人有类似的经历吗?您对我们职业的期望与现实有何不同?

14
为什么目前对函数式编程充满热情?[关闭]
最近,对于Scala,Clojure和F#,我已经听到了很多有关函数式编程语言的热情。我最近开始学习Haskell,以学习FP范例。 我喜欢它,它真的很有趣,并且适合我的数学背景。 但这真的有关系吗?显然,这并不是一个新主意。 这是我的问题: 是什么促成了最近FP的热情?是对OO仅仅是无聊,还是为了使FP比以前更需要而进行了一些更改? 这是否预示着FP的未来?还是像对象数据库这样的时尚? 换句话说,任何人都可以帮助我了解它的来历和去向吗?

9
您在哪里找到时间?[关闭]
我发现自己在新技能,技巧,语言功能等方面落后于我,而且我发现这样做的时间紧缺。在工作,职业,个人和家庭义务之间,我很幸运在这里和那里找到了一些零散的时间,专注于我想要或需要做的任何新技术或阅读。我确实向相关的本地用户群宣传了,但是有时候有时候甚至很难做到? 因此,我想问一下社区,您在何时何地找到时间专注于磨练自己的技能或学习新技能?你安排时间吗?一周或周末放弃睡眠吗?失眠?还有吗 编辑我要感谢所有花时间回答并提出您建议的人。有些事情我知道或曾想过,而另一些事情直到您对它有了新的了解才被认为是一种选择。 编辑2:在尝试从众多最佳答案中寻找哪个答案时,我选择了@Paddyslacker,因为它是我认为最适合当前情况的答案,尽管每个人都有一些非常好的智慧,例如@以利沙@马丁或@ dash-tom-bang。

26
如何提高解决问题的能力?
每个人都说相同的话:“一个真正的程序员知道如何处理实际问题。” 但是他们忘记了如何学习这种能力或在哪里学习的:学校没有教授这种能力。 如何提高我处理复杂编程问题的能力?哪些策略对您有用?我应该关注哪些特定领域,例如算法或设计模式?

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.