如果没有远程调试器，就无法编写web应用程序

Web应用程序通常将客户端和服务器端多种语言之间的交互联系在一起，需要用户进行交互，并且通常包括第三方代码，这些代码可以是简单的API实现，也可以是复杂的框架。

我已经记不清有多少次，当我用一个不错的远程调试器进入并跟踪一个复杂的web应用程序中实际发生的事情时，另一个开发人员坐在我身边，看到他们惊讶地发现有这样的工具存在。通常情况下，即使在看到这些工具的实际运行后，他们仍然不愿意费心安装和设置这些工具。

你只是不能用打印语句调试一个重要的web应用程序。如果应用程序中的所有代码都不正确，则乘以10。

如果您的调试器可以逐步检查所有正在使用的语言，并显示正在发生的http事务，那就更好了。

没有Firebug就无法开发web应用程序

同理，一旦你用过Firebug(或非常接近Firebug的东西)，你就会对那些试图开发web应用程序的人既同情又恐惧。特别是Firebug显示计算样式，如果你还记得不使用它，花了几个小时随机更改各种CSS位，并添加“!重要的”在太多的地方搞笑你永远不会回去。

I'd say that my most controversial opinion on programming is that I honestly believe you shouldn't worry so much about throw-away code and rewriting code. Too many times people feel that if you write something down, then changing it means you did something wrong. But the way my brain works is to get something very simple working, and update the code slowly, while ensuring that the code and the test continue to function together. It may end up actually creating classes, methods, additional parameters, etc., I fully well know will go away in a few hours. But I do it because i want to take only small steps toward my goal. In the end, I don't think I spend any more time using this technique than the programmers that stare at the screen trying to figure out the best design up front before writing a line of code.

我得到的好处是，我不必不断地处理那些因为我碰巧以某种方式破坏了它而不再工作的软件，并试图找出停止工作的原因和原因。

得墨忒耳定律，在聚合和组合的背景下考虑，是一种反模式。

编写完代码后再编写规格说明。(如果有的话)

In many projects I have been involved in, a great deal of effort was spent at the outset writing a "spec" in Microsoft Word. This process culminated in a "sign off" meeting when the big shots bought in on the project, and after that meeting nobody ever looked at this document again. These documents are a complete waste of time and don't reflect how software is actually designed. This is not to say there are not other valuable artifacts of application design. They are usually contained on index cards, snapshots of whiteboards, cocktail napkins and other similar media that provide a kind of timeline for the app design. These are usually are the real specs of the app. If you are going to write a Word document, (and I am not particularly saying you should) do it at the end of the project. At least it will accurately represent what has been done in the code and might help someone down the road like the the QA team or the next version developers.

Emacs更好

管理者无所不知

根据我的经验，经理通常不是通过了解代码来达到这个目的的。不管你怎么跟他们说，它太长了，不对或者太贵了。

还有一个是继第一个之后的:

没有时间把事情做对，但总有时间再做一遍

一位很好的工程师朋友曾经说过，他很生气地描述了这样一种情况:管理层把他的估计减半了，从他那里得到了一个半途而废的版本，然后给了他两倍的时间来返工，因为它失败了。在商业软件世界中，这是一件相当常见的事情。

今天在尝试配置一个只有web接口的路由器时，我想到了一个问题:

网页界面是为傻瓜准备的

上一个固件版本的CLI非常好。这个版本有一个web界面，试图从无知的IT机器人那里隐藏所有网络的复杂性，甚至不能得到正确的vlan。