软件工程

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

20
为什么年轻的程序员对大型机不感兴趣?[关闭]
大型机的关键问题是支持程序员的队伍正在减少。虽然通常这不是问题,因为程序员的供应减少会被薪水的增加所抵消,而工资的增加会通过供求法则导致程序员的供应增加,但我不确定这是否真的会发生大型机。 尽管它们仍然构成许多企业的关键基础架构,但简单的事实是,没有足够的年轻程序员来保持支持人口的增长。 为什么是这样?是什么使大型机对年轻程序员没有吸引力?
51 mainframe 




8
您如何评价乔尔测验?[关闭]
在乔尔测试是确定你的团队是多么好的一个众所周知的测试。您如何看待这些要点?您不同意其中任何一个吗?您有什么要补充的吗?
51 joel-test 

9
只有一个(公共)方法的类是否有问题?
我目前正在从事一个软件项目,该项目对视频监控镜头进行压缩和索引编制。压缩的工作方式是分割背景和前景对象,然后将背景另存为静态图像,并将前景另存为子画面。 最近,我开始复习我为该项目设计的一些课程。 我注意到有许多类只有一个公共方法。其中一些类是: VideoCompressor(使用一种compress方法,该方法接收类型的输入视频RawVideo并返回类型的输出视频CompressedVideo)。 VideoSplitter(使用一种split方法,该方法接收类型的输入视频RawVideo并返回2个输出视频的向量,每个类型均为RawVideo)。 VideoIndexer(使用index接收类型为type的输入视频RawVideo并返回类型为video的视频索引的方法VideoIndex)。 我发现自己实例每个班只是为了让像电话VideoCompressor.compress(...),VideoSplitter.split(...),VideoIndexer.index(...)。 从表面上看,我确实认为类名足以说明其预期功能,实际上它们是名词。相应地,它们的方法也是动词。 这真的有问题吗?

