Dev Easy Notes

Представьте, вы смогли вернуться назад во времени, к себе только начинающему изучать программирование. Какой совет вы бы себе дали? 

У нас же есть куча принципов и best practice. Возьмем например SOLID, несколько принципов составленных в одно слово. Кстати есть слух, что когда Мартин с друзьями собирал эти принципы, принципов было больше, они просто взяли те, из которых получалось слово, а остальные решили опустить). Правда я не проверял насколько это правда.

Проблема принципов SOLID в том что они очень абстрактные. У них может быть несколько трактовок и они не дают конкретики. Я точно несколько раз был свидетелем срачей по поводу того, как правильно трактовать принцип открытости/закрытости. Про принцип подстановки Барбары Лисков я вообще молчу, тут запутались вообще все. У принципов SOLID естественно есть критика советую прочитать. Некоторая критика, притянута за уши и как всегда правда где-то посередине, но стоит ознакомиться со всеми точками зрения.

По мне так, про принципы SOLID лучше уже говорить когда у разработчика есть какой-то опыт. Если мы говорим о начинающих или джунах, то им разумеется лучше давать более конкретные советы. Так будет больше профита всем.

Есть ли более конкретные принципы, которые  стоит использовать, чтобы легко улучшишь свою кодовую базу? Смотрите, я уже делал посты про применение концепций функционального программирования и CQRS. Применив эти две концепции вы уже сможете писать гораздо более поддерживаемый и чистый код. К этим двум вещам, я бы еще добавил еще один.

Не бойтесь создавать объекты. Очень частая ошибка, особенно у начинающих, что они забывают про то, что у нас ООП язык и используют концепции процедурного языка. Отсюда появляются куча функций с более чем 5-ю параметрами, дублирование, избыточность, куча мутабельных полей и вот все эти головные боли. 

Совет как по мне очень простой, давайте на примере. Нужно в функцию передать 4 параметра? Сделайте специальный объект для этого. Из функции нужно вернуть пару значений вместо одного? Лучше сделать свой объект, а не стандартный Pair. Со стандартным Pair легче запутаться, особенно когда объекты одного типа. 

Когда мы используем объекты, мы зажимаем в некоторые тиски то, что можно передать в нашу функцию или класс. Другими словами, мы полагаемся на систему типов, которая за нас сможет отловить баги. Поэтому лучше отдавать предпочтение объектам, а не примитивам, когда появляется более менее сложная структура. 

Самый банальный пример тут это дата. У вас есть несколько вариантов как хранить дату в объекте, которую вы например получаете с бэка.
Первый вариант, это просто строка с уже форматированной датой. Второй вариант это конкретный объект например LocalDateTime. 

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

Часто мы пугаемся создавать объекты по причине того, что они якобы занимают память и нагружают GC. Вот тут вообще можно забить (если речь не идет о методе onDraw), это было проблемой на ранних версиях Android. Сейчас GC очень умный, настолько что порой даже создание ObjectPool получается дороже, чем просто создать объект.

👍28🔥2❤1

www.tgoop.com/dev_easy_notes/170

1.94K viewsedited  Sep 29, 2022 at 17:40

Представьте, вы смогли вернуться назад во времени, к себе только начинающему изучать программирование. Какой совет вы бы себе дали? 

У нас же есть куча принципов и best practice. Возьмем например SOLID, несколько принципов составленных в одно слово. Кстати есть слух, что когда Мартин с друзьями собирал эти принципы, принципов было больше, они просто взяли те, из которых получалось слово, а остальные решили опустить). Правда я не проверял насколько это правда.

Проблема принципов SOLID в том что они очень абстрактные. У них может быть несколько трактовок и они не дают конкретики. Я точно несколько раз был свидетелем срачей по поводу того, как правильно трактовать принцип открытости/закрытости. Про принцип подстановки Барбары Лисков я вообще молчу, тут запутались вообще все. У принципов SOLID естественно есть критика советую прочитать. Некоторая критика, притянута за уши и как всегда правда где-то посередине, но стоит ознакомиться со всеми точками зрения.

По мне так, про принципы SOLID лучше уже говорить когда у разработчика есть какой-то опыт. Если мы говорим о начинающих или джунах, то им разумеется лучше давать более конкретные советы. Так будет больше профита всем.

Есть ли более конкретные принципы, которые  стоит использовать, чтобы легко улучшишь свою кодовую базу? Смотрите, я уже делал посты про применение концепций функционального программирования и CQRS. Применив эти две концепции вы уже сможете писать гораздо более поддерживаемый и чистый код. К этим двум вещам, я бы еще добавил еще один.

Не бойтесь создавать объекты. Очень частая ошибка, особенно у начинающих, что они забывают про то, что у нас ООП язык и используют концепции процедурного языка. Отсюда появляются куча функций с более чем 5-ю параметрами, дублирование, избыточность, куча мутабельных полей и вот все эти головные боли. 

Совет как по мне очень простой, давайте на примере. Нужно в функцию передать 4 параметра? Сделайте специальный объект для этого. Из функции нужно вернуть пару значений вместо одного? Лучше сделать свой объект, а не стандартный Pair. Со стандартным Pair легче запутаться, особенно когда объекты одного типа. 

Когда мы используем объекты, мы зажимаем в некоторые тиски то, что можно передать в нашу функцию или класс. Другими словами, мы полагаемся на систему типов, которая за нас сможет отловить баги. Поэтому лучше отдавать предпочтение объектам, а не примитивам, когда появляется более менее сложная структура. 

Самый банальный пример тут это дата. У вас есть несколько вариантов как хранить дату в объекте, которую вы например получаете с бэка.
Первый вариант, это просто строка с уже форматированной датой. Второй вариант это конкретный объект например LocalDateTime. 

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

Часто мы пугаемся создавать объекты по причине того, что они якобы занимают память и нагружают GC. Вот тут вообще можно забить (если речь не идет о методе onDraw), это было проблемой на ранних версиях Android. Сейчас GC очень умный, настолько что порой даже создание ObjectPool получается дороже, чем просто создать объект.

BY Dev Easy Notes