Ага, более того — это упрощенное определение из исходной статьи Мартина. Но оно плохое, потому что не говорит о инвариантах и ограничениях типа и не дает ответа на вопрос «Как именно правильно организовать иерархию классов, чтобы LSP соблюдался?».
Задача про квадрат и прямоугольник — это классическая задача на которой этот вопрос немного проясняют.
А в оригинальной статье Лисков тем временем (http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-156.ps) даны очень четкие определения того, что считать инвариантами и ограничениями и как правильно наследовать.
Это классическая задачка на LSP мимо которой очень сложно пройти, если изучать этот принцип нормально, а не на уровне «Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.»
но только в последний год осознал, что они означают
Нет, судя по тексту статьи — все еще не осознали.
На каждом проекте люди играют разные роли (actor): Аналитик, Проектировщик интерфейсов, Администратор баз данных. Естественно, один человек может играть сразу несколько ролей. В этом принципе речь идет о том, что изменения в модуле может запрашивать одна и только одна роль. Например, есть модуль, реализующий некую бизнес-логику, запросить изменения в этом модуле может только Аналитик, но никак не DBA или UX.
А если на проекте появляются новые роли — надо все переписывать?
Это определенно может ввести в ступор. Как можно расширить поведение класса без его модификации?
Наследование, вариации паттерна «Стратегия» и так далее. При чем тут dll и jar?
LSP: The Liskov Substitution Principle
Есть класс Квадрат и есть класс Прямоугольник. Что от чего наследовать?
Под интерфейсом здесь понимается именно Java, C# интерфейс. Разделение интерфейса облегчает использование и тестирование модулей.
Так как же их разделять-то?
Что такое зависимость модулей? Это ссылка на модуль в исходном коде, т.е. import, require и т.п. С помощью динамического полиморфизма в runtime можно обратить эту зависимость.
Нет, зависимость — это зависимость между двумя любыми структурными блоками программы (функциями, классами, etc).
В общем, в книжке дяди Боба все есть, очень подробно и с примерами кода. А это стоит убрать.
Это нужно для того, чтобы объединить геттер и сеттер в одну семантическую сущность, на которую можно повесить атрибут и единым образом работать через reflection.
Ок, вот классическая задача — склад, товары на складе, движение товаров, отчет по остаткам, время построения отчета не зависит от количества записей о движении товаров. На 1С это делается (включая UI) без кода вообще.
например, мне надо в зависимости от пары языков предоставить конвертер из одного языка в другой. Ваши предложения?
Это типичный double dispatch. В классических ооп-языках со статической типизацией — решается исключительно через жовизитор.
Только причем тут enum и switch? Они проблему не решают никак.
По моему представлению депремирование в рамках ТК можно организовать следующим образом:
По трудовому договору вознаграждение сотрудника состоит из 2-х частей: окладной и премиальной;
Заранее составляется перечень возможных «прогрешений» и их «стоимость»;
По умолчанию работнику начисляется премия в размере 100%;
Если в оцениваемый период сотрудник допустил какие-либо ошибки, то соответствующим образом уменьшается величина премиальной части.
Я просто вам еще раз напомню, что статья про мотивацию вполне конкретного типа специалистов, опубликованная в сообществе этих же самых специалистов.
Конечно же, я с вами согласен, что мотивация разработчиков, мотивация бухгалтеров и мотивация грузчиков — это совершенно разные вещи, требующих совершенно разных подходов.
Увольнять. Наказанием вы ничего не добьетесь, человек всегда найдет себе оправдание (и далеко не факт, что его оправдание не будет более правдивым, чем ваше обоснование наказания), а вы получите нелояльного сотрудника.
Вы к сожалению не в курсе реалий IT, отсюда недопонимание. Реалии таковы, что большинство компаний платят по схеме «белый оклад + белая премия», где «премия» — это не премия, а часть зарплаты. Вызвано это большим количеством причин, например тем, что в компании существует тарифная сетка, а программисты денег хотят по разному в зависимости от своего опыта.
Я еще раз подчеркну — к нам сотрудники приходят работать на условиях оклада.
Я исхожу из того, что если приходят — значит их оклад устраивает.
В айтишных вакансиях или указывается вилка или не указывается вообще. Итоговая зарплата специалиста — это всегда рыночный компромисс между тем во сколько себя оценивает специалист и тем сколько готова платить компания за работу, которую этот специалист будет выполнять.
Так вот, топикстартер предлагает штрафовать сотрудников не из годовых, квартальных и проектных бонусов (каковые являются вообще отдельной темой для обсуждения), а из вот той части, которая «зарплата о которой договорились на собеседовании», и которая составляется из оклада по тарифной сетке + «премия», чтобы добить зарплату до рыночной стоимости конкретного специалиста.
Но думается мне, что скорее всего дело в Вашем рабоче-крестьянском подходе к работе, где Вам все кругом должны, а Вы делаете милость работодателю, что работаете на него.
Когда я последний раз менял работу, у меня было около двух десятков вариантов. Нет, я не делаю милость работая на того работодателя, которого выбрал. Точно так же как работодатель не делает мне милость выплачивая мне зарплату. Если мы договривались на сумму X в месяц, а я внезапно благодаря системе штрафов получу сумму X — 50%, то в ответ работодатель получит заявление об увольнение. Точно так же как работадатель в случае моего косяка может меня уволить. Если докажет, что косяк имел место быть и произошел в моей зоне ответственности, а не в зоне любого менеджера или самого работодателя.
Я разве писал где-то про «у нас в компании»? Я писал конкретику про процессы контроля?
1. Система премий (и антипремий) должна быть построена на ЧеловекоНезависимойСистеме Контроля!
Вы никогда не построите систему человеконезависимого контроля для человекозависимой системы. Более того, человекозависимой системы, сильно зависящей от особенностей мышления входящих в нее «человеков».
2. Под разные организации как по размерам, так и по сферам деятельности, формам организаций строятся СВОИ системы премирования, базирующиеся на системах контроля, применимых для этой организации.
Автор предлагает вполне конкретную систему премирования для вполне конкретного типа компаний в конкретной индустрии с накопленным опытом решения технических и управленческих проблем. Не имея ни малейшего понятия об этом опыте.
3. Есть обобщенные правила/методы, НО они так или иначе делятся на подходящие к организациям _конкретной_ сферы деятельности/отрасли, формы сотрудничества и определенного диапазона размеров. Как пример: даже взяв две ИТ компании со штатом в 10 человек, занимающихся разработкой ПО (прошу заметить все вроде совпадает), но одни работают в офисе, а вторые разбросаны по миру (УПС!) часть процессов контроля будет РАЗНОЙ!|
И что мешает автоматизировать снятие бэкапа в любой системе, где эти бэкапы есть?
Могу анекдот рассказать
Я вам тоже могу анекдот рассказать. И даже не анекдот, а быль, которая повторяется снова и снова.
Одна компания решила несла убытки из-за управленческих проблем и наняла эффективного менеджера, который предложил оптимизировать убытки за счет зарплат программистов (ну не за счет же менеджеров, которые его наняли) и разработал систему мотивации исходя из представлений о разработке ПО, полученных в ходе обучения на факультете психологии. Программисты поплевались и ушли, остались только те, кто не смог найти другую работу. Компетенций в компании не осталось, качество продукта упало ниже плинтуса, компания не смогла выполнить обязательства/выпустить конкурентоспособный продукт и разорилась. Тем временем конкурент перехватил программистов за счет стабильных условий, отсутствия штрафов и печенек на кухне и использует их опыт полученный в первой компании для разработки продукта, за счет которого компания процветает.
Давайте внимательно посмотрим на то, за что автор предлагает депремировать людей:
Вот небольшой список неприятных ситуаций, достойных денежного наказания, которые были в моей практике и в практике коллег:
Грубые архитектурные ошибки (н-р, разработка сервисов для бизнеса, выполняемых не на серверах, а на локальных машинах; разработка решений без согласования со специалистами по смежным системам);
Сфигали разработчик вообще что-то разрабатывает без задачи в таск-трекере, design review и прочих вещей, которые должны быть в нормальном процессе разработки? Кто должен организовать процесс?
Сокрытие информации и желание стать незаменимым на предприятии (н-р, использование своих пользовательских паролей в исполняемых модулях; документация ненадлежащего качества);
Почему документация не ревьюится? Почему код не ревьюится? Кто должен организовать ревью?
Невыполнение скучной рутинной работы (н-р, составление протоколов, инструкций и документирования в целом; выполнение регламентных работ);
Кто контролирует выполнение регламентных работ? Опять же — где ревью?
Косяки с бекапированием и потерей данных;
Почему бэкапы делаются руками? Почему не автоматизировано?
Самовольная выкладка в продуктив без должного тестирования, выкладка без согласования с пользователями.
Где QA? Где релиз-менеджмент? Почему разработчик вообще имеет права на выкладывание чего-то в продакшн?
Не информирование пользователей о принятых решениях и вообще вопросы коммуникаций.
Почему разработчик должен о чем-то информировать пользователей. Опять же — где релиз-менеджмент? Где продакт-менеджмент? Почему решения, влияющие на пользователей приняты втихую? Почему их не заметил ни QA ни менеджер?
В двух словах — топик-стартер предлагает штрафовать людей за вещи, которые не входят в их компетенции и в их зону ответственности, перекладывая на их ответственность за собственную работу (как менеджера). Отсюда заслуженные минусы человеку, который собрался мотивировать людей штрафами ничего не понимая в том как эти люди работают и, главное, как эта работа должна выполняться.
Задача про квадрат и прямоугольник — это классическая задача на которой этот вопрос немного проясняют.
А в оригинальной статье Лисков тем временем (http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-156.ps) даны очень четкие определения того, что считать инвариантами и ограничениями и как правильно наследовать.
Я хотел намекнуть, что осознание автором принципа LSP далеко не полное, и, что не стоит пользоваться его формулировками.
Например, ее приводит сам Роберт Мартин — web.archive.org/web/20151128004108/http://www.objectmentor.com/resources/articles/lsp.pdf
А в википедии ей посвященая отдельная страница — en.wikipedia.org/wiki/Circle-ellipse_problem
Нет, судя по тексту статьи — все еще не осознали.
А если на проекте появляются новые роли — надо все переписывать?
Наследование, вариации паттерна «Стратегия» и так далее. При чем тут dll и jar?
Есть класс Квадрат и есть класс Прямоугольник. Что от чего наследовать?
Так как же их разделять-то?
Нет, зависимость — это зависимость между двумя любыми структурными блоками программы (функциями, классами, etc).
В общем, в книжке дяди Боба все есть, очень подробно и с примерами кода. А это стоит убрать.
Accept вполне себе прицепляется extension method'ом или враппером-аксептором.
Это ровно тот же самый кривой double dispatch, только процедурный.
Не то чтобы я настаивал на ООП-подходе, но проблема вообще нормально не решается без нормального мультидиспатча. Аксиома Эскобара как она есть.
Это типичный double dispatch. В классических ооп-языках со статической типизацией — решается исключительно через
жовизитор.Только причем тут enum и switch? Они проблему не решают никак.
Не говоря уже о настоящих технологических платформах типа Axapta или 1С?
en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system
А для сеги было и вполне настоящее 3D — ru.wikipedia.org/wiki/Virtua_Racing
Конечно же, я с вами согласен, что мотивация разработчиков, мотивация бухгалтеров и мотивация грузчиков — это совершенно разные вещи, требующих совершенно разных подходов.
Увольнять. Наказанием вы ничего не добьетесь, человек всегда найдет себе оправдание (и далеко не факт, что его оправдание не будет более правдивым, чем ваше обоснование наказания), а вы получите нелояльного сотрудника.
Вы к сожалению не в курсе реалий IT, отсюда недопонимание. Реалии таковы, что большинство компаний платят по схеме «белый оклад + белая премия», где «премия» — это не премия, а часть зарплаты. Вызвано это большим количеством причин, например тем, что в компании существует тарифная сетка, а программисты денег хотят по разному в зависимости от своего опыта.
В айтишных вакансиях или указывается вилка или не указывается вообще. Итоговая зарплата специалиста — это всегда рыночный компромисс между тем во сколько себя оценивает специалист и тем сколько готова платить компания за работу, которую этот специалист будет выполнять.
Так вот, топикстартер предлагает штрафовать сотрудников не из годовых, квартальных и проектных бонусов (каковые являются вообще отдельной темой для обсуждения), а из вот той части, которая «зарплата о которой договорились на собеседовании», и которая составляется из оклада по тарифной сетке + «премия», чтобы добить зарплату до рыночной стоимости конкретного специалиста.
Когда я последний раз менял работу, у меня было около двух десятков вариантов. Нет, я не делаю милость работая на того работодателя, которого выбрал. Точно так же как работодатель не делает мне милость выплачивая мне зарплату. Если мы договривались на сумму X в месяц, а я внезапно благодаря системе штрафов получу сумму X — 50%, то в ответ работодатель получит заявление об увольнение. Точно так же как работадатель в случае моего косяка может меня уволить. Если докажет, что косяк имел место быть и произошел в моей зоне ответственности, а не в зоне любого менеджера или самого работодателя.
Вы никогда не построите систему человеконезависимого контроля для человекозависимой системы. Более того, человекозависимой системы, сильно зависящей от особенностей мышления входящих в нее «человеков».
Автор предлагает вполне конкретную систему премирования для вполне конкретного типа компаний в конкретной индустрии с накопленным опытом решения технических и управленческих проблем. Не имея ни малейшего понятия об этом опыте.
И что мешает автоматизировать снятие бэкапа в любой системе, где эти бэкапы есть?
Я вам тоже могу анекдот рассказать. И даже не анекдот, а быль, которая повторяется снова и снова.
Одна компания решила несла убытки из-за управленческих проблем и наняла эффективного менеджера, который предложил оптимизировать убытки за счет зарплат программистов (ну не за счет же менеджеров, которые его наняли) и разработал систему мотивации исходя из представлений о разработке ПО, полученных в ходе обучения на факультете психологии. Программисты поплевались и ушли, остались только те, кто не смог найти другую работу. Компетенций в компании не осталось, качество продукта упало ниже плинтуса, компания не смогла выполнить обязательства/выпустить конкурентоспособный продукт и разорилась. Тем временем конкурент перехватил программистов за счет стабильных условий, отсутствия штрафов и печенек на кухне и использует их опыт полученный в первой компании для разработки продукта, за счет которого компания процветает.
Сфигали разработчик вообще что-то разрабатывает без задачи в таск-трекере, design review и прочих вещей, которые должны быть в нормальном процессе разработки? Кто должен организовать процесс?
Почему документация не ревьюится? Почему код не ревьюится? Кто должен организовать ревью?
Кто контролирует выполнение регламентных работ? Опять же — где ревью?
Почему бэкапы делаются руками? Почему не автоматизировано?
Где QA? Где релиз-менеджмент? Почему разработчик вообще имеет права на выкладывание чего-то в продакшн?
Почему разработчик должен о чем-то информировать пользователей. Опять же — где релиз-менеджмент? Где продакт-менеджмент? Почему решения, влияющие на пользователей приняты втихую? Почему их не заметил ни QA ни менеджер?
В двух словах — топик-стартер предлагает штрафовать людей за вещи, которые не входят в их компетенции и в их зону ответственности, перекладывая на их ответственность за собственную работу (как менеджера). Отсюда заслуженные минусы человеку, который собрался мотивировать людей штрафами ничего не понимая в том как эти люди работают и, главное, как эта работа должна выполняться.