Привет, меня зовут Поляков Павел, я 15+ лет в айти и я хороший разработчик. Так говорят мои коллеги, так говорят мои менеджеры, так я думаю про себя сам. У меня есть жгучее желание делиться знаниями с другими разработчиками и не только.
В этот канал я буду постить кусочки информации которую полезно было бы знать любому разработчику. В текстовом виде. А что еще интересно - у меня есть ТикТок: https://www.tiktok.com/@gooddevknows, где я в коротких видео тоже рассказываю о том, что знает хороший разработчик.
Поехали!
В этот канал я буду постить кусочки информации которую полезно было бы знать любому разработчику. В текстовом виде. А что еще интересно - у меня есть ТикТок: https://www.tiktok.com/@gooddevknows, где я в коротких видео тоже рассказываю о том, что знает хороший разработчик.
Поехали!
Хороший разработчик знает что такое OLTP и OLAP
В зависимости от того, что мы собираемся делать с данными, мы выбираем тип базы данных, где будем их хранить.
1️⃣ OLTP - online transaction processing
Цель - обеспечить ежедневную работу бизнеса. Например - пользователь делает заказ в интернет магазине, данные о заказе сохраняются в базу данных предназначенную для OLTP и обрабатываются дальше - со временем меняется статус заказа.
Для OLTP часто используют реляционные базы данных, например PostgreSQL.
2️⃣ OLAP - online analytical processing
Цель - принимать решения основываясь на большом объеме данных. Например, мы хотим посчитать среднюю сумму заказа за десять лет существования нашего интернет магазина. При этом в день делается 10 тысяч заказов.
Для OLAP часто используются колоночные базы данных, предназначенные бля бизнес аналитики, например Amazon Redshift.
⬛️ Еще раз OLTP - каждый день, для поддержки бизнес процессов; OLAP - когда нужно, для аналитики. Лучше не смешивать.
В зависимости от того, что мы собираемся делать с данными, мы выбираем тип базы данных, где будем их хранить.
1️⃣ OLTP - online transaction processing
Цель - обеспечить ежедневную работу бизнеса. Например - пользователь делает заказ в интернет магазине, данные о заказе сохраняются в базу данных предназначенную для OLTP и обрабатываются дальше - со временем меняется статус заказа.
Для OLTP часто используют реляционные базы данных, например PostgreSQL.
2️⃣ OLAP - online analytical processing
Цель - принимать решения основываясь на большом объеме данных. Например, мы хотим посчитать среднюю сумму заказа за десять лет существования нашего интернет магазина. При этом в день делается 10 тысяч заказов.
Для OLAP часто используются колоночные базы данных, предназначенные бля бизнес аналитики, например Amazon Redshift.
⬛️ Еще раз OLTP - каждый день, для поддержки бизнес процессов; OLAP - когда нужно, для аналитики. Лучше не смешивать.
Хороший разработчик знает что такое KISS, YAGNI и DRY
Есть универсальные принципы разработки, которые сделают код вашего сервиса или приложения понятнее и легче в поддержке.
1️⃣ KISS - keep it simple, stupid
Чем проще ваша программа, тем лучше она будет работать. Тем легче покрыть ее тестами. Не нужно выдумывать лишних абстракций, стараться сделать все максимально расширяемым в БУДУЩЕМ, делаем минимум, но хорошо, то есть просто и понятно.
2️⃣ YAGNI - you aren't gonna need it
Тебе это не понадобиться. Не нужно концентрироваться на облегчении своей жизни в будущем. Пытаться представить как программа будет изменяться в будущем и подстилать себе соломку. Чаще всего, изменяться она будет не так. А может не будет. А может и вовсе окажется что этот компонент не нужен, им никто не пользуется, тогда и расширять незачем - просто удаляем.
3️⃣ DRY - don't repeat yourself
Не повторяйся или не будь заложником копи-пэйста. Если один и тот же код используется более трех раз - вынесем его в отдельную функцию. Так его будет легче поддерживать. Но помни keep it simple, если это ведет к тому, что понять что происходит будет сложнее - оставим как есть, подождем еще.
⬛️ Еще раз - не надо усложнять сейчас, если это нужно будет в будущем - время найдется.
Есть универсальные принципы разработки, которые сделают код вашего сервиса или приложения понятнее и легче в поддержке.
1️⃣ KISS - keep it simple, stupid
Чем проще ваша программа, тем лучше она будет работать. Тем легче покрыть ее тестами. Не нужно выдумывать лишних абстракций, стараться сделать все максимально расширяемым в БУДУЩЕМ, делаем минимум, но хорошо, то есть просто и понятно.
2️⃣ YAGNI - you aren't gonna need it
Тебе это не понадобиться. Не нужно концентрироваться на облегчении своей жизни в будущем. Пытаться представить как программа будет изменяться в будущем и подстилать себе соломку. Чаще всего, изменяться она будет не так. А может не будет. А может и вовсе окажется что этот компонент не нужен, им никто не пользуется, тогда и расширять незачем - просто удаляем.
3️⃣ DRY - don't repeat yourself
Не повторяйся или не будь заложником копи-пэйста. Если один и тот же код используется более трех раз - вынесем его в отдельную функцию. Так его будет легче поддерживать. Но помни keep it simple, если это ведет к тому, что понять что происходит будет сложнее - оставим как есть, подождем еще.
⬛️ Еще раз - не надо усложнять сейчас, если это нужно будет в будущем - время найдется.
Хороший разработчик знает как что-то объяснить, часть 1
Разработка это не только написание кода, это еще и обсуждения, умение договариваться, умение делиться знаниями и объяснять.
Когда мы что-то рассказываем, то цели могут быть разные, одна из самых интересных это - объяснение. Например мы хотим объяснить, что новый фреймворк намного лучше, чем тот, что используется.
Когда мы что-то объясняем, мы помогаем слушателю ответить на вопрос "почему?". Почему, то что мы говорим это важно и стоит узнать больше про это? Объяснение снижает цену потребления информации. После того что он узнает, слушателю станет проще углубиться в тему самостоятельно.
Самая большая ошибка при объяснении, мы часто думаем, что те кто будут тебя слушать знают тоже что и мы. Это не так. Если начать говорить о том, что слушателю будет сложно понять, то есть большой риск что им станет сложно, не интересно, и они прекратят нас слушать.
Подумаем, кто будет нас слушать? Можно расположить слушателей на шкале понимания предмета.
Тем кто ближе к А нужно знать зачем это все нужно, а тем кто ближе к Z интересно знать как это сделать. В ходе объяснения мы помогаем слушателю двигаться от A до Z.
⬛️ Еще раз - резюмируем, после нашего объяснения, слушатель должен почувствовать, что он стал умнее. Дальше он сможет сам начать разбираться в теме или спросить у нас подробности.
Подписывайся, чтобы увидеть часть 2 - пошагово разберем как подготовить хорошее объяснение.
Разработка это не только написание кода, это еще и обсуждения, умение договариваться, умение делиться знаниями и объяснять.
Когда мы что-то рассказываем, то цели могут быть разные, одна из самых интересных это - объяснение. Например мы хотим объяснить, что новый фреймворк намного лучше, чем тот, что используется.
Когда мы что-то объясняем, мы помогаем слушателю ответить на вопрос "почему?". Почему, то что мы говорим это важно и стоит узнать больше про это? Объяснение снижает цену потребления информации. После того что он узнает, слушателю станет проще углубиться в тему самостоятельно.
Самая большая ошибка при объяснении, мы часто думаем, что те кто будут тебя слушать знают тоже что и мы. Это не так. Если начать говорить о том, что слушателю будет сложно понять, то есть большой риск что им станет сложно, не интересно, и они прекратят нас слушать.
Подумаем, кто будет нас слушать? Можно расположить слушателей на шкале понимания предмета.
Тем кто ближе к А нужно знать зачем это все нужно, а тем кто ближе к Z интересно знать как это сделать. В ходе объяснения мы помогаем слушателю двигаться от A до Z.
⬛️ Еще раз - резюмируем, после нашего объяснения, слушатель должен почувствовать, что он стал умнее. Дальше он сможет сам начать разбираться в теме или спросить у нас подробности.
Подписывайся, чтобы увидеть часть 2 - пошагово разберем как подготовить хорошее объяснение.