意见:框架和第三方组件只能作为最后的手段。

我经常看到程序员立即选择一个框架来完成一项任务，而不学习它工作所需的底层方法。有些东西不可避免地会被打破，或者我们会发现我们没有考虑到的限制，我们会立即陷入困境，不得不重新思考系统的主要部分。只要经过仔细考虑，框架是可以使用的。

如果你想写出好的软件，那就离开你的电脑

去和最终用户以及想要和需要软件的人一起玩。只有从他们那里，你才能理解你的软件需要完成什么以及它需要如何完成。

询问他们对现有流程的爱与恨。 向他们询问他们的流程的未来，它的方向是什么。 出去逛逛，看看他们现在在用什么，弄清楚他们的使用模式。您需要满足并匹配他们的使用期望。看看他们还经常使用什么，特别是如果他们喜欢它并且可以有效地使用它。匹配。

最终用户根本不在乎你的代码有多优雅，也不在乎用什么语言写的。如果它对他们有效，他们喜欢使用它，你就赢了。如果它不能让他们的生活更轻松和更好——他们讨厌它，你就输了。

站在他们的立场上走一英里，然后去写你的代码。

清理和重构在(团队)开发中非常重要

A lot of work in team development has to do with management. If you are using a bug tracker than it is only useful if someone takes the time to close/structure things and lower the amount of tickets. If you are using a source code management somebody needs to cleanup here and restructure the repository quite often. If you are programming than there should be people caring about refactoring of the lazy produced stuff of others. It is part of most of the aspects some will face while doing software development.

大家都同意这种管理的必要性。而且它总是被跳过的第一件事!

不是工具的问题，是你的问题

每当开发人员尝试做一些新的事情，比如做UML图，任何类型的图表，项目管理，他们首先寻找完美的工具来解决问题。在无休止的寻找后，他们发现没有合适的工具，他们的动机就会枯竭。剩下的就是对缺乏可用软件的抱怨。这是一种洞察力，在没有软件的情况下，要组织的计划夭折了。

好吧，只有你自己在处理组织问题。如果你习惯了组织，你可以使用或不使用软件来完成(大多数人都不需要软件)。如果你不习惯组织，没有人能帮助你。

所以“没有合适的软件”只是没有组织的最简单的借口。

依赖管理软件弊大于利

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

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

问题解决了，对吧?

错了。

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

我不受欢迎的观点是:

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

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

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

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

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

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

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

没有闭包我也能活。

看起来现在每个人和他们的母亲都想在一种语言中出现闭包，因为它是自切片面包以来最伟大的发明。我认为这只是另一种炒作。