【问题标题】:Benefits of choosing Windows over Unix as development platform选择 Windows 而不是 Unix 作为开发平台的好处
【发布时间】:2009-02-01 00:15:42
【问题描述】:

Windows/Microsoft 作为开发时使用的平台,在 Linux 或 Solaris 等 Unix 方言上是否有任何技术优势?

我知道公司有时会选择 Microsoft,因为没有足够的了解 Unix 的程序员,或者这些程序员的雇佣成本要高得多。

所以假设所有开发人员都同样了解 Unix 和 Microsoft,是否还有一些情况下你最好在 Windows 中进行开发?

【问题讨论】:

  • 您是在问开发什么平台?或者开发时使用什么平台?

标签: operating-system platform


【解决方案1】:

对我来说,使用 Windows 作为开发平台只有两个论据:

  1. 您必须这样做,因为您正在进行 .Net/Windows 开发(或者因为公司根本没有让您选择);或
  2. 应用程序,特别是 Microsoft Office/Exchange。很抱歉,与 Word/Excel 相比,OpenOffice 很糟糕。

除了恕我直言,Linux 还有其他所有优势,包括:

  • 更快的文件系统(在处理大量小文件时尤其重要)。去年我通过这个开关从 8-10 分钟的构建时间变成了 2-3 分钟(相同代码库的蚂蚁构建);
  • 通常您的开发环境与您的生产环境相匹配(如果您的生产环境是 Windows,那么您的开发环境几乎可以保证是 Windows),这很有用。由于 Windows 和 Linux 上的 JBoss 之间存在差异,我们遇到了 Java 类路径可见性问题;和
  • 一套更好的命令行工具(是的,我知道你可以使用 Cygwin 等,但它不是那么好)。

这就是为什么我发现将 Mac 作为我的下一个开发工作站的想法如此吸引人的原因之一:您可以将其视为带有应用程序(即 Office)的 Unix 或带有像样文件系统的 Windows(如果/当 OSX 时会更好)采用 ZFS),无论哪种方式都是胜利。唯一真正让我反感的是,Apple 做了一些愚蠢的事情,比如将 Java 6 的发布推迟了一年,只是为了让 Leopard 的外观和感觉融入其中。

