По-моему, все смешано в кучу. Principal Engineer это вообще другая ветка, а не следующая ступенька после Team Lead. Должность Team Lead означает, что специалист уже выбрал менеджерскую ветку. Конечно, возможно, что в конкретной этой компании нельзя стать Principal без управления командой, но звучит странно.
Проблема в том, что вы медленно окажетесь в мире, где каждая база кода написана на собственном подмножестве языка.
Не вижу ничего плохого в том, что кодовые базы разных проектов и организаций используют разный стиль. Важно, чтобы в одной и той же кодовой базе стиль был одинаковый.
Так же как и города во всем мире не обязаны быть как под копирку. Главное, чтобы на одной и той же улице рядом со строениями 18-го века не стояли небоскребы :)
Взять упомянутый язык Scala. В каких-то командах привыкли использовать его в "better Java" стиле, какие-то команды любят и умеют писать на Scala в функциональном стиле.
Было бы очень странно и бессмысленно всем в мире диктовать "используй от всей Scala только ООП подмножество" или "ты обязан писать на Scala исключительно в функциональном стиле".
Так я и написал "дать конструктивную оценку". Информацию о том, что у кандидата плохие знания по Java не обязательно доносить именно в категоричной форме. Но мой посыл был в другом - в том, что предлагаемый автором "правильный" вариант еще хуже.
Неплохая статья, многие вещи я и для себя отмечал. Но вот с одним моментом я не согласен полностью:
никаких персональных оценок, вроде «вы недостаточно квалифицированы» или «у вас плохие знания Java». Так нельзя отвечать — это очень грубо. Просто сообщают что не готовы сделать предложение и приглашают попробовать еще раз через год.
В чем грубость дать конструктивную оценку по поводу конкретных областей, которые нужно улучшить кандидату? Чем лучше давать абсолютно неинформативный ответ вида "мы не готовы сделать вам предложение"? По такой логике, кандидат потом должен сидеть и гадать, в каком из пяти интервью и что он сказал не так.
Как раз-таки проблема в том, что часто представление того, что нужно от тимлида, очень расплывчатое. Ему приписывают и то, что он должен быть самым крутым разработчиком в команде, к которому все ходят за помощью, и то что он должен быть архитектором, который утверждает все подходы и технологии. Но на самом деле же тимлид это про другое - про управление командой и умение делегировать. Я знал случаи, когда команду программистов успешно тимлидит человек с бэкграундом вообще не с теми языками программирования, на которых пишется проект.
Жаль, что в локальных IT-компаниях стран СНГ обычно или идти в тимлиды, или Senior Dev до пенсии. Была бы чуть больше развита культура роста в техническом направлении выше Senior Dev - уверен, было бы гораздо меньше тимлидов не на своих местах.
Всегда было интересно, откуда это желание управлять всем и сразу. Ведь если объективно один партнёр хорош как product manager, но слабоват как техлид, а второй хорош как техлид, но такой себе предприниматель, можно же разделить обязанности, но при этом по-прежнему владеть равноценными долями компании.
Вы серьезно думаете, что на современных заводах каждую детальку стоит и вытачивает дядя-токарь вручную с нуля? В наше время уже даже 3D-принтеры используются на некоторых заводах, не говоря уже о другой автоматике. И разница не в том, что код запушить 2 минуты, а детальку выточить не 2 минуты. Разница в том, что на заводе никому и в голову не придет без точных предварительных расчетов согласно законам физики и сопромата наспех что-то выточить наобум и переделывать потом по 20 раз. Но в разработке ПО почему-то все по-другому: тут считается нормальным подходом не думать заранее ни о чем, не писать ТЗ, а просто сделать абы какой прототип по-быстрому, а потом переписывать множество раз. Хотя, по-моему опыту, иногда хоть какой-то предварительный анализ и рисование схем экономит десятки человеко-часов разработчиков.
В общем, ладно, я чувствую, что все советы не будут тут восприниматься, потому что вы заранее сконцентрировались на идее «сделать аналог метода PATH в REST», и только эта идея кажется вам логичной и красивой. Если вам нравится менять состояние БД через queries — на здоровье :)
Теперь давайте все-таки отложим в сторону REST с его различиями null\undefined и попробуем посмотреть на мутации как на функции в языках программирования. И, вместо вашего оригинального технического решения, которое меняет состояние БД в query-запросах (причем, каждое поле в отдельном запросе к БД), можно решить задачу, например, так:
# Создаем input, где все поля - опциональные
input ExampleOptionalInput {
foo: String
bar: String
}
# Создаем мутацию с доп. аргументом
type Mutation {
updateExampleOptionally(input: ExampleOptionalInput!, onlyFields: [String!]): Example
}
Приводите, пожалуйста, аргументы или какую-то статистику к своим выводам, а то обсуждение получается немного бесполезным.
Optimistic lock это просто и поддерживается некоторыми ORM вообще из коробки. Надеяться на partial update как на основное решение при совместном редактировании считаю непрофессиональным. Где-то оно, может, и будет помогать худо-бедно, а где-то, где, скажем, поле «описание» у товара редактируется в 10 раз чаще других полей — не будет.
Эх… Если Вася открыл форму и ушел гулять, а Игорь в это время что-то сохранил, то Вася потом ничего не затрет, а, наоборот, получит алерт. Почитайте, пожалуйста, про принципы, на которых реализуется обычно optimistic lock — версионность и т.п., как это сделано в разных Wiki, в issue tracking системах типа Redmine и других.
Так, как это обычно и делается в самом классическом его применении — мы увидим, что в изменениях Игоря есть конфликты и покажем ему предупреждение \ выкинем исключение, etc. Уточните, какой именно момент непонятен.
Вы всерьез верите, что partial update — хорошее средство защиты от перезаписи при одновременном редактировании несколькими пользователями? :) Если Вася и Игорь одновременно загрузили страничку с формой обновления сущности, Вася поменял описание и цену, а Игорь поменял название и исправил опечатку в описании, то partial update никак не защитит от того, что Игорь перезапишет все изменения Васи в поле описания сущности. В таких случаях применяется что-то более нормальное — например, optimistic lock.
Ок, будет интересно почитать) Только хотел бы попросить кое-что, если не трудно — напишите, пожалуйста, в будущей статье, в чем основной профит от предлагаемого подхода. Потому что я на 90% уверен, что в GraphQL partial update реализуется только усложнением входных типов. А делать partial update ради partial update, либо бороться против 2Кб дополнительного трафика (или использовать это как основное средство против race conditions) выглядит не очень хорошей мотивацией)
Посмотрите первый вариант в моем комментарии выше. Я специально написал его для любителей выполнять одним методом все на свете. Второй вариант с двумя мутациями — это для приложений с четкими различающимися кейсами изменения модели. Например, отдельная форма изменения email, отдельная форма обновления имени и фамилии и т.п. Очевидно, что там даже на бэкенде логика разная будет выполняться в зависимости от формы, и делать это все одним методом с кучей if'ов, мягко говоря, не айс.
Также непонятно, если у вас CRUD, и на каждую сущность форма со всеми полями, зачем отправлять только часть из них, если у вас на руках полная модель.
Можно какие-то более конкретные примеры? Возможно, я просто не до конца понимаю, в чем такая огромная сложность в цепочке «взять объект, полученный из api» → «заменить поля, которые пользователь отредактировал» → «вызвать мутацию».
Может, это и делается немного проще с точки зрения отправки на сервер из фронтенда, но путем создания монструозных типов на сервере, где какой-нибудь Boolean может иметь не 2 значения (true/false), а 3 (true/false/undefined), что на мой взгляд еще хуже.
Предлагаю вместо абстрактных рассуждений рассмотреть конкретный пример.
Скажем, есть такой тип:
type User {
login: String!
role: String!
name: String
email: String
age: Int
}
Предположим, что в нашем приложении есть две формы: 1. Форма обновления «credentials» 2. Форма обновления «профиля». В первой форме нужно обновлять только поля «login», «role», а во второй поля «name», «email», «age».
Есть два варианта решения этой задачи:
Вариант 1, не очень удачный на мой взгляд — делаем input тип со всеми полями и одну мутацию:
input UserInput {
login: String!
role: String!
name: String
email: String
age: Int
}
type Mutation {
updateUser(input: UserInput!): User
}
Перед отображением форм достаем юзера с сервера через api. В первой форме поля «login» и «role» подставляем в UserInput из формы, остальные поля из того, что пришло из api. Во второй форме поля «name», «email», «age» подставляем в UserInput из формы, остальные поля из того, что пришло из api. Вызываем updateUser с заполненным UserInput.
Вариант 2, более адекватный — делаем свой input тип для каждого кейса и две мутации:
input UserCredentialsInput {
login: String!
role: String!
}
input UserProfileInput {
name: String
email: String
age: Int
}
type Mutation {
updateUserCredentials(input: UserCredentialsInput!): User
updateUserProfile(input: UserProfileInput!): User
}
В каждой форме используем соответствующий input и мутацию.
По-моему, все смешано в кучу. Principal Engineer это вообще другая ветка, а не следующая ступенька после Team Lead. Должность Team Lead означает, что специалист уже выбрал менеджерскую ветку.
Конечно, возможно, что в конкретной этой компании нельзя стать Principal без управления командой, но звучит странно.
Не вижу ничего плохого в том, что кодовые базы разных проектов и организаций используют разный стиль. Важно, чтобы в одной и той же кодовой базе стиль был одинаковый.
Так же как и города во всем мире не обязаны быть как под копирку. Главное, чтобы на одной и той же улице рядом со строениями 18-го века не стояли небоскребы :)
Взять упомянутый язык Scala. В каких-то командах привыкли использовать его в "better Java" стиле, какие-то команды любят и умеют писать на Scala в функциональном стиле.
Было бы очень странно и бессмысленно всем в мире диктовать "используй от всей Scala только ООП подмножество" или "ты обязан писать на Scala исключительно в функциональном стиле".
"Выгодное налогооблАжение" это интересно..
Так я и написал "дать конструктивную оценку". Информацию о том, что у кандидата плохие знания по Java не обязательно доносить именно в категоричной форме. Но мой посыл был в другом - в том, что предлагаемый автором "правильный" вариант еще хуже.
Неплохая статья, многие вещи я и для себя отмечал. Но вот с одним моментом я не согласен полностью:
В чем грубость дать конструктивную оценку по поводу конкретных областей, которые нужно улучшить кандидату? Чем лучше давать абсолютно неинформативный ответ вида "мы не готовы сделать вам предложение"? По такой логике, кандидат потом должен сидеть и гадать, в каком из пяти интервью и что он сказал не так.
Как раз-таки проблема в том, что часто представление того, что нужно от тимлида, очень расплывчатое. Ему приписывают и то, что он должен быть самым крутым разработчиком в команде, к которому все ходят за помощью, и то что он должен быть архитектором, который утверждает все подходы и технологии. Но на самом деле же тимлид это про другое - про управление командой и умение делегировать. Я знал случаи, когда команду программистов успешно тимлидит человек с бэкграундом вообще не с теми языками программирования, на которых пишется проект.
Жаль, что в локальных IT-компаниях стран СНГ обычно или идти в тимлиды, или Senior Dev до пенсии. Была бы чуть больше развита культура роста в техническом направлении выше Senior Dev - уверен, было бы гораздо меньше тимлидов не на своих местах.
Всегда было интересно, откуда это желание управлять всем и сразу. Ведь если объективно один партнёр хорош как product manager, но слабоват как техлид, а второй хорош как техлид, но такой себе предприниматель, можно же разделить обязанности, но при этом по-прежнему владеть равноценными долями компании.
Вы серьезно думаете, что на современных заводах каждую детальку стоит и вытачивает дядя-токарь вручную с нуля? В наше время уже даже 3D-принтеры используются на некоторых заводах, не говоря уже о другой автоматике. И разница не в том, что код запушить 2 минуты, а детальку выточить не 2 минуты. Разница в том, что на заводе никому и в голову не придет без точных предварительных расчетов согласно законам физики и сопромата наспех что-то выточить наобум и переделывать потом по 20 раз. Но в разработке ПО почему-то все по-другому: тут считается нормальным подходом не думать заранее ни о чем, не писать ТЗ, а просто сделать абы какой прототип по-быстрому, а потом переписывать множество раз. Хотя, по-моему опыту, иногда хоть какой-то предварительный анализ и рисование схем экономит десятки человеко-часов разработчиков.
Будет одна транзакция. Запросов
UPDATEбудет несколько.Естественно, можно много как организовать валидацию. Основной смысл не меняется.
С таким аргументом и не поспоришь :)
null\undefinedи попробуем посмотреть на мутации как на функции в языках программирования. И, вместо вашего оригинального технического решения, которое меняет состояние БД в query-запросах (причем, каждое поле в отдельном запросе к БД), можно решить задачу, например, так:Optimistic lock это просто и поддерживается некоторыми ORM вообще из коробки. Надеяться на
partial updateкак на основное решение при совместном редактировании считаю непрофессиональным. Где-то оно, может, и будет помогать худо-бедно, а где-то, где, скажем, поле «описание» у товара редактируется в 10 раз чаще других полей — не будет.partial update— хорошее средство защиты от перезаписи при одновременном редактировании несколькими пользователями? :) Если Вася и Игорь одновременно загрузили страничку с формой обновления сущности, Вася поменял описание и цену, а Игорь поменял название и исправил опечатку в описании, тоpartial updateникак не защитит от того, что Игорь перезапишет все изменения Васи в поле описания сущности. В таких случаях применяется что-то более нормальное — например, optimistic lock.partial updateреализуется только усложнением входных типов. А делатьpartial updateрадиpartial update, либо бороться против 2Кб дополнительного трафика (или использовать это как основное средство против race conditions) выглядит не очень хорошей мотивацией)Посмотрите первый вариант в моем комментарии выше. Я специально написал его для любителей выполнять одним методом все на свете. Второй вариант с двумя мутациями — это для приложений с четкими различающимися кейсами изменения модели. Например, отдельная форма изменения email, отдельная форма обновления имени и фамилии и т.п. Очевидно, что там даже на бэкенде логика разная будет выполняться в зависимости от формы, и делать это все одним методом с кучей if'ов, мягко говоря, не айс.
Также непонятно, если у вас CRUD, и на каждую сущность форма со всеми полями, зачем отправлять только часть из них, если у вас на руках полная модель.
Может, это и делается немного проще с точки зрения отправки на сервер из фронтенда, но путем создания монструозных типов на сервере, где какой-нибудь
Booleanможет иметь не 2 значения (true/false), а 3 (true/false/undefined), что на мой взгляд еще хуже.Скажем, есть такой тип:
Предположим, что в нашем приложении есть две формы: 1. Форма обновления «credentials» 2. Форма обновления «профиля». В первой форме нужно обновлять только поля «login», «role», а во второй поля «name», «email», «age».
Есть два варианта решения этой задачи:
Вариант 1, не очень удачный на мой взгляд — делаем input тип со всеми полями и одну мутацию:
Перед отображением форм достаем юзера с сервера через api. В первой форме поля «login» и «role» подставляем в
UserInputиз формы, остальные поля из того, что пришло из api. Во второй форме поля «name», «email», «age» подставляем вUserInputиз формы, остальные поля из того, что пришло из api. ВызываемupdateUserс заполненнымUserInput.Вариант 2, более адекватный — делаем свой input тип для каждого кейса и две мутации:
В каждой форме используем соответствующий input и мутацию.