Полностью согласен. Проблема заниженных оценок и сорванных дедлайно ложится не только на ПМа, но и на разраба. Хотя возможные косяки в оценке разработчика теоретически должны обрабатываться ПМом в виде дополнительной итерации оценки, выделение дополнительного времени на риски и т.д. Но это не значит, что мы как разработчики не должны учитывать озвученные в статье идеи при оценке чего бы то ни было.
С "пятиминутными" правками же разработчик (увы) сделать ничего не может, поэтому, по моему мнению, на старте проекта нужно обсудить регламент этих правок. То есть не когда заказчик уже пришел со словами "а вот у нас тут правочка небольшая", а в момент заключения договора указать (хотя бы примерно) какие изменения в сроках/стоимости такие правочки повлекут)
Хорошо, если все будут соблюдать правила, описанные в статье, на всех уровнях и, может быть, когда-нибудь дедлайны не будут вызывать у нас нервный тик.
Найдутся другие способы пролюбить дедлайн) Мы ж опытные люди все тут)))))
S в SOLID означает Single Responsibility — единственная ответственность Разбивайте код на модули, каждый из которых имеет одну ответственность.
Видишь такое в статье про SOLID - можно смело пропускать.
Не могли бы Вы немного развернуть мысль? Не совсем понимаю, что не так с таким определением.
Давайте просто заглянем в источник (будет локализованный вариант, да простят меня адепты английского)
Извините, не совсем понял, о каком источнике Вы говорите? Я читал дядюшку Боба (и вижу, что в Вашей цитате приводится, предлагаемое им определение единственной ответственности) и Фаулера, но таких переопределений определения у них не припомню.
Я, может, пропустил, это серия статей по игре или Вы просто вырвали интересную для себя единичную тему? Если это первая статья по игре, было бы полезно начать сначала, а не с лута..
Полностью согласен с предыдущим оратором) Я посмотрел Ваши публикации тут и чего-то вроде ДевЛог #19 не нашел) Статья очень заинтересовала и хотелось бы немного больше информации о предыдущих итерациях разработки, ну и о последующих, разумеется, тоже.
Заранее большое спасибо и успехов в Ваших проектах.
К слову о необходимости софт-скиллов и общения с людьми.
Я по образованию вообще повар (выбрал специальность как запасной вариант - люди всегда будут хотеть есть). В какой-то момент времени решил, что вышка все-таки карман не тянет, поступил в универ на специальность математик, системный программист. Однако, закончить не удалось, пришлось делать выбор в пользу усиленной работы, ибо хотелось кушать. Но за время обучения в универе (2 курса) познакомился и неплохо заобщался с товарищами со старших курсов и через одного из них устроился на стажировку в компанию, где сейчас и работаю на Xamarin (еще живой покамест).
Понятное дело, что тут история не столько про софт-скиллы, сколько про везение, но все-таки
От ассемблера пока не рекомендую избавляться, потому что в третьей части (спойлер) мы объединим классы GameObservableInstaller, GameLocatorInstaller и GameAssembler в один монобех-инсталлер, который будет заниматься созданием экземпляров с бизнес-логикой, регистрацией сервисов и лисенеров + прокидыванием в них зависимостей.
Вот тут лично мне кажется, что принцип единственной ответственности будет сильно нарушаться - слишком много причин для изменений получается (если следовать определению единственной ответственности, предложенному господином Мартином), поправьте меня, если я ошибаюсь. Почему нельзя оставить так как есть?
2. a. an additionalpayment made to employees as a means of increasing production (дополнительная оплата работнику, призванная увеличить производительность - т.е. есть фактически премия)
Я так понимаю, что именно вот этот момент и намекает на исключительно умственный труд - "особенно если сфера деятельности обучение, право или медицина"?
А вообще, все это только лишь подтверждает идею о том, что правильный нейминг выбрать довольно сложно)
Полностью согласен. Проблема заниженных оценок и сорванных дедлайно ложится не только на ПМа, но и на разраба. Хотя возможные косяки в оценке разработчика теоретически должны обрабатываться ПМом в виде дополнительной итерации оценки, выделение дополнительного времени на риски и т.д. Но это не значит, что мы как разработчики не должны учитывать озвученные в статье идеи при оценке чего бы то ни было.
С "пятиминутными" правками же разработчик (увы) сделать ничего не может, поэтому, по моему мнению, на старте проекта нужно обсудить регламент этих правок. То есть не когда заказчик уже пришел со словами "а вот у нас тут правочка небольшая", а в момент заключения договора указать (хотя бы примерно) какие изменения в сроках/стоимости такие правочки повлекут)
Найдутся другие способы пролюбить дедлайн) Мы ж опытные люди все тут)))))
Большое спасибо за отзыв и за исправление) Статью поправили.
Извольте, сэр) Фильм "Взлом" 2000 года вроде как (судя по аннотации) про Митника. За качество не ручаюсь, ибо не смотрел. Но раз уж нашел - посмотрю)
Благодарю!
Большое спасибо за статью!
Из чистого любопытства (понимаю, что по большей части это все вкусовщина), почему Вы используете именно Zenject, а не, скажем, VContainer?
То есть Вы просто перечислили паттерны, обманув наши ожидания заголовком статьи, а токсичные мы?)
Благодарю
Не могли бы Вы немного развернуть мысль? Не совсем понимаю, что не так с таким определением.
Извините, не совсем понял, о каком источнике Вы говорите? Я читал дядюшку Боба (и вижу, что в Вашей цитате приводится, предлагаемое им определение единственной ответственности) и Фаулера, но таких переопределений определения у них не припомню.
Простите, на тот момент когда писал комментарий, не видел Вашего ответа)
Полностью согласен с предыдущим оратором) Я посмотрел Ваши публикации тут и чего-то вроде ДевЛог #19 не нашел) Статья очень заинтересовала и хотелось бы немного больше информации о предыдущих итерациях разработки, ну и о последующих, разумеется, тоже.
Заранее большое спасибо и успехов в Ваших проектах.
Протест принят))) Начинаю процедуру скрещивания пальцев...)
А вот упомянули Atomic Heart, тогда почему Pathfinder'ы забыли?) Owlcat же тоже российская студия. Ну и Rouge Traider ждем-с
К слову о необходимости софт-скиллов и общения с людьми.
Я по образованию вообще повар (выбрал специальность как запасной вариант - люди всегда будут хотеть есть). В какой-то момент времени решил, что вышка все-таки карман не тянет, поступил в универ на специальность математик, системный программист. Однако, закончить не удалось, пришлось делать выбор в пользу усиленной работы, ибо хотелось кушать. Но за время обучения в универе (2 курса) познакомился и неплохо заобщался с товарищами со старших курсов и через одного из них устроился на стажировку в компанию, где сейчас и работаю на Xamarin (еще живой покамест).
Понятное дело, что тут история не столько про софт-скиллы, сколько про везение, но все-таки
Эх, жаль с 10 ведерком несовместимо. Или планируете поддержку андроида менее 12го добавлять?
Вот тут лично мне кажется, что принцип единственной ответственности будет сильно нарушаться - слишком много причин для изменений получается (если следовать определению единственной ответственности, предложенному господином Мартином), поправьте меня, если я ошибаюсь. Почему нельзя оставить так как есть?
Вопрос может быть немного не по теме статьи, но все-таки.
Из языков у Вас пока Pyton, JS, и Java, планируется ли добавление С#?
Спасибо Вам большое за статью и за разъяснения)
По поводу таксиста соглашусь (правда при условии, что он работает не на некую компанию).
Согласно Collins English Dictionary:
A salary is the money that someone is paid each month by their employer, especially when they are in a profession such as teaching, law, or medicine.
Сумма денег выплачиваемая работнику работодателем ежемесячно, особенно, если сфера деятельности обучение, право или медицина.
В то время как incentives согласно тому же словарю:
1. a motivating influence; stimulus (мотивация, стимул)
2. a. an additional payment made to employees as a means of increasing production (дополнительная оплата работнику, призванная увеличить производительность - т.е. есть фактически премия)
Я так понимаю, что именно вот этот момент и намекает на исключительно умственный труд - "особенно если сфера деятельности обучение, право или медицина"?
А вообще, все это только лишь подтверждает идею о том, что правильный нейминг выбрать довольно сложно)
Честно говоря, не совсем понимаю, что с salary не так
Большое спасибо за статью, очень познавательно!
А есть информация из-за чего конкретно разругались Белл и Брабен, что аж до судебных споров дошло? Или это в статье было, просто я не заметил?