问题标签 [future-proof]

最近，我听到了很多关于函数式编程语言（例如 F#）的好消息。此外[和不相关]，我还注意到 MVC 开始获得大量曝光——也许是自从 Silverlight/WPF 引入以来。

我从来没有在没有先做研究的情况下加入潮流——事实上，我花了一点时间才飞跃到 .NET。有人刚刚在我之前的一个关于早期采用新技术的问题中发表了评论，这让我停下来思考。

我一直在努力寻找时间来学习 WPF，但现在我开始怀疑这是否是要走的路。诸如 F# 之类的语言和 MVC 编程模型会继续存在还是只是下一个时尚？还是人们真的认为这些是 C#/VB 和 OOP 的潜在替代品？

我的大部分开发都是在内部应用程序上进行的，要么以丰富的 Web 应用程序的形式部署在 Intranet 上，要么以 Winforms 实用程序应用程序的形式分发到各个机器上。到目前为止，我选择的技术非常标准——T-SQL/PL*SQL、C#/VB、JavaScript/AJAX、CSS。

我想我正在努力确定的是，在不久的将来，在我的工具箱中使用这些技术的哪种组合最有效率/最有用？

自动编号字段（例如 SQL Server 中的“身份”）是为数据库表提供唯一键的常用方法。然而，鉴于它们很常见，在未来的某个时候，我们将处理它们将开始达到最大值的问题。

有谁知道或有推荐的策略来避免这种情况？我希望许多答案会建议切换到 guid，但考虑到这将需要大量的开发（尤其是在许多系统集成并共享价值的情况下），还有其他方法吗？我们是否正朝着新的硬件/操作系统/数据库将简单地允许整数值越来越大的方向前进？

我正在考虑尽量减少对尚未编写的应用程序的未来影响。我试图避免任何 3rd 方产品，甚至避免特定于操作系统的调用。任何人都可以建议将来验证应用程序的其他方法。这个想法是不必在 10 或 20 年内重写主要部分，并且只需要进行维护（错误修复）。

我的想法：

由于各种原因，我绝对鄙视存储过程：成本、可伸缩性和兼容性。

• 成本：我可以用一台好的 MySQL 服务器的成本获得 2-3 台好的轻量级 Web 应用程序服务器。

• 可扩展性：当然我可以缓存查询结果，但是当使用存储过程时，我失去了获得更精细的缓存粒度的机会，而且它将应用程序与始终使用 MySQL 联系起来（谁有钱从MySQL到别的东西？）

• 兼容性：在某些时候 list_foo_widgetsByUser() 存储过程可能不适合客户端 #123 的需求。修改 list_foo_widgetByUser() 的签名将是自杀……所以我必须编写一个新的 sproc cl123_list_foo_widgetByUser()，这样会导致疯狂或杀人的 DBA。

我的解决方案：

从应用程序的存储库中提取模型并将它们放入外部存储库。然后，每个应用程序都会有一个指向外部存储库的 models/Base 子目录。然后在前面放置一个简单的工厂方法，例如 GetModel("FooWidgets")，它将 baseFooWidget 类作为实例或应用程序特定的子实例返回。这将允许单个应用程序继承 FooWidget 的类或与 Liquabase 等工具结合使用，从而允许更大的可变性基础。

我脑后有个声音说这太容易了……我在这里错过了什么？

参考资料：我知道 PHP Kohana 框架在这些方面做了一些事情，以允许应用程序设计人员用附加功能包装 Kohana 的基本库，如果 PHP 可以做到，我看不出任何其他语言有问题。

哪个是首选boost::lock_guard还是boost::mutex::scoped_lock？

我正在使用 Boost.Thread，希望在 C++11 线程可用时转移到它。

是scoped_lock下一个 c++ 标准的一部分吗？

偏爱一个比另一个有什么优势吗？

注意：我知道这scoped_lock只是typedef.lock_guard

编辑：我错了scoped_lock不是. 这是一个。typedeflock_guardtypedefunique_lock

背景：我现在正在开发一个 .NET WinForms 应用程序（C#），它带有一个用于数据层的 ADO.net 数据库。

