Hello everyone, I'm back again. From now on, I want to share with you my experiences of being alive, as well as my 12 years in Spring and my 2-month survival journey in this field. Previously, while creating this material, I shared it through SlideShare and my code is now available on my YouTube channel. The content we are going through today is being recorded and will be made public after it is organized, so I hope you keep that in mind. 

Now, let's get started with the session I have prepared. Before that, let me briefly introduce myself. I currently work as a server developer in the community team of a local gathering at the Damgeum market. One of my key features is that most of my career has been focused on developing enterprise software based on Java and Spring.

The point is that it is packed. So today, in this session, I want to share with you the experiences of a developer familiar with Java and Spring, exploring the characteristics of hotel information and the support provided by the Spring ecosystem step by step. Before we get started, let me tell you about the content I have prepared. Today, I will be discussing three main topics. As I present my story, I will be using a lot of code. Unfortunately, from the perspective of Java and Kotlin, as well as the support from the Spring ecosystem, I found it necessary to explain things using code. So, if you try to read through all the code individually, it might be quite challenging for you to enjoy the session. When I need to refer to the code, I will...

I'll provide you with enough time, so you just need to focus on the code during that time. Otherwise, I would appreciate it if you could listen to what I'm saying comfortably. 

Now, let's take a look at the topic. Please feel free to engage. In 2016, I happened to read an article about Kotlin. The title was I tried using Kotlin for Android development, and it was the best. I thought, Is this Kotlin a new language? It's a language that runs on the JVM, and I realized that I could also use Spring with it. I have a memory of creating a simple project at that time. While making the project, I found many aspects of Kotlin that I really liked, particularly its language features.

I felt that, of course, there were some inconveniences at that time. However, despite that, I thought that if given the opportunity, I would like to use it at a production level. In 2016, after a year, in 2017, Google officially added Kotlin as a programming language for Android. I also remember that the Spring team officially announced support for Kotlin in Spring 5 around that time. I believe that during that period, as I created toy projects and became interested in Kotlin, I searched for related resources. Although it wasn't publicly visible, I found that many of the contributors from the Spring team stood out. They were probably involved in Kotlin.

I remember that a lot of effort was put into trying to integrate this Spring framework well. So, regarding Kotlin, I thought it would be good to read some philosophy and explore the linguistic characteristics of Kotlin. I have prepared a brief overview. Kotlin introduces itself as practical and concise, focusing on interoperability with Java. This content is from the book Kotlin in Action, which I understand was written by several developers who created Kotlin. It seems that Kotlin's interoperability with Java demonstrates nearly 100% compatibility. Additionally, the background of how the Kotlin language was created comes from the process of developing tools for their company, IntelliJ.

I believe that we need to write code more efficiently and create tools, and I remember that we progressed while developing the language. Now, I would like to discuss an important part of today's content, which is about simplicity and safety. 

Let's first look at simplicity. As developers, we actually spend more time maintaining existing code than writing new code. Therefore, the simpler and more concise the code is, the easier it is to understand. There are several factors that contribute to making code concise, and one of them seems to be the simplicity of the language itself. When a language is simple, it allows us to easily grasp the intent of the code written in that language, providing a clear and easily understandable syntax structure to achieve that intent.

To understand the methods available, we can consider the necessary disruptive elements, meaning the additional code-related elements. In that sense, I believe that from the very beginning of its creation, programmers have made significant efforts to reduce meaningless parts or ancillary elements in the code. For example, when using a data class, methods such as getters, setters, equals, and toString are automatically generated. In Java, these functionalities often require the assistance of external tools, like Lombok, but in this language, they are supported at the language level, allowing for less code to be written while still achieving the intended purpose. Another point to consider is that the standard library provides a rich set of APIs.

We can achieve our goals in a more concise manner with a cheering style. Lastly, we can also write the code more simply by using various syntax sugars, which are known as syntactic sugar. If the code is more concise, it tends to take less time, and importantly, it also reduces the time for 1n. I believe that the second lecture can significantly enhance a developer's productivity and allow for faster development. Now that we've discussed conciseness, let's explore stability. To prevent various errors that may occur during surfing, we incorporate several codes in advance. Through these, we can ensure stability. Furthermore, to secure greater safety...

