Должен ли junior уметь писать код соответствующий SOLID?

 
 
 
Сообщения:6
Добрый день коллеги. Устроился недавно программистом junior.Фирма существует 3 года, занимается поддержкой CRM, раньше занимались 1c все программисты, сейчас на java переучились.Дали мне тестовое задание написать консольную утилиту которая конвертирует справочники. Я ее написал но мне сказали все неправильно , код не переиспользуемый и.т.д. Я ее уже раз 10 переписывал. Опыта написания программ с нуля у меня нет(только маленьких приложений тестовых для себя) ,в основном ранее занимался исправлением багов. В основном проблема в том ,что я не могу понять абстракции которые мне придумал старший программист , он дал заготовку - интерфейсы и пару базовых классов и говорит реализуй. А я не могу понять принцип единственной ответственности классов. Процесс длится долго, написал , старший просмотрел ,сказал почему у тебя твой класс выполняет эти функции , он не должен .Исправил , опять не туда методы засунул . Он видит решении более абстрактно , а я начинаю реализовывать , нужно добавить какую -то функцию или класс и сужу несколько часов думаю куда их засунуть, в какой пакет или класс , или новый создать .Когда создавать новый класс, а когда добавить функцию в существующий. И так уже больше месяца. В общем мое абстрактное мышление не совпадает с мышлением старшего программиста. Про паттерны проектирования читал, на пальцах и на реальных примерах про "принцип единственной ответственности" понятно(про вещи которые в жизни у нас встречаются авто, инструменты например) , а вот на реальный код его перенести не могу. Как их применять не пойму, всякие менеджеры , хелперы, воркеры, фабрики,домены, провайдеры - в общем каша в голове , в каком случае что использовать . Старший сказал почитай готовые проекты, может так поймешь, говорит что он не учился этому, а это от природы умение обобщать и разбивать на абстракции. Может работу менять ? Подскажите пожалуйста какие нибудь советы новичку .Заранее благодарен.
 
 
Сообщения:9895
Проблема с SOLID - их можно трактовать по-разному, особенно SRP. Мы можем сказать что "заведовать учетными записями" - это 1 функция, либо "удалять учетные записи" - это 1 функция. Ну допустим решили что "удалять учетные записи" - это одна функция, а управлять ими (удалять, добавлять, редактировать) - это несколько функций, и если мы их поместим в 1 класс, то нарушим SRP. Стоит ли рефакторить код? Он может и будет более SOLIDным, но станет ли он лучше? За гибкость очень часто нужно платить простотой, т.е. чем гибче напишем, тем сложнее код будет.

И вот получается что теперь мы должны балансировать - написать просто или написать гибко. И то, и то хорошо, но часто это взаимоисключающие качества. Я почти всегда выбираю простоту вместо гибкости. Во-первых, эта гибкость может никогда не понадобиться (а время мы потратили), во-вторых, возможно она понадобится в другом месте (и прийдется переписать наш красивый и гибкий код на другой красивый и гибкий код), ну и как обычно мы могли понять требования не полностью - и опять же это приведет к серьезным переписываниям.

Это все не значит что твой старший не прав, на форуме мы тут не сможем оценить ситуацию. Может он перегибает палку, может ты и правда плохо пишешь, а может и то, и то. Мой совет - пока про паттерны можно забыть, они нужны не столько для того чтоб их применять, сколько для того чтоб проще было общаться с коллегам. По SOLIDy есть книга от Head First, также имеет смысл взглянуть на Clean Code, ну и на Effective Java.

И сильно не спеши - если не получается со сложными задачами, может тебе могут выдать какие-то простенькие баги пока ты набиваешь руку.
Изменен:07 ноя 2019 08:49
 
 
Сообщения:6
Спасибо за советы, книжки почитал по рефакторингу и код немного улучшаться стал (сам замечаю). Тут я так понял нужно время все таки, на начальном этапе работы у меня каша в голове(большой объем информации попал в память за короткий срок и каждые его по разному усваивает) , сейчас постепенно приходит понимание. Надеюсь дальше чуть легче станет.
 
Модераторы:frymock
Сейчас эту тему просматривают:Нет