这个问题让我感到有趣的是，我刚刚读了答案的第一页，到目前为止，我还没有发现一个有争议的观点。

也许这更能说明stackoverflow产生共识的方式。也许我应该从最底层开始。: -)

在开始构建电子系统之前，每个开发人员都应该花几周甚至几个月的时间来开发基于纸张的系统。他们还应该被迫使用他们的系统。

开发一个好的基于纸张的系统是一项艰苦的工作。它迫使你考虑人性(繁琐的过程会被忽略，过于复杂的过程往往会崩溃)，并教会你欣赏简单的价值(新工作放在这个托盘里，QA工作放在这个托盘里，存档放在这个盒子里)。

一旦你弄清楚如何在纸上构建一个系统，构建一个有效的计算机系统通常会容易得多——一个人们实际上想要(并且能够)使用的系统。

我们开发的系统并不是由一群训练有素的自动机控制的;真实的人使用它们，真实的人由经理培训，经理也是真实的人，没有太多的时间浪费在培训他们如何跳过你的圈子。

事实上，关于我的第二点:

每个开发人员都应该被要求进行交互式培训课程，向用户展示如何使用他们的软件。

从长远来看，不需要探索所有形式的测试，QA也可以做得很好

很多地方似乎都有一种“方法”，即“我们怎么做”。这似乎隐含地排除了其他方法。

从长远来看，这是一个严重的问题，因为QA的主要功能是将错误归档并修复它们。

如果你不能找到尽可能多的bug，你就不能很好地做到这一点。例如，当您排除方法时，由于过于依赖黑盒，您开始忽略整个可发现的编码错误类别。这意味着，您正在使整个编码错误类无法修复，除非有人偶然发现它。

潜在的问题似乎往往是管理层+员工。有这个问题的管理者似乎对计算机科学和/或他们团队的价值主张有狭隘的想法。他们倾向于创建反映他们的方法的团队，以及测试方法的白名单。

我并不是说你可以或应该一直做所有的事情。让我们面对现实吧，对于给定的产品来说，一些测试方法只是在浪费时间。有些方法在产品成熟度的特定级别上更有用。但我认为，测试组织缺少的是挑战自己学习新事物的能力，并将其应用于整体绩效。

这里有一个假设的对话可以总结:

我:你测试了启动脚本10年，却对shell脚本及其工作原理一无所知?! 测试人员:是的。 我:权限? 测试人员:安装程序会这样做 我:平台，发布特定的依赖? 测试者:我们为此存档bug 我:错误处理? 测试人员:当错误发生时，客户支持会给我们发送一些信息。 我:好吧…(开始考虑在stackoverflow中写帖子…)

UML图被高度高估了

当然有一些有用的图，例如复合模式的类图，但是许多UML图是绝对没有价值的。

许多开发人员对在哪里放置东西没有充分的认识，导致在文件、类和方法级别上源代码组织混乱。此外，相当一部分这样的开发人员基本上对代码组织问题一无所知。试图教导、哄骗、威胁或羞辱他们保持代码干净是徒劳的。

在任何一个非常成功的项目中，通常都有一个开发人员，他有良好的组织意识，非常安静地对代码库进行扫把，以防止混乱。

管理者无所不知

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

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

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

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

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

网页界面是为傻瓜准备的

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