Многие на собеседованиях любят гонять по последним фичам языка.
Эта фраза задаёт дух остальной части статьи: на собеседованиях спрашивают чушь, ведь большая часть сидит на старых версиях.
При этом из первого не следует второго. То, что на собеседованиях глупо спрашивать все распоследние фичи языка, которые легко посмотреть в чейнджлоге не означает, что сидеть на допотопных версиях языков и библиотек является хорошей практикой.
Оправдания в духе "у нас тут миллиард строк кода, нас некогда его рефакторить, нас надо фичи пилить" говорят лишь о том, что уровень разработки в компании низкий, а всем заправляют менеджеры, которые стремятся получить результат здесь и сейчас. Для компании такой подход может быть и оправдан, но для разработчика работа в таком месте является не всегда правильным решением.
Это как собеседования по алгоритмам: обычно они не имеют отношения к реальной работе, но это не значит, что разработчик совсем не должен думать о своей теоретической подготовке.
Если суммировать, то по-сути к увеличению частоты релизов привели выстраивание и нормализация процессов, появление автотестов и разбиение релизов на более мелкие.
Абсолютно правильный подход с точки зрения организации работы, вот только для команд в итоге это превращается в бесконечную гонку и работу на фича фабрике. Правда, с последним ничего не поделать наверное.
Статья хотя и рассматривает тему, которая в интернете и различных учебниках раскрыта уже множество раз, но все же может кому-то пригодиться.
Вопрос в другом: зачем у вас в компании для повышения на следующий грейд решать какие-то выдуманные задачи, если процессу повышения предшествует как минимум полгода работы сотрудника? Разве его результатов за период не достаточно для принятия решения? В чем ценность того, что человек смог написать алгоритм калькулятора?
Все же, надо отметить, что языковая нагрузка, т.е. количество задач, связанных с разными языками всё-таки неравномерна.
Да, сравнение со строительной бригадой от части уместно, но при условии, что наша бригада большую часть времени занимается плиточными работами и изредка нужно сделать что-то по электрике.
Так и тут: большая часть задач — это php разработка, но при этом команда иногда делает задачи, требующих знания других технологий и языков.
Вероятно, при этом код на другом языке будет не совсем идиоматичным, но это не делает его плохим.
Зато появляется возможность применить подходящую технологию там, где ей место, не ограничиваясь одним языком, а для ребят появляются точки роста и развития.
Эх, это же ведь все просто исторический очерк и в следующей статье будет рассказано, как все это было заменено на один из популярных инструментов, ведь правда?
Правила оформления кода — это самый безобидный, простой и к тому же автоматизируемый способ поддерживать читабельность и чистоту. От нарушения каждого отдельного правила в каждом отдельном месте мозг не взорвется, но вот если каждый в проекте будет писать так, как ему вздумается, то взрыв как раз таки наступит очень скоро. И чтобы не тратить дни на бессмысленные споры типа табы или пробелы и придуман кодстайл.
У кого-то наступает выгорание от того, что линтер просит поменять порядок импортов? Толи ещё будет, когда к такому человеку придет бизнес с хард дедлайном!
Ваш пример не проще. Вы реализуете специальную конструкцию, где у основного метода run нужно ещё не забывать вызывать task.Tick(), тем самым вы фактически переизобретаете корутины, только корявого вида.
Ещё раз хочу обратить Ваше внимание, что контекст не имеет отношения к многозадачности, это лишь способ переноса информации.
Возвращаясь опять к вашему примеру, нет, вам не удастся со своей библиотекой сосредоточиться на бизнес-логике. Во, первых вам надо будет помнить про упомянутый выше Tick, что уже завязывает вашу логику на библиотеку. Во вторых, вы не сможете ничего заканселить, если внутри метода у вас будет например http вызов: вам придется городить внутри сложный механизм и все равно в итоге вы начнёте работать с context.Context.
В стандартном гошном подходе вы бы просто написали несколько функций с контекстом в качестве первого параметра и в основном методе запустили бы их в корутинах, в вашем же случае — попытка сделать что-то похожее не генераторы в php.
Для статьи стоило бы показать пример решения вашей задачи на стандартных механизмах голанга и потом с помощью вашей библиотеки. Пока выглядит как переусложнение там, где не нужно. Паттерны разумеется в го применимы, и command, и job, и любые другие, но как и всегда, если это обосновано чем-то
Интерфейсы в го в большинстве случаев стоит делать только на стороне потребителя.
Т.е. вполне можно иметь просто тип Task, так как у вас нет разных типов задач, требующих обобщения. Если же в будущем они появятся — можно будет ввести интерфейс.
А пользователь вашей библиотеки вполне может у себя завести интерфейс с нужными ему методами и использовать его в меру необходимости, так как в отличии от php в го применим duck-typing
Вы все время упоминаете context.Context, что он нужен для асинхронности или корутин. Но ведь это не так: контекст, как сообщает нам официальная документация — это переносчик состояния процесса или, что более специфично, текущего api вызова.
Чаще всего контекст используется для хранения в нем специфичной для запроса информации (например, проброса такой информации, как трейсинг), а также прокидывания сигналов отмены.
Т.е., с его помощью можно контролировать выполнение нижележащих вызовов, например задавать таймауты запросов.
Самое главное, что контекст понимают все встроенные в язык пакеты, связанные с какими-либо вызовами, а также все другие библиотеки.
Почему вы его противопоставляете своему подходу с джобами?
Пытаться искать общие точки и на их фоне попробовать стать не джуном, а выше. Ведь позиция складывается из нескольких вещей:
степень самостоятельности
знание языка и его экосистемы
Причем первое скорее имеет приоритет над вторым.
Если вы синьор в мобильной разработке, то скорее всего по первому пункту уже явно должны проходить не на джуна и в любой другой области.
С точки зрения языка и экосистемы надо смотреть на варианты либо с переходом на тот же язык, что у вас уже есть (например, андроид разработчик на Java-бекенд), либо активно учить язык в свободное время (это не так сложно обычно).
Ещё вариант перейти внутри своей компании, если есть такая возможность. Это самый простой путь, так как вас уже знают.
Судя по всему, php постепенно и придет к тому, что типы будут везде. Уже сейчас в большинстве проектов считается обязательным как минимум для нового кода использовать типизацию. Пока ещё невозможно это делать для переменных, но думаю, что и там тоже типы добавятся со временем.
Не думаю, что язык когда-либо станет строго типизированные, поскольку это сломает обратную совместимость в куче проектов, но то, что через некоторое время типы будут применяться повсеместно, это точно. И скорее всего такой код будет работать быстрее, чем код без типов.
Во-первых, с появлением возможности указывать типы язык не перестал быть языком с динамической типизацией.
Во-вторых, есть немало проектов, которые переписывать никто не будет, а вот внедрить в них потихоньку типизацию с целью увеличения качества кода вполне можно.
В-третьих, типизация не делает язык лучше всех остальных, она лишь привносит ещё одно улучшение, которое можно применять с целью сделать свой код качественнее.
А почему нет? Например, в тех же тестах часто есть конструкции вида MyClass|TestObject и теперь это можно законно использовать на уровне языка, а не аннотаций.
Смотря что понимать под фичами. Первые задачи могут быть готовы и на второй день (в теории), но часто сложность общего функционала все-таки выше, чтобы человек, который второй день работает с проектом, мог сразу выкатить что-то существенное в прод
Pulsar тоже не очень любит. Как минимум размер пакета в протоколе по-умолчанию — 5 мегабайт.
Может быть в целом и не нужно слать такие большие задания? Положили пейлоад в сторадж, положили событие с его id в очередь и все
Благодарю за поздравления :)
Абстрактно отвечать не готов. Часто да, язык в дистрибутиве операционный системы не самый свежий.
Судя по комментариям именно в легаси монстрах этот вопрос и возникает.
Эта фраза задаёт дух остальной части статьи: на собеседованиях спрашивают чушь, ведь большая часть сидит на старых версиях.
При этом из первого не следует второго. То, что на собеседованиях глупо спрашивать все распоследние фичи языка, которые легко посмотреть в чейнджлоге не означает, что сидеть на допотопных версиях языков и библиотек является хорошей практикой.
Оправдания в духе "у нас тут миллиард строк кода, нас некогда его рефакторить, нас надо фичи пилить" говорят лишь о том, что уровень разработки в компании низкий, а всем заправляют менеджеры, которые стремятся получить результат здесь и сейчас. Для компании такой подход может быть и оправдан, но для разработчика работа в таком месте является не всегда правильным решением.
Это как собеседования по алгоритмам: обычно они не имеют отношения к реальной работе, но это не значит, что разработчик совсем не должен думать о своей теоретической подготовке.
Если суммировать, то по-сути к увеличению частоты релизов привели выстраивание и нормализация процессов, появление автотестов и разбиение релизов на более мелкие.
Абсолютно правильный подход с точки зрения организации работы, вот только для команд в итоге это превращается в бесконечную гонку и работу на фича фабрике. Правда, с последним ничего не поделать наверное.
Статья хотя и рассматривает тему, которая в интернете и различных учебниках раскрыта уже множество раз, но все же может кому-то пригодиться.
Вопрос в другом: зачем у вас в компании для повышения на следующий грейд решать какие-то выдуманные задачи, если процессу повышения предшествует как минимум полгода работы сотрудника? Разве его результатов за период не достаточно для принятия решения? В чем ценность того, что человек смог написать алгоритм калькулятора?
Все же, надо отметить, что языковая нагрузка, т.е. количество задач, связанных с разными языками всё-таки неравномерна.
Да, сравнение со строительной бригадой от части уместно, но при условии, что наша бригада большую часть времени занимается плиточными работами и изредка нужно сделать что-то по электрике.
Так и тут: большая часть задач — это php разработка, но при этом команда иногда делает задачи, требующих знания других технологий и языков.
Вероятно, при этом код на другом языке будет не совсем идиоматичным, но это не делает его плохим.
Зато появляется возможность применить подходящую технологию там, где ей место, не ограничиваясь одним языком, а для ребят появляются точки роста и развития.
Эх, это же ведь все просто исторический очерк и в следующей статье будет рассказано, как все это было заменено на один из популярных инструментов, ведь правда?
Линтер не поменяет, потому что поменяет форматер. Он для того и придуман, чтобы вообще о таких мелочах не думать и вручную не править
Правила оформления кода — это самый безобидный, простой и к тому же автоматизируемый способ поддерживать читабельность и чистоту. От нарушения каждого отдельного правила в каждом отдельном месте мозг не взорвется, но вот если каждый в проекте будет писать так, как ему вздумается, то взрыв как раз таки наступит очень скоро. И чтобы не тратить дни на бессмысленные споры типа табы или пробелы и придуман кодстайл.
У кого-то наступает выгорание от того, что линтер просит поменять порядок импортов? Толи ещё будет, когда к такому человеку придет бизнес с хард дедлайном!
Ваш пример не проще. Вы реализуете специальную конструкцию, где у основного метода run нужно ещё не забывать вызывать task.Tick(), тем самым вы фактически переизобретаете корутины, только корявого вида.
Ещё раз хочу обратить Ваше внимание, что контекст не имеет отношения к многозадачности, это лишь способ переноса информации.
Возвращаясь опять к вашему примеру, нет, вам не удастся со своей библиотекой сосредоточиться на бизнес-логике. Во, первых вам надо будет помнить про упомянутый выше Tick, что уже завязывает вашу логику на библиотеку. Во вторых, вы не сможете ничего заканселить, если внутри метода у вас будет например http вызов: вам придется городить внутри сложный механизм и все равно в итоге вы начнёте работать с context.Context.
В стандартном гошном подходе вы бы просто написали несколько функций с контекстом в качестве первого параметра и в основном методе запустили бы их в корутинах, в вашем же случае — попытка сделать что-то похожее не генераторы в php.
Да, и паниковать при ошибках плохая практика.
Для статьи стоило бы показать пример решения вашей задачи на стандартных механизмах голанга и потом с помощью вашей библиотеки. Пока выглядит как переусложнение там, где не нужно. Паттерны разумеется в го применимы, и command, и job, и любые другие, но как и всегда, если это обосновано чем-то
Интерфейсы в го в большинстве случаев стоит делать только на стороне потребителя.
Т.е. вполне можно иметь просто тип Task, так как у вас нет разных типов задач, требующих обобщения. Если же в будущем они появятся — можно будет ввести интерфейс.
А пользователь вашей библиотеки вполне может у себя завести интерфейс с нужными ему методами и использовать его в меру необходимости, так как в отличии от php в го применим duck-typing
Вы все время упоминаете context.Context, что он нужен для асинхронности или корутин. Но ведь это не так: контекст, как сообщает нам официальная документация — это переносчик состояния процесса или, что более специфично, текущего api вызова.
Чаще всего контекст используется для хранения в нем специфичной для запроса информации (например, проброса такой информации, как трейсинг), а также прокидывания сигналов отмены.
Т.е., с его помощью можно контролировать выполнение нижележащих вызовов, например задавать таймауты запросов.
Самое главное, что контекст понимают все встроенные в язык пакеты, связанные с какими-либо вызовами, а также все другие библиотеки.
Почему вы его противопоставляете своему подходу с джобами?
Добавьте тогда в список ещё Windows и Office.
А если серьезно, какое отношение большая часть программ имеет к тайм-менеджементу?
Какой-то случайный набор программ.
Пытаться искать общие точки и на их фоне попробовать стать не джуном, а выше. Ведь позиция складывается из нескольких вещей:
Причем первое скорее имеет приоритет над вторым.
Если вы синьор в мобильной разработке, то скорее всего по первому пункту уже явно должны проходить не на джуна и в любой другой области.
С точки зрения языка и экосистемы надо смотреть на варианты либо с переходом на тот же язык, что у вас уже есть (например, андроид разработчик на Java-бекенд), либо активно учить язык в свободное время (это не так сложно обычно).
Ещё вариант перейти внутри своей компании, если есть такая возможность. Это самый простой путь, так как вас уже знают.
Судя по всему, php постепенно и придет к тому, что типы будут везде. Уже сейчас в большинстве проектов считается обязательным как минимум для нового кода использовать типизацию. Пока ещё невозможно это делать для переменных, но думаю, что и там тоже типы добавятся со временем.
Не думаю, что язык когда-либо станет строго типизированные, поскольку это сломает обратную совместимость в куче проектов, но то, что через некоторое время типы будут применяться повсеместно, это точно. И скорее всего такой код будет работать быстрее, чем код без типов.
Во-первых, с появлением возможности указывать типы язык не перестал быть языком с динамической типизацией.
Во-вторых, есть немало проектов, которые переписывать никто не будет, а вот внедрить в них потихоньку типизацию с целью увеличения качества кода вполне можно.
В-третьих, типизация не делает язык лучше всех остальных, она лишь привносит ещё одно улучшение, которое можно применять с целью сделать свой код качественнее.
А почему нет? Например, в тех же тестах часто есть конструкции вида MyClass|TestObject и теперь это можно законно использовать на уровне языка, а не аннотаций.