软件工程

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

5
价值转换器会带来更多麻烦吗?
我正在使用需要大量值转换的视图的WPF应用程序。最初,我的哲学(部分是受到有关XAML信徒的激烈辩论的启发)的,我应该严格按照支持视图数据要求的观点来构建视图模型。这意味着将值转换为可见性,画笔,大小等所需的任何值转换都将由值转换器和多值转换器处理。从概念上讲,这似乎很优雅。视图模型和视图都将具有独特的目的并且可以很好地分离。在“数据”和“外观”之间将划清界限。 好吧,在将这种策略赋予“旧的大学尝试”之后,我有些怀疑是否要继续以这种方式发展。我实际上正在强烈考虑转储值转换器,并将(几乎)所有值转换的责任直接交给视图模型。 使用价值转换器的现实似乎并没有达到完全分开的关注点的表观价值。对于价值转换器,我最大的问题是使用它们很乏味。您必须创建一个新类,实现IValueConverter或IMultiValueConverter,将一个或多个值转换为object正确的类型,进行测试DependencyProperty.Unset(至少对于多值转换器而言),编写转换逻辑,在资源字典中注册转换器 [请参见下面的更新],最后,使用相当冗长的XAML(这要求转换器的绑定和名称都使用魔术字符串)来连接转换器[请参见下面的更新]。调试过程也不是一件容易的事,因为错误消息通常是不明确的,尤其是在Visual Studio的设计模式/ Expression Blend中。 这并不是说替代方案(使视图模型负责所有值转换)是一种改进。这很可能是另一面草更绿的问题。除了失去优雅的关注点分离之外,您还必须编写一堆派生属性,并确保RaisePropertyChanged(() => DerivedProperty)在设置基本属性时认真调用,这可能会带来令人不愉快的维护问题。 以下是我汇总的初始清单,这些清单允许视图模型处理转换逻辑并取消使用值转换器的优缺点: 优点: 由于取消了多转换器,因此总绑定数更少 较少的魔术字符串(绑定路径+转换器资源名称) 无需再注册每个转换器(还要维护此列表) 减少编写每个转换器的工作(无需实现接口或强制转换) 可以轻松注入依赖项以帮助进行转换(例如颜色表) XAML标记不那么冗长,更易于阅读 转换器重用仍然可能(尽管需要一些计划) DependencyProperty.Unset没有神秘问题(我在多值转换器中注意到的一个问题) *删除线表示如果您使用标记扩展,这些好处将消失(请参阅下面的更新) 缺点: 视图模型和视图之间的耦合更强(例如,属性必须处理可见性和画笔之类的概念) 更多的总体属性可允许直接映射视图中的每个绑定 RaisePropertyChanged必须为每个派生属性调用(请参阅下面的更新2) 如果转换基于UI元素的属性,则仍必须依赖转换器 因此,正如您可能会说的那样,我对此问题感到非常沮丧。我非常不愿走重构的道路,只是意识到无论我在视图模型中使用值转换器还是暴露大量的值转换属性,编码过程都是同样低效而乏味的。 我是否缺少任何利弊?对于那些尝试了两种价值转换方式的人,您觉得哪种对您更好,为什么?还有其他选择吗?(门徒提到了有关类型描述符提供程序的一些内容,但是我无法理解他们在说什么。对此的任何见解都将受到赞赏。) 更新资料 我今天发现,可以使用一种称为“标记扩展”的东西来消除注册值转换器的需要。实际上,它不仅消除了注册它们的需要,而且还提供了在您键入时选择转换器的智能感知Converter=。这是让我入门的文章:http : //www.wpftutorial.net/ValueConverters.html。 使用标记扩展的能力在上面我的优缺点列表和讨论中(见删除线)在某种程度上改变了平衡。 作为这个启示的结果,我正在尝试一个混合系统,在该系统中,我将转换器用于BoolToVisibility我所说的内容MatchToVisibility,并将视图模型用于所有其他转换。MatchToVisibility基本上是一个转换器,可以让我检查绑定值(通常是枚举)是否与XAML中指定的一个或多个值匹配。 例: Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue=Visible, IfFalse=Hidden, Value1=Finished, Value2=Canceled}}" 基本上,这是检查状态为已完成还是已取消。如果是,那么可见性将设置为“可见”。否则,它将设置为“隐藏”。事实证明,这是非常普遍的情况,使用此转换器可以为我节省约15个属性(以及关联的RaisePropertyChanged语句)。请注意,当您键入时Converter={vc:,“ MatchToVisibility”将显示在智能菜单中。这显着减少了出错的机会,并减少了使用值转换器的麻烦(您不必记住或查找所需值转换器的名称)。 如果您感到好奇,我将在下面粘贴代码。这种实现的一个重要特点MatchToVisibility是,它检查是否绑定的值是一个enum,如果是,它检查,以确保Value1,Value2等也都是相同类型的枚举。这样可以在设计时和运行时检查是否有任何枚举值输入错误。为了将其改进为编译时检查,您可以改用以下代码(我手动输入了此代码,因此,如果我有任何错误,请原谅我): Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue={x:Type {win:Visibility.Visible}}, …
20 silverlight  wpf  mvvm  xaml 