Many defensive codes are needed; therefore, obtaining greater stability can be interpreted similarly to saying that we need to add more various codes to the program. This means that as we write more code, we have to accept a decline in productivity. In other words, there seems to be a bit of a trade-off relationship between stability and productivity. In the context of Eco, while pursuing safety, it also provides many ways to reduce the costs associated with this trade-off. A representative example is Eco's type system, which can track types that cannot be null. Additionally, it prohibits the use of operations that can lead to null pointer exceptions at runtime. From another perspective, type checking and testing can be done through operators after the operations.

Casting occurs naturally, allowing for preemptive defense against issues similar to class casting sessions. Lastly, in special types such as enumerations, it checks whether there are values that are not evaluated. Therefore, even without writing a comprehensive case, it can be confirmed that all values have been safely validated. 

Currently, there are a few questions that have come in. After I finish my presentation, I will take a moment to check them and provide answers where I can. Ultimately, since all of these processes are provided at the compile stage, we can say that there is no decrease in productivity and that greater stability can be secured in many areas. 

This concludes a brief overview of the philosophy behind Kotlin. In 2021, I revisited the concepts I first encountered in 2016 and briefly looked at them again in 2017.

After that, I haven't seen 1-dong for almost five years. Was it four years? I couldn't see it at all, and in 2011, I joined the carrot market and met the framework again. My coding skills have improved significantly; I became more familiar with coding and started to understand the framework better. Now, I would like to introduce how it has changed bit by bit. I want to emphasize that a lot of code will be presented. If you try to read this code, it might be really difficult for you to grasp the essence. So, I will provide guidance on which parts of the code to focus on, and it would be great if you could concentrate on those moments. First, I mentioned that there are three main topics today. Among them, the first one is about the framework.

I would like to talk about something. The incorrect type system now tracks values that cannot be null. Therefore, it prohibits the use of operations that could lead to a null pointer exception at runtime. If you look at the type of the object post at the top of the code, you will see that there is a question mark at the end. The presence of the question mark indicates that this post could be null, meaning it might be a value contained in an array list. Therefore, in order to actually use that value, it is essential to verify in advance that it is not null, as shown in the code. If you do not confirm that it is not null through the if statement, the compilation will fail. So, since I am accustomed to this, initially, I used if statements for all of these checks.

I wrote code to handle you, but now the code has become quite long, and there were some inconveniences when dealing with such parts in Java. In Kotlin, there are several features that allow you to handle you more safely. I would like to take a look at those.

First, the safe call operator, which is related to the question mark and the dot. As you can see, the first branching statement for the post object has disappeared. Just like you saw, there is a question mark attached to the post object in the code I wrote, followed by the dot and the id. This means that it safely indicates that the post object can be null, and when it is not null, it retrieves the id value. If it is null, it simply handles it without causing an error.

이렇게 해서 자연스럽게 저 포스트 객체가 null인지, 또는 제 아이디 객체가 null인지 검증할 수 있습니다. 여기서 좀 더 다른 연산자를 통해서 더 간단하게 줄일 수 있는데, 바로 엘비스 연산자라는 것입니다. 이 엘비스 연산자는 물음표와 함께 콜론으로 표현할 수 있습니다. 지금 한 줄이 더 사라졌죠? 이제 두 개의 분기문이 사라지고 한 줄로 모든 것을 표현하는 것을 보실 수 있습니다. 그래서 호스트 객체가 null이 아니라면 id 값을 꺼낼 거라는 의미이고, 만약 저 id 값이 null이라면 뒤쪽에 있는 예외를 발생시키라는 의미로 해석할 수 있습니다. 마지막으로 null 아님을 단언할 수 있는 느낌표 두 개를 키워드로 볼 수 있는데, 이 null 아님을 단언한다는 것은 저 id 값이 null일 수 없다는 것을 의미합니다.

You can think of it as meaning that I will just treat you as if you are not null. If it were a null value, it could actually cause problems. At that point, a null pointer exception would occur at runtime. Therefore, I can use the non-null keyword only in situations where safety is sufficiently secured. So, in total, there are three methods through which we can handle nulls more safely. I have learned and applied methods that allow us to handle nulls in a more concise and safer way. 

Now, let's take a look at the second part, which is this code. This code uses conditional statements to change the data based on the type of 'i' that is passed in. It signifies that the data will change in a different way depending on the type. Let's make this code safer and more concise by using language constructs.

