Как бороться со специальным складом ума?

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

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

— Ротианского
источник

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

— Рог

Добро пожаловать в разработку программного обеспечения!

— Яннис

@YannisRizos, нет, нет, нет! ;)

— Ротиан

@Rotian Это почти обязательное чтение: joelonsoftware.com/articles/fog0000000332.html . Немного устаревший, но все же отличный ресурс, и, вероятно, стоит ответить как таковой.

— К.Стефф

В более широком смысле, я рекомендую «Чистый код» и «Чистый кодер» дяди Боба. Я не согласен со всем, что он говорит в этих книгах, но они очень хорошая пища для размышлений. Они, конечно, открыли мне глаза совсем немного!

— Майкл Скотт Шаппе

Ответы:

Вы уже знаете часть ответа: вам нужно подавать пример. Вам также нужно привыкнуть к тому факту, что ваше «лидерство» может быть проигнорировано, что ваши коллеги будут продолжать делать то, что они всегда делали - либо потому, что это делает босса счастливым, либо потому, что они сами ценят целесообразность, а не долгосрочная ремонтопригодность.

В конце концов, вы должны позволить своим результатам говорить сами за себя. Вы пропустили крайний срок на три дня, но сэкономили команде QA хотя бы столько запланированных дней тестирования, потому что вы тестировали свою разработку, и она в основном работает так, как задумано? Это победа.

Однако, в конце концов, если у вас нет какой-либо степени заинтересованности руководства в подобном компромиссе, вы попадаете в неправильную среду и вам нужно найти еще один способ, который способствует успешной практике. Плохие практики формируют привычку, поэтому чем раньше вы сможете найти способ отстоять свою позицию или перейти на рабочую среду с лучшими практиками, тем лучше.

— Майкл Скотт Шаппе
источник

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

— Ротиан

+1. Будьте тем изменением, которое хотите видеть в своей команде. Установите стандарт.

— Скотт С. Уилсон

+1 за то, что результаты говорят сами за себя. Это в сочетании с наглядным примером - лучший способ повлиять на позитивные изменения. Люди, естественно, хотят делать хорошую работу (большинство, во всяком случае), и если они видят, что кто-то добивается результатов лучше их, они, вероятно, спросят секрет. И они, скорее всего, будут слушать, когда просят по собственному желанию, чем если им говорят, незапрошенные.

— Эрик Дитрих

@Rotian Конечно, не ваша конкретная среда, но да, я был там и сделал это. Хуже всего было то, что в то время я даже не совсем понимал, насколько это плохо. Я только знал, что что-то было не так на глубоком уровне, и в конце концов решил, что этого достаточно, чтобы выбраться. Только в последние годы я смог указать на конкретные практики, которые они должны (или не должны) делать.

— Майкл Скотт Шаппе

Ничего?

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

Если вы обычный программист, то устанавливать стандарты и относиться к архитектуре продукта на самом деле не ваша работа (особенно 2 месяца). Вы должны стремиться улучшить продукт так, как можете (включая изменение культуры), но не за счет отчуждения вашей команды и / или босса. Быть новым парнем, который думает, что знает лучше, это быстрый и простой способ сделать это.

Я бы спросил, почему вы делаете все эти быстрые хакерские исправления? Это из-за предыдущих быстрых хакерских исправлений? Тогда достаточно просто указать, что, если все было сделано "правильно" в первую очередь ...

В конце концов, плохие методы программирования приводят к конкретной боли. Если люди думают, что не будут, все, что вам нужно сделать, это подождать.

— Telastyn
источник

Насколько я понимаю, проблема не в том, что эти люди делают временные исправления из-за нехватки времени. Проблема в том, что они не считают это техническим долгом, который должен быть погашен в будущем. Это как прыжки: вы можете без поддержки Земли в течение некоторого времени просто отлично, но вам лучше быть готовым к приземлению.

— 9000

@ 9000: ОП говорит, что это для графика и управления, поэтому я предполагаю (надеюсь), что это в основном нехватка времени. Недооценка реальной работы, связанной с разработкой программного обеспечения, не является чем-то необычным.

— Теластин

Я согласен, что плохие методы приводят к конкретной боли; но конкретная боль не всегда приводит к изменениям, которые вы ожидаете увидеть в рациональном мире. Исходя из опыта, я могу вам сказать, что существуют менеджеры, которые не будут учиться на этой боли и не будут поощрять правильную практику. Они просто будут продолжать ссориться, потому что для того, чтобы поступить иначе, потребуется противостоять ИХ боссам, которые будут отстаивать время, чтобы сделать это «правильно», что они не всегда готовы сделать.

— Майкл Скотт Шаппе

@UncleMikey: Конечно. Но если ваши менеджеры слишком неэффективны, чтобы правильно планировать, вы мало что можете сделать.

— Теластин

@ 9000 и Теластин - да, и то и другое, я думаю, - определенное незнание того факта, что такая вещь, как технический долг, действительно существует в сочетании со средой, которая поощряет обходные пути по разным причинам (будь то время, привычка и т. Д.).

— Ротиан