4
使用公共决赛而不是私人获得者
我看到大多数不变的POJO都是这样写的: public class MyObject { private final String foo; private final int bar; public MyObject(String foo, int bar) { this.foo = foo; this.bar = bar; } public String getFoo() { return foo; } public int getBar() { return bar; } } 但是我倾向于这样写它们: public class MyObject { public final String foo; …

11
有人喜欢比例字体吗?[关闭]
我在阅读有关编程风格的Wikipedia文章,并注意到反对垂直对齐的代码的某个论点: 依靠等宽字体;表格格式假定编辑器使用固定宽度的字体。大多数现代代码编辑器都支持比例字体,程序员可能更喜欢使用比例字体以提高可读性。 老实说,我认为我从未见过喜欢使用比例字体的程序员。我也没有想到使用它们的任何真正好的理由。为什么有人会喜欢比例字体?

7
配对编程什么时候起作用?什么时候避免呢?
并非一直在刻苦地配对编程,而是在团队中选择性地使用配对编程。我认为在以下情况下效果最佳: 加强项目中全新的团队成员(而不是让他们自己浏览文档或代码)。 初级和高级人员一起工作(有助于显示经验丰富的开发人员的一些技能和技巧,此外,它还允许老狗有时学习新的技巧)。 当某人试图查找缺陷时,通常可以帮助您与另一只眼睛配对。 什么时候使用配对程序,为什么? 什么时候避免成对编程?为什么?

3
HTTP请求标头和请求正文中包含什么?
我正在为移动客户端开发一组Web服务,并且要求将唯一的设备ID包含在所有请求中,存储在某些请求中,并用于过滤其他请求中的结果。 有人建议将其放在自定义HTTP标头中,因为它将包含在所有请求中,因此我开始怀疑可以使用什么标准来确定给定的数据段是否属于标头或与标头中的其他数据一起请求正文。 有没有这样的标准?

5
“基于配置的约定”是否违反基本的编程原则?
我查看了WPF MVVM框架Caliburn.Micro,并阅读到很多标准内容都基于命名约定。 例如,将视图中的属性自动绑定到视图模型中的属性。尽管这似乎很方便(删除了一些样板代码),但是我的第一个本能反应是,对于将要读取此代码的新程序员而言,这并不完全明显。换句话说,应用程序的功能并不能完全由其自己的代码来解释,而不能由框架的文档来完全解释。 编辑: 因此,这种方法称为约定优于配置。由于找不到与此相关的任何问题,因此我更改了问题: 我的问题是: 约定优于配置是简化事情的正确方法,还是违反了某些编程原则(如果是,则违反了哪些编程原则)?

6
在微服务中,每个服务是单个数据库还是单个数据库实例?
我了解微服务架构中的每个服务都应具有自己的数据库。但是,拥有自己的数据库,实际上是在同一个数据库实例中简单地拥有另一个数据库,还是在字面上拥有另一个数据库实例? 这样,我并不是说共享数据库,这是不对的,而是数据库实例。 例如,如果我使用的是AWS并具有3个服务,那么我是否要在单个RDS实例上为每个服务创建3个数据库,还是要创建3个RDS实例,每个实例都包含一个数据库,供3个服务分别使用? 如果在单个RDS实例上使用多个数据库是一个更好的主意,那么它会否决拥有独立服务的目的,因为: RDS实例的资源将在服务之间共享。在特定时间可能大量使用数据库的服务A是否会影响使用不同数据库但在同一RDS实例上的服务B? 所有服务将取决于该RDS实例上的数据库版本。

5
从C内部调用shell命令是一个好主意吗?
udevadm info -q path -n /dev/ttyUSB2我想从C程序中调用一个unix shell命令()。经过大约一周的努力,我可以自己重新实施它,但是我不想这样做。 我打电话popen("my_command", "r");还是被广泛接受的优良作法,还是会引入不可接受的安全性问题并转发兼容性问题?做这样的事情对我来说是错误的,但是我不能指责为什么会不好。
50 c  unix  shell 

3
什么是类型系统?
背景 我正在设计一种语言,作为辅助项目。我有一个工作正常的汇编器,静态分析器和虚拟机。由于我已经可以使用构建的基础结构来编译和运行非平凡的程序,因此我考虑在大学里做一个演讲。 在我的演讲中,我提到VM提供了一种类型系统,有人问“ 您的类型系统用于什么? ”。回答后,我被问这个问题的人嘲笑。 因此,即使我几乎肯定会因提出这个问题而声名狼藉,但我还是去找程序员。 我的理解 据我了解,类型系统用于提供有关程序中实体的附加信息层,以便运行时,编译器或任何其他机器知道如何处理其所操作的位字符串。它们还有助于维护合同-编译器(或代码分析器,运行时或任何其他程序)可以验证程序在任何给定的点上以程序员期望其操作的值运行。 类型也可以用于向那些人类程序员提供信息。例如,我找到以下声明: function sqrt(double n) -> double; 比这更有用 sqrt(n) 前者提供了大量信息:sqrt标识符是一个函数,以一个double作为输入,并产生另一个double作为输出。后者告诉您它可能是一个带有单个参数的函数。 我的答案 因此,在被问到“您的类型系统是干什么的?”之后 我回答如下: 类型系统是动态的(类型被分配给值,而不是分配给包含它们的变量),但是强大,没有令人惊讶的强制规则(您不能将字符串添加到整数,因为它们表示不兼容的类型,但是您可以将整数添加到浮点数) 。 VM使用类型系统来确保指令的操作数有效。可供程序员使用,以确保传递给其函数的参数有效(即类型正确)。 类型系统支持子类型化和多重继承(这两种功能均可供程序员使用),并且在对对象使用动态方法分配时会考虑类型-VM使用类型来检查针对给定类型实现的给定消息的功能是什么。 后续问题是“如何将类型分配给值?”。因此,我解释了所有值都装在框内,并有一个指向类型定义结构的指针,该结构提供有关类型名称,其响应的消息以及其继承的类型的信息。 在那之后,我被嘲笑了,我的回答被“那不是一个真正的类型系统”打断了。 所以-如果我所描述的不符合“真实类型系统”的条件,那会是什么?那个人对我提供的内容不能视为类型系统是正确的吗?

8
为什么Itanium处理器很难为其编写编译器?
通常说英特尔的Itanium 64位处理器体系结构失败是因为革命性的EPIC指令集很难为其编写好的编译器,这意味着缺乏IA64的良好开发人员工具,这意味着缺乏开发人员为该体系结构创建程序,因此没有人愿意使用没有太多软件的硬件,因此该平台出现了故障,并且全都需要马蹄钉 好的编译器。 但是,为什么编译器之类的东西这么难解决技术问题?在我看来,如果编译器供应商难以实现EPIC中的显式并行性,为什么首先要把负担加在它们身上?似乎还没有解决该问题的好方法,它不是一个很好的解决方案:而是将负担加在Intel上,并为编译器-编写器提供一个更简单的目标。 Itanium于1997年问世。到那时,UCSD P-Code字节码系统已有近20年的历史,Z机才更年轻,而JVM是编程语言世界中新出现的炙手可热的新星。英特尔为什么没有指定“简单的Itanium字节码”语言,而是提供一种工具,将这些字节码转换为经过优化的EPIC代码,从而利用他们最初设计系统的人员的专业知识呢?
50 history  compiler 

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.