I will try to change it. First, I will look at the concepts of expressions and statements. An expression can produce a value, while a statement exists as a block surrounding itself and does not produce any value. This is the difference. Now, a statement has produced a value, while an expression cannot produce a value. You can understand it simply like this: in Java, all control structures are actually statements, meaning they do not produce values. In contrast, in languages like C, all control structures except loops are made as expressions. Therefore, it is not about producing values but rather about creating results. In the upper part, you can see that within the branching statements, for each value, you do not need to perform a specific action; simply returning the value of the if statement itself means that the evaluated value can be returned immediately.

You can see here that we can take a step further because this type itself can create a function. Additionally, it supports type inference, which allows us to simplify this code. Just like this, you can use the function's return value directly as this type. By doing so, the return value of the function will infer a type and be used as the appropriate type, making it easier to achieve our goal.

Now, up to this point, I've briefly talked about functions. Moving forward, I would like to explore how we can make this code safer and more concise by using some other control statements. In Kotlin, there is a construct similar to the switch statement in Java, which is also a type. In other words, it is a result...

Each answer can be returned immediately. Now, by including pattern matching, we can use richer conditions for matching. If you look at the code that has now changed to the left, it simply moves the item object. Then, depending on whether the passed item object is of type new topic or new post, the data is transformed in different ways. If it is not of type 2, you can see that it throws an exception externally, stating that it is a type that cannot be processed through the switch statement. In this way, in code, you can see that using an external statement is much simpler than using branching statements. As a reference, in the case of Java, starting from version 17, you can use pattern matching in switch statements as well. So you can use it in a similar way.

Now, if we look closely at this code, I think I can explain how it operates. Depending on the type of the item object, it transforms in different ways. Here, the new item refers to a news item, while the item is written as an abstract class. It is structured to hold high-quality posts. 

Now, if I were to add a new subclass in this situation, what would happen? As you might imagine, an exception would occur due to the branching in the code. Right, there is no handling code for the like type, so it falls through that branch. This means that unless we write thorough test code, we might encounter this situation at runtime. In this part, we can handle it more safely with this series of classes.

라는 키워드를 제공합니다. 2 쉴드 클래스는 추상 클래스와 비슷합니다. 남아 이제 추상 클래스와 다른 점은 제안된 클래스의 계층 구조를 만들 때 사용할 수 있다는 것입니다. 좀 더 쉽게 말하자면, 클래스 외부에 자신을 상속할 클래스를 줄 수 없고, 상속하려면 반드시 시리즈 클래스 내부에 중첩해서 작성을 해야 합니다. 이렇게 중첩해서 작성을 하고 있고, 누가 자신을 상속받았는지를 명확하게 알고 있기 때문에, 쉴드 클래스로 변경을 하게 되면 왼쪽에서 쉴드 클래스의 모든 하위 클래스를 처리한다면 else 분기가 필요가 없습니다. 왜냐하면 현재 짐 하이클래스가 유토피아이기 때문에 뉴스 토픽 간유 스토퍼 스트로 작성이 되어 있고, 그 모든 것들이 한 분기 문 안에서 다 처리가 되었기 때문에 안전하게 다 다뤄졌다는 것입니다. 만약에 여기서 제가 앞서 보여드린 것과 같이 뉴스 라이크와 같은 새로운 타입을 선언한다면,

If you don't put the processing code for that map item, a compilation error will occur, indicating that you haven't handled a certain type. Therefore, we can handle types much more safely and have the advantage of dealing with various conditional statements. Thanks to this, I've learned a lot and was able to simplify the code. Now, I want to share a different story about not overdoing things. There is a class here with three constructors. This is a common coding pattern where we use constructor overloading to set some properties to default values. By utilizing linguistic devices in our code, we can make it safer and more concise. By using this constructor, you can write code to create objects, which allows you to do the following: First, there is a version that passes all the parameters required for the full default constructor, then a reduced version, and finally a further reduced version.

I wrote this in three different versions. Now, if I change the ID of the topic and the ID of Psy, what will happen? Actually, it goes in without any problem because the types match, so there are no issues. Therefore, there is actually a chance for mistakes. In Kotlin, named arguments allow you to specify the values passed to the constructor or function explicitly. By naming them, you can also change the order of the arguments being passed. Even when the constructor changes, you can clearly bind the properties you want to bind, regardless of the order, which makes it safer to write. Additionally, when using named parameters along with another technique called default arguments, you can write more efficient code. Default arguments allow you to provide values for parameters in the constructor.

