Как получается плохой софт

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

Мы адаптировали статью тимлида команды Yelluw про основные грабли и проблемы, влияющие на появление плохого программного продукта на рынке.

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

• Слабое в техническом плане руководство

Лишенные последовательности и неверные решения никогда не перерастают в качество. Хорошие проекты никогда не пишутся инстинктивно. Это результат организованных и основанных на фактах решениях. Сильный руководитель задает тон остальным сотрудникам. Все люди, так или иначе, учатся на примерах.

• Нечеткие обязанности

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

• Отсутствие тестирования

Факт: сегодня большое количество проектов пишется без последующего выполнения тестов. Никаких юнит-тестов. Никаких тестов по интеграции. Даже никаких как это будет работать на машине заказчика-тестов. Код просто пишется (копируется с Гита), компилится и выдается клиентам.

• Нежелание учиться

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

• Сотрудники-мудаки

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

• Ориентированность на краткосрочные цели

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

Нашли в своем проекте схожие черты? Без паники. Важно понимать, что плохой продукт является результатом, который находится в пределах вашего контроля. Зная и принимая такое положение вещей – первый шаг к изменениям в работе компании.

Перевод статьи https://dev.to/yelluw/how-bad-software-gets-made