Я присоединился к команде разработчиков из шести два месяца назад. Люди хорошие, все хорошо. Но все больше и больше я наблюдаю специальное мышление. Вещи быстро исправляются, за счет удобства использования в будущем мало испытаний, и два человека с радостью признались, что им нравится нести знания в голове, а не записывать их.
Как с этим бороться? Я хотел бы привести пример, но время ограничено - мне нравится архитектура и фактическая реализация материала. Но я боюсь, что специальное мышление заражает меня, и вместо того, чтобы стремиться к ясности и простоте в дизайне и коде - что нелегко установить, - я теряю бесконечную спираль хаков на взломы - которых нет аутсайдер может отсоединиться - только ради графика и руководства.
architecture
coding-style
management
technical-debt
Ротианского
источник
источник
Ответы:
Вы уже знаете часть ответа: вам нужно подавать пример. Вам также нужно привыкнуть к тому факту, что ваше «лидерство» может быть проигнорировано, что ваши коллеги будут продолжать делать то, что они всегда делали - либо потому, что это делает босса счастливым, либо потому, что они сами ценят целесообразность, а не долгосрочная ремонтопригодность.
В конце концов, вы должны позволить своим результатам говорить сами за себя. Вы пропустили крайний срок на три дня, но сэкономили команде QA хотя бы столько запланированных дней тестирования, потому что вы тестировали свою разработку, и она в основном работает так, как задумано? Это победа.
Однако, в конце концов, если у вас нет какой-либо степени заинтересованности руководства в подобном компромиссе, вы попадаете в неправильную среду и вам нужно найти еще один способ, который способствует успешной практике. Плохие практики формируют привычку, поэтому чем раньше вы сможете найти способ отстоять свою позицию или перейти на рабочую среду с лучшими практиками, тем лучше.
источник
Ничего?
Я имею в виду, деловые временные ограничения существуют. Ваш может быть сценарий, когда время выхода на рынок более ценно, чем простота использования в будущем.
Если вы обычный программист, то устанавливать стандарты и относиться к архитектуре продукта на самом деле не ваша работа (особенно 2 месяца). Вы должны стремиться улучшить продукт так, как можете (включая изменение культуры), но не за счет отчуждения вашей команды и / или босса. Быть новым парнем, который думает, что знает лучше, это быстрый и простой способ сделать это.
Я бы спросил, почему вы делаете все эти быстрые хакерские исправления? Это из-за предыдущих быстрых хакерских исправлений? Тогда достаточно просто указать, что, если все было сделано "правильно" в первую очередь ...
В конце концов, плохие методы программирования приводят к конкретной боли. Если люди думают, что не будут, все, что вам нужно сделать, это подождать.
источник