Ребята, я с радостью сделаю технические темы, главное пишите что вам интересно, а не просто общие фразы, чтобы по реакциям я мог понять за что голосует большинство.
Видео я действительно не снимаю, у меня сейчас в основном стримы, поэтому смотрите на вкладке "трансляции"
Видео я действительно не снимаю, у меня сейчас в основном стримы, поэтому смотрите на вкладке "трансляции"
👍34❤6💩3🤔1🤩1
Forwarded from Digital Ниндзя
Кстати, подумал, что почти все из гейт-кип тим очень любят государство, очень надеятся на него во всех вопросах. Это роднит их со скуфами. В чём прикол мема «Альтушка с госуслуг». Альтушка для скуфа — символ молодости, он грезит о юности, и альтушка должна приблизить его к этой самой юности. В возрасте у скуфа ворох проблем: жена, дети. Но скуф — этатист и паттерналист, он верит в государство и поддерживает его всеми силами. И государство поможет скуфу, в том числе, почувствовать себя молодым, выдав альтушку на госуслугах.
🤡71👍15🤮7😁4🤣2🤯1💯1
Я такой дичи от Саши Ильина не ожидал. Признаю, ошибся насчёт него, думал нормальный парень, оказалось у него тоже какие-то "гейт-кип", "скуфы'.
Жаль
Жаль
🤡66🤣26👍5💯5🖕5☃3😢1🫡1
Про технический контент
Я тут немного поресерчил каналы своих коллег, чтобы понять какие темы особо трогают сердца 💕 подписчиков.
✏️Что я нашел:
- самореклама, много саморекламы
- истории как с мидла залететь на сеньора
- мемасы о том какие все вокруг неправильные, уставшие, смешные, глупые и т.д.
- советы как стать джуном и научиться просить зарплату повыше
- токсичные посты о том как все плохо и подробное мнение автора на этот счет
- скринщоты коммертаиев с кучей матов и оскорблений, и ответы на комментарии в этом же стили
- базовые howto видео и статьи о том что такое SOLID, gof, grasp и т.д.
- безмерно большое количество подкастов о том как строить команды, управлять людьми, почему Y (подставь по вкусу) - это неважно
- и прочие вещи которые вообще не помогут никому и никогда стать хорошим инженером
❤️ Чего я хотел бы найти:
- посты о том как люди пишут код, с мини отчетамии о том что получается, что нет
- анализ новостей, трендов с мнением автора (без воды)
- примеры реальных кейсов по проектированию и разработке (с решением)
- статистика и анализ по исследованию кодовых баз
- автоматизации и улучшения процессов разработки с цифрами
Чтобы мне зарядиться хорошей энергией и начать писать посты из второй группы, посоветуйте в комментартях каналы где есть такой контент.
Я тут немного поресерчил каналы своих коллег, чтобы понять какие темы особо трогают сердца 💕 подписчиков.
✏️Что я нашел:
- самореклама, много саморекламы
- истории как с мидла залететь на сеньора
- мемасы о том какие все вокруг неправильные, уставшие, смешные, глупые и т.д.
- советы как стать джуном и научиться просить зарплату повыше
- токсичные посты о том как все плохо и подробное мнение автора на этот счет
- скринщоты коммертаиев с кучей матов и оскорблений, и ответы на комментарии в этом же стили
- базовые howto видео и статьи о том что такое SOLID, gof, grasp и т.д.
- безмерно большое количество подкастов о том как строить команды, управлять людьми, почему Y (подставь по вкусу) - это неважно
- и прочие вещи которые вообще не помогут никому и никогда стать хорошим инженером
❤️ Чего я хотел бы найти:
- посты о том как люди пишут код, с мини отчетамии о том что получается, что нет
- анализ новостей, трендов с мнением автора (без воды)
- примеры реальных кейсов по проектированию и разработке (с решением)
- статистика и анализ по исследованию кодовых баз
- автоматизации и улучшения процессов разработки с цифрами
Чтобы мне зарядиться хорошей энергией и начать писать посты из второй группы, посоветуйте в комментартях каналы где есть такой контент.
❤52🔥13👍7🤡3💯1
У меня была попытка два года назад делать видео с аналитикой кодовых баз.
Я делал анализ репозитория NPM думаю, что интересно было бы возобновить подобную активность.
Что скажете?
Я делал анализ репозитория NPM думаю, что интересно было бы возобновить подобную активность.
Что скажете?
YouTube
Анализирую NPM (начало)
#soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - https://t.iss.one/softwareengineervlog
Спонсорство - https://donate.s0er.ru
Сайт платным контентом - https://soer.pro
Зеркало для видео Дзен Видео - https://zen.yandex.ru/i…
Основной канал для общения и публикации новых видео - Телегарм - https://t.iss.one/softwareengineervlog
Спонсорство - https://donate.s0er.ru
Сайт платным контентом - https://soer.pro
Зеркало для видео Дзен Видео - https://zen.yandex.ru/i…
👍131🔥35🤡3
Что такое "профессионализм"
Разрабы часто испытывают чувство неуверенности в своих знаниях и страдают от синдрома самозванца.
Между тем, понять насколько твой уровень высок очень просто - открываешь исходный код на гитхаб любого проекта (по твоей специализации) и делаешь три вещи:
1) разворачиваешь репо и запускаешь код;
2) читаешь код и разбираешься, что он делает;
3) модифицируешь код, добавляя новую фичу или исправляя баг.
Если все три пункта можешь сделать "на изи" для произвольного проекта, то можно перестать волноваться о своих скилах, у тебя все ок.
И совершенно неважно, что кто-то может назвать 100500 причин почему код проекта ужасен, почему архитектура должна быть другой или любая иная критика, которая может быть полезной для развития проекта, а может быть просто словоблудием. Важно только одно - уметь запустить и внести изменение в любой проект.
Отсюда вопрос к дорогому читателю- когда вы последний раз пробовали работать с чужим кодом? Что это было и какие результаты получили?
SOER | PRO | Boosty
Разрабы часто испытывают чувство неуверенности в своих знаниях и страдают от синдрома самозванца.
Между тем, понять насколько твой уровень высок очень просто - открываешь исходный код на гитхаб любого проекта (по твоей специализации) и делаешь три вещи:
1) разворачиваешь репо и запускаешь код;
2) читаешь код и разбираешься, что он делает;
3) модифицируешь код, добавляя новую фичу или исправляя баг.
Если все три пункта можешь сделать "на изи" для произвольного проекта, то можно перестать волноваться о своих скилах, у тебя все ок.
И совершенно неважно, что кто-то может назвать 100500 причин почему код проекта ужасен, почему архитектура должна быть другой или любая иная критика, которая может быть полезной для развития проекта, а может быть просто словоблудием. Важно только одно - уметь запустить и внести изменение в любой проект.
Отсюда вопрос к дорогому читателю- когда вы последний раз пробовали работать с чужим кодом? Что это было и какие результаты получили?
SOER | PRO | Boosty
👍59🤔6
Go вошел в топ 10 языков программирования
Согласно рейтингу TIOBE, который оценивает интерес к языкам программирования по количеству поисковых запросов, еще год назад Go был за пределами десятки, а сейчас занимает 7-ое место. За год ему удалось подняться на 6 позиций (с 13 на 7 место).
Когда языки программированию так быстро набирают обороты, всегда хочется задать вопрос: Почему?
Стандартный ответ: быстрый, простой, стабильный, изначально заточенный на параллелизм.
Правдивый ответ: грамотный маркетинг и многолетние денежные вливания от Google
Ситуация ровно такая же как в свое время с Java - есть мощная компания, которая имеет огромное влияние на рынок, есть свои требования, предъявляемые к разработчикам, есть большая часть собственного ПО (в том числе OpenSource), следовательно есть возможность создавать спрос на новый ЯП.
В итоге компания постепенно продавливает ситуацию, формируя спрос на услуги Go разработчиков. Разработчиков на Go не так много, зарплаты на новый язык чуть выше, отсюда возникает интерес и новый драйвер развития.
Заметный рост популярности языка Go начался после 2016 года, это связано с тем, что язык "оброс" нужными библиотеками и фреймворками.
В современном мире все языки заметно двигаются за счет Веба. В период с 2012 по 2016 для Go были созданы такие фреймворки как Gin, Beego, Iris и другие, которые отлично подходят для веб разработки.
Так же Go стал популярен благодаря активному использованию в микросервисах (go-kit, go-micro и т.д.)
Резюмируя выше сказанное - язык перспективный, не заставляет программиста излишне страдать при написании программ, имеет сильную поддержку в мире, новые компании активно внедряют решения на Go в свой стек.
Но если выбирать между Java и Go, по-прежнему стоит учитывать, что легаси-коду, написанному на Java, жить еще много лет, и пока у Go не будет такого же "шлейфа" из махрового ПО, тренд может в любой момент схлопнуться.
SOER | PRO | Boosty
Согласно рейтингу TIOBE, который оценивает интерес к языкам программирования по количеству поисковых запросов, еще год назад Go был за пределами десятки, а сейчас занимает 7-ое место. За год ему удалось подняться на 6 позиций (с 13 на 7 место).
Когда языки программированию так быстро набирают обороты, всегда хочется задать вопрос: Почему?
Стандартный ответ: быстрый, простой, стабильный, изначально заточенный на параллелизм.
Правдивый ответ: грамотный маркетинг и многолетние денежные вливания от Google
Ситуация ровно такая же как в свое время с Java - есть мощная компания, которая имеет огромное влияние на рынок, есть свои требования, предъявляемые к разработчикам, есть большая часть собственного ПО (в том числе OpenSource), следовательно есть возможность создавать спрос на новый ЯП.
В итоге компания постепенно продавливает ситуацию, формируя спрос на услуги Go разработчиков. Разработчиков на Go не так много, зарплаты на новый язык чуть выше, отсюда возникает интерес и новый драйвер развития.
Заметный рост популярности языка Go начался после 2016 года, это связано с тем, что язык "оброс" нужными библиотеками и фреймворками.
В современном мире все языки заметно двигаются за счет Веба. В период с 2012 по 2016 для Go были созданы такие фреймворки как Gin, Beego, Iris и другие, которые отлично подходят для веб разработки.
Так же Go стал популярен благодаря активному использованию в микросервисах (go-kit, go-micro и т.д.)
Резюмируя выше сказанное - язык перспективный, не заставляет программиста излишне страдать при написании программ, имеет сильную поддержку в мире, новые компании активно внедряют решения на Go в свой стек.
Но если выбирать между Java и Go, по-прежнему стоит учитывать, что легаси-коду, написанному на Java, жить еще много лет, и пока у Go не будет такого же "шлейфа" из махрового ПО, тренд может в любой момент схлопнуться.
SOER | PRO | Boosty
👍47
Кирилл Мокевнин выдал интересный пост про Осознанную Меркантильность. Интересно потому что на мой взгляд Хекслет долгое время была одной из лучших школ, которые я видел на рынке.
Потом, года три назад, Кирилл в подкасте у Мы обречены начал говорить о том, что в плане бизнеса либо "качество", либо "массовость". После чего приоритеты Хекслета явно начали меняться в сторону массовости.
И вот внезапный интерес к накрутке опыта. Значит ли это, что теперь Хекслет будет предлагать своим ученикам составлять "правильные" резюме? Что думаете?
Потом, года три назад, Кирилл в подкасте у Мы обречены начал говорить о том, что в плане бизнеса либо "качество", либо "массовость". После чего приоритеты Хекслета явно начали меняться в сторону массовости.
И вот внезапный интерес к накрутке опыта. Значит ли это, что теперь Хекслет будет предлагать своим ученикам составлять "правильные" резюме? Что думаете?
Telegram
Организованное программирование | Кирилл Мокевнин
Нормально ли накручивать опыт в резюме?
Последние полтора, может два года, с этой темой мощно вошел в индустрию Антон Назаров, вызвав такое бурление, что до сих пор земля дрожит. Правда сам я наблюдал за это со стороны, не участвуя и не особо вникая в то…
Последние полтора, может два года, с этой темой мощно вошел в индустрию Антон Назаров, вызвав такое бурление, что до сих пор земля дрожит. Правда сам я наблюдал за это со стороны, не участвуя и не особо вникая в то…
🤡31🤔11😐2❤1👍1👀1
На гитхаб набирает обороты решение, которое использует схему генерации кода, описанную мной ещё в 2017 году.
Суть следующая:
1. Тесты выступают в роли дескриминатора, т.е. пока тесты не пройдут, сгенирированный код не будет принят;
2. ИИ генерирует код пока не будут пройдены тесты.
Таким образом ИИ можно поручить уже более осмысленные задачи. И пока идёт генерация, человек занимается чем-то полезным. Например, смотрит рилсы.
По идее следующий шаг - это dsl для тестов, который будет приближен к естественным языкам.
Суть следующая:
1. Тесты выступают в роли дескриминатора, т.е. пока тесты не пройдут, сгенирированный код не будет принят;
2. ИИ генерирует код пока не будут пройдены тесты.
Таким образом ИИ можно поручить уже более осмысленные задачи. И пока идёт генерация, человек занимается чем-то полезным. Например, смотрит рилсы.
По идее следующий шаг - это dsl для тестов, который будет приближен к естественным языкам.
GitHub
GitHub - BuilderIO/micro-agent: An AI agent that writes (actually useful) code for you
An AI agent that writes (actually useful) code for you - BuilderIO/micro-agent
👍64😁17🤡8🔥5
Решение проблемы избыточных состояний через конечные автоматы
Часто замечаю в коде у фронтенд-разработчиков такой паттерн, как выражение одного логического состояния через несколько состояний в коде. Рассмотрим, например, такой код на React, который описывает состояние некоторой формы:
Здесь разработчик создает целых три разных независимых состояний в коде (состояние ошибки, состояние загрузки, состояние успеха), но логически весь этот код отвечает за состояние формы - то есть за одно и то же состояние. Это одна форма, которая может либо находиться в одном из четырех состояний:
1. в состоянии загрузки
2. в состоянии ошибки
3. в состоянии успеха
4. в состоянии готовности к редактированию.
Несложно посчитать, что код выше сгенерирует нам целых восемь различных состояний вместо четырех необходимых. Помимо запутанности и сложночитаемости, такой код плох тем, что мы генерируем недостижимые состояния, которые непонятно, как обрабатывать. Например, что делать, если у нас одновременно есть ошибка и переменная isSuccessful равна true? Скорее всего, программист выберет какое-то одно состояние как приоритетное, но так или иначе, такой код будет порождать запутанность и баги.
Выход из этой ситуации - это использование конечных автоматов. Конечный автомат - это математическая модель, описывающая конечный набор возможных состояний и определяющая, что автомат может находится только в одном из этих состояний в конкретный момент времени. Также автомат может переходить из одного состояния в другое. В коде на React конечный автомат можно довольно создать, используя редюсер, а возможные состояния удобно описываются через тип-сумму:
Созданные formReducer и initialState мы можем использовать в нашем компоненте через useReducer. Таким образом, мы получили удобное декларативное описание возможных состояний нашей системы, а также совокупность переходов из одного состояния в другое.
Часто замечаю в коде у фронтенд-разработчиков такой паттерн, как выражение одного логического состояния через несколько состояний в коде. Рассмотрим, например, такой код на React, который описывает состояние некоторой формы:
const [error, setError] = useState<string | undefined>(); // в форме есть ошибки
const [loading, setLoading] = useState<boolean>(false); // форма загружается на сервер
const [isSuccessful, setIsSuccessful] = useState<boolean>(false); // форма успешно отправлена
Здесь разработчик создает целых три разных независимых состояний в коде (состояние ошибки, состояние загрузки, состояние успеха), но логически весь этот код отвечает за состояние формы - то есть за одно и то же состояние. Это одна форма, которая может либо находиться в одном из четырех состояний:
1. в состоянии загрузки
2. в состоянии ошибки
3. в состоянии успеха
4. в состоянии готовности к редактированию.
Несложно посчитать, что код выше сгенерирует нам целых восемь различных состояний вместо четырех необходимых. Помимо запутанности и сложночитаемости, такой код плох тем, что мы генерируем недостижимые состояния, которые непонятно, как обрабатывать. Например, что делать, если у нас одновременно есть ошибка и переменная isSuccessful равна true? Скорее всего, программист выберет какое-то одно состояние как приоритетное, но так или иначе, такой код будет порождать запутанность и баги.
Выход из этой ситуации - это использование конечных автоматов. Конечный автомат - это математическая модель, описывающая конечный набор возможных состояний и определяющая, что автомат может находится только в одном из этих состояний в конкретный момент времени. Также автомат может переходить из одного состояния в другое. В коде на React конечный автомат можно довольно создать, используя редюсер, а возможные состояния удобно описываются через тип-сумму:
type FormState = {
state: 'loading';
} | {
state: 'error';
message: string;
} | {
state: 'ready';
} | {
state: 'successful';
}
type FormAction = {
type: 'set_loading'
} | {
type: 'set_error',
payload: {
error_message: string;
}
} | {
type: 'set_ready',
} | {
type: 'set_successful'
}
const initialState: FormState = { state: 'ready' };
const formReducer = (state: FormState, action: FormAction):FormState => {
// ...
}Созданные formReducer и initialState мы можем использовать в нашем компоненте через useReducer. Таким образом, мы получили удобное декларативное описание возможных состояний нашей системы, а также совокупность переходов из одного состояния в другое.
👍108
И снова "бабкина логика"
Итак, если человек прыгнул с 10го этажа и не разбился, значит ли это что прыгать с 10го этажа безопасно? Казалось бы, ответ очевиден, даже не зная статистику, понятно, что на основе одного случая строить умозаключение нельзя.
Но это очевидно не для всех. Недавно в узких кругах пролетела новость, что один из серых братьев таки умудрился пройти собес у одного из лучших соеров - Вани Ботанова, и не просто пройти, а получить оффер на сеньора. Потом оказалось, что офер он не получил (завалил "culture fit" и не прошел "background check") и не на сеньора, а на мидла.
Почему же сторонникам альтернативных методик попадания в АйТи решили распиарить такой сомнительный кейс? Для меня очевидно, что Ваня - сильный соер, и для них это дело принципа доказать, что они не хуже. Но если других успехов нет, то надо брать что есть. В итоге пришлось приукрасить реальность, чтобы сделать "Новость мирового масштаба"?
Дело в том, что Ваня собеседует людей постоянно, поэтому к нему регулярно приходят накрутчики. Давайте попытаемся прикинуть эффективность прохождения собесов с накруткой.
Обычно в "паровозике" (это новое ноу-хау от людей, которые пытаются изменить мир, о нем как-нибудь в другой раз) участвует не менее 10 человек. Исходя из того, что других новостей нет, делаем вывод - из 10 человек собес смог пройти всего 1.
Считаем КПД, получаем 10%. На мой взгляд такой результат совсем никуда не годится. Но маркетинг беспощадная штука, поэтому надо просто скрыть количество неудач, и "бабкина логика" сделает свое дело - если "один смог, значит все смогли".
Хорошо, что бОльшая часть соеров умеет в аналитику и сразу отсекает такие тейки, но всегда найдутся люди, которые поверят и будут думать, что метод рабочий.
Чуваку, который смог пройти собес - респект, ты реально крут! Тем кто не прошел, не расстраивайтесь, ведь главное верить и все получится. Тем более, что Ваня прямо говорит, что если техскилы нормальные, то его не волнует приписывание опыта. Так что качайте харды и все будет хорошо!
SOER | PRO | Boosty
Итак, если человек прыгнул с 10го этажа и не разбился, значит ли это что прыгать с 10го этажа безопасно? Казалось бы, ответ очевиден, даже не зная статистику, понятно, что на основе одного случая строить умозаключение нельзя.
Но это очевидно не для всех. Недавно в узких кругах пролетела новость, что один из серых братьев таки умудрился пройти собес у одного из лучших соеров - Вани Ботанова, и не просто пройти, а получить оффер на сеньора. Потом оказалось, что офер он не получил (завалил "culture fit" и не прошел "background check") и не на сеньора, а на мидла.
Почему же сторонникам альтернативных методик попадания в АйТи решили распиарить такой сомнительный кейс? Для меня очевидно, что Ваня - сильный соер, и для них это дело принципа доказать, что они не хуже. Но если других успехов нет, то надо брать что есть. В итоге пришлось приукрасить реальность, чтобы сделать "Новость мирового масштаба"?
Дело в том, что Ваня собеседует людей постоянно, поэтому к нему регулярно приходят накрутчики. Давайте попытаемся прикинуть эффективность прохождения собесов с накруткой.
Обычно в "паровозике" (это новое ноу-хау от людей, которые пытаются изменить мир, о нем как-нибудь в другой раз) участвует не менее 10 человек. Исходя из того, что других новостей нет, делаем вывод - из 10 человек собес смог пройти всего 1.
Считаем КПД, получаем 10%. На мой взгляд такой результат совсем никуда не годится. Но маркетинг беспощадная штука, поэтому надо просто скрыть количество неудач, и "бабкина логика" сделает свое дело - если "один смог, значит все смогли".
Хорошо, что бОльшая часть соеров умеет в аналитику и сразу отсекает такие тейки, но всегда найдутся люди, которые поверят и будут думать, что метод рабочий.
Чуваку, который смог пройти собес - респект, ты реально крут! Тем кто не прошел, не расстраивайтесь, ведь главное верить и все получится. Тем более, что Ваня прямо говорит, что если техскилы нормальные, то его не волнует приписывание опыта. Так что качайте харды и все будет хорошо!
SOER | PRO | Boosty
🔥37👍21🤡19❤6💊3
Инженерные задачи
Программистов много, а инженеров мало. Многие приравнивают программистов и инженеров, но я не согласен с таким упрощением.
Чтобы понять разницу между программистом и инженером надо посмотреть на задачи, которые решают те и другие.
Для программиста стандартная задача сводится к "разработай интерфейс", "сделай компонент", "настрой роутинг", "оптимизируй запрос". С позиции сложности такие задачи вполне могут вызвать взрыв мозга, поэтому однозначно сказать, что все задачи программиста любой может решить не напрягаясь - неправильно.
Можно спорить, что компонент, написанный джуном, будет архитектурно плох, тормозить или еще как-то не так работать, а вот сеньор сделает красиво и безупречно. На практике всем пофиг. Код - есть код. А пользователь давно приучен "программирование - это сложно, ошибки неизбежны".
Сложность у программиста обычно комбинаторного характера - слишком много частных случаев, которые нужно комплексирвоать между собой, трудно найти общее решение, нужно запоминать много частных случаев и т.д.
Для инженера задачи выглядят совсем иначе: "написать утилиту определяющую износ жесткого диска", "разработать библиотеку для анализа таймсириес данных, для поиска корневой причины", "сделать модуль проактивного мониторинга", "разработать модуль коммутации для IP-телефонии" и т.д.
Существенным отличием является то, что поставленная перед инженером задача не имеет готового решения или алгоритма действий. Высокая степень неизвестного (обычно около 50%) , для написания кода требуется получить решение в аналитическом виде, а потом закодировать. На этапе кодирования можно разделить задачу на подзадачи и отдать решение программистам.
Когда я работал над системами мониторинга, большую часть времени я занимался тем, что искал модели корреляции между разрозненными событиями, учился отличать "информационный шум", вырабатывал метрики оптимального потребления ресурсов, решал архитектурные вопрос на уровне системы и т.д.
После имплементации решения занимался тюнингом и проверкой корректности, для этого генерировать разные синтетические наборы данных, чтобы проверить гипотезы и удостовериться в корректности работы разработанной системы. И делать много другой аналитической работы.
Большинство инженерных задач лежат в области работы с данными, моделями, архитектурой, декомпозицией, а не написанием кода. Инженеры используют ЯП ровно для того ради чего они создавались - закодировать описанное решение.
Сейчас многие работы раскиданы по специалистам разного профиля - data-инженеры, QA, кодеры, архитекторы. Но провести абсолютно ровные границы между обязанностями невозможно, поэтому конечное разбиение будет сильно разным от компании к компании.
Мы не можем взять человека на должность программиста, давать ему только задачи на кодирование и надеяться, что он после некоторого количества задач вдруг научится решать инженерные задачи. Это принципиально разные вещи, поэтому инженерное образование и образование программиста нужно рассматривать отдельно.
SOER | PRO | Boosty
Программистов много, а инженеров мало. Многие приравнивают программистов и инженеров, но я не согласен с таким упрощением.
Чтобы понять разницу между программистом и инженером надо посмотреть на задачи, которые решают те и другие.
Для программиста стандартная задача сводится к "разработай интерфейс", "сделай компонент", "настрой роутинг", "оптимизируй запрос". С позиции сложности такие задачи вполне могут вызвать взрыв мозга, поэтому однозначно сказать, что все задачи программиста любой может решить не напрягаясь - неправильно.
Можно спорить, что компонент, написанный джуном, будет архитектурно плох, тормозить или еще как-то не так работать, а вот сеньор сделает красиво и безупречно. На практике всем пофиг. Код - есть код. А пользователь давно приучен "программирование - это сложно, ошибки неизбежны".
Сложность у программиста обычно комбинаторного характера - слишком много частных случаев, которые нужно комплексирвоать между собой, трудно найти общее решение, нужно запоминать много частных случаев и т.д.
Для инженера задачи выглядят совсем иначе: "написать утилиту определяющую износ жесткого диска", "разработать библиотеку для анализа таймсириес данных, для поиска корневой причины", "сделать модуль проактивного мониторинга", "разработать модуль коммутации для IP-телефонии" и т.д.
Существенным отличием является то, что поставленная перед инженером задача не имеет готового решения или алгоритма действий. Высокая степень неизвестного (обычно около 50%) , для написания кода требуется получить решение в аналитическом виде, а потом закодировать. На этапе кодирования можно разделить задачу на подзадачи и отдать решение программистам.
Когда я работал над системами мониторинга, большую часть времени я занимался тем, что искал модели корреляции между разрозненными событиями, учился отличать "информационный шум", вырабатывал метрики оптимального потребления ресурсов, решал архитектурные вопрос на уровне системы и т.д.
После имплементации решения занимался тюнингом и проверкой корректности, для этого генерировать разные синтетические наборы данных, чтобы проверить гипотезы и удостовериться в корректности работы разработанной системы. И делать много другой аналитической работы.
Большинство инженерных задач лежат в области работы с данными, моделями, архитектурой, декомпозицией, а не написанием кода. Инженеры используют ЯП ровно для того ради чего они создавались - закодировать описанное решение.
Сейчас многие работы раскиданы по специалистам разного профиля - data-инженеры, QA, кодеры, архитекторы. Но провести абсолютно ровные границы между обязанностями невозможно, поэтому конечное разбиение будет сильно разным от компании к компании.
Мы не можем взять человека на должность программиста, давать ему только задачи на кодирование и надеяться, что он после некоторого количества задач вдруг научится решать инженерные задачи. Это принципиально разные вещи, поэтому инженерное образование и образование программиста нужно рассматривать отдельно.
SOER | PRO | Boosty
👍78🤡13
Люблю статьи про анализ кода, особенно когда речь заходит об анализе кода ядра Freax.
Когда анализируешь старые кодовые базы, котороые получили невероятное развитие, то видишь как работают эволюционные методы разработки проекта, не только в коде, но и архитектуре.
На ранних стадиях вполне допустимы жёсткие связи и отсутствие границ между частями программы, которые реализуют разную бизнес логику, и в будущем скорее всего получат свои интерфейсы и будут развиваться отдельно. Возможно даже поддерживаться отдельными командами разрабов.
Такое упрощение на ранних стадиях позволяет все сосредоточить в одних руках, не тратить время на дополнительный анализ, не создавать дополнительную сложность и не размывать фокус внимания.
Разговоры о красивом коде тоже быстро разбиваются, когда видишь гигантов с миллионами строк кода, прочитать который- это целое искусство.
Так что рекомендую начать изучать исходники и прочитать статью по ссылке выше.
Когда анализируешь старые кодовые базы, котороые получили невероятное развитие, то видишь как работают эволюционные методы разработки проекта, не только в коде, но и архитектуре.
На ранних стадиях вполне допустимы жёсткие связи и отсутствие границ между частями программы, которые реализуют разную бизнес логику, и в будущем скорее всего получат свои интерфейсы и будут развиваться отдельно. Возможно даже поддерживаться отдельными командами разрабов.
Такое упрощение на ранних стадиях позволяет все сосредоточить в одних руках, не тратить время на дополнительный анализ, не создавать дополнительную сложность и не размывать фокус внимания.
Разговоры о красивом коде тоже быстро разбиваются, когда видишь гигантов с миллионами строк кода, прочитать который- это целое искусство.
Так что рекомендую начать изучать исходники и прочитать статью по ссылке выше.
Хабр
Исследуем внутренности Linux версии 0.01
Ядро Linux считается ужасно масштабным опенсорсным ПО. Последняя на момент написания этой статьи версия 6.5-rc5 состоит из 36 миллионов строк кода. Само собой, Linux — это плод упорного многолетнего...
👍52
Файлы или СУБД
Задача: в каких случаях использовать СУБД, а в каких файлы для работы с данными.
Краткое сравнение
Золотым стандартом хранения данных в архитектуре современных программ является хранение в базе данных. Не сильно ошибусь, если скажу, что в произвольном проекте сложнее Hello World на этапе проектирования будет заложена СУБД.
В большинстве случаев это оправданное решение, которое отработано во многих проектах, имеет понятные способы масштабирования, управления и скорее всего не испортит проект.
Преимущество СУБД с позиции архитектора:
- унифицированный способ хранения и обработки (стандартизация CRUD);
- быстрый поиск, агрегация и извлечение данных;
- логика обработки может быть объединена с данными;
- возможность проверить ограничения на уровне СУБД;
- стандартны API для работы с СУБД, что позволяет подключать разные приложения;
- безопасность и резервное копирование делаются по готовым шаблонам;
- большой запас прочности для роста проекта;
- унификация описания структур и связей между данными.
Недостатки:
- дополнительная сложность на этапе сопровождения;
- недостатки "черного ящика" - не всегда возможно понять причину проблем, так как разработчик СУБД, как правило, стороннее лицо;
- производительность и масштабирование требует дополнительной квалификации, не всегда делается правильно;
- привязка к вендору (вендорлок);
- усложнение за счет дополнительных абстракции ну уровне БЛ (например, ORM).
Вместо СУБД можно использовать другой способ: хранение данных в файлах. Такое решение имеет следующие преимущества:
- хранение неизменяемых данных (или в случае изменения части данных полностью перезаписывается весь набор);
- быстрый инкремент данных;
- простой способ хранения данных;
- не требует повышения уровня абстракции (нет дополнительных слоев в архитектуре, в существующей архитектуре добавляется модуль для работы с данными);
- низкое зацепление данных (каждый файл - собственный неймспейс, который не обязан быть связан с другими файлами);
- свобода в выборе структуры данных и способах их обработки;
- простой способ интеграции приложений, не требует доп. драйверов и протоколов;
- легко передавать, хранить, архивировать, шифровать данные;
- возможность использовать текстовые и бинарные форматы;
Недостатки:
- медленная вставка "в середину" данных;
- логика отделена от самих данных, каждое приложение должно реализовывать свой парсинг и обработку данных;
- ограничения на размеры файлов и их количество со стороны файловых систем;
- контроль за схемами данных и их связями лежит на приложении;
- приходится "велосипедить" для обычных CRUD задач, обычно с просадкой по скорости.
Вывод
Рассматривать файлы в качестве основного способа хранения и обработки данных смысла не имеет, лучше сразу заложить СУБД, однако файлы отлично подходят в качестве вспомогательного инструмента для решения следующих задач:
- промежуточное накопление сырых данных для последующей обработки;
- ведения различных текстовых или бинарных логов (как текстовых, так и лога изменений данных, например, может использоваться в Event Sourcing);
- ведения журналов аудита (в отличие от лога имеет дополнительные требования, исключающие подмену данных, что потребует дополнительных тех. решений);
- экспорт/импорт данных (файлы замечательно подходят для промежуточного хранения и конвертирования);
- как элемент распределенных транзакций.
Реакции влияют на темы постов:
100 x 💡 - пост по архитектуре
100 х 🥷 - пост про код
100 х 👑 - пост про профессиональный рост
#архитектура #знания
SOER | PRO | Boosty
Задача: в каких случаях использовать СУБД, а в каких файлы для работы с данными.
Краткое сравнение
Золотым стандартом хранения данных в архитектуре современных программ является хранение в базе данных. Не сильно ошибусь, если скажу, что в произвольном проекте сложнее Hello World на этапе проектирования будет заложена СУБД.
В большинстве случаев это оправданное решение, которое отработано во многих проектах, имеет понятные способы масштабирования, управления и скорее всего не испортит проект.
Преимущество СУБД с позиции архитектора:
- унифицированный способ хранения и обработки (стандартизация CRUD);
- быстрый поиск, агрегация и извлечение данных;
- логика обработки может быть объединена с данными;
- возможность проверить ограничения на уровне СУБД;
- стандартны API для работы с СУБД, что позволяет подключать разные приложения;
- безопасность и резервное копирование делаются по готовым шаблонам;
- большой запас прочности для роста проекта;
- унификация описания структур и связей между данными.
Недостатки:
- дополнительная сложность на этапе сопровождения;
- недостатки "черного ящика" - не всегда возможно понять причину проблем, так как разработчик СУБД, как правило, стороннее лицо;
- производительность и масштабирование требует дополнительной квалификации, не всегда делается правильно;
- привязка к вендору (вендорлок);
- усложнение за счет дополнительных абстракции ну уровне БЛ (например, ORM).
Вместо СУБД можно использовать другой способ: хранение данных в файлах. Такое решение имеет следующие преимущества:
- хранение неизменяемых данных (или в случае изменения части данных полностью перезаписывается весь набор);
- быстрый инкремент данных;
- простой способ хранения данных;
- не требует повышения уровня абстракции (нет дополнительных слоев в архитектуре, в существующей архитектуре добавляется модуль для работы с данными);
- низкое зацепление данных (каждый файл - собственный неймспейс, который не обязан быть связан с другими файлами);
- свобода в выборе структуры данных и способах их обработки;
- простой способ интеграции приложений, не требует доп. драйверов и протоколов;
- легко передавать, хранить, архивировать, шифровать данные;
- возможность использовать текстовые и бинарные форматы;
Недостатки:
- медленная вставка "в середину" данных;
- логика отделена от самих данных, каждое приложение должно реализовывать свой парсинг и обработку данных;
- ограничения на размеры файлов и их количество со стороны файловых систем;
- контроль за схемами данных и их связями лежит на приложении;
- приходится "велосипедить" для обычных CRUD задач, обычно с просадкой по скорости.
Вывод
Рассматривать файлы в качестве основного способа хранения и обработки данных смысла не имеет, лучше сразу заложить СУБД, однако файлы отлично подходят в качестве вспомогательного инструмента для решения следующих задач:
- промежуточное накопление сырых данных для последующей обработки;
- ведения различных текстовых или бинарных логов (как текстовых, так и лога изменений данных, например, может использоваться в Event Sourcing);
- ведения журналов аудита (в отличие от лога имеет дополнительные требования, исключающие подмену данных, что потребует дополнительных тех. решений);
- экспорт/импорт данных (файлы замечательно подходят для промежуточного хранения и конвертирования);
- как элемент распределенных транзакций.
100 x
100 х
100 х
#архитектура #знания
SOER | PRO | Boosty
Please open Telegram to view this post
VIEW IN TELEGRAM