问题：我现在如何开发它，以便轻松迁移到通过 HTTP Web 服务或 REST 接口抽象数据层的模型？

例如，仅使用带有工厂的标准 C# 接口来获得使用 ADO.net 的接口的具体实现是最好的吗？

谢谢

所有 Python 内置程序都是子类，object我也遇到了许多用户定义的类。为什么？上课的目的是什么object？这只是一个空班，对吧？

我们有一个基于 Web 的客户端-服务器产品。该客户端预计将在100万以上用户中使用（一家著名公司将使用它）。

我们的服务器设置在云端。设计时的主要问题之一是如何使整个程序面向未来。说：

1. 云提供商出现故障，然后自动转移到另一个云中的备份
2. 完全移动到不同的服务器等

到目前为止，我们认为的选项是：

1. DNS：我们自己在云上运行 DNS 名称服务器。
2. 目录服务器 - 目录服务器也存在于云端
3. 让我们的服务器将未来的移动和未来的 URL 等返回给客户端 - 其中客户端专门设计用于处理这些场景

既然这应该是一个常见的问题，那么最好的解决方案是什么？由于我们公司很小，我们正在寻找技术和财务成本最低的解决方案（比如选项 3 等）？

有人可以提供一些相同的指示吗？

ķ

假设我的任务是设计一个具有基于浏览器的前端的产品。
销售团队想要一个时髦的应用程序。产品管理团队希望使产品具有成本效益（贯穿维护阶段）

现在假设技术团队可以拨打电话（我希望:)）是否给用户一个“丰富”的外观和感觉像 stackoverflow/facebook 这样的网站，或者给他们一些 2006 年时代的东西......考虑到..

1. 产品寿命预计为6年左右
2. 产品维护团队应该不需要重构代码来匹配未来的浏览器
3. 产品维护团队只会增强业务功能
   ..以及很多类似的相关内容

..你会推荐使用ajax吗？如果是的话，是什么让我保证我今天使用的 UI（ajax 框架）将在接下来的 2-3 个浏览器版本中继续工作而不会发生任何变化？

编辑：请不要假设我对 AJAX 有任何反对意见。自 1999 年以来，我一直在研究 DHTML，而在它被称为 ajax 之前，我一直在研究 ajax :) 我也一直在研究服务器端组件，这些组件自 2002 年以来就不需要更改，因为它们被编码为规范。

话虽如此，我已经亲身体验了我必须编写多少“优雅地失败”代码才能让这些反复无常的浏览器满意。无论如何，感谢您的所有回答，我想我又回到了实现“失败优雅”的代码。

背景

我对编程并不陌生，但是在处理客户及其需求方面我是新手。这是我与当前客户的历史：我继承了一个 PHP 应用程序，它已完成 2/3，继续使其 100% 完成，直到客户需要导致应用程序和数据库需要重写的（主要）功能。我花了两周时间起草新应用程序如何与新更改以及其他所需功能一起工作，在获得批准后，我再次开始构建应用程序。我现在被要求添加在新版本之前没有讨论过的新功能——而且，它们非常重要。此外，整个应用程序拥有 300 多个用户，这使得它变得更加困难。

问题

忽略客户要求最初未讨论的功能这一事实。如何使我构建的应用程序具有功能证明？在一个完美的世界中，客户会确切地知道应用程序应该具有哪些功能，这将使我的工作更容易完成。但事实并非如此，我所说的这些主要特性是在起草应用程序时应该包含的那些，而不是在应用程序上线时包含的那些——尽管这个问题对于未来对应用程序的任何修改或特性来说都是通用的。

我不喜欢告诉我的客户他要求的功能或更改非常重要，以至于我必须（再次）重写整个应用程序。但是，在写这篇文章时，我突然想到，如果不重新开始就无法添加该功能，这可能不是我的错。但这似乎几乎是他想要的任何新功能，因为有些东西已经为应用程序硬编码，现在更改它们以获得新功能是行不通的。

任何与这种情况有关的个人经历都会很棒——我希望我不是唯一一个处理这种情况的人，因为这可能会非常令人沮丧。谢谢！