10
您如何帮助其他程序员成长?
作为团队负责人,您如何帮助程序员成长? 我之所以这样问,是因为有几个程序员在和我一起工作,我真的很想“放开他们”,以发挥他们的最大潜力,并使他们保持快乐。 但是我不太清楚该怎么做,我是否必须 经常与他们互动,还是给他们安静的时间,让他们不受干扰? 请他们遵循编码准则,例如强制执行单元测试,编码样式,还是让他们做自己认为合适的事情? 对他们宽容。例如,是否真的不在乎他们是真正上班8个小时还是4个小时,还是需要在工作场所执行一些“纪律”? 猜猜是什么,每个职位都有自己的观点,不同的人会为不同的事情争论。这种混乱使管理人员变得更加困难。 你怎么看?
20 management 

8
开发时与同事打交道,需要建议[关闭]
很难说出这里的要求。这个问题是模棱两可,含糊,不完整,过于宽泛或夸张的,不能以当前的形式合理地回答。如需帮助澄清此问题以便可以重新打开, 请访问帮助中心。 8年前关闭。 此问题是从Stack Overflow 迁移而来的,因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 我开发了当前的项目架构,并开始自行开发(达到revision 40)。 我们正在开发一个简单的地铁路线框架,我的设计似乎做得非常好- 几个主要模型,相应的视图,主要逻辑和数据结构均按“应有的方式”建模,并且与渲染完全分离,并且还实现了算法部分除了主要模型之外,交叉点数量很少。 我将这种设计称为可扩展,可定制,易于实现的设计,它主要基于“黑匣子交互”进行交互,而且很好。 现在,完成了什么: 我开始了相应接口的一些实现,移植了一些方便的库,并为一些应用程序部分编写了实现存根。 我有描述编码风格的文档以及该编码风格用法的示例(我自己的书面代码)。 我强迫使用或多或少的现代C++开发技术,包括no-delete代码(通过智能指针包装)等。 我记录了具体接口实现的目的以及应如何使用它们。 单元测试(大多数情况下是集成测试,因为没有很多“实际”代码)和所有核心抽象的一组模拟。 我缺席了12天。 我们现在拥有什么(该项目是由团队的其他4位成员开发的): 3个不同的编码风格遍布项目(我猜,他们两个人同意使用相同的样式:),同样适用于我们的抽象的命名(例如CommonPathData.h,SubwaySchemeStructures.h),它们基本上头宣布了一些数据结构。 绝对缺乏有关最近实施的零件的文档。 我最近称之为“ single-purpose-abstraction现在”的事件至少可以处理2种不同类型的事件,与其他部分的关系紧密等等。 现在,一半的已使用接口包含成员变量(sic!)。 原始指针的用法几乎无处不在。 单元测试已禁用,因为“ (Rev.57) They are unnecessary for this project”。 ... (可能不是全部)。 提交历史记录表明,我的设计被认为是一种过大的技巧,人们开始将其与个人自行车和重新实现的车轮结合起来,然后在集成代码块时遇到了问题。 现在-该项目仍然只执行其少量工作,我们存在严重的集成问题,我假设有一些内存泄漏。 在这种情况下有什么办法可以做? 我确实意识到我的所有努力都没有任何好处,但是截止日期很快就到了,我们必须做些事情。有人有类似情况吗? 基本上,我认为为该项目做好一个良好的开端(好吧,我已尽力)可能会带来一些好处,但是,我知道我错了。

