两个重要而又容易被忽视的角色

本文强调了Web前端工程师和产品工程师在网站开发中的关键作用,指出许多中小型企业忽视这两个职位,而它们对于提升用户体验和优化资源利用至关重要。

  我敢打赌,在中国,一半以上甚至更多的,以网站为主营业务的或者把网站很看重的公司,没有Web前端工程师和产品工程师这两个职位,甚至有些有点规模的公司也可能没有这个职位,当然,这不能包括像alibaba,sina,163这样的公司,只是指中小型公司而言。如果你们公司有,请给我留言告诉我你们公司的规模和相关的信息。

  做得好一点的公司,一般是项目经理/部门主管+投资方(项目管理中的投资方,实际上就是老板,反正就是决定你要做什么并给你钱的人)来承担产品工程师的角色,由美工来承担Web前端工程师的角色,特别是Web前端工程师,是最容易被忽略的角色。

  企业想挤出利润,无非两个方面,一个是开源,另一个是节流。而这两个角色,恰恰可以用开源节流来比喻,产品工程师可以设计出更好的产品,这就是开源,Web前端开发工程师可以精简网页代码,提高用户访问速度,减小企业带宽上的支出,甚至可以减小服务器上的支出,这不是节流是什么?相比有些企业,以靠克扣员工工资来实现节流,这个节流要节省得多。

  产品工程师

  很多公司的流程基本上是这样的,由需求部门(一个或者多个,如果公司小,可能就是老板等几个人)提出需求,提交到项目经理或者IT部门主管,然后 IT部门主管根据需求进行开发,这中间可能要判断是做还是不做,判断的依据主要是开发难不难,麻烦不麻烦,很少去考虑合不合理。各位,看到什么问题没有,很多IT的部门主管,他只是一个管理者+项目经理的组合,或者干脆就是一个项目经理。需求部门交给我的需求,我按照要求按时按质做完就OK了。但时,需求部门往往是不懂互联网的,这种情况很多公司大量存在,对于一些老板本身就是做互联网的,或者较大的公司,这种情况会比较少。

  问题就来了,一个不懂互联网的人,根据自己的喜好或者自己的判断来提出一些需求,有些需求可能很无理,有些时候可能是自己的喜好,有些时候可能是违背互联网的基本准则的。而技术部门往往是只要没有技术难度就开发吧,反正我就按你要求做了,这个中间,没有一个懂互联网的人来把关。注意,懂互联网的人,不是懂技术的人,懂技术的人很多都是不懂互联网的。比如说我曾经见过有公司的老板要在网站的两边加一副对联,结果别人说像灵堂一样,也曾经有公司的老板要把网站做得像电视一样(不是视频网站,就是一个非常酷的过场动画这样子,想法是好的,可惜不适合大型网站,不利于访问也不利于SEO)。

  这个时候一定要有一个产品工程师或者产品组来承担这个中间人,注意,还没有到美工的层面,他需要根据需求方的需求,再加上自己对互联网的了解,来设计这个产品。他要考虑到浏览器、带宽、用户习惯等等内容,以确定如何布置页面中的内容,确定功能之间的关联。在这个时候,如果产品工程师不懂技术,可以邀请Web前端工程师和项目经理/部门主管参与,因为某些地方为了用户体验可能要使用到一些技术,需要由这些人来确定是否要行。

  Web前端工程师

  相对于产品工程师,这个职位显得很加缺乏,因为产品工程师很多时候可以由项目经理或者部门主管兼任,但Web前端工程师这个职位,是很多公司都不重视的职位,很多公司是这样的,Html和CSS由美工负责,而Javascript由程序员负责。但问题是,很多美工对Html/CSS只能实现,至于规范也速度很少考虑,而程序员对Javascript就更加了,从我接触过的程序员中,绝大多数人觉得Javascript是一个比较简单的语言,没什么前途,看不起这种语言,也认为Javascript只能实现一些交互而已。

  所以实际上,很多企业是用两个懂一点点的人,来做这个重要的工作。如果让我来选择,我愿意放弃一个,甚至两个程序员,来换一个Web前端工程师。为什么要这么做?我认为,一个网站两个非常重要的地方,就是他的交互性与速度。很多程序员喜欢划分前台与后台,他们都认为前台不重要,只要后台功能完成了,前台不是很简单的事么!不!不是这样的,前台比后台重要,为什么这么说?你想想,一个用户是通过什么接触到你的网站的,是前台,是Web页面,而不是后台冷冰冰的程序。你有再强大的功能,如果用户操作起来很复杂,那么用户也会抛弃你的,除非用户别无选择,比如说工信部的备案,但问题是,现在互联网同质化越来越厉害,抄袭也变得风行,你真的有这么高的技术壁垒让其它公司没有办法做到和你一样的产品么?

  注意,不要钻牛角尖,我并非说后台完全不重要,你要非说就算你前台再好,我后台一个死循环出不来,那不是也没戏,这是抬杠!除了大型网站和逻辑错误,现在多数网站并不存在后台影响速度的问题,或者说影响不是那么明显。前台所带来的问题,要比后台带的问题多得多,也容易解决得多,往往是可以花少量的代价来解决大问题的,可是往往很多企业愿意去花钱买带宽买服务器租CDN以提高速度,却不愿意请一个Web前端工程师来解决这个问题。同时,请注意,就算你服务器再快你的带宽再高,用户的带宽是不变的,如果你超出了用户带宽的阀值,你所做的一切将都是豪无意义的。

  程序员往往可以实现Javascript的功能,但是由于Javascript的特殊性,他们很难以最优化的方式来开发Javascript代码,就可能就造成他们去网上Copy一段Javascript,然后只要实现效果即可,大量重复的甚至是有Bug的代码被应用到网站中,这些代码将会影响到用户的执行效率,降低用户体验。在HTML方面,这也是程序员的弱项,他们也觉得这个东西太简单,实现起来很容易,但是HTML和Javascript都是入门易深入难的东西,如何合理地组织Html+CSS,让浏览器更快更有效率地执行,这个也是需要很多年的经验的。

  在用户体验方面,大公司可能用UE/UI等部门,而小公司的话,一定要有Web前端工程师,美工只是设计页面,很难照顾到用户体验这个层面,当然不排除有些美工已经有这样的水平。实际上用户体验也和产品设计一样,都属于开源的一部分,因为如果用户体验好就能带来更多的用户,不是开源是什么。

  最后,我想分析一下造成这两个职位被忽视的原因,产品工程师一职,往往被项目经理或者部门主管+投资人代替了,一般来说,做到主管级的人对行业多多少少算比较了解,所以这个职位的缺失可能不会带来大问题,但也有时候会因为这个职位的缺失而导致项目失败的安例发生,这就要求主管同时也要有产品工程师的能力。

  Web产端工程师是最容易被忽略也是最不好招聘的职位,究其原因,是因为部门主管往往是做技术出身的,而技术人员常常会轻视或者忽视前台的工作,也正是这个原因,造成了Web前端工程的工作比较低,所以很多人不愿意去做这个职位,我就常常看到新人如果让ta学习Html/CSS /Javascript,ta就会问你,什么时候我才可以真正编程啊,这样就形成了一个恶性循环,企业不重视,工资上不去,程序员也就不愿意学习了。然后,这个职位可以给公司省下非常高的费用,可以节省数个程序员,减少带宽及服务器。不信?试试看吧!

 

  来源:涂雅投稿,原文网址,转载请保留此链接,否则视为侵权。

