有时使用正则表达式从HTML中提取一些内容是可以的。严肃地说，与迟钝的解析器争论，或者使用快速的正则表达式，如/<a href="([^"]+)">/?这并不是完美的，但是您的软件可以更快地启动和运行，并且您可能还可以使用另一个正则表达式来验证提取的匹配是否确实看起来像一个URL。当然，这很俗气，而且可能在一些边缘情况下失败，但对于大多数使用来说已经足够好了。

基于大量的“如何使用正则表达式获取HTML?”的问题，几乎每天都在这里发布，而且事实上每个答案都是“使用HTML解析器”，这应该是有足够的争议性的。

记录器配置是浪费时间。如果这意味着学习一种新的语法，尤其是一种无声地失败的语法，为什么要有它们呢?不要误解我，我喜欢好的伐木。我喜欢日志记录器的继承和向日志记录器的处理程序添加格式化程序。但是为什么要在配置文件中进行呢?

您希望在不重新编译的情况下对日志代码进行更改吗?为什么?如果您将日志代码放在单独的类、文件中，会有什么不同呢?

您是否希望将可配置的日志与您的产品一起分发给客户端?这不是提供了太多信息吗?

最令人沮丧的是，用流行语言编写的流行实用程序往往会按照该语言指定的格式编写良好的api。编写一个Java日志实用程序，我知道您已经生成了javadocs，我知道如何导航。为您的日志记录器配置编写一种特定于域的语言，我们有什么?也许有文件，但到底哪里去了?你来决定怎么组织，我对你的思路不感兴趣。

有时使用正则表达式从HTML中提取一些内容是可以的。严肃地说，与迟钝的解析器争论，或者使用快速的正则表达式，如/<a href="([^"]+)">/?这并不是完美的，但是您的软件可以更快地启动和运行，并且您可能还可以使用另一个正则表达式来验证提取的匹配是否确实看起来像一个URL。当然，这很俗气，而且可能在一些边缘情况下失败，但对于大多数使用来说已经足够好了。

基于大量的“如何使用正则表达式获取HTML?”的问题，几乎每天都在这里发布，而且事实上每个答案都是“使用HTML解析器”，这应该是有足够的争议性的。

.．.“澄清想法”不应该是开发者的唯一责任……是的，XKCD让我用了那个特定的短语…

我们经常会收到一些项目，这些项目都是在伪元类型特定的“代码”中指定的，如果你愿意这样称呼它的话。经常有产品经理为一个项目制定初始需求，并执行接近0%的基本逻辑验证。

我并不是说技术方法不应该由架构师制定，或者具体的实现不应该是开发人员的责任，而是说它应该是产品经理的需求，以确保他们的需求在逻辑上是可行的。

就我个人而言，我参与过太多“简单”的项目，这些项目在这里或那里遇到了一些范围渐变，然后遇到了与之前的需求相矛盾的“小”更改或功能添加——无论是含蓄的还是明确的。在这种情况下，要求做出近乎不可能的改变的人很容易对开发人员无法实现他们的梦想感到愤怒。

依赖管理软件弊大于利

我在Java项目中工作过，其中包括超过100个不同的库。在大多数情况下，每个库都有自己的依赖项，而这些依赖库也有自己的依赖项。

像Maven或Ivy这样的软件应该通过自动获取每个库的正确版本，然后递归获取其所有依赖项来“管理”这个问题。

问题解决了，对吧?

错了。

下载库是依赖项管理的简单部分。困难的部分是创建软件的心理模型，以及它如何与所有这些库交互。

我不受欢迎的观点是:

如果你不能口头解释，在你的头脑中，你的项目中所有库之间的基本交互，你应该消除依赖直到你可以。

同样地，如果列出从某个函数直接或间接调用的所有库(及其方法)所用的时间超过10秒，那么您在管理依赖关系方面做得很差。

您应该能够轻松回答“我的应用程序的哪些部分实际上依赖于库XYZ?”

当前的依赖关系管理工具弊大于利，因为它们很容易创建极其复杂的依赖关系图，而且它们实际上没有提供减少依赖关系或识别问题的功能。

我见过开发人员包含了10或20 MB的库，在项目中引入了数千个依赖类，只是为了消除几十行简单的自定义代码。

使用库和框架是很好的。但成本总是存在的，掩盖成本的工具本身就是有问题的。

此外，有时(注意:当然不总是)通过编写一些小的类来实现您所需要的东西比引入对大型通用库的依赖更好。

使用较短的变量名是可以的

但不是嵌套循环中的索引。