Про технический контент
Я тут немного поресерчил каналы своих коллег, чтобы понять какие темы особо трогают сердца 💕 подписчиков.
✏️Что я нашел:
- самореклама, много саморекламы
- истории как с мидла залететь на сеньора
- мемасы о том какие все вокруг неправильные, уставшие, смешные, глупые и т.д.
- советы как стать джуном и научиться просить зарплату повыше
- токсичные посты о том как все плохо и подробное мнение автора на этот счет
- скринщоты коммертаиев с кучей матов и оскорблений, и ответы на комментарии в этом же стили
- базовые 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
Публикую серию гостевых постов от @YinKio:
Гибкая архитектура. Взглаяд через призму ответственности
Ряд кратких постов о построении гибкой архитектуры с точки зрения распределения ответственности.
- Критерии
- Принципы
- Инструменты
Ознакомление с ними может повысить вероятность сохранения гибкости архитектуры на длительном промежутке времени.
Гибкая архитектура. Взглаяд через призму ответственности
Ряд кратких постов о построении гибкой архитектуры с точки зрения распределения ответственности.
- Критерии
- Принципы
- Инструменты
Ознакомление с ними может повысить вероятность сохранения гибкости архитектуры на длительном промежутке времени.
👍11
Критерии гибкости архитектуры
Гибкая архитектура - это архитектура, способная эффективно адаптироваться к изменяющимся требованиям масштабируемости, функциональности и безопасности системы; это архитектура, которую удобно использовать.
Построение гибкой архитектуры невозможно без понимания критериев, согласно которым её можно назвать гибкой.
Самый важный критерий - это результат. Результатом качественной архитектуры является высокая скорость внесения изменений в работу приложения.
Остальные критерии являются косвенными. Это значит, что соблюдение каждого из них увеличивает вероятность сохранения максимальной скорости внесения изменений в продукт, однако не гарантирует её высокие показатели.
Важность косвенного критерия зависит от состояния текущего проекта. Выбирать, какой из них имеет наибольший приоритет, нужно исходя из тактических и стратегических преимуществ, которые они принесут в случае их успешного соблюдения. Выработка чёткой стратегии оценки важности критериев, а также методы их измерения - тема очень интересная, однако выходит за рамки этого ряда постов.
В зависимости от автора косвенные критерии могут очень сильно отличаться друг от друга. Ниже я привожу краткий и далеко не полный список важных критериев.
Перечень косвенных критериев
- Ясность и читаемость кода - чем выше, тем лучше.
- Распределение ответственности между компонентами
- Покрытие юнит тестами - средний оптимальный показатель 80%
- Степень связанности кода (coupling) - чем ниже, тем лучше
- Скорость рефакторинга
- Скорость тестирования
Понимание критериев и умение расставлять приоритеты на основании состояния текущего проекта может помочь в построении гибкой архитектуры. Однако от них мало пользы, если не знать принципы и инструменты построения архитектуры.
Гибкая архитектура - это архитектура, способная эффективно адаптироваться к изменяющимся требованиям масштабируемости, функциональности и безопасности системы; это архитектура, которую удобно использовать.
Построение гибкой архитектуры невозможно без понимания критериев, согласно которым её можно назвать гибкой.
Самый важный критерий - это результат. Результатом качественной архитектуры является высокая скорость внесения изменений в работу приложения.
Остальные критерии являются косвенными. Это значит, что соблюдение каждого из них увеличивает вероятность сохранения максимальной скорости внесения изменений в продукт, однако не гарантирует её высокие показатели.
Важность косвенного критерия зависит от состояния текущего проекта. Выбирать, какой из них имеет наибольший приоритет, нужно исходя из тактических и стратегических преимуществ, которые они принесут в случае их успешного соблюдения. Выработка чёткой стратегии оценки важности критериев, а также методы их измерения - тема очень интересная, однако выходит за рамки этого ряда постов.
В зависимости от автора косвенные критерии могут очень сильно отличаться друг от друга. Ниже я привожу краткий и далеко не полный список важных критериев.
Перечень косвенных критериев
- Ясность и читаемость кода - чем выше, тем лучше.
- Распределение ответственности между компонентами
- Покрытие юнит тестами - средний оптимальный показатель 80%
- Степень связанности кода (coupling) - чем ниже, тем лучше
- Скорость рефакторинга
- Скорость тестирования
Понимание критериев и умение расставлять приоритеты на основании состояния текущего проекта может помочь в построении гибкой архитектуры. Однако от них мало пользы, если не знать принципы и инструменты построения архитектуры.
👍29
Принципы проектирования архитектуры
Одним из важных аспектов для построения гибкой архитектуры является распределение ответственности между компонентами системы. В основании предложенных принципов лежит работа с ответственностью, потому что именно с ней мы работаем в коде, распределяя обязанности и задачи между компонентами.
Здесь рассмотрены проблемы некоторых популярных принципов и предложена им альтернатива.
Следует отметить, что данный набор принципов, как и все другие, бесполезен, если не понимать, каким критериям должна соответствовать гибкая архитектура, а также без понимания, какие инструменты управления ответственностью существуют.
Проблемы SOLID
SOLID принципы также предназначены для построения гибкой архитектуры ПО. Однако они обладают рядом недостатков:
- Неочевидность терминов, используемых в расшифровке
- Малое внимание к ответственности компонентов, из-за чего открывается большой простор для спекуляций
- Сложные формулировки
- Прямая ориентация на ООП, на ФП есть только неявная
- Отсуствие балансирующих принципов
Проблемы DRY, KISS, YAGNI
Данные принципы прекрасны в своей простоте. Они ориентированы на определения областей ответственности, однако это не указано в их расшифровке.
Переработанный перечень принципов
Некоторые из предложенных принципов являются переработкой уже существующих в контексте распределения ответственности. Их цель - обеспечить не меньшую полноту по сравнению с предшественниками и решить их проблемы. Здесь они представлены в тезисном виде.
Важные определения
Ответственность здесь представляется обязанностями и задачами, которые должен выполнять компонент.
Делегирование - передача части ответственности другому компоненту
Вмешательство - неуместное участие в процессе выполнения задачи, создание помех, которые уменьшают понятность кода для программиста.
Определение области ответственности - это интерфейс, определение класса, функции, или части тела функции.
Перечень принципов
Essence Defines Responsibility
Компоненты, ближе к сути предметной области, определяют область ответственности компонентов, которые дальше от неё
No Duplicate Responsibility Principle
Дублирование определений области ответственности компонентов должно устраняться
Delegate Responsibility Principle
Компонент должен делегировать часть ответственности, если это упростит использование системы
Reversive Delegate Responsibility Principle
Компонент должен возвращать часть или полностью отказываться от ответственности, если это упростит использование системы
Isolate Responsibility Principle
Компонент не должен допускать вмешательства в свою область ответственности, а также сам не должен вмешиваться в область ответственности другого компонента
Assign Necessary Orders Principle
Компонент должен поручать только те обязанности и задачи, которые необходимы для его работы
Complete All Orders Principle
Компонент должен выполнять все обязанности в своей области ответственности
Complete Necessary Orders Principle
Компонент должен брать на себя только те обязанности и задачи, которые ему поручили
Итог
Использование данного набора принципов увеличит вероятность удобного распределения ответственности. Однако слепое их применение вредно. Критерии и инструменты могут помочь не забыть о назначении этих принципов.
Одним из важных аспектов для построения гибкой архитектуры является распределение ответственности между компонентами системы. В основании предложенных принципов лежит работа с ответственностью, потому что именно с ней мы работаем в коде, распределяя обязанности и задачи между компонентами.
Здесь рассмотрены проблемы некоторых популярных принципов и предложена им альтернатива.
Следует отметить, что данный набор принципов, как и все другие, бесполезен, если не понимать, каким критериям должна соответствовать гибкая архитектура, а также без понимания, какие инструменты управления ответственностью существуют.
Проблемы SOLID
SOLID принципы также предназначены для построения гибкой архитектуры ПО. Однако они обладают рядом недостатков:
- Неочевидность терминов, используемых в расшифровке
- Малое внимание к ответственности компонентов, из-за чего открывается большой простор для спекуляций
- Сложные формулировки
- Прямая ориентация на ООП, на ФП есть только неявная
- Отсуствие балансирующих принципов
Проблемы DRY, KISS, YAGNI
Данные принципы прекрасны в своей простоте. Они ориентированы на определения областей ответственности, однако это не указано в их расшифровке.
Переработанный перечень принципов
Некоторые из предложенных принципов являются переработкой уже существующих в контексте распределения ответственности. Их цель - обеспечить не меньшую полноту по сравнению с предшественниками и решить их проблемы. Здесь они представлены в тезисном виде.
Важные определения
Ответственность здесь представляется обязанностями и задачами, которые должен выполнять компонент.
Делегирование - передача части ответственности другому компоненту
Вмешательство - неуместное участие в процессе выполнения задачи, создание помех, которые уменьшают понятность кода для программиста.
Определение области ответственности - это интерфейс, определение класса, функции, или части тела функции.
Перечень принципов
Essence Defines Responsibility
Компоненты, ближе к сути предметной области, определяют область ответственности компонентов, которые дальше от неё
No Duplicate Responsibility Principle
Дублирование определений области ответственности компонентов должно устраняться
Delegate Responsibility Principle
Компонент должен делегировать часть ответственности, если это упростит использование системы
Reversive Delegate Responsibility Principle
Компонент должен возвращать часть или полностью отказываться от ответственности, если это упростит использование системы
Isolate Responsibility Principle
Компонент не должен допускать вмешательства в свою область ответственности, а также сам не должен вмешиваться в область ответственности другого компонента
Assign Necessary Orders Principle
Компонент должен поручать только те обязанности и задачи, которые необходимы для его работы
Complete All Orders Principle
Компонент должен выполнять все обязанности в своей области ответственности
Complete Necessary Orders Principle
Компонент должен брать на себя только те обязанности и задачи, которые ему поручили
Итог
Использование данного набора принципов увеличит вероятность удобного распределения ответственности. Однако слепое их применение вредно. Критерии и инструменты могут помочь не забыть о назначении этих принципов.
👍48🔥8
Инструменты определения ответственности
Для того, чтобы эффективно применять инструменты для определения ответственности, нужно знать область, в которой ответственность распределяется, время а также между кем она распределяется.
Областью в данном случае представляется структура компонентов в системе, начало и конец ответственности определяются условными временными рамками, распределяется же ответственность между компонентами системы. Ответственность здесь - это задача компонента или его перечень обязанностей. Компонент - объект или функция.
В программировании есть два основных инструмента для определения ответственности компонентов: интерфейс и функция. Интерфейс предназначен для разграничения ответственности в рамках структуры системы, функция - во временных рамках.
Распределение ответственности в рамках структуры системы представляется группировкой методов или функций. Во временных - это их вызов и получение результата или побочного эффекта.
В ООП ответственность распределяется между объектами и методами с помощью определений классов или интерфейсов. В ФП - между функциями. Хотя в ФП явно не выделяют понятие "интерфейс", тем не менее он наблюдается при группировке функций по типу, с которыми они работают.
Таким образом, не зависимо от ООП или ФП в программировании есть два основных инструмента для определения ответственности: интерфейс и функция.
Понимание, какими инструментами орудует программист, увеличивает ваероятность их уместного применения. В этом также могут помочь критерии гибкой архитектуры и принципы её построения
Для того, чтобы эффективно применять инструменты для определения ответственности, нужно знать область, в которой ответственность распределяется, время а также между кем она распределяется.
Областью в данном случае представляется структура компонентов в системе, начало и конец ответственности определяются условными временными рамками, распределяется же ответственность между компонентами системы. Ответственность здесь - это задача компонента или его перечень обязанностей. Компонент - объект или функция.
В программировании есть два основных инструмента для определения ответственности компонентов: интерфейс и функция. Интерфейс предназначен для разграничения ответственности в рамках структуры системы, функция - во временных рамках.
Распределение ответственности в рамках структуры системы представляется группировкой методов или функций. Во временных - это их вызов и получение результата или побочного эффекта.
В ООП ответственность распределяется между объектами и методами с помощью определений классов или интерфейсов. В ФП - между функциями. Хотя в ФП явно не выделяют понятие "интерфейс", тем не менее он наблюдается при группировке функций по типу, с которыми они работают.
Таким образом, не зависимо от ООП или ФП в программировании есть два основных инструмента для определения ответственности: интерфейс и функция.
Понимание, какими инструментами орудует программист, увеличивает ваероятность их уместного применения. В этом также могут помочь критерии гибкой архитектуры и принципы её построения
👍30