When writing parameters, you can provide default values. This means you can assign default values to the arguments. Therefore, by using these default arguments and named parameters, you can write code very succinctly without needing to overload the constructor. For example, in the case of text, author, and topic, the values of the provided arguments will be used. However, for the other arguments that are not provided, such as ID or grade, the default values will be used instead. This means that you can write the code very easily without overloading. As you have shared in the chat window, what we are doing here can essentially be seen as using the builder pattern at the language level. It seems like we can create code that is very readable.

Now, I would like to bring up a somewhat different topic. I want to take a look at the structure of the code that was widely used until the Sphinx era, and I plan to make some changes to it. This code, in the case of Earth Mapper, has an interface that includes a method for receiving input for a child and returning a user object. To create a Topic Detail object, it receives an Earth Mapper object and uses it internally. In Spring, this type of code structure is usually referred to as the Template Method Pattern. However, after the reformation, it has become a term that is not commonly used anymore. Nonetheless, I intentionally brought it up for this discussion. First of all, the code I will show is something I am quite familiar with, having used Java for a long time. It uses the Object keyword to write an anonymous class for the none method.

It's about passing it on. In Java, this method is also referred to as an anonymous class, and another term used is an anonymous object. It's often called a subject as well. I was initially familiar with this method, but fortunately, I've experienced using Java 8, so I thought I could use a simpler method. It's about using functional interfaces that can be used after Java 8. In Java, to declare a functional interface, you need to annotate the interface with the @FunctionalInterface annotation. This is a common practice for marking it. Of course, just because it doesn't have this annotation doesn't mean it won't work, but generally, the annotation is widely used.

To declare a functional interface, you need to attach the keyword fun in front of the interface. By adding this fun keyword, it is recognized as a functional interface in the context. In the case of fun, it can be written differently, allowing for a simpler syntax. Up to this point, I have used methods that are quite familiar to me. The Kotlin language has features related to functional programming, making it easier to write code. In Kotlin, functions are first-class citizens, meaning you can treat functions like regular values. You can store functions in variables, pass them to other functions, and create new functions to return. So when defining this function, you take an ID as a parameter, and if you look at the part highlighted in yellow, it shows that you take an ID as input.

Now, when writing a function that returns a user, you don't have to write a functional interface. When a function takes another function as a parameter or returns a new function, this method is referred to as a function type. By writing it this way, I can declare and pass a function that has a specific purpose and a single feature. This declared function can be easily called and used as needed. Up to this point, I've shown you some code that I've integrated into my work while learning the linguistic features of the Kotlin language. Now, I'd like to discuss a somewhat different topic: coding conventions. Coding conventions are the overall rules about how to write code, including what type of quotation marks to use and how to handle indentation.

When coding, I usually consider how many spaces to use and the maximum width. There are various things that can be a bit strange in the code. For example, typically, I don't use semicolons, but here they are used. Also, at the end of a function, I usually don't leave a space, but it can be included in some cases. These issues can be addressed through our coding conventions. The official site of the coding language offers suggestions for their coding conventions. By using these coding conventions alongside linting, you can write code in a consistent manner. Writing code in a consistent way is beneficial for the team.

Overall, I believe we can gain significant advantages in terms of maintainability by writing code in the same format. I've been running for about 20 minutes now, but I actually have over 50 slides prepared for the latter part. So, I'll try to go a bit faster. This is the second story. It's about a child with a rich expression. Here, we have a class written with Spring's bean configuration information. This is the code for registering the data source as a bean. It reads the necessary configuration values from environment variables and uses a builder to create the data source. Although this code is for using an embedded data source, in a real operational environment, such code might not be used, but reading environment variables and configuring objects is very common. If we try to make this code a bit more concise and safer through linguistic devices, we could do it like this. First, let's try to simplify the code that constructs the object a bit more.

