у менеджера сроки-дедлайны, и не очень понятно, зачем отдавать человеко-месяц фронта на работу, результатом которой будет "всё осталось ровно так, как было".
Так и не понял, что изменится в лучшую сторону для менеджера, если его начальство будет думать, что переход был его идеей. Скорее наоборот – для начальства верхнего уровня это ещё более "осталось, как было, а время и ресурс потратили". Он мазохист, хочет, чтобы наказали его, а не программиста?
Мне кажется релиз по инициативе разработчика нажатием одной кнопки в CI это уже стандарт по индустрии.
CI != CD. И вообще CI должна запускаться безо всякой кнопки, просто по факту мержа фичи в общий бранч.
UPD: а релиз по инициативе разработчика – это никакой не стандарт, а воплощённый кошмар. Представьте себе команду из нескольких десятков, а то и сотен программистов, каждый из которых релизит в прод, когда ему вздумается.
В Tunk Based Development есть только мастер, очень удобная методология кстати
Есть свои плюсы, одно время использовали. Но в этом случае и деплой делается иначе. В любом случае, если программист, закончив фичу, вмерживает её в мастер и она тут же появляется на проде, без предварительного тестирования – это категорически неправильно.
Эффективно, когда разработчик сразу заявляет: вижу риск, что задача не будет выполнена, потому что то-то и то-то. Предлагаю... или жду ответа, как быть.
В этом случае описанная в статье ситуация невозможна
Всё равно эти предложения и решение руководителя должны быть отражены в тикете – что опять же делает описанную ситуацию невозможной.
Дело не во вредности руководителя, а в том, что он тупо не понимает, в чём преимущество нововведения.
Ага, а если предложить ему приписать нововведение себе, то сразу проникнется его ценностью. Камон.
Не понимаю. Вы предлагаете руководителю НЕ мониторить тикеты? А чем он тогда вообще занимается, и откуда узнаёт о состоянии дел?
а) Повышенная ментальная нагрузка, в одном из спринтов у меня было около 100 задач
Мне ежедневно приходит сотни полторы апдейтов. Никакой особой перегрузки это не создаёт: если держишь руку на пульсе, достаточно одного взгляда, чтобы понять – всё ли тут в порядке или требуется вмешаться. А если начинаешь не успевать – это явный индикатор того, что команду пора дробить на более мелкие.
Неэффективно
А что тогда эффективно? Поделитесь опытом.
Вопрос приоритетов: нужно, чтобы твоя идея воплотилась, или нужно, чтобы тебя почитали
Нет, вопрос вовсе не в этом, а в том, что если руководитель не согласен развивать ценные идеи разработчиков, если лавры достанутся не ему – это очень плохой руководитель.
Две ситуации: "Разработчик написал в тикете, что задача не решается потому-то, и спокойно её отложил" и "Разработчик написал в тикете, что задача не решается потому-то, и обговорил с руководителем новые сроки её исполнения".
Опять-таки, вопрос организации процесса. В норме разработчик не может сам принимать решения об откладывании работ, а руководитель непрерывно мониторит изменения в тикетах, так что не может быть не в курсе, даже если такое произошло.
Особенно когда у вас крупная компания, и никакой даже не стратап
Я и писал: где в принципе присутствует иерархия руководства.
Но есть срочные хотфиксы, например.
Для хотфиксов должна быть отдельная процедура – в принципе мало чем отличающаяся, только что изменение мержится изначально не в релиз, а в хотфикс бранч, и тестируется там.
Иногда разработчик забывает это сделать.
Если забыл, то это баг, который должен был выявиться при тестировании – а отнюдь не во время попытки мержа в мастер.
Если вам дают руку помощи, а вам кажется, что ваш труд присваивают
Вы писали совсем о другом: убедить руководителя, что идея разработчика принадлежит ему – иначе он откажется её продвигать. Это совершенно нездоровые отношения.
Я бы сказал, что статья о том, как общаться с руководителем в условиях неверно организованного процесса. Например:
Ой, а я же тебе на позапрошлом дэйлике сказал, что Луна в Третьем доме, поэтому на неё забил…
Если задача приостановлена, это должно быть отражено в тикете. Тогда и вопросов не будет.
Хотя деплоит в прод за редким исключением не разработчик.
Не может быть никаких исключений. В сколько-нибудь серьёзном проекте (где в принципе присутствует иерархия руководства) у программистов просто не должно быть доступа на прод.
По мере выполнения задачи могут возникать тонкости, которые знает только сам исполнитель, такие как:
— нужно не забыть добавить переменную в env;
— нужно выполнить команду на серваке и ещё запустить крон;
То же самое. PR должен включать в себя деплой скрипт, в котором всё это делается, запускаемый релиз менеджером. В идеале ещё и роллбэк скрипт, на случай непредвиденностей.
— нужно к деплою подготовить фича-ветку так, чтобы в ней были самые последние изменения из master, иначе в день деплоя по чатам будут летать сообщения на тему «Срочно исправь конфликты в своей ветке!»;
Фичи не должны напрямую мержиться в мастер. Сначала в релизный бранч, где всё в комплексе тестируется, и только после того, как QA дали добро – в мастер и на прод.
Поднесите ему идею, заразите сомнением, дайте намёк на решение, наконец, сделайте так, чтобы он подумал, что это его собственная идея (задача со звёздочкой для самых хитрых подчинённых) — и всё, теперь он играет за вас, а влияния в компании у него больше!
Я бы в конторе, где такое происходит, работать не хотел. Руководитель, радостно присваивающий себе идеи подчинённых, и подчинённые-подхалимы, которые его к этому подталкивают.
Можно и ещё попридираться, но вот эти пункты просто таки глаз режут.
Как уже писал, совсем его не знаю. Правда, пару раз случалось просматривать код – и прямо скажу, он вовсе не показался мне простым. Обычно я неплохо понимаю код на незнакомых языках, но это не тот случай – многое навскидку неочевидно. Да и как-то плохо сочетается декларированная простота с тем самым
превратился в гигантскую, сверхсложную кучу
Могу предположить, что в этом и проблема: задачи в области применения языка не решаются ограниченным набором простых средств при сохранении приемлемой эффективности. Поэтому приходится идти на усложнение, противоречащее изначально заложенной в язык философии. И вряд ли с этим что-то можно поделать: всё же языки разрабатываются для решения бизнес-задач, а не для удовольствия программистов, и если бизнес требует добавления в него конструкций, ускоряющих процесс разработки, это обязательно произойдёт.
Как уже писал, совсем его не знаю. Правда, пару раз случалось просматривать код – и прямо скажу, он вовсе не показался мне простым. Обычно я неплохо понимаю код на незнакомых языках, но это не тот случай – многое навскидку неочевидно. Да и как-то плохо сочетается декларированная простота с тем самым
превратился в гигантскую, сверхсложную кучу
Могу предположить, что в этом и проблема: задачи в области применения языка не решаются ограниченным набором простых средств при сохранении приемлемой эффективности. Поэтому приходится идти на усложнение, противоречащее изначально заложенной в язык философии. И вряд ли с этим что-то можно поделать: всё же языки разрабатываются для решения бизнес-задач, а не для удовольствия программистов, и если бизнес требует добавления в него конструкций, ускоряющих процесс разработки, это обязательно произойдёт.
Эти "правильные" пишут тем, у кого статус "не ищу работу"...
Ну для начала, статьи – таки инструкция для тех, кто именно что ищет. При том, что автор сам прекрасно понимает, что заранее огласив такой список претензий, станет неинтересен примерно всем. Что ничуть не мешает ему советовать другим действовать по такому, совершенно провальному алгоритму.
Как только работадатели начнут писать честно в своих вакансиях, работникам сразу будет смысл писать честно в CV.
Что было раньше, курица или яйцо? У меня есть простое правило: стараюсь вести себя так, как мне хотелось бы, чтобы относились ко мне. А в данном случае вообще не понимаю, зачем скрывать свои предпочтения. Чтобы лишний раз сходить на собес и чувством глубокого удовлетворения констатировать, что все работодатели неправильные? Напишите сразу, чего хотите – откликнутся только правильные.
Почему? Вы же [справедливо] ожидаете от работодателя, чтобы он честно и подробно рассказал, какие требования к Вам будут предъявляться? Найм – это двусторонний процесс, было бы логично столь же честно сообщить ему и о Ваших ожиданиях.
Отсылки к моей личности оставлю без ответа: сам по себе переход на оную свидетельствует об отсутствии аргументации по сути. Разве что вот это:
Почему бы просто не пройти мимо, если Вы не разделяете моих взглядов?
А почему бы мне, собственно, не прокомментировать по теме, в которой я неплохо разбираюсь? Вы готовы исключительно к хвалебным комментариям?
Минусов в карму тоже ставить не буду – в отличие от. Мелко это.
@DmitryR3989мне кажется, хабр не совсем то место, где следует описывать свои красные флаги. Попробуйте опубликовать сиви из двух разделов:
Моя квалификация
Требования к работодателю
И во втором разделе перечислите всё, что написано в этих двух статьях. Так было бы честно – работодатели сразу видели бы, стоит ли им пытаться Вас нанять. Сэкономите массу времени на (не)хождении по собесам – и себе, и кандидатам в работодатели.
Мне кажется файлы по 1500 строк и ужасная архитектура пооекта - это не свойство RN
Разумеется. Это свойство программистов, от которых мы тот код получили.
можно и рефакторинг приложения устроить, но нужно конечно системно понять - что плохо, почему так, втащить TypeScript, если проблемы со сборкой - перейти на expo
Это уже не рефакторинг, а полное переписывание. А коль скоро всё равно переписывать, то нет необходимости цепляться за конкретную технологию – тем более ту, которая уже однажды показала себя не лучшим образом. Я поизучал, что есть в кроссплатформе, ознакомился с опытом других и принял решение использовать флаттер. Не пожалел, решение вполне себя оправдало.
Ну что тут можно поделать, менеджер сказал "хочу", пилим генератор.
Что бывает всякое, понятно. Мне просто любопытно, что за функционал таким образом обеспечивается. Сегодня элемент меню называется так, а завтра по-другому, без изменения кода приложения? Звучит загадочно 🙂
Данная статья является туториалом по написанию простейшего кодогенератора. Тема с локализацией рассматривается как пример.
Согласитесь, разумнее было бы в качестве примера взять более практически применимую задачу, чем дублирование intl.
однако он не позволит получить, например, arb файл из интернета во время работы приложения и использовать его для локализации
Не очень представляю себе такой сценарий использования. Чтобы использовать строки из .arb, код приложения должен знать, что такая строка в нём есть – добавить новую строку, не меняя код приложения не получится. Да и зачем менять строки в рантайме, я не знаю. Это же не контент, а UI. Опечатку разве что исправить – а как часто это нужно? Может, я ошибаюсь – тогда поясните.
На Эльбрусе для катания на лыжах (а это в основном ниже 4000) нужна адаптация.
Вообще говорили, что влияние высоты сильно зависит от региона, и Кавказ чуть ли не самый сложный в этом смысле. Но всё же да, после пары дней акклиматизации 3800 вроде не должны представлять проблемы. На Эльбрусе не катался, личного опыта нет – но в Гудаури всё кошерно, а там диапазон высот до 3600.
Ага, и каждый программист сам решает, что и когда релизить. Не верю ©
Так и не понял, что изменится в лучшую сторону для менеджера, если его начальство будет думать, что переход был его идеей. Скорее наоборот – для начальства верхнего уровня это ещё более "осталось, как было, а время и ресурс потратили". Он мазохист, хочет, чтобы наказали его, а не программиста?
CI != CD. И вообще CI должна запускаться безо всякой кнопки, просто по факту мержа фичи в общий бранч.
UPD: а релиз по инициативе разработчика – это никакой не стандарт, а воплощённый кошмар. Представьте себе команду из нескольких десятков, а то и сотен программистов, каждый из которых релизит в прод, когда ему вздумается.
Есть свои плюсы, одно время использовали. Но в этом случае и деплой делается иначе. В любом случае, если программист, закончив фичу, вмерживает её в мастер и она тут же появляется на проде, без предварительного тестирования – это категорически неправильно.
Простите, это я никак по-другому интерпретировать не могу:
В этом случае описанная в статье ситуация невозможна
Всё равно эти предложения и решение руководителя должны быть отражены в тикете – что опять же делает описанную ситуацию невозможной.
Ага, а если предложить ему приписать нововведение себе, то сразу проникнется его ценностью. Камон.
Не понимаю. Вы предлагаете руководителю НЕ мониторить тикеты? А чем он тогда вообще занимается, и откуда узнаёт о состоянии дел?
Мне ежедневно приходит сотни полторы апдейтов. Никакой особой перегрузки это не создаёт: если держишь руку на пульсе, достаточно одного взгляда, чтобы понять – всё ли тут в порядке или требуется вмешаться. А если начинаешь не успевать – это явный индикатор того, что команду пора дробить на более мелкие.
А что тогда эффективно? Поделитесь опытом.
Нет, вопрос вовсе не в этом, а в том, что если руководитель не согласен развивать ценные идеи разработчиков, если лавры достанутся не ему – это очень плохой руководитель.
Опять-таки, вопрос организации процесса. В норме разработчик не может сам принимать решения об откладывании работ, а руководитель непрерывно мониторит изменения в тикетах, так что не может быть не в курсе, даже если такое произошло.
Я и писал: где в принципе присутствует иерархия руководства.
Для хотфиксов должна быть отдельная процедура – в принципе мало чем отличающаяся, только что изменение мержится изначально не в релиз, а в хотфикс бранч, и тестируется там.
Если забыл, то это баг, который должен был выявиться при тестировании – а отнюдь не во время попытки мержа в мастер.
Вы писали совсем о другом: убедить руководителя, что идея разработчика принадлежит ему – иначе он откажется её продвигать. Это совершенно нездоровые отношения.
Я бы сказал, что статья о том, как общаться с руководителем в условиях неверно организованного процесса. Например:
Если задача приостановлена, это должно быть отражено в тикете. Тогда и вопросов не будет.
Не может быть никаких исключений. В сколько-нибудь серьёзном проекте (где в принципе присутствует иерархия руководства) у программистов просто не должно быть доступа на прод.
То же самое. PR должен включать в себя деплой скрипт, в котором всё это делается, запускаемый релиз менеджером. В идеале ещё и роллбэк скрипт, на случай непредвиденностей.
Фичи не должны напрямую мержиться в мастер. Сначала в релизный бранч, где всё в комплексе тестируется, и только после того, как QA дали добро – в мастер и на прод.
Я бы в конторе, где такое происходит, работать не хотел. Руководитель, радостно присваивающий себе идеи подчинённых, и подчинённые-подхалимы, которые его к этому подталкивают.
Можно и ещё попридираться, но вот эти пункты просто таки глаз режут.
Как уже писал, совсем его не знаю. Правда, пару раз случалось просматривать код – и прямо скажу, он вовсе не показался мне простым. Обычно я неплохо понимаю код на незнакомых языках, но это не тот случай – многое навскидку неочевидно. Да и как-то плохо сочетается декларированная простота с тем самым
Могу предположить, что в этом и проблема: задачи в области применения языка не решаются ограниченным набором простых средств при сохранении приемлемой эффективности. Поэтому приходится идти на усложнение, противоречащее изначально заложенной в язык философии. И вряд ли с этим что-то можно поделать: всё же языки разрабатываются для решения бизнес-задач, а не для удовольствия программистов, и если бизнес требует добавления в него конструкций, ускоряющих процесс разработки, это обязательно произойдёт.
Как уже писал, совсем его не знаю. Правда, пару раз случалось просматривать код – и прямо скажу, он вовсе не показался мне простым. Обычно я неплохо понимаю код на незнакомых языках, но это не тот случай – многое навскидку неочевидно. Да и как-то плохо сочетается декларированная простота с тем самым
Могу предположить, что в этом и проблема: задачи в области применения языка не решаются ограниченным набором простых средств при сохранении приемлемой эффективности. Поэтому приходится идти на усложнение, противоречащее изначально заложенной в язык философии. И вряд ли с этим что-то можно поделать: всё же языки разрабатываются для решения бизнес-задач, а не для удовольствия программистов, и если бизнес требует добавления в него конструкций, ускоряющих процесс разработки, это обязательно произойдёт.
Ну для начала, статьи – таки инструкция для тех, кто именно что ищет. При том, что автор сам прекрасно понимает, что заранее огласив такой список претензий, станет неинтересен примерно всем. Что ничуть не мешает ему советовать другим действовать по такому, совершенно провальному алгоритму.
Что было раньше, курица или яйцо? У меня есть простое правило: стараюсь вести себя так, как мне хотелось бы, чтобы относились ко мне. А в данном случае вообще не понимаю, зачем скрывать свои предпочтения. Чтобы лишний раз сходить на собес и чувством глубокого удовлетворения констатировать, что все работодатели неправильные? Напишите сразу, чего хотите – откликнутся только правильные.
А по сути-то, не переходя на мою личность, есть, что ответить?
Почему? Вы же [справедливо] ожидаете от работодателя, чтобы он честно и подробно рассказал, какие требования к Вам будут предъявляться? Найм – это двусторонний процесс, было бы логично столь же честно сообщить ему и о Ваших ожиданиях.
Отсылки к моей личности оставлю без ответа: сам по себе переход на оную свидетельствует об отсутствии аргументации по сути. Разве что вот это:
А почему бы мне, собственно, не прокомментировать по теме, в которой я неплохо разбираюсь? Вы готовы исключительно к хвалебным комментариям?
Минусов в карму тоже ставить не буду – в отличие от. Мелко это.
@DmitryR3989мне кажется, хабр не совсем то место, где следует описывать свои красные флаги. Попробуйте опубликовать сиви из двух разделов:
Моя квалификация
Требования к работодателю
И во втором разделе перечислите всё, что написано в этих двух статьях. Так было бы честно – работодатели сразу видели бы, стоит ли им пытаться Вас нанять. Сэкономите массу времени на (не)хождении по собесам – и себе, и кандидатам в работодатели.
SWIFT не знаю совсем. Тем не менее: вроде одно логически вытекает из другого, не?
из
Задач-то бесконечное количество, соответственно, для каждой из них язык должен предоставить то самое специальное решение.
Разумеется. Это свойство программистов, от которых мы тот код получили.
Это уже не рефакторинг, а полное переписывание. А коль скоро всё равно переписывать, то нет необходимости цепляться за конкретную технологию – тем более ту, которая уже однажды показала себя не лучшим образом. Я поизучал, что есть в кроссплатформе, ознакомился с опытом других и принял решение использовать флаттер. Не пожалел, решение вполне себя оправдало.
Что бывает всякое, понятно. Мне просто любопытно, что за функционал таким образом обеспечивается. Сегодня элемент меню называется так, а завтра по-другому, без изменения кода приложения? Звучит загадочно 🙂
Согласитесь, разумнее было бы в качестве примера взять более практически применимую задачу, чем дублирование intl.
Не очень представляю себе такой сценарий использования. Чтобы использовать строки из .arb, код приложения должен знать, что такая строка в нём есть – добавить новую строку, не меняя код приложения не получится. Да и зачем менять строки в рантайме, я не знаю. Это же не контент, а UI. Опечатку разве что исправить – а как часто это нужно? Может, я ошибаюсь – тогда поясните.
Вообще говорили, что влияние высоты сильно зависит от региона, и Кавказ чуть ли не самый сложный в этом смысле. Но всё же да, после пары дней акклиматизации 3800 вроде не должны представлять проблемы. На Эльбрусе не катался, личного опыта нет – но в Гудаури всё кошерно, а там диапазон высот до 3600.