在我的公司,我们承担着为我们的产品创建一个新的软件架构的重大任务。我们目前的体系结构已经使用了许多产品迭代,并持续了很长的时间,是时候退休了。UI架构目前在WTL/ATL3.0和COM中实现。
我们刚刚完成了后端架构的设计,它将像其前身一样经得起时间的考验。然而,UI技术发展得如此之快,以至于我们团队中没有人具备我认为应该持续多年的基础所需的专业知识。我们目前的目标是WPF的这一架构,并考虑各种替代战略,以帮助我们缺乏对这项技术的专门知识。我们正在考虑的一些办法:
architecture.
那么,我要问您的问题是,您如何解决类似的情况:您必须使用您的团队目前还没有架构师级别知识的新技术来创建一个健壮、丰富、持久的体系结构?你以前提到的任何策略都成功了吗,还是有其他的方法我完全错过了?
总的来说,我并不主张以这种身份使用您不熟悉的技术。考虑到这一点,我们相信WPF可能提供的用户体验将给我们提供我们多年来想要使用的能力。无论如何,你必须从某个地方开始。;-)
发布于 2010-02-05 20:26:01
最终你必须学习你所选择的GUI。
作为这类项目的外部顾问之一,我建议对备选方案2进行修改。
在consultants.
您的后续问题(“关于具有专业知识的公司的建议”)令人不安。如果你没有可信的技术合作伙伴,现在是开始培养他们的时候了。找到你可以信任的人需要一段时间。
找到他们的唯一方法是付钱给他们做一些工作,看看你是否喜欢他们和工作。这个过程可能需要很长时间。
一个人做第一件事的问题是显而易见的。如果你试图在没有专家的情况下在最后期限内做到这一点,你就会犯错误。你会把那些错误扔进混凝土里。你会永远和他们生活在一起。当学习新东西时,日历是最危险的。
选项1在没有时间压力的情况下起作用。你在学习的时候做些一次性的东西。然后建造一些你知道你将不得不扔掉的东西。那就造出真实的东西。
做第三件事的问题是,你可能要求顾问做的太多了。如果他们计划你的架构,你可能不会完全理解它。你会走捷径,坏事也会发生。如果--另一方面--你自己去做,你就会明白为什么那些角落不应该被砍掉。
此外,#3是一个机会,在每一个你认为可能是酷的功能。在你了解技术之前,你并不真正理解什么是必要的,什么是容易的,什么是困难的。你很可能会要求一些昂贵和有风险的东西,因为很难确切地理解它有多昂贵和有风险。
发布于 2010-02-05 19:41:22
首先,WPF可能是一个不错的选择。这正被微软所接受,而这似乎确实是事情长期发展的方向。我最近做了一个非常类似的决定,并决定使用WPF。在经历了一项新技术带来的最初痛苦之后,事实证明这是一个非常好的决定。
话虽如此,我强烈推荐2和3的混合物。
如果你能找到一个好的顾问来帮助你的设计,你应该能够让他们来帮助你在设计和架构阶段,一些项目的初步建设,他们也可能帮助你的开发人员提高速度。在家里提供帮助(或者至少是随叫随到的帮助)将极大地帮助您完成尝试使用WPF开发的初始阶段。
它还有助于引入具有使用WPF经验的开发人员和/或设计人员。
https://stackoverflow.com/questions/2209805
复制相似问题