|
|
6 回复 | 直到 13 年前
|
1
0
你已经发现了一个关键问题——当你买东西的时候,你还有工作要做,而且可能还有很多工作要做。我说过我每次都倾向于买东西。编写代码是很困难的,调试代码是很困难的——当你买的时候,你不仅仅是买了你买的代码/应用程序——事实上它是有效的——后者是90%的好处。 但是,由于您的需求非常普遍,为什么不使用开放源码呢?这有两个突出的好处。 1)由于您可以访问源,因此您可以将其弯曲到您的意愿,即无需在现有系统的顶部设置单一登录。定制登录模块以使用您已经存在的基础设施,因此无需保持同步、节省时间、干净的方法等。许多开源软件通过组件化(?)承认现实世界。不管怎样,这些方面都是特定于环境的。他们往往是数据库/身份不可知论者。 2)如果你明智地选择,你将拥有一批已经了解系统并随时准备提供帮助的顶尖技术人员——唯一的问题是他们还不适合你(还没有!). 我的建议是选择一个简单的目标——票务系统似乎就是一个,分析在开放源码的世界里有什么能满足你的大多数/所有需求。评估并提出请求 Rent A Coder 对于所需的任何更改。坐下来等待结果,希望是非常好的。你损失了一点时间,积累了很多经验。 开源不等于Linux/Unix——还有很多很好的.NET工具。 |
|
2
0
一个系统更适合以下情况:
但是…很明显,你被你买的东西困住了。如果可以的话,一定要有一个系统,你可以为它构建自己的外接程序,使之与你的业务模型相匹配。 |
|
|
3
0
显然,这要看情况而定。我的一般规则是,如果它是内部的,我们就购买它,如果需要的话,我们就集成它。我们的企业系统管理员有一条支持线,如果她有问题,我们的组织外部的人,这不是一个巨大的项目负担我们的开发人员。 如果它是我正在运送的产品的一部分,我就构建它,或者根据需要从开放源码库中获取一些源代码。没有什么比别人的黑盒代码破坏了你的产品更糟糕的了。运输产品中的依赖性越少越好,imho。 我倾向于购买像你提到的支持产品。好的产品为共享的认证系统、面向主题的用户提供了很好的集成点,而且您的客户服务团队可能还没有意识到他们想要/需要的大量功能。 但是,要分析什么。对于我来说,像这样的“管理”项目最重要的是机会成本。我的团队还能做些什么来让我们的公司赚更多的钱,吸引更多的客户,等等?当然,这些项目对底线有一些积极的影响,但与新产品、改进的产品等相比,没有任何影响。随着时间的推移,包括维护,开发人员/项目经理/测试人员将在这个管理项目上花费多长时间?如果您购买,集成点不会经常改变,但如果您构建,您的客户(内部人员)将不断要求新功能,您将能够在您的剩余任期内维护此项目。 |
|
4
0
买?陌生人,这是你买的什么? 说真的,我很久没有为自己的项目买过软件了。我的所有开发工具都是免费的,我的所有第三方库都是免费的(不是GPL)。甚至我的操作系统也是免费的。我必须为测试的目的支付Windows的费用,但是大多数工作都使用跨平台的工具。 任何需要代码的东西如果不能立即从免费的工具或库中获得,我要么从头开始写(所有的算法在网络上都是免费的),要么使用我多年来一直在添加源代码的代码片段库(自我这么老以来就很大了)。 购买(“获取”)几乎总是比构建更快,除非所购买的东西如此糟糕,以至于集成是一场噩梦。这可以通过避免来自几乎没有记录的供应商的最新产品来缓解。 |
|
|
5
0
你的要求越“标准化”,买的越合适(或者换个说法,不要重新设计轮子)。相反,您的需求越独特,您就越可能考虑构建。 你很正确地指出,即使在购买时,也会有一些定制。记住,任何定制都会在每次升级/修补时花费您的成本。我建议,如果您的需求接近由您可能购买的工具所支持的业务模型,那么您应该认真考虑将业务流程重新调整为供应商标准。如果不可能,询问您是否购买了正确的工具。 我建议如果有人出于成本原因建议建造它,那就大喊大叫吧。根据我的经验,购买成本是众所周知的,建造成本是隐藏的。请记住,您将决定在应用程序的使用寿命内继续编写代码(对于业务应用程序,平均7年),但在决定购买和构建时,可能只考虑初始开发成本。 我非常喜欢单一的单片数据库,但有时这是不可行的。更重要的是要有一个“单一的真相来源”;如果有多个数据库保存着类似的数据,那么选择一个数据库作为给定数据的权威来源,并有一个过程来维护所有其他数据库与该来源的一致性。最好是自动的。 |
|
|
6
0
做任何事情的整体系统是 Raison d'être 对于如此多的企业应用程序。然而,我发现,如果你不愿意支付一大笔钱,你将面临集成问题。 “最好的”解决方案是非常主观的,任何答案都是正确的,但如果我是王者,我可能会选择合适的、根深蒂固的开放源代码解决方案,并将Web服务包装在需要相互交流的项目上。如果我是国王。 作为一个切点,有免费的票务系统 RT (等)你不用担心买东西。 |
推荐文章