<think>嗯,用户正在深入研究SpringBoot中的特定注解,特别是@NotEmpty和@NestedConfigurationProperty。用户可能是个Java开发者,正在进行项目开发或学习,遇到了配置验证的需求。ta的问题很具体,说明对框架的理解已经到中级水平。注意到用户特意引用了四个技术文档片段,其中三个都提到spring-boot-starter-validation依赖,一个展示了@Valid的用法。这说明用户实际需求可能更偏向于验证相关的@NotEmpty而非纯配置的@NestedConfigurationProperty。但ta同时问两个注解,可能有配置绑定的综合需求。关于@NotEmpty:准备先说本质——它来自JSR-380标准而非Spring特有,这点很重要但容易被忽略。结合引用[2][4],需要强调在DTO验证时配合@Valid的流程:实体类字段加注解→Controller参数用@Valid→BindingResult处理错误。引用[4]的controller示例特别适合说明实际开发中的错误处理逻辑。对于@NestedConfigurationProperty:这个冷门得多,用户可能是在读配置文件时遇到的。要重点说明它解决的结构化配置问题,比如把application.yml中的嵌套属性映射到Java对象。补充代码示例很重要,因为Spring文档对此描述很简略。安全问题突然想到:用户没问但应该提醒的是,用@NotEmpty时注意空字符串和空集合的区别,因为有些开发者会混淆。最后的相关问题设计:1和3题紧扣用户引用的验证场景,2题针对ta额外问的配置注解。这样能覆盖ta可能的后续需求。</think> 好的,我们来详细解释 `@NotEmpty` 和 `@NestedConfigurationProperty` 这两个注解在 Spring Boot 中的含义、作用和使用场景。 --- ### 一、`@NotEmpty` 注解 1. **作用:** * 该注解用于**验证一个字段的值不能为空(not empty)**。它通常用在 Bean 验证的上下文中。 * 它会对目标应用以下约束: * 对于 `String`:长度必须大于 0(不能是空字符串 `""`)。 * 对于集合(如 `Collection`、`Map`、数组等):必须包含至少一个元素(不能为空集合)。 * 对于其他类型(如 `Integer`, `Long`)通常是无效的,因为无法应用“空”的概念(它们可能是数值 `0` 或 `null`)。 * 特别注意:它**不会**检查值是否为 `null`(这是 `@NotNull` 注解的职责)。它只检查在值存在(非 `null`)的前提下,是否是空字符串或空集合。 2. **来源:** * `@NotEmpty` 是 Java Bean Validation API (JSR 380) 规范的一部分,由 `javax.validation.constraints` 包提供。 * Spring Boot 通过引入 `spring-boot-starter-validation` 依赖(如你在引用[2], [3]中看到的)来集成并启用此功能。 3. **使用场景:** * **表单提交数据验证:** 确保用户在表单中必须填写某个字段(例如用户名、邮箱),而不仅仅是空格或空值。 * **API 请求参数验证:** 确保 API 请求体(例如 JSON 或 XML)中的特定字段存在且不为空,特别常用在 `@RequestBody` 中(如引用[4]所示)。 * **数据库实体字段验证:** 在数据持久化之前,保证关键字段(非数据库 `NOT NULL` 约束的代码级补充)的有效性。 * 需要确保一个列表或数组至少包含一个元素才能进行后续处理时。 4. **用法示例:** ```java import javax.validation.constraints.NotEmpty; public class User { @NotEmpty(message = "用户名不能为空") private String username; @NotEmpty(message = "角色列表不能为空") private List<String> roles; // Getters and Setters... } ``` 在你的 Controller 中(如引用[4]所示): ```java @RestController @RequestMapping("/users") public class UserController { @PostMapping public ResponseEntity<User> createUser(@Valid @RequestBody User user, BindingResult result) { if (result.hasErrors()) { // 处理验证错误(如引用[4]所示),返回错误信息(例如 "用户名不能为空") ... return ResponseEntity.badRequest().body(...); } // 处理有效请求 ... return ResponseEntity.ok(savedUser); } } ``` **关键点:** * 在字段上添加 `@NotEmpty`。 * 在 Controller 的方法参数中,对需要验证的对象(如 `User user`)添加 `@Valid` 注解(或 Spring 的 `@Validated`)。 * 使用 `BindingResult` 参数(紧随 `@Valid` 参数之后)来检查和处理验证错误。 --- ### 二、`@NestedConfigurationProperty` 注解 1. **作用:** * 该注解的主要作用是为 Spring Boot 的 **外部化配置(如 `application.properties`/`.yml`)绑定到配置属性类** 提供 **元数据提示(metadata hints)**,特别是在属性类中包含其他配置类(嵌套配置)时。 * 它本身**不强制执行任何运行时逻辑或验证**。它的目的是帮助 Spring Boot 的 **Configuration Metadata** 处理器(在编译时或通过 `spring-boot-configuration-processor` 依赖)理解配置属性的结构。 * 简单来说:它告诉 Spring Boot,“这个字段不是一个普通的值类型(如 `String`, `int`),而是一个 **嵌套的、本身也是配置属性类** 的对象”,使得在 IDE 编辑配置文件(如 `application.yml`)时,可以自动提示(代码补全)这个嵌套类的属性。 2. **来源:** * 该注解由 Spring Boot 提供,位于 `org.springframework.boot.context.properties` 包下。 3. **使用场景:** * 当你的 `@ConfigurationProperties` 类**包含对其他自定义配置类(也通常是 `@ConfigurationProperties` 类)的引用**时。 * 当你希望 IDE 或者 `spring-configuration-metadata.json` 文件能够正确地**理解和描述这个嵌套配置结构**时。 * 主要用于**改善开发体验(如 IDE 自动补全)和配置属性文档生成**。 4. **用法示例:** 假设我们有两个配置类: `ServerProperties.java` (嵌套配置类): ```java @ConfigurationProperties(prefix = "server") public class ServerProperties { private String host; private int port; // Getters, Setters... } ``` `AppProperties.java` (主配置类): ```java @ConfigurationProperties(prefix = "app") public class AppProperties { private String name; // 关键用法:标注这个字段是一个嵌套的配置属性 @NestedConfigurationProperty private ServerProperties server; // ServerProperties 本身也是一个配置属性类 private String description; // Getters, Setters... } ``` 在 `application.yml` 中使用: ```yaml app: name: My Application description: A demo app server: # <-- IDE 可以基于 @NestedConfigurationProperty 提供 host 和 port 的自动补全 host: 127.0.0.1 port: 8080 ``` **关键点:** * 在主配置类(`AppProperties`)中,对嵌套配置类(`ServerProperties`)类型的字段添加 `@NestedConfigurationProperty`。 * 确保嵌套类(`ServerProperties`)本身也被注解为 `@ConfigurationProperties`(`prefix` 可以在父类或本类设置)。 * 这个注解通常是可选的,但加上它能**显著改善复杂嵌套配置在 IDE 中的支持和元数据生成的准确性**。没有它,IDE 可能无法推断 `app.server.host` 和 `app.server.port` 是有效配置项,无法提供自动补全。 --- ### 总结对比 | 特性 | `@NotEmpty` | `@NestedConfigurationProperty` | | :---------------- | :---------------------------------------- | :---------------------------------------- | | **目的** | **运行时数据验证** (值不能为空字符串/空集合) | **提供配置元数据提示** (支持嵌套配置绑定) | | **来源** | JSR 380 (Java Bean Validation API) | Spring Boot | | **作用域** | 字段或方法参数 | 字段 | | **是否执行验证** | 是 | 否 (纯元数据注解) | | **依赖** | `spring-boot-starter-validation` | (隐式包含) 但需 `@ConfigurationProperties` 支持 | | **主要使用场景** | Controller 参数验证、表单验证、业务规则检查 | 配置属性类(`@ConfigurationProperties`) 的嵌套结构定义 | | **对 IDE 影响** | 不明显 | 显著改善 `application.properties/yml` 的自动补全 | 通过理解这两个注解的不同定位(数据验证 vs. 配置绑定辅助),你可以在 Spring Boot 项目中更准确地应用它们:`@NotEmpty` 用于保证数据的完整性,而 `@NestedConfigurationProperty` 主要用于提升复杂配置定义的开发体验[^1][^2][^3][^4]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值