There is a scope function called apply in Kotlin. Using this scope function, you can easily apply it to a builder, and the content inside the apply block will actually receive the built object as the context. Therefore, you can write the necessary values and configuration settings without explicitly mentioning the builder, making it very convenient to create objects. This scope function is a feature included in the Kotlin standard library, and you can think of it as executing a block of code that operates within a specific object context. Yes, I might be speaking a bit fast. Kotlin itself is currently introducing version 1.7. When you use scope functions like let and run together, it forms a scope where you don't have to reference the object's name explicitly, allowing you to access the object directly.

You can access entities using the keywords that have been promised to be turned on. Since there are various scope functions, I thought it would be convenient to use them well according to the purpose. Now, rather than discussing incorrect language, I would like to take a look at some features supported by Spring using language constructs. Here, I am going to refine the code that extracts environment variables. As you can see, it is extracting properties from the environment object. When extracting properties, I am passing the type to retrieve the desired type. Additionally, to handle the data in the necessary form, you can see that there are operations to transform the data, such as using functions like map. This code utilizes an extension function provided by Spring through Kotlin.

하면, 조금 더 편하고 이렇게 안전하게 환경 던 술을 꺼내 쓸 수가 있어요. 총 3가지 형태의 확장 함수를 제공해 주는데요. 어이 확장 함수라는 것은 어떤 클래스의 멤버 메소드인 것처럼 호출할 수 있지만, 그 클래스 밖에 선언된 함수라고 보시면 돼요. 즉, 지금 보면 어플의 퍼티 비주얼을 확장해 가지고 몇 가지 편리한 코틀린 확장 함수를 제공하고 있죠. 덕분에 조금 더 편리하고 안전하게 인발 이벤트로부터 값을 조금 넣고, 틀린스럽게 꺼내서 쓸 수 있는 코드를 만나실 수 있어요. 또 하나, 다른 스프링이 제공하는 확장 함수를 살펴보려고 하는데요. 여기 스프링 JDBC 템플릿을 이용해서 데이터베이스에서 데이터를 조회하는 코드가 있어요. 이 코드는 즉, 커리라는 이코 함수는 총 3개의 인자를 받아서 동작을 합니다. 첫 번째 인자는 SQL이구요.

The second parameter is for acquiring data in the context of the second clause, and there is a perfect object for it. The third parameter is the value to be passed for scaling. This is an interface written in Java, and you can use the extension functions provided by Spring with Kotlin to make some changes. By utilizing one of the conventions in Kotlin, you can actually extract the necessary external functions. First, the order of the parameters is SQL, then the value to be passed to SQL, and finally, you can see that the last parameter is mapped outside the function, enclosed in parentheses. This makes the purpose clearer and more defined. Compared to the previous code, it doesn't become significantly more concise, but it allows us to express the purpose more distinctly.

Ah, and I want to take a look at some codes that support repair a bit more. First, when you write a test code, you can use this. When writing a test code, if you want to inject something through the constructor, you basically need the @Autowired annotation. However, since this code currently only needs to receive one existing object, it only uses one injection. If there were multiple objects, it would become quite inconvenient. To simplify this part, Spring provides an annotation called @TestConstructor. Thanks to this, even in the code, it is impressive that it supports easily receiving the necessary dependencies through the constructor of the test class. Looking at another piece of code, when we usually write web tests in Spring, we use Mock MVC to do so.

테스트를 보통 많이 작성합니다. 제목은 MVC를 통해서 어떤 HTTP 메소드의 어떤 URL을 호출할 것이고, 이때 엑스트라 타입은 미디어 타입은 무엇인지, 이 결과로 상태는 OK이고, 뷰의 이름은 무엇이며, 모델에는 어떤 데이터가 들어 있어야 하는지를 검증하는 코드가 있습니다. 이 코드를 스프링이 지원해주는 DSL을 이용하면, 좀 더 손쉽고 간결한 코드로 바꿔줄 수 있습니다. 즉, 이제 MVC에서 메소드를 호출할 것이고, 그 내부에 어떤 타입의 필요한 파라미터들이 있을 것이며, 그 결과 값으로 상태는 무엇이고 뷰, 그리고 모델까지 좀 더 간단하게 테스트 코드를 작성할 수 있다는 것을 알 수 있었습니다. 이 DSL은 이제 도메인 스페시픽 언어를 의미합니다.

