我们是初创公司,有少数(14)客户使用我们的产品。这些产品是在闭源Web开发框架中开发的,该框架仅由核心的一个开发人员维护。
基本上,框架服务器必需,以便能够运行其中内置的任何应用程序。所以在我们的应用程序层中没有代码。将其视为CMS,允许我们使用框架服务器本身的专有语言进行开发。
此框架基于Java构建,并且是封闭源代码。它有一层插件需要使用专有的IDE来构建它们。
我从事中间技术管理,我一直在向我的IT总监/总裁提出一些改变建议,但显然我没有通过。我建议用我们自己的开发团队开始在另一个框架(ASP.NET MVC,Symfony,SPRING MVC)中开发新组件,并将这些组件100%与我们的旧应用程序集成,直到我们适应移植的方式从旧框架到新框架的旧应用程序。
无论哪种方式,这个计划都有很多变化。任何来自SO的知识的建议。
作为替代问题: 为什么要在一个只有一个开发人员而没有文档的密切Web开发框架上构建业务?
上次评论: 我想可能布鲁斯是对的。我的高层管理团队更关注继续销售和支持我们当前的产品而不是继续销售和支持我们的产品。可能当我们从14个客户端扩展到30个客户端时,他们会看到我们拥有的可扩展性不足,并且暂时采取其他行动。我认为这场战斗一直持续到2011年。感谢您的投入。
答案 0 :(得分:6)
尽可能快地废弃它并进行迁移,因为你只是在糟糕的情况下抛出了好钱。这就是所谓的Sunk Cost Fallacy
答案 1 :(得分:2)
小公司的管理层关注的是保持业务和满足客户。如果当前的架构支持这一点,那么管理者将会很高兴并且不会改变。如果业务不稳定,他们可能没有资源(现金)来支持投资开发新框架的时间和工具。
如果业务表现良好,足以支持在新框架中投入资源,那么您需要证明投资回报率(ROI)值得投资。然后,他们可以决定是否有足够的时间和现金来支付变更费用。
改变的情况是: 显着提高了开发效率。 显着提高质量。 显着增加功能。 与保持当前平台相关的风险。
答案 2 :(得分:1)
根据您的说法,更改软件的主要障碍是所有者开发了您当前未记录的代码。
专注于让主人加入您的行列。一旦所有者投票改变新代码,你就可以完成一些工作,直到那时你可能会遇到使用创可贴。
答案 3 :(得分:0)
从目前市场的发展来看,唯一的原因是策略不好。
您可能尝试在双许可证基础上打开产品,但如果没有文档,外部开发人员不太可能跳过它(尽管IDE可能会在这方面有所帮助)。
规定变更可以基于风险与机会评估。
从您描述的情景来看,我认为需要认真考虑的核心因素是人力资源:
还要认真考虑图片中的知识部分:作为一个组织,您需要在默认和显式知识之间建立更好的平衡。
也许试着确定改变的障碍(个人和组织),即:
分析它们并整合结果以支持更明智的决策过程。