7
编写自己的数据访问/数据映射层是“好”主意吗?
当前,我们处于选择使用现成的对象关系映射器或滚动自己的关系的情况下 我们有一个遗留应用程序(ASP.NET + SQL Server),其中数据层和业务层不幸地混在一起。该系统在数据访问方面并不是特别复杂。它从一大组(35-40)相互关联的表中读取数据,在内存中进行处理,然后以摘要格式将其保存回其他表中。现在,我们有机会进行一些重构,并且正在寻找可用于分离和正确构建数据访问的候选技术。 无论我们决定采用哪种技术,我们都希望: 在我们的域模型中具有持久性忽略的POCO对象 有一个抽象层,使我们可以根据模拟的基础数据源对域模型对象进行单元测试 显然,在模式和框架等方面已经有很多东西。 我个人正在推动将EF与ADO.NET单元可测试存储库生成器/ POCO实体生成器结合使用。它满足了我们的所有要求,可以轻松地捆绑在Repo / UnitOfWork模式中,并且我们的数据库结构相当成熟(已经进行了重构),因此我们不会每天对模型进行更改。 但是,小组中的其他人则建议完全从头开始设计/发布我们自己的DAL。(自定义DataMappers,DataContext,存储库,无处不在的接口,过分依赖以创建具体对象,自定义LINQ到底层查询翻译,自定义缓存实现,自定义FetchPlan实现...),该列表不胜枚举,直言不讳我是疯子。 引发的一些争论是“至少我们将控制自己的代码”或“哦,我在先前的项目中使用过L2S / EF,这无非是头疼”。(尽管我以前在生产中都使用过,发现任何问题很少而且相差不大,而且很容易处理) 因此,您在超级经验丰富的开发人员/架构师中是否有任何智慧的言语可能会帮助我将这个产品从我看来将是一场彻底的灾难中解脱出来。我忍不住想,通过规避EF问题而获得的任何利益,都将因尝试重新发明轮子而同样迅速地丧失。

