Это как раз самое удивительное и есть. Нет, не родственники. Владельцы компании где-то познакомились с юным талантом, восхитились и назначили. Жесть, конечно. Сразу скажу – владельцы далеко не идиоты, и бизнес они в конечном итоге раскрутили более, чем серьёзный – лет через 20 компанию продали за €600М.
Достаточно создать интерфейс для необходимой зависимости
В дарт каждый класс и так интерфейс. От добавления буковки I абсолютно ничего не меняется. Я не вижу в примере использования якобы DI фреймворка собственно инжекции зависимостей, в коде они жёстко зашиты в сам класс этого разнесчастного счётчика. Передать ему мок зависимости (скажем, стэйта) при тестировании я не могу. Дальше просто не разбирался, этого достаточно. Тем более, всё остальное очень уж напоминает FizzBuzz Enterprise Edition.
Я, конечно, дико извиняюсь, но первое, что вижу в коде – жёстко прописанные зависимости CounterDepsNode от CounterManager и CounterStateHolder. Как это мокать, например?
Был у меня в жизни случай, практически ровно такой же – СЕО назначили парня 17 лет. Мы об этом не знали сначала, тоже выглядел старше. Тоже неглупый, в чём-то разбирался. Кончилось тем, что у парня от ощущения собственной важности натурально крышу снесло, он почувствовал себя королём, который может обо всех ноги вытирать – и не упускал случая это делать. В конце концов выгнали, разумеется.
Мораль: власть над людьми иногда и взрослых-то превращает в неадекватов, а уж детскую психику таким испытаниям точно лучше не подвергать.
в статье по большей степени застрагиваются разработчики начального уровня
Если речь о рекомендации начинающим пробовать том числе собственные способы решения типовых проблем, то вопросов нет, это полезно. Но вот экстраполировать аж на целую эпоху – пожалуй, перебор 🙂
Мы живем в эпоху, когда программирование все чаще превращается в подбор существующих решений, а не в создание новых.
Пожалуй, я бы с этим поспорил. При обучении программированию – да, конечно, ибо оно по определению основывается на типовых задачах. В реальной же работе это не так: стандартные кейсы обычно покрываются библиотеками/фреймворками, а вот бизнес-логика (реализация которой, собственно, и составляет основной смысл программирования) обычно уникальна у каждого нового продукта – иначе не было бы смысла в его разработке, можно было бы просто взять готовый.
в моей жизни, к сожалению, все складывается примерно таким образом, как описано в статье
Я бы не сказал, что в статье всё неверно – по сути, все перечисленные проблемы могут возникать при неправильной организации работы. Но они вовсе не обязательны – тогда как статья создаёт впечатление, что иначе просто не бывает, с ними столкнутся все. В реальности единственная неразрешимая по сути проблема – то, что не все обладают достаточной самодисциплиной для удалённой работы. Таким людям она противопоказана, и ничего с этим не поделаешь. Сталкивался, кто-то сам уходил, кого-то и увольнять приходилось. Для остальных удалёнка по большинству критериев лучше офиса.
Так что мне, сказать программистам, чтобы отшивали бизнес, и сами не лезли в случае неясностей? 🙂 У нас это не так работает: вопросы часто обсуждаются совместно, по инициативе обеих сторон. И такого, чтобы бизнесу было "не до нас", не бывает – ибо бизнес прекрасно знает, что программисты работают в его интересах.
Или что, программисты не поняли задачу? А почему сказали "всё понятно"?
А почему нет-то? Поначалу выглядит понятно, а полезешь глубже – возникают вопросы. Обычное дело. Можно забить и сделать ровно то, что написано. Но лучше уточнить.
Если каждый делает свой кусок задачи по согласованному ТЗ
Это кодеры. У нас программисты. Они постоянно коммуницируют как друг с другом, так и с бизнесом. Есть общие чаты групп, где всегда можно получить консультацию коллег или согласовать новое решение. Если график произвольный, всё это становится крайне неудобным и главное, неэффективным.
Будут вопросы - всегда можно кого-то спросить кто знает (и в неурочное время тоже).
Об этом, кстати, было в статье: плохо, если тебя могут дёргать в любой момент. Мы такого стараемся избегать.
Чтобы их менеджерить удобно было?
В том числе. В хорошем смысле: не подглядывать, кто чем занят, а координировать работу.
___
Ну и в дополнение ко всему этому опять же сошлюсь на статью, некоторые вопросы там подняты правильно. В частности, фиксированные рабочие часы всё же вносят в жизнь некую упорядоченность. Иначе люди начинают путаться, где у них работа, а где личная жизнь.
просыпаешься когда хочешь, засыпаешь когда хочешь, а не когда "положено".
Только если работа делается в одно лицо. Занимаюсь организацией удалённой работы более 15 лет, и сам работаю вне офиса – если речь о командной работе, такое просто невозможно. У нас, например, "когда хочешь" ограничено выбором смены работы: с утра или вечером. Но рабочие часы фиксированные для обеих смен, и значительно перекрываются – чтобы была возможность совместной работы всех со всеми. Конечно, если кому-то нужно в конкретный день изменить график, это делается без проблем. Но в какие часы этот человек сегодня доступен, должно быть известно всегда. Ещё есть особые требования: в дни релизов все должны быть на связи независимо от их графика, и готовы подключиться в случае проблем.
@ksenia_strakhova это подборка надёрганных из интернета рассуждений, или таки есть некоторый личный опыт? Очень похоже на очередную историю о том, как одни бедные "коучат" других бедных, как стать богатыми.
Есть стойкое ощущение, что пора создавать отдельный HabrGPT. Мало того, что статьи по ИИ натурально заполонили ресурс, так ещё и те, что вроде бы по другим темам, оказывается, им написаны. Камон, пипл...
Где-то валяется фото чего-то вроде доски почёта из Новой Зеландии – "передовики производства" на фоне трупов уничтоженных ими крыс. Которые иначе кушают беззащитных автохонных киви.
Эффективность метода, правда, вызывает серьёзные сомнения: вряд ли несколько десятков убитых крысюков окажут значимое влияние на популяцию.
А как с заказчиком договоритесь, так и поставите. Ваша задача оценить трудоёмкость работ (я потом обычно умножаю на π/2 😁), согласовать дату релиза и что конкретно в него войдёт.
Основной минус водопадной модели в том, что у заказчика постоянно меняются хотелки по ходу проекта.
Наоборот. В "рафинированной" водопадной модели заказчик и исполнитель встречаются дважды: при подписании ТЗ, и потом акта приёмки. Заказчик не видит текущего состояния продукта и никакие хотелки у него возникать не могут в принципе. В реальности чуть иначе, но всё равно базовая идеология сохраняется: мы делаем ровно то, что заказано, а если заказчик ошибся в требованиях, то это его проблема.
А вот в эджайле регулярные изменения хотелок не просто возможны – они ещё и приветствуются, ибо целью является поставка максимальной ценности заказчику.
Код бы посмотреть... 🤔
Это как раз самое удивительное и есть. Нет, не родственники. Владельцы компании где-то познакомились с юным талантом, восхитились и назначили. Жесть, конечно. Сразу скажу – владельцы далеко не идиоты, и бизнес они в конечном итоге раскрутили более, чем серьёзный – лет через 20 компанию продали за €600М.
В дарт каждый класс и так интерфейс. От добавления буковки
Iабсолютно ничего не меняется. Я не вижу в примере использования якобы DI фреймворка собственно инжекции зависимостей, в коде они жёстко зашиты в сам класс этого разнесчастного счётчика. Передать ему мок зависимости (скажем, стэйта) при тестировании я не могу. Дальше просто не разбирался, этого достаточно. Тем более, всё остальное очень уж напоминает FizzBuzz Enterprise Edition.Я, конечно, дико извиняюсь, но первое, что вижу в коде – жёстко прописанные зависимости
CounterDepsNodeотCounterManagerиCounterStateHolder. Как это мокать, например?Был у меня в жизни случай, практически ровно такой же – СЕО назначили парня 17 лет. Мы об этом не знали сначала, тоже выглядел старше. Тоже неглупый, в чём-то разбирался. Кончилось тем, что у парня от ощущения собственной важности натурально крышу снесло, он почувствовал себя королём, который может обо всех ноги вытирать – и не упускал случая это делать. В конце концов выгнали, разумеется.
Мораль: власть над людьми иногда и взрослых-то превращает в неадекватов, а уж детскую психику таким испытаниям точно лучше не подвергать.
А пофиг. Моя реализация универсальна, любому годится.
Пхэ. Garbage in, garbage out. Всё!
Ага. Только у меня релизы раз в неделю. Это даже если не вспоминать маньяков, которые по нескольку раз в день релизят.
Да, и до завтра работа будет стоять. Возможно, срочная. Не устраивает.
Если речь о рекомендации начинающим пробовать том числе собственные способы решения типовых проблем, то вопросов нет, это полезно. Но вот экстраполировать аж на целую эпоху – пожалуй, перебор 🙂
Пожалуй, я бы с этим поспорил. При обучении программированию – да, конечно, ибо оно по определению основывается на типовых задачах. В реальной же работе это не так: стандартные кейсы обычно покрываются библиотеками/фреймворками, а вот бизнес-логика (реализация которой, собственно, и составляет основной смысл программирования) обычно уникальна у каждого нового продукта – иначе не было бы смысла в его разработке, можно было бы просто взять готовый.
Я бы не сказал, что в статье всё неверно – по сути, все перечисленные проблемы могут возникать при неправильной организации работы. Но они вовсе не обязательны – тогда как статья создаёт впечатление, что иначе просто не бывает, с ними столкнутся все. В реальности единственная неразрешимая по сути проблема – то, что не все обладают достаточной самодисциплиной для удалённой работы. Таким людям она противопоказана, и ничего с этим не поделаешь. Сталкивался, кто-то сам уходил, кого-то и увольнять приходилось. Для остальных удалёнка по большинству критериев лучше офиса.
Так что мне, сказать программистам, чтобы отшивали бизнес, и сами не лезли в случае неясностей? 🙂 У нас это не так работает: вопросы часто обсуждаются совместно, по инициативе обеих сторон. И такого, чтобы бизнесу было "не до нас", не бывает – ибо бизнес прекрасно знает, что программисты работают в его интересах.
А почему нет-то? Поначалу выглядит понятно, а полезешь глубже – возникают вопросы. Обычное дело. Можно забить и сделать ровно то, что написано. Но лучше уточнить.
Это кодеры. У нас программисты. Они постоянно коммуницируют как друг с другом, так и с бизнесом. Есть общие чаты групп, где всегда можно получить консультацию коллег или согласовать новое решение. Если график произвольный, всё это становится крайне неудобным и главное, неэффективным.
Об этом, кстати, было в статье: плохо, если тебя могут дёргать в любой момент. Мы такого стараемся избегать.
В том числе. В хорошем смысле: не подглядывать, кто чем занят, а координировать работу.
___
Ну и в дополнение ко всему этому опять же сошлюсь на статью, некоторые вопросы там подняты правильно. В частности, фиксированные рабочие часы всё же вносят в жизнь некую упорядоченность. Иначе люди начинают путаться, где у них работа, а где личная жизнь.
Только если работа делается в одно лицо. Занимаюсь организацией удалённой работы более 15 лет, и сам работаю вне офиса – если речь о командной работе, такое просто невозможно. У нас, например, "когда хочешь" ограничено выбором смены работы: с утра или вечером. Но рабочие часы фиксированные для обеих смен, и значительно перекрываются – чтобы была возможность совместной работы всех со всеми. Конечно, если кому-то нужно в конкретный день изменить график, это делается без проблем. Но в какие часы этот человек сегодня доступен, должно быть известно всегда. Ещё есть особые требования: в дни релизов все должны быть на связи независимо от их графика, и готовы подключиться в случае проблем.
@ksenia_strakhova это подборка надёрганных из интернета рассуждений, или таки есть некоторый личный опыт? Очень похоже на очередную историю о том, как одни бедные "коучат" других бедных, как стать богатыми.
Есть стойкое ощущение, что пора создавать отдельный HabrGPT. Мало того, что статьи по ИИ натурально заполонили ресурс, так ещё и те, что вроде бы по другим темам, оказывается, им написаны. Камон, пипл...
Где-то валяется фото чего-то вроде доски почёта из Новой Зеландии – "передовики производства" на фоне трупов уничтоженных ими крыс. Которые иначе кушают беззащитных автохонных киви.
Эффективность метода, правда, вызывает серьёзные сомнения: вряд ли несколько десятков убитых крысюков окажут значимое влияние на популяцию.
А как с заказчиком договоритесь, так и поставите. Ваша задача оценить трудоёмкость работ (я потом обычно умножаю на π/2 😁), согласовать дату релиза и что конкретно в него войдёт.
Наоборот. В "рафинированной" водопадной модели заказчик и исполнитель встречаются дважды: при подписании ТЗ, и потом акта приёмки. Заказчик не видит текущего состояния продукта и никакие хотелки у него возникать не могут в принципе. В реальности чуть иначе, но всё равно базовая идеология сохраняется: мы делаем ровно то, что заказано, а если заказчик ошибся в требованиях, то это его проблема.
А вот в эджайле регулярные изменения хотелок не просто возможны – они ещё и приветствуются, ибо целью является поставка максимальной ценности заказчику.
Разве что как я писал: по сервису на каждую буковку каждого CRUD модуля. Но это однозначно плохое проектирование.