内部开发团队应该构建/维护多少个应用程序？
我一直认为内部开发小组实际上应该只构建/维护三个应用程序。
- 内部复合/可插入/可扩展应用程序。
- 公司网站。
- （可选）适用于现场员工的 #1 移动版本。
我是一名顾问，无论我走到哪里，我的客户都会在网络和桌面上拥有数十个一次性应用程序来满足每种需求，无论它们与其他应用程序的相关性如何。有人来到 IT 部门并说“我需要这个”，IT 开发人员转身编写另一个一次性的 ASP.NET 应用程序或另一个 WinForms 应用程序。
你有什么看法？我应该接受“我们想要/需要多少应用程序”运动吗？我认为这很常见；但这明智吗？
编辑： 有同事指出，这取决于开发的重点——你是做应用程序还是做系统？我想对我来说，内部开发就是建立一个系统； MS Word、iTunes 和 Photoshop 等可交付软件产品的开发就是制作应用程序。
I've always been of the opinion an internal development group should really only be building/maintaining three applications.
- An internal composite/pluggable/extendable application.
- The company website.
- (Optional) A mobile version of #1 for field employees.
I'm a consultant, and everywhere I go, my clients have dozens of one-off applications in the web and on the desktop for every need no matter how related to the others. Someone comes to IT and says "I need this", and IT developers turn around and write another one-off ASP.NET application, or another WinForms app.
What's your opionion? Should I embrace the "as many apps as we want/need" movement? I assume it's common; but is it sensible?
EDIT:
A colleague pointed out that it depends on the focus of the development - are you making apps or are you making a system? I guess to me, internal development is about making a system; development of shippable software products, like MS Word, iTunes, and Photoshop, is about making apps.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
他们全部？
All of them?
哇，我同意你的看法吗？问题在于，许多一次性应用程序（在某些时候）都会有许多一次性维护请求。从业务规则更新到新报告请求的任何内容。在某些时候，需要维护的应用程序与可用开发人员的比例将变得捉襟见肘/征税。
从我可能（有限？）的角度来看，我开始认为#1 和#3 可以归结为 Sharepoint。我工作的大多数一次性应用程序（一家拥有 500 多名律师的大型律师事务所）都包含以下一项或多项内容：
尝试使用[命名您的技术]构建上述任何一项，并且您将有大量的维护周期值得期待（而不是相对较小的维护周期）共享点更改）。
如果我可以重申一下我认为您的观点：为什么不将大部分开发周期用于改进和维护一个可以支持大多数业务一次性需求的单一应用程序，而不是启动推出源源不断的小型专业应用程序？
Wow do I ever agree with you. The problem is that many one-off applications will (at some point) each have many one-off maintenance requests. Anything from business rule updates to requests for new reports. At some point the ratio of apps that need to be maintained to available development staff is going to be stretched/taxed.
From my perhaps (limited?) vantage point, I'm starting to think #1 and #3 could be boiled down to Sharepoint. Most one-off applications where I work (a large 500+ attorney law firm) consist of one or more of the following:
Try to build any one of the above using [name your technology], and you've got lots of maintenance cycles to look forward to (versus a relatively minor Sharepoint change).
If I could restate what I think is your point: why not put most of your dev cycles to work improving and maintaining a single application that can support most of your business' one-off needs, rather than cranking out an unending stream of smallish speciality apps?
这个问题取决于很多因素，而且很主观。我曾在需要多种不同应用程序的公司工作过，因为我们在谨慎的孤岛中开展业务。在这种情况下，内部小组可能不会构建和维护应用程序，但可以构建多个应用程序，并由另一个小组负责维护。
另外，“应用程序”是什么意思？如果你足够宽泛这个术语，那么你可以说“这只是一个大应用程序”。
总之我觉得主要考虑的是集团的能力以及业务需求是什么。
This question depends on so many things and is subjective besides. I've worked at companies that have needed several different apps because we do business in discreet silos. In that case, an internal group may not build and maintain apps, but may build several, with another group that is responsible for maintenance.
Also, what do you mean by "app"? If you broaden the term enough, then you could say "it's all just one big app".
In short, I think the main consideration is the capacity of the group and what business needs are.
我认为应该有内部开发团队，每个团队都有一个系统，其中可能包含多个应用程序。举几个例子来说明我所说的系统的含义：
ERP - 如果您是产品制造商，您可能需要一个系统来跟踪库存、账簿和资金会计以及其他计划元素。此类系统的规模范围很广，但我怀疑在大多数情况下都会进行一些定制，这就是使用团队的地方，如果公司成功并且需要新系统，最终可能会一遍又一遍地这样做取代以前的系统，因为这些系统可能需要数年时间才能完全启动并运行。车间应用程序可能与 CFO 需要的不同，以便编写季度收益数字（这里举两个例子）。
CRM - 跟踪组织内所有对销售和营销部门有用的客户交互怎么样？同样，有许多不同的解决方案，并且通常会由另一个团队进行定制。销售团队可能只有一种数据视图，但如果公司有支持部门，他们可能需要有关客户的不同数据来帮助他们。
CMS - 现在，我可以在这里看到您的三个应用程序有意义，但请注意除了简单内容之外还有其他内容。
CMS - 现在，我可以
我认为我不想在一切都是自制解决方案并且根本不使用外部代码的地方工作。许多代码都可以以相当好的方式使用，例如工具，但也可以使用数据库服务器或开发 IDE 等组件。
I think there should be internal development teams that each has a system which may contain multiple applications within it. To take a few examples of what I mean by systems:
ERP - If you are a manufacturer of products, you may need a system to keep track of inventory, accounting of books and money, and other planning elements. There are a wide range of scales of such systems but I suspect in most cases there is some customization done and that is where a team is used and may end up just doing that over and over if the company is successful and a new system is needed to replace the previous one as these can take years to get fully up and running. The application for the shop floor is likely not the same one as what the CFO needs in order to write the quarterly earnings numbers to give two examples here.
CRM - How about tracking all customer interactions within an organization that can be useful for sales and marketing departments? Again, there are many different solutions and generally there is customizations done which is another team. The sales team may have one view of the data but if there is a support arm to the company they may want different data about a customer to help them.
CMS - Now, here I can see your three applications making sense, but note what else there is beyond simple content.
I don't think I'd want to work where everything is a home grown solution and there is no outside code used at all. Lots of code out there can be used in rather good ways such as tools but also components like DB servers or development IDEs.
那么，除了多个一次性应用程序之外，还有什么替代方案呢？一个超级庞大的应用程序可以运行所有的东西？这对我来说似乎更糟糕......
So what's the alternative to several one-off applications? One super-huge application that runs everything and everything? That seems even worse to me...