превращает аспекты из средства борьбы с boilerplate в инструмент принуждения к архитектурным стандартам, что особенно актуально в больших командах, где кодревью превращается в бесконечную войну с человеческим фактором.
Не видите противоречий? Отвергая один архстандарт, пытаетесь применить другой. И про код ревью уже по другому пишите
Во-первых, код ревью минимизирует ошибки, а не полностью предотвращает.
Во-вторых, даже вы сами говорите, что на код ревью отслеживаете качество кода. А если код не соответствует общепринятым практикам и правилами хорошего тона, он по любому некачественный. Так что ваш аргумент про код ревью говорит в мою пользу.
В-третьих, написание кода под системные вещи требует особого отношения. Как и в играх, зачастую жертвуют наглядностью и структурированностью в пользу быстродействия и экономии памяти. Поэтому сравнивать системный и прикладной код по одним и тем же критериям я бы не стал.
То, что вы где-то там principal engineer, это, безусловно, здорово. Но ваш стиль общения лично меня приводит к мысли, что вы - не командный игрок. Или слишком упиваетесь своими силами, делая атмосферу в команде токсичной.
Напоследок я бы хотел подчеркнуть ещё один нюанс. В 90% случаях в продуктовые команды не набирают суперпрофи. Их и на рынке не так много, и задачи, которые стоят перед командой, не требуют высокой квалификации. И бизнес не хочет платить высокую зарплату, если, абстрактно, уровень задач примерно "покрасить кнопку в другой цвет". Так вот, для таких не хватающие звёзд с небес людей следование перечисленным в статье концепциям и правилам это очень правильный путь.
А вам я желаю побольше сложных и нетривиальных вызовов, где вы можете и дальше поднимать свою квалификацию и свысока поплевывать на людишек снизу.
Вообще не вижу проблем. На планировании давать самые сложные задачи, установить на компьютер трекер активности со скринами, каждую невыполненную задачу фиксировать со служебной запиской, при оценке стабильно выставлять низкую. Варианты воздействия есть всегда.
Но это, согласитесь, идиотизм. И так вести себя - просто противно. Проще договориться и дать время на поиск работы (месяц, два), или выплатить компенсацию и по соглашению сторон.
В конце концов, рынок ИТ не такой большой, при устройстве на работу все равно пробивают человека (по крайней мере в крупных компаниях). Полюбовно расстаться, если не сработались, в интересах всех участников
Причем здесь конкретно solid? Это лишь один из принципов организации кода. На мой взгляд, вполне рабочий и корректный.
Проблема в другом - когда работает над кодом более одного человека, важно иметь общее понимание. Если каждый будет лепить код как ему вздумается, будет каша. Если используются паттерны и solid, есть хотя бы понимание, кто, что и как делает. Оптимально или нет, это уже вопрос, не имеющий правильного ответа
То, что бизнес может развернуть хотелки, вообще не влияет на рефакторинг. Из разряда - не буду мыть автомобиль шефа, не буду проходить ТО, все равно же завтра он его может продать и купить самокат.
Если у вас классы выполняют функции, отличные от их названия, как раз говорит о том, что рефакторингом в коде никто не занимался
Если "А потом выясняется, что те две «похожие» функции на самом деле делали немного разные вещи" - то это повод вернуть назад 2 функции с соответствующим комментарием, а не городить "параметры, флаги, условия, превращая элегантную абстракцию в монстра с десятком необязательных параметров и логикой, понятной только его создателю".
Чем вам не нравится TDD? "Половина тестов проверяет очевидные вещи вроде того, что два плюс два равно четыре" - ну не пишите такие тесты. Пишите, где они проверяют более осмысленную логику.
"потому что он полностью завязан на внешние источники, и единственный вариант его тестирования — элегантный отказ" - тестирование модуля, завязанного на внешние интеграции, осуществляется с применением mock-сервисов. Типа wiremock, mockoon.
Про solid - тоже неверно. Если у вас простейший crud, и логика в бд, то усложнять код не нужно. А если у вас более сложная архитектура? Это же как со строительством дома - сделать простейшую хибару проект не нужен. А как только начинаем смотреть МКД, нифига ж себе, оказываются есть архитектурные нормы и требования. И серьезную перепланировку без заключения о прочностных характеристиках не получить. Хотя казалось бы, всего лишь снести одну несущую стену. То есть, я хотел сказать, пробросить какие то поля из базы на форму, минуя бизнес-логику
Буквально пару дней назад прочитал, что физики смогли доказать, что луч лазера при определенных условиях имеет тень. Это означает, что он становится непрозрачным для других световых волн.
Сходил специально в магнит, чтобы проверить. Новый интерфейс действительно поприятнее. Но долго работал сервис проверки марок, или как то так назывался.
Наверное, в плане удобства достаточно выровнялись с конкурентами
Из всех касс самообслуживания (Пятёрочка, магнит, Ашан, Леруа, Вкусвилл) - магнит самый раздражающий. Ну это ладно. Хуже другое - из 4 или 5 касс работает от силы только одна. Причем постоянно. На остальных - горят ошибки
Ради интереса посмотрел другие и ваши статьи.
Цитата из последней:
превращает аспекты из средства борьбы с boilerplate в инструмент принуждения к архитектурным стандартам, что особенно актуально в больших командах, где кодревью превращается в бесконечную войну с человеческим фактором.
Не видите противоречий? Отвергая один архстандарт, пытаетесь применить другой. И про код ревью уже по другому пишите
Во-первых, код ревью минимизирует ошибки, а не полностью предотвращает.
Во-вторых, даже вы сами говорите, что на код ревью отслеживаете качество кода. А если код не соответствует общепринятым практикам и правилами хорошего тона, он по любому некачественный. Так что ваш аргумент про код ревью говорит в мою пользу.
В-третьих, написание кода под системные вещи требует особого отношения. Как и в играх, зачастую жертвуют наглядностью и структурированностью в пользу быстродействия и экономии памяти. Поэтому сравнивать системный и прикладной код по одним и тем же критериям я бы не стал.
То, что вы где-то там principal engineer, это, безусловно, здорово. Но ваш стиль общения лично меня приводит к мысли, что вы - не командный игрок. Или слишком упиваетесь своими силами, делая атмосферу в команде токсичной.
Напоследок я бы хотел подчеркнуть ещё один нюанс. В 90% случаях в продуктовые команды не набирают суперпрофи. Их и на рынке не так много, и задачи, которые стоят перед командой, не требуют высокой квалификации. И бизнес не хочет платить высокую зарплату, если, абстрактно, уровень задач примерно "покрасить кнопку в другой цвет". Так вот, для таких не хватающие звёзд с небес людей следование перечисленным в статье концепциям и правилам это очень правильный путь.
А вам я желаю побольше сложных и нетривиальных вызовов, где вы можете и дальше поднимать свою квалификацию и свысока поплевывать на людишек снизу.
Вообще не вижу проблем. На планировании давать самые сложные задачи, установить на компьютер трекер активности со скринами, каждую невыполненную задачу фиксировать со служебной запиской, при оценке стабильно выставлять низкую. Варианты воздействия есть всегда.
Но это, согласитесь, идиотизм. И так вести себя - просто противно. Проще договориться и дать время на поиск работы (месяц, два), или выплатить компенсацию и по соглашению сторон.
В конце концов, рынок ИТ не такой большой, при устройстве на работу все равно пробивают человека (по крайней мере в крупных компаниях). Полюбовно расстаться, если не сработались, в интересах всех участников
Легко. Просишь заменить на проекте или уйти по собственному. 99% не изображают из себя жертвы репрессий и уходят.
Причем здесь конкретно solid? Это лишь один из принципов организации кода. На мой взгляд, вполне рабочий и корректный.
Проблема в другом - когда работает над кодом более одного человека, важно иметь общее понимание. Если каждый будет лепить код как ему вздумается, будет каша. Если используются паттерны и solid, есть хотя бы понимание, кто, что и как делает. Оптимально или нет, это уже вопрос, не имеющий правильного ответа
То, что бизнес может развернуть хотелки, вообще не влияет на рефакторинг. Из разряда - не буду мыть автомобиль шефа, не буду проходить ТО, все равно же завтра он его может продать и купить самокат.
Если у вас классы выполняют функции, отличные от их названия, как раз говорит о том, что рефакторингом в коде никто не занимался
Если "А потом выясняется, что те две «похожие» функции на самом деле делали немного разные вещи" - то это повод вернуть назад 2 функции с соответствующим комментарием, а не городить "параметры, флаги, условия, превращая элегантную абстракцию в монстра с десятком необязательных параметров и логикой, понятной только его создателю".
Чем вам не нравится TDD? "Половина тестов проверяет очевидные вещи вроде того, что два плюс два равно четыре" - ну не пишите такие тесты. Пишите, где они проверяют более осмысленную логику.
"потому что он полностью завязан на внешние источники, и единственный вариант его тестирования — элегантный отказ" - тестирование модуля, завязанного на внешние интеграции, осуществляется с применением mock-сервисов. Типа wiremock, mockoon.
Про solid - тоже неверно. Если у вас простейший crud, и логика в бд, то усложнять код не нужно. А если у вас более сложная архитектура? Это же как со строительством дома - сделать простейшую хибару проект не нужен. А как только начинаем смотреть МКД, нифига ж себе, оказываются есть архитектурные нормы и требования. И серьезную перепланировку без заключения о прочностных характеристиках не получить. Хотя казалось бы, всего лишь снести одну несущую стену. То есть, я хотел сказать, пробросить какие то поля из базы на форму, минуя бизнес-логику
А вы можете показать хоть одну закладку? Или включаете вашу фантазию?
Спасибо, про ограничения serial не знал
Spring state machine? ))
Язык Дракон. Вполне себе промышленный.
https://ru.m.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E%D0%9D
Оказывается, Тинькофф подключает услугу информирования т-банка, без разрешения оформляя номер телефона в т-мобайл.
Вот, спасибо гоуслугам, узнал о существовании номера, который был на меня оформлен без моего ведома
И тем не менее, книжка от банды 4 - очень познавательная.
Я бы добавил ещё разрешение длинных имён файлов + отключение верификации ssl, если используется самоподписанный сертификат
Событийная модель и микросервисы полностью перпендикулярны друг другу. Между ними нельзя ставить ИЛИ.
Кстати, реактивная модель прекрасно работает с событиями.
Это оффер. Ничего секретного в нем нет. Персданные убрал
При всем уважении, то что вы выдаете за оффер, таковым не является
Оффер - это такой документ, где прописываются название должности, график работы и зарплата. Типа такой:
Лет 10 назад сделал Ласик. До сих пор единичка (было -3).
Доволен как слон
Буквально пару дней назад прочитал, что физики смогли доказать, что луч лазера при определенных условиях имеет тень. Это означает, что он становится непрозрачным для других световых волн.
Сходил специально в магнит, чтобы проверить. Новый интерфейс действительно поприятнее. Но долго работал сервис проверки марок, или как то так назывался.
Наверное, в плане удобства достаточно выровнялись с конкурентами
Из всех касс самообслуживания (Пятёрочка, магнит, Ашан, Леруа, Вкусвилл) - магнит самый раздражающий. Ну это ладно. Хуже другое - из 4 или 5 касс работает от силы только одна. Причем постоянно. На остальных - горят ошибки