Participated in the event for the first time in half a year with 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
It was completely different from what I thought in advance, but it was quite interesting
What is Domain Driven Design? How good is it? How should I do it? (Around here was too fast to take notes at all)
--Motivation ――Why Domain Driven Design? --What is Non-Domain Driven Design? --Get lost in the code forest --Scattering related implementations
--Summary --Domain Driven Design is a practice for practicing what is commonplace
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.
――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
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.
--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)
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! !!
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
Recommended Posts