I participated in JJUG CCC 2019 Fall.

Participated in the event for the first time in half a year with Java! !!

Basic knowledge of object-oriented programming learned in Java

--Object-oriented thinking can be applied to software development --Mr. Masuda's commitment to object-oriented programming --Modularity --Split the program by type (value type) --Make a module with a mold --Seaminess --Development method to eliminate the seams of a series of activities --Words I want you to take home --Type

Encapsulation --Two modes --Mode 1 --Use only predefined types --Standard library and built-in types only --Type consumer --Mode 2 --Define your own type --Mold producer ――What is object-oriented programming skill improvement? --Transitioning from mode 1 to mode 2 --Class design skills --Skills for discovering and improving unique types --Summary --Encapsulate the concept of type into a class --Give a definition of a range of values and a definition of value operations to a class and embody it

Impressions

It was completely different from what I thought in advance, but it was quite interesting

13: 30-14: 15 Open! Domain Driven Design Door

Presenter's material (No)

Overview

What is Domain Driven Design? How good is it? How should I do it? (Around here was too fast to take notes at all)

Memo when I heard

--Motivation ――Why Domain Driven Design? --What is Non-Domain Driven Design? --Get lost in the code forest --Scattering related implementations

Purpose --Software users and code should be connected --Practice to improve maintainability, not development speed --What is Domain Driven Design? --What is a domain? --What is the scope of the software? --Domain and code are connected through a model --It will be an iterative development --Upstream of knowledge --Domain Expert --The subject of the work --People who know what is important --People who consult with developers when deciding on a domain --Developers need conversations with domain experts --Use ubiquitous language ――Words that anyone can understand --Understanding by using the other party's language --Deepen mutual understanding
Component ――It's too early to take notes. .. --To a deep model ――I can't grasp everything from the beginning ――The power of conversation is important --Catch the momentary nuances --I don't hate refactoring

--Summary --Domain Driven Design is a practice for practicing what is commonplace

Impressions

It was interesting because there was a story that led to "basic knowledge of object-oriented programming learned in Java". There were many points that I couldn't keep up with because it was too fast.

14: 30-15: 15 Reintroduction to JUnit

Presenter's material

Note

――Why write test code --Because regression testing is possible --High reliability ――Do not leave personality --Confirm debug completion at runtime ――Debugging is fun ――Psychological damage occurs when humans point out mistakes. .. .. .. --Test tips --Write the test first --Implemented after confirming test failure --Implemented after guaranteeing failure --Give a descriptive test name --Write the test name in Japanese --All team members must be fluent in Japanese --Do not overwrite assertions ――Write in moderately organized units --Use assertAll as needed --Don't be too particular about coverage --Do not test proven code --No need to test getter and setter

Impressions

I felt that the first half was for beginners and the second half was important At present, it has not been developed for test first, so I felt that I wanted to improve it. I especially want to work on UI testing.

16: 45-17: 30 An example of breaking away from the huge legacy system at Name.com, where the third year of new graduates faced

Presenter's material

Note

--What is a legacy system? --Behavior as intended --The internal code is complicated and difficult to maintain. --High maintenance cost --Problems of breaking away from legacy systems --There is no document about the specifications (specifications) --Some parts are complicated and difficult to correct (implementation) --Implemented in pure Java --Implementation that is difficult to understand --Define raw query --Solid setting information --Class responsibility is ambiguous --No unit test code (test)

Solution --No documentation on specifications (specifications) --Share all together on the wiki --Leave detailed code information in git when magically --Some parts are complicated and difficult to correct (implementation) --Implemented in pure Java --Selection of JDK --Framework selection --Selection of Web API architecture --Implementation whose intention is difficult to understand --Prevention of personality by conducting code reviews --Standard implementation according to the framework --Define raw query --Introduction of framework --Solid setting information --Unify setting information to YALM --Class responsibility --Clarify responsibilities for each layer --Design that does not affect other modules --No unit test code --Introduction of JUnit --Introduction of Mockito ――For the future --Strict adherence to rules and regular maintenance are required --Otherwise, it becomes a legacy

Impressions

I often look at the in-house system, but it is often difficult to understand the implementation. I feel that there are many opportunities to fight legacy systems. (Repairs will be done soon ...) I will use it as a reference for how to fight! !!

Impressions of the entire event

I attended a lecture for beginners, but I often couldn't keep up with the amount of information. → I want you to reduce the amount of information, such as limiting the number of slides. I was surprised that the lunch was gorgeous → It was delicious. Thank you very much. I also wanted to hear about Gradle → The first step for those who fully understand Gradle to not understand anything I want to focus on listening to UI testing ← I'm interested now