Как завуалированно переносится ответственность, с “хорошего менеджера” (который как раз должен был настроить эти процессы взаимодействия и поделить ответственности) на “плохого инженера” (который якобы должен выполнить работу менеджера, по мнению автора).
В идеальном мире все так, ответственность несёт исполняющий, раз он взялся, тут спору нет. Но если человек называется менеджером (лидом, пм), то будет добр - создай условия, чтобы такого в принципе не возникало.
Так же как и инженер - вряд ли будет спрашивать у менеджера: “как сделать это, а как то”. Это его зона ответственности, и чем меньше он отвлекается на ошибки менеджмента - тем эффективнее работает.
Описанный 2 пример с backend разработчиком - будет работать по умолчанию, если условием для “отфутболивания” задачи будут не просто “у нас все работает”, а “у нас все протестировано и вот результат”.
Дальше - задача управляющего проектом(командой) решить в каком же месте оно тогда могло сломаться, с кого спрос и где архитектурная проблема.
Получил в подарок от жены к 23 фев. Заказали как только вышел пост, на следующий день уже привезли.
Легко читается (учитывая техническую сложность вопроса), чувствуется что написана с душой. Радует обилие деталей, личных примеров и тестов, особенно ценен личный опыт автора. Есть некоторые ассоциации с книгой "Паттерны программирования игр: Роберт Нистрем", где автор также делится своими наработками.
Сам пишу на C# (Unity), но всегда интересны подкапотные детали и особенности работы. Если переживете что не знаете C++ - не волнуйтесь, примеры хорошие, написано доходчиво. Но базовое понимание синтаксиса все же будет плюсом.
Из последнего интересного, что сработало для меня - это разбиение задачи на 2-3 составляющие, но не до таких мелких деталей (немного в другой плоскости).
Вместо:
"упаковать текстуры в атласы, так как обновилась юнити и старый SpritePacker уже не работает"
Делаем:
Что вообще нужно сделать (пункты из головы - все на "бумагу")
как это было устроено на проектах
что изменилось в обновлениях юнити
какие нюансы я помню
каков результат? для чего это делаю?
[Это самое важное] Собственно осмысленно потраченное время на изучение этих вопросов. Т.е. ты заранее предполагаешь что на это уйдёт не 5 минут а .. (2 часа, день, два)
И только здесь эта задача переходит к процессу решения.
В зависимости от размеров задачи - пункт 1 можно пропустить, а если задача и так мелкая - то и 2ой будет лишним.
А если что-то большое (обычно оно выявляется на 2ом этапе), то появится и 4ый - занести важное в документацию, чтобы в будущем, можно было подсмотреть подсказку или хотя бы ход мыслей (так как технически - информация всеравно устареет). Суть в том, что мы заранее себя подготавливаем к тому, что на запись информации тоже нужно время.
Тогда по завершению - нет ощущения что 3 дня что-то делал, а что именно - не понятно.
Если бы справлялись, то не было бы споров об архитектурах, ведь если подняться от 1:0 хотя бы на уровень инструкций, а там уже и до простого ЯП - то получаем те же самые проблемы как и в обычном языке.
Азбукой морзе - тоже можно общаться, но это лишь способ передачи информации, а не ее конструкции.
В Run-cat - как раз не хватает загрузки оперативной памяти.
А так идея с двумя иконками - вполне удобно. Только что бы без наведения можно было узнавать статус (не важно - в виде процентов или какой-либо анимации, но с цветами - все же тяжелее будет восприятие)
Как завуалированно переносится ответственность, с “хорошего менеджера” (который как раз должен был настроить эти процессы взаимодействия и поделить ответственности) на “плохого инженера” (который якобы должен выполнить работу менеджера, по мнению автора).
В идеальном мире все так, ответственность несёт исполняющий, раз он взялся, тут спору нет. Но если человек называется менеджером (лидом, пм), то будет добр - создай условия, чтобы такого в принципе не возникало.
Так же как и инженер - вряд ли будет спрашивать у менеджера: “как сделать это, а как то”. Это его зона ответственности, и чем меньше он отвлекается на ошибки менеджмента - тем эффективнее работает.
Описанный 2 пример с backend разработчиком - будет работать по умолчанию, если условием для “отфутболивания” задачи будут не просто “у нас все работает”, а “у нас все протестировано и вот результат”.
Дальше - задача управляющего проектом(командой) решить в каком же месте оно тогда могло сломаться, с кого спрос и где архитектурная проблема.
Отличная книга! Спасибо за ваш труд!
Получил в подарок от жены к 23 фев. Заказали как только вышел пост, на следующий день уже привезли.
Легко читается (учитывая техническую сложность вопроса), чувствуется что написана с душой. Радует обилие деталей, личных примеров и тестов, особенно ценен личный опыт автора. Есть некоторые ассоциации с книгой "Паттерны программирования игр: Роберт Нистрем", где автор также делится своими наработками.
Сам пишу на C# (Unity), но всегда интересны подкапотные детали и особенности работы. Если переживете что не знаете C++ - не волнуйтесь, примеры хорошие, написано доходчиво. Но базовое понимание синтаксиса все же будет плюсом.
Отличная статья! Спасибо за выжимку опыта.
В целом именно это и интересует - запуск Дискорд на своем сервере (через docker). Звонки как я понял, уже работают у них.
А так смотрю что чего-то схожего больше и нет по сути.
Достойно отдельной статьи!
Stoat интересно выглядит, кто-то пробовал?
Довольно хорошо написано, как для статей про MVC, где обычно любят излишне усложнять.
Также понравилось что показали какую именно проблему это решает.
Интересно будет почитать продолжение, спасибо.
Спасибо, статья полезная!
Но хорошо бы как-то обуздать ИИ кашу, особенно к концу, приходится просто скроллить одно и то же..
Ничего себе здесь перекличка)
Интересно как так, что человек, якобы разбирающийся в устройстве Android - не знает что подобные разрешения, есть у половины приложений на маркете.
Кроме специфичных - доступа к камере, контактам и т.п. (это понятно из назначения приложения)
Из последнего интересного, что сработало для меня - это разбиение задачи на 2-3 составляющие, но не до таких мелких деталей (немного в другой плоскости).
Вместо:
"упаковать текстуры в атласы, так как обновилась юнити и старый SpritePacker уже не работает"
Делаем:
Что вообще нужно сделать (пункты из головы - все на "бумагу")
как это было устроено на проектах
что изменилось в обновлениях юнити
какие нюансы я помню
каков результат? для чего это делаю?
[Это самое важное] Собственно осмысленно потраченное время на изучение этих вопросов. Т.е. ты заранее предполагаешь что на это уйдёт не 5 минут а .. (2 часа, день, два)
И только здесь эта задача переходит к процессу решения.
В зависимости от размеров задачи - пункт 1 можно пропустить, а если задача и так мелкая - то и 2ой будет лишним.
А если что-то большое (обычно оно выявляется на 2ом этапе), то появится и 4ый - занести важное в документацию, чтобы в будущем, можно было подсмотреть подсказку или хотя бы ход мыслей (так как технически - информация всеравно устареет). Суть в том, что мы заранее себя подготавливаем к тому, что на запись информации тоже нужно время.
Тогда по завершению - нет ощущения что 3 дня что-то делал, а что именно - не понятно.
Если бы справлялись, то не было бы споров об архитектурах, ведь если подняться от 1:0 хотя бы на уровень инструкций, а там уже и до простого ЯП - то получаем те же самые проблемы как и в обычном языке.
Азбукой морзе - тоже можно общаться, но это лишь способ передачи информации, а не ее конструкции.
В одной из статей (здесь же на Хабре) прочитал хорошую фразу, которая как мне кажется - ёмко описывает ваш комментарий:
"Мысль изреченная есть ложь" (Тютчев)
Примерная суть в том, что в языке - крайне не достаточно конструкций, чтобы явно изложить свою мысль.
Если ещё по библиотекам и синтаксису - то можно отметить структурные (вложенные) корутины и их удобный синтаксис. В Java подобного синтаксиса нет.
Постепенно приходит понимание, но первое время - да, листик висел с этими it, this.. А так, в первую очередь, стараешься что бы читалось осмысленно.
Я бы выделил ещё scope функции в Котлин, очень удобно и хорошая вариативность в использовании.
scopes: let, run, with, apply, also
Идея супер!
В Run-cat - как раз не хватает загрузки оперативной памяти.
А так идея с двумя иконками - вполне удобно. Только что бы без наведения можно было узнавать статус (не важно - в виде процентов или какой-либо анимации, но с цветами - все же тяжелее будет восприятие)
Статья супер, давно так не зачитывался, спасибо!
Прям блаженство среди "ии генерации".
Хорошая выжимка опыта, спасибо!
Ждём продолжения и технических деталей.
Да явно же, через ИИ прогнали всю эту простыню.