高层架构到底层细节贴上软件工程

什么是软件工程师？什么是高级软件工程师？许多公司将“高级软件工程师”定义为作为程序员超过6年的人。但这并不总是正确的。

前几天，有人问我是建议成为“通才”还是“专家”。一个人是否应该专注于一项特定的技术，并真正精通它，还是做一点点任何事情。我曾经写虽然我仍然部分地持有这一观点，但需要加以阐述。

软件工程师的心态永远不会导致专家的狭隘。但这并不意味着你不会“钻研”一项特定的技术。实际上，您深入研究了许多特定的技术/框架/抽象级别。你变得精通他们，然后你继续下一个。可可能是从一份工作过渡到另一份工作，在那里，不熟悉的东西和已知的部分一起使用。随着时间的推移，你收集了足够的经验，每一项新技术都是熟悉的，而且你很快就会进入它。另一方面，长期专注于某一特定技术并不能让您看到解决问题的所有可能方案。所以没有，主要做jQuery/Rails/Spring/android/…15年并不能使你成为一名“高级软件工程师”。

软件工程师的思维方式是解决问题。你越年长，你就越快找到更简单的解决方案。你熟悉的技术越多，你就越能生产出更多的非本地化解决方案--比如，在一个多技术项目(web、android和IOS前端，带有java后端、公共api)--一个在一种特定技术中看起来不错的解决方案，可能在其他技术中是一种攻击。

软件工程师的心态并不是说“我不知道，另一位同事在做这件事”。我在面试中得到了这样的答案--人们甚至一直在执行JSR规范，并且只知道他们在过去两年中所从事的工作。软件工程师应该关注的是如何与其他人相适应。

这不是建筑师的角色吗，有些人可能会问

也许我试图把我喜欢做的事情(深入应用程序的所有部分，从高层架构到底层细节)贴上“软件工程思维”的标签。也许我只是添加了另一个同义词“全堆栈开发人员”陈词滥调。无论如何，我认为鼓励人们看到更广泛的技术前景是好的，鼓励他们花时间关注特定的问题和技术也是同样重要的。否则，他们可能会成为那些建筑师和老年人之一，他们假装知道很多，但实际上还没有看到复杂的细节。魔鬼就在细节里。软件工程师两者都有。

https://www.imdb.com/list/ls082556538/

是最近用于编写Web应用程序的一种方法(和/或宣言)，希望这种方法非常流行。虽然我不完全同意这些建议，但我会迅速地考虑所有的12个因素

，并根据Java生态系统来讨论它们，并提到绝对的“必须”和我不同意的要点。有关更多信息，请访

1. 代码库-一个代码库，多个部署。这意味着您不能拥有不同版本的各种代码基。分支机构没问题，不同的回购不是。我甚至会更进一步，不推荐颠覆。并不是因为这样不好，而是因为git和mercurial做了同样的事情，而且做得更多。您可以以使用SVN的方式使用git/mercurial，但不能反过来使用git/mercurial。用于DVCS的工具(例如SourceTree)已经相当好了
2. 相依性-显然，您必须将尽可能多的依赖项放在您的清单中(例如pu.xml)。宣言建议不要依赖预先安装的软件，例如ImageMagick或Pandoc，但我不会那么严格。如果您的部署是自动化的，并且保证了给定工具的存在，那么您不应该花费数天的时间试图将其封装在工作语言库中。如果它像在JAR文件中放置一个可导出的脚本一样容易，然后再提取它，那就好了。但是，如果它需要安装，而且您确实需要安装它(ImageMagick确实是一个很好的例子)，我不认为期望它被安装是错误的。只要检查启动是否存在，如果不存在，请快速失败。
3. 配增长。但他们不必这么做。您可以完全按照管理环境变量的方式更改属性文件中的值。
4.  
5. 并发性-这是关于使用本机进程的。我认为这与Java运行时无关，Java运行时使用隐藏Unix进程的线程。顺便提一句，另一个对Unix的明确引用(而不是保持OS无关)。
6. 可处置性-那是关于拥抱失败的。即使一个或多个应用程序实例死亡，您的系统也必须正常工作。这肯定会发生，尤他们提到了SIGTERM，这是一个特定于*nix的信号，而12因子应用程序的一般想法是独立于操作系统。有一个明显的倾向，Linux，但这一种构建应用程序的方法，考虑到上面的评论。

http://www.itangyuan.com/book/16340329.html

事件(或消息)驱动的系统(在它们)有一些好处。我已经讨论过为什么我认为但这不是我现在要写的。

我将(非常简短地)写关于“依赖”和“耦合”的文章。当我们消除编译时依赖关系时，我们似乎消除了组件之间的耦合。例如：

https://www.yousuu.com/booklist/614c457c10315a7c17fcf485

1 2 3 4 5 6

class CustomerActions {   void purchaseItem(int itemId) {     //...     purchaseService.makePurchase(item, userId);   } }

VS

1 2 3 4 5 6

class CustomerActions {   void purchaseItem(int itemId) {     //...     queue.sendMessage(new PurchaseItemMessage(item, userId));   } }

看起来好像你的CustomerActions类不再依赖于PurchaseService。它不在乎谁来处理PurchaseItem留言。一定会有PurchaseService它将处理消息，但前一个类在编译时没有绑定到它。这看起来像是“松耦合”的一个很好的例子。但事实并非如此。

首先，这两个类首先可以松耦合。一个与另一个交互并不意味着它们是耦合的--它们可以独立地进行更改，只要PurchaseService维护其合同makePurchase方法