0

它可以像单行脚本一样简单，也可以像带有解析器和调试器的完整编程语言一样复杂。

但是创建一个节省劳动力的工具有一个众所周知的危险，它比最初的任务需要更多的劳动力来创建（除非你可以将它分摊到多个项目中）。

我担心被这个次要项目冲昏了头脑，试图使它完美，并扩展它......而主要项目却萎靡不振（例如：Knuth 花了数年时间写“计算机编程的艺术”来创建 TeX帮他排版）。

我不是在考虑标准的支持/开发工具，例如构建工具、测试系统、错误跟踪器和源代码控制，而是您为特定项目创建的工具，以支持您自己的开发，只有开发人员才会使用（即它不是项目的可交付成果）。

4

3 回答 3

3

很容易沉浸在工具创建的乐趣中。我们试图通过查看我们需要编写的工具来管理它，花费一些体面的时间寻找我们可以使用或屈服于我们意愿的开源，然后才诉诸自己的滚动。我们也将其作为零迭代、练习、冲刺和 Scrum 来执行 - 如果一个工具需要超过一个冲刺（2 周），它就太大了。

于 2009-03-18T10:50:25.570 回答
1

这简单。

从编写用例（或用户故事）开始。确保包括运营和支持人员以及最终用户。

然后构建软件以交付用例。

任何“支持/开发工具”都必须是用例的一部分来证明它的合理性。

编辑在编码支持方面，成本/收益很简单。构建代码生成工具的成本与项目的净节省成本是多少？开发人员工具很少有价值。软件长期运行支持；它只是在很短的时间内开发。你可能会花 2 年时间来开发它；客户可能会花费 10 年或更长时间来运营它。节省几个月的开发时间通常是无关紧要的。

这里的所有都是它的。

请记住，支持和帮助台是一流的用户。支持用例必须与最终用户用例一起混合。用例根据需要进行优先级排序和构建。在某些时候，可操作性考虑必须优先于用户功能。

例如，我们刚刚完成了几个页面，这些页面仅供运营（和可能的服务台）人员使用，以帮助客户完成一项特别重要的交易。

很少需要编写新的基础架构（语言、编译器、调试器、操作系统、RDBMS、ESB 等）。

然而，编写新协议以及相关的客户端和服务器通常是必要的。并非所有事情都可以通过使用 ODBC/JDBC 数据库连接的桌面软件轻松解决。同样，并非一切都是基于 HTTP 的 Web 应用程序。

发明一种新的编程语言就是让你的爱好接管你的工作的一个例子。如果您无法使用TIOBE 索引中的前 50 种语言中的一种，那您只是在玩。

于 2009-03-18T11:12:21.477 回答
1

感谢您的提问！回复很长，很晚，但希望值得一读。

约定

我将这些临时工具称为“脚手架”，类似于建筑行业，在制造业中，它们通常被称为“夹具和固定装置”，如果您更喜欢学术上听起来更响亮的名称，它是“工具和生产技术”。

“正确的方式

似乎可以通过简单的成本效益分析来确定是否投资脚手架的决定（正如项目管理科学所拥有的那样）：估计开发成本，与预测的收益进行比较，以及脚手架的价值是否更大比建造它的成本有一个好处：

COST               BENEFIT
Spec         £500  Time saved over 2 years £3000
Development £2000  Savings on training      £600
Total:      £2500                          £3600

好吧，但是如果一个类似的工具已经现成可用，但没有提供完全所需的功能，因此没有提供相同水平的好处怎么办？该分析得到了一个额外的维度“购买与构建”（请注意，对于许多社区工具，它只是免费的许可成本，许多其他费用仍然适用，因此这些工具需要在“购买”类别下进行评估）：

       COSTS              BENEFIT
BUILD  Spec         £500  Time saved over 2 years £3000
       Development £2000  Savings on training      £600
       Total:      £2500                          £3600

BUY    License      £500  Time saved over 2 years £1000
       Setting up   £500  Savings on training      £300
       Total:      £1000                          £1300

显然，现成的工具更便宜。然而，它的投资回报率 (ROI) 仅为 30%，而对于自己动手的解决方案则为 44%。

好吧，如果事情就这么简单就好了，因为在现实生活中，实际成本和收益很难提前识别和量化。您如何量化开发人员在脚手架上工作而不是项目可交付成果的机会成本？或者在脚手架中包含一些生产知识的好处，这样新的初学者就不必花时间学习手动构建或发布过程？或者任何人都能够在不到半小时的时间内一步构建任何版本的软件，而不是高级开发人员花费大部分时间来完成任务的好处？

此外，预测数据和实际数据之间不可避免地会存在一些差异，预期差异（也称为“风险”）越大，您就越不能依赖这些数据来实现。风险为我们的分析提供了第三个维度，并且考虑到一些成本和收益完全取决于整个成本收益情况，它们真的开始失控了。

实用方法

我相信有更简单的方法。与其尝试将脚手架视为一项资本投资并量化未来几年的成本和收益，不如尝试评估当前情况并采取更灵活的方法，即：

  • 自动执行任务会比手动执行任务花费更长的时间吗？

  • 一项任务能否在没有脚手架的情况下可靠地完成，并且不需要高度专业化的人才或超人的能力？

  • 成本是否超过在不久的将来可以提取的收益？

如果有任何答案为“否”，那么您最有可能在脚手架上进行投资会更好。

一些笔记

还有一些事情要记住：

  • 脚手架是高度特定的、临时的，有时甚至是一次性的。避免以与处理应用程序或组件相同的方式进行开发的陷阱，脚手架本质上更接近工作原型。请记住，编写一个涵盖相同功能的应用程序将花费大约 10 倍于脚手架脚本的资源，而编写一个通用组件将花费 10 倍于应用程序的工作量。Benji Smith 在他的创造性爆发“我为什么讨厌框架”中对这一点做了一个精彩的说明。工具应该作为实现目标的手段，但本身并不是目标。

  • 脚手架应与应用程序分开；它并不是真正的可交付成果，在大多数情况下不应替换旨在维护和配置的应用程序部分。

  • 拥有定制脚手架在竞争中具有真正的优势：

    • 加快发展。

    • 避免重复工作。

    • 减少对准确性和魔法超能力的需求，这些超能力通常供不应求且非常昂贵。

    • 减少人为错误。

    • 提供结果的一致性。

    • 赋予以所需的确切方式做事的能力（与现成的工具相反）。

    • 有助于在团队中保存知识（它永远不会退出，并且总是可以进行逆向工程）。

    • 提高士气，因为开发人员不必将时间花在平凡的任务上。

  • 通过粗略的非关键解决方案脚手架可以作为新工具、技术、技术、想法的试验场，这些工具后来可以成为杀手级应用程序的基础（FogBugz是最初开发的内部工具的一个很好的例子测试 FogCreek 创始人关于处理软件问题的正确方法的假设，因为他们坚信必须以任何 COTS 工具都不支持的精确方式完成。众所周知，后来脚手架被利用成为独立旗舰产品）。通过搭建脚手架，您可以创造知识产权。

  • Test Driven Development (TDD) is a notable and practical way of building scaffolding for testing. TDD provides some excellent guidelines on “when enough is enough” that can be extended on other bespoke tools.

于 2009-05-06T15:54:39.353 回答