5
绕过人力资源部接受采访[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,使它成为软件工程堆栈交换的主题。 5年前关闭。 我最近发送了一份我有资格的职位申请,并收到了以下回复:“很遗憾地通知您,您当前的任职资格与我们当前的职位空缺不符。我们将保留您的简历,如果职位空缺,非常适合您的技能,我们会在那时与您联系。” 列出的职位需要具备A,B,C,D和E的技术技能,并具有X和Y的出色表现。我在履历表和求职信中列出了我在A到E和X方面的经验。没有与Y的任何经验。这使我相信我有资格担任该职位,而人力资源代表(似乎不属于公司的一部分)是错误的。我要求澄清我缺少哪些资格,但尚未收到答复。 我对公司和将与之合作的开发人员进行了大量研究,我认为这将是一个理想的工作场所。我不想轻易拒绝。我正在考虑直接与公司的开发负责人联系(通过Twitter),并请他查看我的简历。他不知道我是谁。这是一个好主意吗?
20 interview 

9
面试中提交代码[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,使它成为软件工程堆栈交换的主题。 4年前关闭。 我正在面试一家互联网创业公司的职位。该职位涉及在他们非常大的用户信息数据库上进行数据挖掘。作为(远程)面试程序的一部分,该程序涉及检查数据库的一个子集,他们要求我提交用于分析的代码。 我主要担心的是,该代码是“专有的”,因为缺少更好的词。如果最终为他们工作,我可以毫无问题地给他们提供所有代码,但是考虑到他们可能会采用这些代码,而不是雇用我,并在更大的数据库上使用它来产生收入,我很犹豫。我只是在偏执吗?这是合理的关注吗?
20 interview 

2
从运行时获取的类型动态生成类
是否可以用C#(或任何其他语言)执行以下操作? 我正在从数据库中获取数据。在运行时,我可以计算获取的列数和数据类型。 接下来,我想使用这些数据类型作为字段“生成”一个类。我还想存储我在集合中获取的所有记录。 问题是我想在运行时同时执行步骤1和2 这可能吗?我目前正在使用C#,但如果需要的话,可以改用其他软件。


11
信息隐藏不仅仅是一种约定吗?
在Java,C#和许多其他强类型,静态检查的语言中,我们习惯于编写如下代码: public void m1() { ... } protected void m2() { ... } private void m2() { ... } void m2() { ... } 一些动态检查的语言不提供关键字来表达给定类成员的“私有性”级别,而是依靠编码约定。例如,Python为私有成员添加下划线前缀: _m(self): pass 可以争论的是,以动态检查的语言提供这样的关键字只会增加用处,因为它只能在运行时检查。 但是,我也找不到以静态检查的语言提供这些关键字的充分理由。我发现需要用相当冗长的关键字(例如protected烦人和分散注意力)填充代码。到目前为止,我还没有遇到过由这些关键字引起的编译器错误会使我免于错误的情况。相反,我一直处在错误放置位置的情况下,protected使我无法使用库。 考虑到这一点,我的问题是: 信息隐藏不仅仅是程序员之间用来定义类正式接口的一部分的约定吗? 可以用来保护班级的秘密状态免遭攻击吗?反射可以覆盖此机制吗?什么使编译器强制实施信息隐藏值得?

1
OAuth的替代品?
在将API服务扩展到外部使用者和开发人员时,Web行业正在/已经转向使用OAuth。简单有一些优雅之处。...而且,三步OAuth流程还不错...我只是发现它是一堆糟糕的选择中最好的。 是否有其他更好,更安全的替代方案? 安全参考来自以下URL: OAuth 2.0对网络不利吗? 没有签名的OAuth 2不利于网络 我在IT安全性堆栈交换中遇到了这一点,并认为从安全性的角度来看这是很痛苦的: OAuth / OpenID / Facebook Connect ..疯狂吗? 也许SAML 2.0是替代方案? 那OpenID呢? 这个问题的目的是从编程的角度来看。 OAuth是当今存在的最佳选择吗? 是否存在替代选项,这些选项使我可以将Web应用程序扩展到从安全角度,实现角度,寿命(不需要几个月的返工)以及更好的支持消费者的Web应用程序,并支持消耗我的Web的移动应用程序应用。

8
巨大的整体应用的危险
我现在从事的一个大型项目现在是高级设备的控制(及所有)应用程序,它是固件的核心。 该设备相当先进,具有比我在内存中所能说的更多的不同功能,其中98%由该庞大的可执行文件处理。一方面,该程序可维护性强,内部模块化程度高,文档正确,并且按目录和文件等对功能进行了合理隔离。 但是最后,它被全部集中到一个应用程序中,该应用程序执行从远程数据库通信,触摸屏处理,处理十二种各种通信协议,测量,几种控制算法,视频捕获,日出时间和复活节日期(认真地,通常,这是非常紧密相关的内容,通常仅通过一些在一些远模块之间滴加的数据才相关。 它可以通过几个单独的可执行文件相互通信来完成,例如,通过套接字进行通信,具有更特定的目的,可以根据需要加载/卸载等等。没有这种特定方式的原因。 一方面,它有效,而且还可以。该项目更加简单,无需维护多个二进制文件的构建。当您可以仅调用方法或读取变量而不是通过套接字或共享内存进行通信时,内部结构也更容易。 但另一方面,这东西的大小,规模让我感到无所适从,感觉就像是驾驶泰坦尼克号一样。我总是被教导要模块化,将所有内容都聚集到一个庞大的文件中感觉很不对。我知道的一个问题是,一个严重的崩溃(甚至无关紧要的)使所有模块崩溃了,但是代码质量确保在发行版中不会真正发生这种情况。否则,内部隔离和防御性编程可确保即使一半内部模块由于某种原因正常发生故障,该操作仍将大部分正确地运行。 我还忽略了哪些其他危险?为什么这使我感到恐惧?这只是对未知的非理性恐惧吗?这样进行严肃的大型项目是否可以接受?请平息我的担心,或者给我一个很好的理由将2.0版重构为多个较小的二进制文件。

4
人们为什么认为不推荐使用SOAP?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 今天浏览SO时,我发现了这个 这里问题,它从下面开始: 当然,您会告诉我SOAP已被弃用,而我被迫使用它 到目前为止,在SO上发现了很多这样的声明,这只是触发了我提出这个问题。 REST有它的用途,SOAP有它的用途,在某些地方它们作为功能相交,但不能相互替换。 所以我想知道,为什么人们认为SOAP被“弃用了”?是无知吗?SOAP和WS- *规范的复杂性?REST炒作?什么? 如果您认为不赞成使用SOAP,请告诉我原因。我很好奇!
20 web-services  soa  soap 

2
嵌入式C开发人员的良好单元测试示例
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,使它成为软件工程堆栈交换的主题。 6年前关闭。 下周,我将与我的部门进行有关单元测试和测试驱动开发的演讲。作为其中的一部分,我将展示一些我最近编写的代码中的真实示例,但我也想展示一些我将在演讲中编写的非常简单的示例。 我一直在网上寻找良好的例子,但一直在努力寻找任何特别适合我们开发领域的例子。我们编写的几乎所有软件都是在小型微控制器上运行的深层控制系统。只要您远离“底层”层,就有很多C代码很容易适用于单元测试(我将在PC上而不是在目标本身上谈论单元测试):直接对话的东西到微控制器外设。但是,我发现的大多数示例都倾向于基于字符串处理(例如出色的Dive Into Python罗马数字示例),并且由于我们几乎从未使用过字符串,因此这实际上并不适合(关于我们的代码通常使用的唯一库函数)是memcpy,memcmp和memset,strcat 或正则表达式不太正确)。 那么,问题就来了:请问有人可以提供一些很好的功能示例,这些功能可以用来在实时会话中演示单元测试吗?在我的观点(可能会发生变化)中,一个好的答案可能是: 一个足够简单的功能,任何人(甚至只是偶尔写代码的人)都可以理解; 看起来没有意义的函数(即计算奇偶校验或CRC可能比将两个数字相乘并添加随机常数的函数更好); 一个足够短的函数,可以在一个人的房间里书写(我可能会利用Vim的许多剪贴板来减少错误……); 该函数以数字,数组,指针或结构为参数,并返回相似的内容,而不是处理字符串。 具有简单错误(例如>而不是>=)的函数易于插入,在大多数情况下仍然可以使用,但在某些特殊情况下会中断:易于通过单元测试进行识别和修复。 有什么想法吗? 尽管可能无关紧要,但是测试本身可能会使用Google Test Framework以C ++编写:我们所有的标头都已经包含了#ifdef __cplusplus extern "C" {包装器;到目前为止,这与我已经完成的测试效果很好。

3
C#实际上是一种多平台语言吗?
此问题是从Stack Overflow 迁移而来的,因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 C#(和一般的.net平台)看起来正成为多目标应用程序的不错选择: 官方MS .net框架:全面的Windows开发,asp.net开发,Windows Phone开发等 mono及其所有派生产品:monotouch,monodroid:世界其他地区。该工具今天是RTM。 这是否意味着C#成为针对最受欢迎的平台(台式机,Web和移动设备)的一种好语言? 使用目标平台(目标C,Java等)的“本机”语言是否还更好? 它只是一团烟雾,只有营销语言吗? 请注意,我实际上意识到我无法在平台之间复制/粘贴代码。但是我确信可以重用较低层的应用程序(模型,业务等),但是我知道我必须将较高层(Gui等)适应该平台。我的目标是更专注于必需的技能,而不是技术代码共享。 [edit]我是一家大规模使用c#的公司的ac#开发人员。这就是为什么我在扩展公司目标平台范围的计划中谈到c#的原因。
20 c#  mono  monodroid 

6
直接修改超全局变量
此问题是从Stack Overflow 迁移而来的,因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 我见过人们(通常会写出好的代码)直接$_POST使用如下代码更改数组: // Add some value that wasn't actually posted $_POST['last_activity'] = time(); // Alter an existing post value $_POST['name'] = trim($_POST['name']); // Our pretend function // Pass the entire $_POST array as data to work with in the function // The function …
20 php 

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.