It is called PMDG, and it is a somewhat old concept, similar to the concept of programming languages. Usually, the most common DSLs we use are SQL and regular expressions. In Java, when we deal with Scala, we typically handle it as a string or store it in a file like XML. Therefore, if we consider these two languages, there is a certain sense of alienation between DSL and the Java we actually use. However, since the language level supports DSL, it allows for better readability and maintainability while also enjoying features like code auto-completion and syntax checking at compile time. Looking at this code, the test code is now...

You can see that the horn leader is being mocked. If you think about the title MVC DSL that you saw earlier, you might feel a bit awkward as well. So, using this code, which is Spring, it helps you to handle the mocking in a more elegant way, allowing you to process it in a way that is more consistent with the hoteling style. Since the mock library doesn't have a significant difference, you should be able to use it without much inconvenience. Lastly, I have prepared a topic on asynchronous requests. This code is for setting up asynchronous requests in Spring. When it receives a request, it subscribes to the publisher of forum news and responds when there is new news for the client. Spring has supported asynchronous request handling since version 3.

To handle asynchronous requests now, you just need to specify that the type is asynchronous in the controller. Since Spring 5, it has supported reactive types like Mono and Flux. In fact, Spring already supports several asynchronous models, but it also provides a programming model called coroutines for asynchronous programming. The Spring team has been very proactive in adopting this. As you can see, even though it is asynchronous processing code, it appears as if it is just coding for synchronous processing, making it very easy to handle asynchronous requests. However, to understand coroutines a little more easily, I have prepared some information about other asynchronous programming concepts.

Here, I am going to create a function that retrieves user information, organization information, and repository information from GitHub. Inside the code, if any events occur, it first queries the initial user information. Then, using that user information, it retrieves the organization and repository information. In other words, the first task must occur first, and the second and third tasks should be processed simultaneously, returning the results afterward. You can use CompletableFuture to achieve this. 

First, I will provide three functions that retrieve user, organization, and repository information, respectively. Each function will return a CompletableFuture type. Additionally, I will ensure that the CompletableFuture type can handle the retrieved information properly.

You can declare a function that returns a value like this. The first thing you need to do is to use the bufferation to query user information. Once the user information is retrieved, the next step is to pass it to the handler. At this point, you can use the compose method to pass the data. The handler that is passed this way will already have the user information retrieved, and it will use that information to query the organization and repository details. When the information retrieval for both the organization and repository is completed simultaneously, you can write the code to return the actual object as a result. In this part, you can utilize the method reference and the callback to perform asynchronous programming. If you use the reactive library for this part, you can write it like this. Now, this is about the reactive library. The reactive library uses a type called monohub flex.

Here, I simply created a brief draft that returns only what is input through the mouth. Similarly, you can write a mono type, such as banana, for the given operation. Now, the first thing we need to do internally is to create an operation replacement and use two operation objects to acquire user information. Using this acquired user information, we will then proceed to query organization and repository information. At this point, in Reactive Library, you can use something called play map. I apologize for missing this yesterday. Now, when the process is executed within this plate, after querying the main organization information and repository information, we will use a method called home to ensure that after the two asynchronous tasks are completed, all information—user information, repository information, and organization information—is combined and returned.

You can write it like this. You have taken a look at the reactive library, so how about in this coroutine? You can write the code like this. As you can see, there is no special type being used. Without using a special type, you can just use the keyword suspend in front of the function, and inside the coroutine, you will see the keyword async. If you write the code in a procedural or imperative style like that, the code will actually operate asynchronously. In other words, just like the CompletableFuture or the active type you saw earlier, you can write asynchronous code in this coroutine. One thing I definitely want to mention is that this is not about good or bad.

하고자 하는 건 아니었고, 목적과 용도에 따라서 사용하시면 됩니다. 코틀린에서는 비동기 프로그래밍 모델로 고통을 제공하고 있고, 코틀린을 이용하면 조금 더 쉽게 비동기 프로그래밍을 할 수 있다는 것을 보여드리고 싶었습니다. 제2의 코틀린이 어떻게 동작하는지 궁금하실 수 있는데, 이 부분은 조금 있다가 김태운님이 이어서 코틀린에 대해 소개해 주실 것입니다. 이렇게 제가 한 40분 정도의 시간을 써서 여러분들에게 3가지 주제를 말씀드렸는데, 조금 더 쉬운 내용을 하나 더 준비해봤습니다. 지금 저에게 주어진 시간에 5분이 더 있어서 다행스럽게 생각합니다. 만약 5분이 없었다면 제가 시간을 초과했을 것 같습니다. 하나 더 이야기를 들어보고 발표를 마무리하겠습니다.

