Я тоже не пишу. И не собираюсь. В редких случаях, когда вообще нет ресурса, помогаю в проектировании бд, в аналитике, написание контрактов. Могу подсказать по архитектуре. Но все - именно как исключение из обычного рабочего процесса. Есть другие активности, которые не позволяют серьезно и вдумчиво погружаться в код.
Мало что погружаться, так ещё и нет предсказуемости в сроках
превращает аспекты из средства борьбы с boilerplate в инструмент принуждения к архитектурным стандартам, что особенно актуально в больших командах, где кодревью превращается в бесконечную войну с человеческим фактором.
Не видите противоречий? Отвергая один архстандарт, пытаетесь применить другой. И про код ревью уже по другому пишите
Во-первых, код ревью минимизирует ошибки, а не полностью предотвращает.
Во-вторых, даже вы сами говорите, что на код ревью отслеживаете качество кода. А если код не соответствует общепринятым практикам и правилами хорошего тона, он по любому некачественный. Так что ваш аргумент про код ревью говорит в мою пользу.
В-третьих, написание кода под системные вещи требует особого отношения. Как и в играх, зачастую жертвуют наглядностью и структурированностью в пользу быстродействия и экономии памяти. Поэтому сравнивать системный и прикладной код по одним и тем же критериям я бы не стал.
То, что вы где-то там principal engineer, это, безусловно, здорово. Но ваш стиль общения лично меня приводит к мысли, что вы - не командный игрок. Или слишком упиваетесь своими силами, делая атмосферу в команде токсичной.
Напоследок я бы хотел подчеркнуть ещё один нюанс. В 90% случаях в продуктовые команды не набирают суперпрофи. Их и на рынке не так много, и задачи, которые стоят перед командой, не требуют высокой квалификации. И бизнес не хочет платить высокую зарплату, если, абстрактно, уровень задач примерно "покрасить кнопку в другой цвет". Так вот, для таких не хватающие звёзд с небес людей следование перечисленным в статье концепциям и правилам это очень правильный путь.
А вам я желаю побольше сложных и нетривиальных вызовов, где вы можете и дальше поднимать свою квалификацию и свысока поплевывать на людишек снизу.
Вообще не вижу проблем. На планировании давать самые сложные задачи, установить на компьютер трекер активности со скринами, каждую невыполненную задачу фиксировать со служебной запиской, при оценке стабильно выставлять низкую. Варианты воздействия есть всегда.
Но это, согласитесь, идиотизм. И так вести себя - просто противно. Проще договориться и дать время на поиск работы (месяц, два), или выплатить компенсацию и по соглашению сторон.
В конце концов, рынок ИТ не такой большой, при устройстве на работу все равно пробивают человека (по крайней мере в крупных компаниях). Полюбовно расстаться, если не сработались, в интересах всех участников
Причем здесь конкретно solid? Это лишь один из принципов организации кода. На мой взгляд, вполне рабочий и корректный.
Проблема в другом - когда работает над кодом более одного человека, важно иметь общее понимание. Если каждый будет лепить код как ему вздумается, будет каша. Если используются паттерны и solid, есть хотя бы понимание, кто, что и как делает. Оптимально или нет, это уже вопрос, не имеющий правильного ответа
То, что бизнес может развернуть хотелки, вообще не влияет на рефакторинг. Из разряда - не буду мыть автомобиль шефа, не буду проходить ТО, все равно же завтра он его может продать и купить самокат.
Если у вас классы выполняют функции, отличные от их названия, как раз говорит о том, что рефакторингом в коде никто не занимался
Если "А потом выясняется, что те две «похожие» функции на самом деле делали немного разные вещи" - то это повод вернуть назад 2 функции с соответствующим комментарием, а не городить "параметры, флаги, условия, превращая элегантную абстракцию в монстра с десятком необязательных параметров и логикой, понятной только его создателю".
Чем вам не нравится TDD? "Половина тестов проверяет очевидные вещи вроде того, что два плюс два равно четыре" - ну не пишите такие тесты. Пишите, где они проверяют более осмысленную логику.
"потому что он полностью завязан на внешние источники, и единственный вариант его тестирования — элегантный отказ" - тестирование модуля, завязанного на внешние интеграции, осуществляется с применением mock-сервисов. Типа wiremock, mockoon.
Про solid - тоже неверно. Если у вас простейший crud, и логика в бд, то усложнять код не нужно. А если у вас более сложная архитектура? Это же как со строительством дома - сделать простейшую хибару проект не нужен. А как только начинаем смотреть МКД, нифига ж себе, оказываются есть архитектурные нормы и требования. И серьезную перепланировку без заключения о прочностных характеристиках не получить. Хотя казалось бы, всего лишь снести одну несущую стену. То есть, я хотел сказать, пробросить какие то поля из базы на форму, минуя бизнес-логику
А что, API gateway в точка банке не знают? Их же дофига. Хоть тот же TYK
Используйте ИИ. Будет виртуальный архитектор. Но лучше такой, чем вроде никакого
Спасибо
Диплодок же не умеет в on-premise? Ему нужно облако Яндекса?
Документацию пишет аналитик. Ну, хотя бы фт. Разработчики ругаются от необходимости ее писать.
У нас аналитик отвечает за доку. И кросс ревью только аналитики делают.
Сборку документацию не встроили в пайплайн, но есть ручная джоба по сборке документации из конкретной ветки. Запускаем для релизов
Наглядный пример того, что паттерн Катастрофоустойчивость является актуальным
Я тоже не пишу. И не собираюсь. В редких случаях, когда вообще нет ресурса, помогаю в проектировании бд, в аналитике, написание контрактов. Могу подсказать по архитектуре. Но все - именно как исключение из обычного рабочего процесса. Есть другие активности, которые не позволяют серьезно и вдумчиво погружаться в код.
Мало что погружаться, так ещё и нет предсказуемости в сроках
Ради интереса посмотрел другие и ваши статьи.
Цитата из последней:
превращает аспекты из средства борьбы с 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, если используется самоподписанный сертификат