Как объяснить программисту принцип единой ответственности?

Question

[herfleisch]

Никак не могу доказать коллеге что нехорошо когда метод класса формы занимается созданием сокета, принятием данных, определением типа пакета, распарсиванием пакета в структуру в зависимости от типа пакета и отображением данных на форме. Как вы поступаете в таких ситуациях? Как заставить человека разделять ответственность классов, абстрагированию? Или оставить всё как есть, чтобы через год взяться за голову с криками «кто писал этот код»?

Answer 1

[Rafael Osipov]

Я думаю, что будет нелишним утвердить сверху внутренние стандарты на проектирование и реализацию программных решений в вашей компании. Тогда отпадёт необходимость доказывать воинствующим дилетантам, что они мало того, что идут на грабли сами, так ещё и тянут всех остальных, кто их мудрого подхода не разделяет.

Answer 2

[Shedal]

Нужно объяснять на примерах. Покажите, почему деление на слои хорошо, чем оно удобно, — на конкретном примере. Покажите, насколько удобнее тестировать отдельные классы, в которые можно сделать dependency injection стаба или мока. Да куча примеров есть, вот на них и показывайте, желательно применительно к вашему конкретному случаю.

Людям намного проще сначала понимать конкретные вещи а уже потом через них осознавать более абстрактные принципы.

Comments

[herfleisch]

Дело в том что он всё отрицает на конкретных примерах. Всё, что я бы не объяснял, — он всё объявляет фуфлом и всё отрицает. Я не могу найти способа повлиять на него.

[Shedal]

Может быть, вам стоит сменить коллегу? :)
Собственно говоря, на Хабре вы в таком случае вряд ли получите совет. Это уже зависит от конкретного человека — какие есть рычаги влияния на его сознание. Если никак не получается, подумайте, так ли вам нужно его учить? Или стоит с ним расстаться и нанять более адекватного человека.

Answer 3

[Tagire]

Устройте(возможно через начальство) так, чтобы была нужна небольшая консольная утилита, которая реализует часть функциональности.

Comments

[Shedal]

Да, что-то в этом духе будет хорошим живым примером :)

Answer 4

[Константин Китманов]

Нагуглите статей про S.O.L.I.D., заставьте прочесть.

Comments

[herfleisch]

Я дал ему книгу, по-ходу дела он даже не начал её читать. Роберт Мартин: «Чистый код».

[Константин Китманов]

Статьи проще прочесть — они короче. Заинтересуется — дойдет и до Мартина.

[denver]

Не заинтересуется. Таким людям интересно что быстрее — for или while. Или как обойтись одной переменной вместо десяти, чтобы память сэкономить.

Answer 5

[afiskon]

Нельзя убедить в чем-то человека, если он этого не хочет. Вот когда он затрахается искать в своем коде ошибки или когда старший программист наорет на него, что в его коде нереально разобраться, вот тут то и самое время как бы между делом сказать, что на хабре рекомендовали принцип единой ответственности. А если подходящий момент не наступает… значит его код годится, и это — самое главное.

Answer 6

[slang]

Лоббируйте ввод обязательного код-ревью в компании. Цепляйте на комиты хуки с проверкой код-стайла, мёртвого кода, комментирования, длинны методов, и прочих фишек (для этого уже полно написанных инструментов). У коллеги просто не будет возможности сдать свой говнокод. Если же протолкнуть идею не выйдет — значит компании это не нужно, а нужен код, который пишет Ваш коллега. Тогда найдите более достойную компанию.

Answer 7

[Monca]

Ну как всегда — линейка

Answer 8

[Алексей Блышко]

Сомневаюсь что тут что-то может помочь кроме личного опыта.
Если он, как специалист, достаточно грамотный, можно сделать так чтобы с его кодом никто не пересекался.
Обычно это означает, что он будет делать периферию. Делать и переделывать, если понадобится. При этом давать иногда ему делать фиксы ядра, написанным в хорошем стиле. Чтобы чувствовал разницу.
При этом с увольнением я бы не спешил. Зачастую специалист с таким подходом делает работу на совесть. Сложно в поддержке и развитии, но работает. Возможно даже сразу :) Если в команде нужен такой человек — его можно использовать.
Иначе — попробовать отыскать следующего. Для менеджера это будет лишний повод попрактиковаться в подборе команды :)

Answer 9

[Максим Дьяченко]

Вы уверенны, что это необходимо? Как-то видел как программист потратил три дня на оптимизацию кода, который должен был выполнится ОДИН РАЗ. Время работы кода сократилось с 10 минут до пяти.

Вообще действительно человека тут не переубедить. Каждый программист должен пройти через стадию «Какой мудак писал этот код???? Ой, это же я… вот мудак!»

Если можете сказать: «ты должен писать вот так-то, потому, что я так сказал», то скажите.
Если нет — смиритесь :)

Comments

[tampere]

Если не переубеждается — пусть потом набьёт шишки на поддержке.
А если человек может 3 дня потратить на оптимизацию ненужного кода, то у него мало задач, поэтому он занимается тем, что ему интересно, т.е., оптимизацией.

Answer 10

[dborovikov]

Красивое название SRP всего лишь синоним сильного сцепления — одной из двух составляющих модульности на ряду с низкой связанностью. Можете постыдить коллегу, сказав что его код не модульный. Если он начнет гнуть в сторону того, что ему не нужна модульность, попробуй прибегнуть к аргументу, что его код не читабелен. Обычно плохо понятный код подвержен ошибкам более, чем чисто написанный. Объясняется это так: человек способен держать в памяти одновременно лишь ограниченное количество объектов, причем только в одном контексте. Таким образом, перемешивание контекстов (нарушение SRP) ведет к багоопасному коду.

Но если ваш коллега упертый, просто забейте на него. Если ему не дано понять, он не поймет.

Answer 11

[yumitsu]

Предложите ему в добровольно-принудительном порядке заняться рефакторингом во внеурочное время. В добровольном — значит, без оплаты часов.
Для усиления эффекта рекомендую сделать это предложение, когда ориентировочное(на ваш взгляд) количество требуемых часов приблизится и/или перевалит за пару сотен.

Comments

[denver]

Хехе, а результат сформулировать как «чтобы всё было как в книжке и в статьях»? Боюсь это нарушит все принципы SMART постановки и закончится как в анекдотах про летчиков и инженеров:
— Something loose in cockpit.
— Something tightened in cockpit.

Answer 12

[andreycha]

Я студентам ставлю условие: в вашем приложении я должен без труда заменить формочки на консоль. По крайней мере в плане разделения UI и логики это помогает. А дальше по такому же принципу разъясняешь про разделение внутри логики и так до (почти) бесконечности.