This segment discusses the topic of functional programming styles in Spring 5. With the evolution of the Java language, the programming model of Spring has undergone significant changes. With the introduction of Java 5, annotations became a part of the language, leading to the adoption of annotation-based programming models in Spring starting from version 2.5 in 2007. As a result, many functionalities have been incorporated and utilized, allowing us to develop with a programming model that is both concise and powerful. The use of annotations has made handling web applications much simpler. Following this, with Spring 5 being based on Java 8, many changes have taken place.

I woke up, and especially with the introduction of functions related to the interface and lambda in the API, the Spring team has the opportunity to make new attempts at functional APIs. They are starting to incorporate functional styles, and one representative example is this lightweight functional programming model you see here. This lightweight functional programming model allows you to map requests in a functional style using objects like the Naoto Bong dimension. You can map requests using paths, HTTP methods, and media types in very diverse strategies. If you write this code in a functional style using annotations, it changes like this. Now, you can use annotations like @RequestMapping, @GetMapping, and @PostMapping to write it. You can consider this functional style code and this code to perform the same function.

If you look closely at the functional style code, you'll notice some repetitive parts. Specifically, there are instances of the Person media type strategy that lead to duplication. These areas can be modified using the four-stepped method. From the request to the response, you can explicitly write it this way. By using a quantitative programming model, you can write it clearly from the request to the response, making it a good and testable programming model. However, the execution remains somewhat unchanged. Now, how can we change this code? The Spring team provides a router DSL using Kotlin. By using the router DSL, you can write the code in a more concise and clear manner. It becomes very intuitive. Additionally, you can also implement it similarly with beans.

You can register beans using a lambda expression. If you use the part that supports the incorrect code with the number 3, it will change like this. You can write the configuration information in DSL, and the beans defined in this way will be created as objects of the application context's initializer. In Spring Boot, you can easily register and use them with the application method. In fact, if you are using a hotel with sound 5N as a coordinator, it is a feature that you can use immediately. However, when using Spring Boot with annotation-based conventions, you couldn't enjoy such advantages. Typically, annotation-based conventions simply require you to add how to do something in Spring Boot, which allows you to configure applications in various ways with dozens of automated configuration strategies.

I have two questions. First, how can we create a clearer structure instead of relying on the automated configuration method? Second, how can we structure a Spring application more effectively? From this perspective, I was curious about what the Spring team has to offer. In that context, the Spring team announced a project called Spring Pink in 2010 and 2011. This is a DSL that structures the Spring framework. As you can see, it is designed to create web applications, and it outlines how to configure internal beans, MBC settings, and converters using DSL. The objects created can be executed directly. So, there are two DSLs available for explicitly configuring Spring Boot, and they are structured with a focus on clarity and effectiveness.

Through these two projects, you can explicitly structure your code and make great use of functional styles. The code written this way minimizes the use of annotations and reflection, and it hardly utilizes automatic class detection. As a result, it is about 40% faster than annotation-based approaches. I can make comparisons, but since time is limited, I think I should wrap it up here. I recommend reviewing the previous content later through the slides. However, this is not about showing something better or worse; it's about suggesting different methods. This concludes the session I prepared. Since I've spent quite a bit of time on questions, I will finish here, and we will move on to the next session about car rental at 8 o'clock.

I will start in 5 minutes. Thank you, Yeon Lee.

자프링 외길 12년차, 코프링 2개월 생존기 | 당근마켓 Server 밋업 1회

당근의 팀원 모두는 사업가이자 사용자의 마음을 읽어내는 사람들이에요. 동네의 가치를 발견하고, 커뮤니티에 속한 모든 주체의 삶에 긍정적 영향을 줄 수 있는 서비스를 만들어요. 문제를 발견하고 가설을 검증하는 끊임 없는 시행착오 속에서, 회사와 우리는 함께 성장하고 있어요.

자프링 외길 12년차, 코프링 2개월 생존기 | 당근마켓 Server 밋업 1회

자프링 외길 12년차, 코프링 2개월 생존기 | 당근마켓 Server 밋업 1회

스크립트