Знание SOLID и других супер аббревиатур не делает ваш код хорошим. — знание абривиатур не делает, а использование (в частности SOLID) делает и объясню почему. Статья расчитана на новичка, который еще не сможет оценить как лучше написать. Поэтому здесь и акцент, не знаешь как, то делай так и в большинстве случаев это будет оправдано. вот когда понабет шишек и наберется опыта, вот тогда уже можно будет рассуждать о преимуществах и недостатках того или иного подхода.
"
Что такое хороший код.
1. Это читаемый и понятный код. Что это такое- читателю не составляет труда понять ход мыслей программиста и use case который был реализован. В следующий раз когда потребуется добавить подобный функционал, время добавления предсказуемо. При этом дизайн может быть с неоптимальным, дубовеньким и на первый взгляд не правильным, в этом случае добавление займет не 4 часа, а 6." — на уровне хелоу ворда будет работать без проблем, на уровне большого проекта с сотнями классов и тысячами зависемостей понять в принципе как работает проект — это уже задача не на один месяц и кто же Вам даст столько времени то. Используется SOLID — как минимум код слабосвязанный, разбираешься только в своем куске остальное не заботит, вероятность сломать что-то минимизируется, а если на косячил, то либо с высокой вероятность на уровне тестирования выплывут баги.
2. Не соглашусь — нужно лепить патерн и правильный подход и зависимость через конструктор. Причина опять же проста, Если проект старттап он начинает жить и 100% появляются требования к доработке и накручиванию нового функционал, а вот предуагадать что прикручивать придется, а что перепиливать — не угадаешь. И когда наступает эта необходимость, обсчет сроков уже вполне себе нормальная задача. А вот другая сторона медали если проект пришел в в поддержку, вот тут уже нужно смотрть на ситуацию и в большинстве случаев, во всяком случае в моей практике полностью его переделывать для бизнеса не выгодно и придется ваять костыли ини куда от этого не денешься.
3. Любая технология, подход, практика используется взвешенно и в соотвествии с ее предназначением. — соглашусь. 90% задач, а может больше основной фактор это скорость реализации. Если наработан правильный стиль, а именно писать реализации интерфейсов а не классы и максимально увеличивать изолированность кода — это на мой субъективный взгляд два самых важных принципа, то время разработки увеличивается примерно на 5-10%, а вот сопровождение кода уменьшается в разы. Попробуйте сопровождать код типа «монолит» — взмокнете и будете очень грубо выражаться в сторону разработчиков. Но повторюсь — даттые советы ориентированы на новичка, который неспособен еще отличить необходимость того или иного подхода.
p.s. не нравится мне пример насчет автомата калашникова. Давайте возьмем самолет. Задача построить самолет — нужно стпроить самолет а не с оглядкой переделать его в звездолет — это я с Вами соглашусь на 100%. Вот только, когда заказчик скажет что у него оказывается взлетная полоса короткая и а грузоподъемность нужно увеличить в два раза, С Вашими подходами Вам придется делать новый самолет, а мне просто поставить на старую модель более мощный двигатель позволяющий вертикальный взлет. Такая алигория мне кажется лучше описывает картинку.
Но в любом случае спасибо за комментарий, всегда интересно и полезно выслушать другое мнение, даже если оно и противоречет собсвенному.
Спасибо за критику. «категоричность в нашей профессии — это как раз зачастую проявление синдрома «самого умного программиста».» — согласен на 100%, буду работать над стилем изложения.
Вы совершенно правы, возраст не играет ключевую роль, но при двух условиях — разработчик в возрасте (скажет старше 35 лет) и с постоянным опытом работы, причем он не ленился учиться. К примеру у многих разработчиков с большим стажем присутствует серьезная консервативность во взгляде на методологию программирования, некоторые к примеру принципиально не переучиваются допустим с Clarion или Delphi на более востребованные языки и платформы, если же он постоянно развивался, освоил .NET, JAVA, использование IoC контейнеров и ORM и т.д. и что самое главное сумел перестроиться под самое важное изменение в программирование — это работа в команде. Раньше программирование было индивидуальное в большинстве своем, сейчас же командное, и это оказало серьезное влияние на всю отрасль в целом. Второе условие -это коммуникативность или как вы совершенно точно выразились адекватность. Если оба эти условия соблюдены то возраст это будет скорее плюс чем минус.
Не совсем понял, Ваше высказывание. Если Вы имеете ввиду, что если начать заниматься программированием когда тебе за 30 — то трудоустройство программистом затруднительно — с такой формулировкой я соглашусь т.к. в программировании очень важен опыт, который сын ошибок трудных. Но смена рода деятельности после 30 — это уже исключение так что все возможно. Если умеешь, готов и что самое важное есть возможноть учиться, то вперед. Но нужно быть готовым что учитсья придется всерьез и долго и ни в коем случае нельзя ориентироваться на рекламу со слоганами типа «Вы нам заплатите и за один… три месяца мы сделаем из Вас программиста и будете получать стотыщпятьсот долларов» или книги с формулировками «Освоим программмирование за 21 день» и т.д.
"
Что такое хороший код.
1. Это читаемый и понятный код. Что это такое- читателю не составляет труда понять ход мыслей программиста и use case который был реализован. В следующий раз когда потребуется добавить подобный функционал, время добавления предсказуемо. При этом дизайн может быть с неоптимальным, дубовеньким и на первый взгляд не правильным, в этом случае добавление займет не 4 часа, а 6." — на уровне хелоу ворда будет работать без проблем, на уровне большого проекта с сотнями классов и тысячами зависемостей понять в принципе как работает проект — это уже задача не на один месяц и кто же Вам даст столько времени то. Используется SOLID — как минимум код слабосвязанный, разбираешься только в своем куске остальное не заботит, вероятность сломать что-то минимизируется, а если на косячил, то либо с высокой вероятность на уровне тестирования выплывут баги.
2. Не соглашусь — нужно лепить патерн и правильный подход и зависимость через конструктор. Причина опять же проста, Если проект старттап он начинает жить и 100% появляются требования к доработке и накручиванию нового функционал, а вот предуагадать что прикручивать придется, а что перепиливать — не угадаешь. И когда наступает эта необходимость, обсчет сроков уже вполне себе нормальная задача. А вот другая сторона медали если проект пришел в в поддержку, вот тут уже нужно смотрть на ситуацию и в большинстве случаев, во всяком случае в моей практике полностью его переделывать для бизнеса не выгодно и придется ваять костыли ини куда от этого не денешься.
3. Любая технология, подход, практика используется взвешенно и в соотвествии с ее предназначением. — соглашусь. 90% задач, а может больше основной фактор это скорость реализации. Если наработан правильный стиль, а именно писать реализации интерфейсов а не классы и максимально увеличивать изолированность кода — это на мой субъективный взгляд два самых важных принципа, то время разработки увеличивается примерно на 5-10%, а вот сопровождение кода уменьшается в разы. Попробуйте сопровождать код типа «монолит» — взмокнете и будете очень грубо выражаться в сторону разработчиков. Но повторюсь — даттые советы ориентированы на новичка, который неспособен еще отличить необходимость того или иного подхода.
p.s. не нравится мне пример насчет автомата калашникова. Давайте возьмем самолет. Задача построить самолет — нужно стпроить самолет а не с оглядкой переделать его в звездолет — это я с Вами соглашусь на 100%. Вот только, когда заказчик скажет что у него оказывается взлетная полоса короткая и а грузоподъемность нужно увеличить в два раза, С Вашими подходами Вам придется делать новый самолет, а мне просто поставить на старую модель более мощный двигатель позволяющий вертикальный взлет. Такая алигория мне кажется лучше описывает картинку.
Но в любом случае спасибо за комментарий, всегда интересно и полезно выслушать другое мнение, даже если оно и противоречет собсвенному.