【讨论】:

    【解决方案2】:

    就在我的脑海中:

    • .NET(尽管单声道真的很棒)
    • Visual Studio - 可能是最好的 IDE
    • 优秀的文档(在我看来,MSDN 库比手册页对开发人员更友好)
    • 庞大的用户群(这更像是一项业务,但仍然是一个非常重要的因素)
    • 二进制兼容性(支持 4-5 个内核和标准 C 库版本比在 Linux 发行版中可以找到的无限组合要容易得多)

    【讨论】:

    • 我认为问题不在于目标平台;但是开发时使用的平台。因此,只有您的第二点是相关的。
    • Javier:即使问题是关于目标平台,我想你也会同意目标平台和开发平台并非完全无关。
    【解决方案3】:

    您能做的最好的事情之一就是让您的选择保持开放。选择独立于平台的技术,您将能够拥有适用于任何 O/S 或实施的软件。从技术角度来看,这很有意义,从商业角度来看也是如此。

    至于 Windows 平台的具体技术优势,除了大型开发人员社区和开发信息存储以及广泛支持的 IDE (如 Visual Studio)之外,我想说你很难找到一个。即使在那里,Eclipse 也可以使用独立于平台的技术来完成同样出色的工作。

    【讨论】:

      【解决方案4】:

      Microsoft 系统倾向于在不同部分之间进行更好的集成 - 如果您使用纯二进制软件(x86 和 comctl3d 比运行 *nix 的所有软件更容易支持),那么需要担心的异质性就会少得多。

      Windows 上的学习曲线一开始很浅,但总体距离较长。在 Unix/Linux 上,一开始是一个艰难的过程,但后来当操作系统的内部工作开始变得有意义时,完成工作变得更加容易。

      至少这是我对他们的体验。 Windows 用于快速回报,Linux 如果您打算做一些更长期的事情。和虚拟机,如果你不能决定:)

      【讨论】:

        【解决方案5】:

        我认为这个问题提出了错误的二分法。没有理由你必须选择 windows 而不是 unix,反之亦然。虚拟化是免费且简单的。这是两全其美!

        【讨论】:

        • 对于“必须测试资源管理器”问题尤其如此。在 *nix 上为 FireFox/Opera 开发,在带有 IE、Safari、Chrome、FireFox、Opera 的 VM 中进行测试。
        【解决方案6】:

        我们拥有 Windows 开发平台的一个原因(即使我们的生产是在 Linux 或 Solaris 上)是所有人的通用环境

        这意味着参与实现软件的所有不同人群:

        • 并非所有开发人员(业务、职能人员也关心工作环境)
        • 都在同一个平台上 (Windows)
        • 使用所有相同的工具进行书写/交流(如在 Word、PowerPoint 中)
        • 可以在笔记本电脑上拥有相同的环境

        简而言之:所有人(开发人员和非开发人员都一样)的环境一致性。


        另一个原因是折旧:很容易管理 PC 的折旧,因为这些服务比完整的 Unix 服务器(如 Sun Fire、F15K 或 F50K、.. .):后者需要一些昂贵的辅助服务合同(如“青铜”、“白银”或“黄金”,具体取决于所需的级别)。一台 PC 更容易修复/更换,开发人员“搞砸”它并使其彻底崩溃并不重要;)

        话虽如此,这样做的缺点是您不必每天都更换 PC:这意味着要管理大量台式机,您不能就这样决定升级(操作系统也是如此)。

        所以其他答案都是关于“虚拟机”的,而您的 PC 集是 2003 年的,只有 40Go 的硬盘驱动器和 1 个可能是 2Go 的内存......,您意识到“虚拟化”不是总是一个明显的解决方案。
        因此,开发人员需要一些 Unix“集成”服务器才能在更接近目标的环境中测试他们的产品。在某种程度上,这更好,因为这些集成服务器以统一的方式进行管理,避免了“它适用于我TM”的综合症,而不是虚拟机,每个开发人员都是自己的自己的小世界/服务器的根/管理员;)。

        【讨论】:

          【解决方案7】:

          我可以给你一个 Windows 人员可能会提出的常见论点,尽管我不一定同意。

          • 人们有时认为生产时的 Windows 机器更易于维护和部署。那是因为管理员可以使用很多可视化工具。因此,他们更喜欢 .Net 或特定于 Windows 的开发语言,以便于集成。

          • 如果您的客户或内部客户使用所有 Windows 台式计算机,有些人会争辩说使用 Windows 服务器做事的工作量更少。这包括 Microsoft Office 文档共享(即 sharepoint)或 Windows 文件共享的内容。显然,编写一个 .Net 应用程序来处理这种 Microsoft 特定的约束更容易。

          我真的想不出任何其他原因。后一种可能是最有效的——除非您使用 MSFT 开发工具,否则可能有一些特定于 Microsoft 的技术难以集成。

          【讨论】:

            【解决方案8】:

            某些特定类型开发的外围原因:

            • 您需要查看 Firefox 和资源管理器中的内容
            • 您正在使用闪存(AFAIK 您无法在 linux 上开发,而且播放器很糟糕)。
            • 您正在开展一个涉及 MS Office 集成的项目
            • 您的办公室有一些糟糕的邮件或便笺系统,您无法通过其他任何方式登录。同上一些 vpn 设置。

            我认为所有这些事情都令人遗憾。

            【讨论】:

              【解决方案9】:

              为什么不同时使用?

              在任何一种情况下,您都可以在 Windows 或 Linux/Unix 中使用虚拟机,而无需使用 Virtual Box 或 Vmware 播放器。或者您可以从您的开发箱远程桌面/vnc 到其他平台。如果您在 .net 中开发,您可能会在 Windows for dev 上做得更好。如果你为 LAMP 开发,Windows/*nix 都可以。

              【讨论】:

                【解决方案10】:

                给我 apache mysql (ok postgres in a pinch) php 和 eclipse .. 谁在乎操作系统 ..

                【讨论】:

                  猜你喜欢
                  • 1970-01-01
                  • 2010-09-21
                  • 2018-06-22
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  相关资源
                  最近更新 更多