[Java, Программирование] Small things that pollute your code
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
I'm not going to discuss global things like design patterns and so on, as there's enough literature on that topic. Instead, I'd like attract your focus to some small things that are still affect lucidity and maintainability of our code.
Polluting code with methods or access modifiers for 'test only'
First of all, if you give access to something that shouldn't be used in production code, it sooner or later will be used by someone just because it could seem suitable. The argument that it's an internal stuff doesn't work as it absolutely shouldn't be matter, writing you a library or isolated project! Treat people who will add anything to your internal codebase the same way as if they use your existing code as a different library.
Thus, if for some reason in test, you need to call something that should not be called on prod — use reflection or whatever else but do not expose it in production code! And there's no reason to afraid of reflection for test proposes, at the end, you using Mockito, shouldn't it be bad in that case as well?
Avoiding of JavaDoc
I've heard quite a lot, a weird strange argument that «JavaDoc means that code is not self-documented». I wouldn't talk about that self-documented code in reality is myth — it's an absolutely separate topic. JavaDoc is about providing a contract with your code. And again, it doesn't matter, writing you a library or isolated project! Only on private methods, I can agree, that JavaDoc can be skipped. Who is writing one service in your project shouldn't go and read all implementations of other services or DAOs or whatever that he's using. He should be able to open an interface and read JavaDoc and that is it!
For example, if you're writing something that returning Map, and using LinkedHashMap to provide some specific order — you have to mention that in JavaDoc! Otherwise, who is using that service can't rely on the order as it wasn't part of the contract, and nothing will prevent you to silently change that behaviour later.
The other popular argument: «Tests are better description». Of course, BDD is a useful thing and it's a pretty nice way to check your code behaviour, but someone who will write one service in your codebase should investigate all tests of services (neither their implementation) that he will need to use before doing that! You have to provide a contract!
No interface for single implementation of a service
The same reason as in a previous paragraph. To write new service we want just open interface and read about a contract of services that we'll use. We are not interesting in the implementation!
Overtesting in unit-tests
Test only things that you really should! There's absolutely no sense to make a unit test for controller that doing nothing more than simply delegate everything to a service.
There's no sense to test your domain layer. I saw some examples when people test sterilisation of a POJO by Jackson, explaining that as they're testing that annotations is putted correctly… Come on! Tests are description of how your code logic should work and Jackson annotations is also description! Your just cannot test that, as if you write one description wrong, why you decided that by adding another one you will avoid mistake and not just copy it? Furthermore, for any change in your model, now you will have to change same description in two different places!
This particular example was even more ridiculous as ObjectMapper was created in each test, so, has nothing with the real one in a Spring context. Thus, because of different configurations it may serialise differently in prod at the end…
If your description is correct, you can check only by integration tests. Unit tests for sterilisation/deserialisation checking nothing other than sterilisation/deserialisation works. And if it is a part of some framework and not part of your code — do not test it!
Afraid of framework's 'magic'
For example, Spring core bring you lifecycle of beans and instruments to work with it and all services should be beans inside the context. If you want, for example, to do something with a DB before any of beans start using it, use ContextStartedEvent or BPP for for your DB connector bean but do not create separate object for the DB connector! Otherwise you will create second configuration that have to be maintained exactly the same way as the first one and this is the field for potential bugs. Don't reinvent the wheel if your already have a proper instrument!
I thought that for most of developers that things are obvious. Unfortunately, I've found out that it isn't a case… Hope that this small article will push to rethink approach…
===========
Источник:
habr.com
===========
Похожие новости:
- [ReactJS, Лайфхаки для гиков, Облачные сервисы, Программирование] 10 инструментов для повышения продуктивности React-девелоперов в 2020 году (перевод)
- [C++, Научно-популярное, Программирование] Дядя Миша. Основы организации оперативной памяти и работа с ней в С\С++
- [Python, Программирование] Создание нейросети по распознаванию лиц на фотографиях из Вконтакте
- [C++, Программирование, Разработка под Arduino, Робототехника] Обзор методики обучения робототехнике на базе НикиРобот
- [Python, Программирование, Промышленное программирование] Устройство CPython. Доклад Яндекса
- [Swift, Программирование, Разработка мобильных приложений, Разработка под iOS] Swift: Копируй-изменяй
- [API, C, Параллельное программирование, Программирование] Реализуем простые кооперативные потоки на C (перевод)
- [Микросервисы, Программирование] Перенос процесса BPMN из IBM BPM в Camunda — пошаговое руководство (перевод)
- [JavaScript, Node.JS] Создание Discord-бота, используя библиотеку discord.js | Часть №2 | Аргументы
- [Angular, ReactJS, VueJS] Angular vs React vs Vue 2020
Теги для поиска: #_java, #_programmirovanie (Программирование), #_java, #_software_development, #_enterprise, #_java, #_programmirovanie (
Программирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:07
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
I'm not going to discuss global things like design patterns and so on, as there's enough literature on that topic. Instead, I'd like attract your focus to some small things that are still affect lucidity and maintainability of our code. Polluting code with methods or access modifiers for 'test only' First of all, if you give access to something that shouldn't be used in production code, it sooner or later will be used by someone just because it could seem suitable. The argument that it's an internal stuff doesn't work as it absolutely shouldn't be matter, writing you a library or isolated project! Treat people who will add anything to your internal codebase the same way as if they use your existing code as a different library. Thus, if for some reason in test, you need to call something that should not be called on prod — use reflection or whatever else but do not expose it in production code! And there's no reason to afraid of reflection for test proposes, at the end, you using Mockito, shouldn't it be bad in that case as well? Avoiding of JavaDoc I've heard quite a lot, a weird strange argument that «JavaDoc means that code is not self-documented». I wouldn't talk about that self-documented code in reality is myth — it's an absolutely separate topic. JavaDoc is about providing a contract with your code. And again, it doesn't matter, writing you a library or isolated project! Only on private methods, I can agree, that JavaDoc can be skipped. Who is writing one service in your project shouldn't go and read all implementations of other services or DAOs or whatever that he's using. He should be able to open an interface and read JavaDoc and that is it! For example, if you're writing something that returning Map, and using LinkedHashMap to provide some specific order — you have to mention that in JavaDoc! Otherwise, who is using that service can't rely on the order as it wasn't part of the contract, and nothing will prevent you to silently change that behaviour later. The other popular argument: «Tests are better description». Of course, BDD is a useful thing and it's a pretty nice way to check your code behaviour, but someone who will write one service in your codebase should investigate all tests of services (neither their implementation) that he will need to use before doing that! You have to provide a contract! No interface for single implementation of a service The same reason as in a previous paragraph. To write new service we want just open interface and read about a contract of services that we'll use. We are not interesting in the implementation! Overtesting in unit-tests Test only things that you really should! There's absolutely no sense to make a unit test for controller that doing nothing more than simply delegate everything to a service. There's no sense to test your domain layer. I saw some examples when people test sterilisation of a POJO by Jackson, explaining that as they're testing that annotations is putted correctly… Come on! Tests are description of how your code logic should work and Jackson annotations is also description! Your just cannot test that, as if you write one description wrong, why you decided that by adding another one you will avoid mistake and not just copy it? Furthermore, for any change in your model, now you will have to change same description in two different places! This particular example was even more ridiculous as ObjectMapper was created in each test, so, has nothing with the real one in a Spring context. Thus, because of different configurations it may serialise differently in prod at the end… If your description is correct, you can check only by integration tests. Unit tests for sterilisation/deserialisation checking nothing other than sterilisation/deserialisation works. And if it is a part of some framework and not part of your code — do not test it! Afraid of framework's 'magic' For example, Spring core bring you lifecycle of beans and instruments to work with it and all services should be beans inside the context. If you want, for example, to do something with a DB before any of beans start using it, use ContextStartedEvent or BPP for for your DB connector bean but do not create separate object for the DB connector! Otherwise you will create second configuration that have to be maintained exactly the same way as the first one and this is the field for potential bugs. Don't reinvent the wheel if your already have a proper instrument! I thought that for most of developers that things are obvious. Unfortunately, I've found out that it isn't a case… Hope that this small article will push to rethink approach… =========== Источник: habr.com =========== Похожие новости:
Программирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:07
Часовой пояс: UTC + 5