Questions tagged «decisions»

我现在正在管理一个由15名开发人员组成的团队，而我们在选择技术时陷入了困境，该团队被分为两个完全相反的团队，就WCF与Web API的使用进行了辩论。 支持Web API使用的团队A提出了以下原因： Web API只是编写服务的现代方式（Wikipedia） WCF是HTTP的开销。这是TCP，Net Pipes和其他协议的解决方案 由于[DataContract]和[DataMember]以及这些属性，WCF模型不是POCO SOAP不像JSON那样可读性强 与JSON（通过HTTP传输）相比，SOAP是网络的开销 没有方法重载 支持WCF使用的团队B说： WCF支持多种协议（通过配置） WCF支持分布式事务 WCF有许多很好的例子和成功案例（虽然Web API仍然很年轻） 双工非常适合双向通讯 这场辩论仍在继续，我现在不知道该怎么办。我个人认为，我们应该仅在正确的使用位置使用工具。换句话说，如果我们想通过HTTP公开服务，则最好使用Web API，而在TCP和Duplex方面则要使用WCF。 通过搜索互联网，我们无法获得可靠的结果。支持WCF的职位很多，但相反，我们也发现有人对此表示抱怨。我知道这个问题的性质听起来可能有争议，但是我们需要一些好的提示来决定。我们处于一个偶然地选择技术可能会让我们后悔的时机。我们想睁大眼睛选择。 我们的用法主要用于Web，我们将通过HTTP公开我们的服务。在某些情况下（例如5％到10％），我们可能需要分布式事务。 我现在应该怎么办？如何以建设性的方式处理这场辩论？

49 wcf  decisions  web-api 

编程时，完美主义可能是好事，也可能是坏事。 解决问题的时间和地点在哪里？ 您什么时候决定解决方案过高，太笼统或太过未来？ 如果问题不清楚，请发表评论。

37 methodology  time-management  problem-solving  decisions 

我有2天的时间对公司要使用的工具和平台做出非常认真的决定，以便将其WPF应用程序移植到Linux / Android / iOS。 显然，我可以指出，我的前辈说，只有2天时间不足以阅读所有可能的选择，以及尝试，制作原型等内容。我可以说，这对我没有帮助，我有2天的时间，并且2天后将做出决定。期。 一方面，我感到沮丧，另一方面，我认为这种方法有一定道理，否则，我很容易陷入很多下载的SDK，框架，API，博客文章等之中，沉迷于做基准工作，运行示例并忘记了过程的全部目的。 仍然我担心，错误的决定将使公司付出沉重的代价。那么，您认为做出此类决定的“理想”过程是什么？

36 development-process  time-management  decisions 

是否有一套行业认可的规则来避免供应商锁定？ 我的意思是，可以向经理或其他决策者展示的东西易于理解且易于验证。 是否有任何一套普遍接受的规则，清单或条件集可以帮助以客观，可衡量的方式检测和防止供应商锁定？ 你们中的任何人是否曾就项目初期阶​​段供应商锁定的风险警告过经理？

23 management  decisions  risk 

我们经常在业务会向客户承诺一项新功能的场景中运行。企业将保证以特定方式实现该功能。企业承诺的这些技术细节通常很差。不幸的是，现在已经设置了客户端，并希望以业务描述的方式实现此功能。 最后，企业只希望在不考虑质量和可维护性的情况下完成此功能。有什么好方法可以后退吗？我们如何向企业解释在收集需求之前提供技术详细信息是一个坏主意？

14 project-management  decisions 

当开始一个新项目时，我的老板总是避免做出固定的决定。他通常在说：好吧，就开始写点东西，并尽可能通用。当您完成后，我们将看看我们如何继续。他的论点基本上是您永远不知道和“敏捷开发”。 为了使问题尽可能笼统：如果老板不喜欢做决定，您会怎么做？ 只是坚持并编写可能在几周后进行大量重构和部分重写的代码？还是继续讨论直到老板做出至少一些决定？这或多或少是我目前的策略。因为这就像物理定律，所以在某些时候需要交付一些东西。要么是因为老板的老板想看到结果，要么是因为某些时候东西变得荒谬。 我还发现老板几乎批评了所有事情。甚至是基于他自己的建议...

12 design  project-management  requirements  decisions 

给定一个旨在为应用程序添加新功能的小型项目，所引入的更改涉及一些现有代码，涉及在某些领域中进行更新。在实施期间，我发现其中一些更新的代码具有重构的候选对象。 这是否是一个适当的重构时间，从而又需要对受影响的那些组件进行回归测试（因此可能引入的范围最初不是项目的一部分）？还是我应该推迟，完成功能，也许有一个单独的项目进行重构（尽管我有点犹豫，因为业务用户可能不会完全赞助一个不添加任何功能的项目，除非他们重视代码的可维护性...）？

11 testing  refactoring  decisions  maintainability  scope 

我目前正在两种可行的软件设计/解决方案之间进行选择。解决方案1易于实现，但会以专有格式锁定某些数据，以后将很难更改。解决方案2难以实现，但以后将更容易更改。 我应该选择YAGNI还是应该将退出成本纳入决策？还是换个角度问，退出成本是TCO的一部分吗？ 我正在考虑再回头问客户，他是否认为退出成本是相关的，但我想知道社区首先想到的是什么。 PS退出成本是否正确？

10 design  architecture  terminology  decisions