关于将累积设计 Flex 项目转换为 Mate 的建议
我们有一个内部 Flex 应用程序，它的设计更多地是通过功能蠕变而不是任何清晰的愿景。 它基本上是一种 CRM 和报告系统，它利用大量 Flex 组件（树、图形、自定义组件、数据网格 - 各种）并与 .NET Web 服务后端通信。
它最初是我的第一个 Flex 项目，并且是用你可能期望从原型中得到的那种“犹豫”、“希望”和“修复”的风格来编写的。 然而，它现在已经发展到我们将添加其他（新手）开发人员的地步，但一个人（叹息，可能是我）在大约一分钟内重写当前快照可能并非不可能。月。 因此，现阶段我认为考虑在 Mate 框架。
我不需要关于选择哪个框架的建议，我想要的是关于如何重构项目的建议。 看起来这将涉及拆除所有东西并几乎重新开始（我并不完全反对），但是框架是否必须从头开始构建？ 是否有任何已知和推荐的方法来解决此类问题？
We have an internal Flex application which has been designed more through feature creep than by any kind of clear vision. It's basically a kind of CRM and reporting system which utilises quite a lot of Flex components (trees, graphs, custom components, datagrids - all sorts) and talks to a .NET webservice backend.
It was initially my first Flex project and has been written with the bodge, hope and repair kind of style you might expect from a prototype. However, it's now grown to the point where we'll be adding other (neophyte) developers, but it might not be impossible for one person (sigh, probably me) to rewrite the current snapshot in about a month. So, at this stage I'm thinking it might be a good idea to consider a new version implemented in the Mate framework.
I don't need advice on which framework to choose, what I would like is advice on how to go about refactoring the project. It seems like this will involve tearing everything down and pretty much starting again (which I'm not totally averse to), but does the framework have to be built in from the ground up? Are there any known and recommended methods of attacking this kind of problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
几个月前我也做了类似的事情。 我所做的是创建一个新的包结构，并将所有“移植”代码移到那里。 我从整体视图结构开始，然后转向“分支”。 新代码在需要的地方引用了旧代码，但旧代码没有引用新代码。 拥有新的包结构有助于明确哪些已移植，哪些未移植，而且也很容易看到我何时取得了进展。
I did a similar thing a couple of months back. What I did was that I created a new package structure and moved all "ported" code there as I went along. I started with the overall view structure and moved my way towards the "branches". The new code referenced the old where needed, but no old code referenced the new. Having a new package structure helped in making it clear what had been ported and what had not, and it was also easy to see when I made progress.