День 2244. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 45. У организаций никогда нет времени, чтобы правильно создать ПО, но они находят ресурсы, чтобы исправить его позже
Это великая тайна бизнеса ПО. Многие проектные группы работают в условиях нереалистичного графика и ограниченного бюджета, что вынуждает их экономить на качестве. В результате часто появляется продукт, который необходимо долго и дорого приводить в порядок или даже отказываться от него. Однако каким-то образом организация находит время, деньги и людей для доработки или замены.
Почему не сразу?
Очевидно, если система настолько необходима и актуальна, что руководство оказывает сильное давление на работников, требуя ускорить её развёртывание, то стоит создавать её должным образом. Когда у команды разработчиков нет времени, квалифицированного персонала, надлежащих процессов или инструментов для правильного выполнения работы, им неизбежно придётся переделывать хотя бы часть работы. Ранее мы обсудили, что такая доработка влечет снижение продуктивности.
К сожалению, многие не понимают, насколько важно потратить дополнительное время на разработку изначально правильного ПО, а не на его доработку позже. Время, необходимое для применения эффективных методов обеспечения качества, таких как обзоры кода, тестирование или технические экспертные оценки, часто не закладывается в график. В результате люди начинают проводить такие оценки, только осознав их важность. А даже если они запланированы, оказывается, что у людей нет времени на них. Отказ от экспертных оценок и других методов обеспечения качества означает не отсутствие дефектов, а то, что кто-то найдёт их позже, когда последствия будут более серьёзными.
Масштабные неудачи чаще всего являются результатом плохого управления, а не технических проблем. Недооценка объёмов работ в сочетании с нереалистичной надеждой на то, что разработчики смогут работать быстрее, чем в прошлом, приводит к отставанию от графика и снижению качества. И простые разработчики, и руководители должны предусматривать время и действия, необходимые для достижения успеха, чтобы избежать потенциально огромных затрат времени и денег.
Достижение баланса
Почти все технические специалисты хотят добросовестно трудиться и предоставлять высококачественные продукты и услуги. Иногда это желание вступает в противоречие с внешними факторами, такими как смехотворно короткие сроки, продиктованные руководством, или правила, установленные руководящими органами. Специалисты-практики не всегда знают о бизнес-мотивах или причинах такого давления. Качество и целостность тоже должны быть частью обсуждения, когда команда обдумывает, что можно сделать, чтобы уложиться в сроки, достичь бизнес-целей и реализовать правильную и надёжную функциональность.
Как и у многих, у меня тоже не всё получается идеально, но я стараюсь сразу сделать свою работу хорошо, чтобы избежать финансовых потерь, затрат времени, позора и потенциальных юридических последствий, связанных с необходимостью переделывать всё заново. Если для этого потребуется больше времени, пусть будет так. Выигрыш в долгосрочной перспективе стоит первоначальных инвестиций.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
Уроки 50 Лет Разработки ПО
Урок 45. У организаций никогда нет времени, чтобы правильно создать ПО, но они находят ресурсы, чтобы исправить его позже
Это великая тайна бизнеса ПО. Многие проектные группы работают в условиях нереалистичного графика и ограниченного бюджета, что вынуждает их экономить на качестве. В результате часто появляется продукт, который необходимо долго и дорого приводить в порядок или даже отказываться от него. Однако каким-то образом организация находит время, деньги и людей для доработки или замены.
Почему не сразу?
Очевидно, если система настолько необходима и актуальна, что руководство оказывает сильное давление на работников, требуя ускорить её развёртывание, то стоит создавать её должным образом. Когда у команды разработчиков нет времени, квалифицированного персонала, надлежащих процессов или инструментов для правильного выполнения работы, им неизбежно придётся переделывать хотя бы часть работы. Ранее мы обсудили, что такая доработка влечет снижение продуктивности.
К сожалению, многие не понимают, насколько важно потратить дополнительное время на разработку изначально правильного ПО, а не на его доработку позже. Время, необходимое для применения эффективных методов обеспечения качества, таких как обзоры кода, тестирование или технические экспертные оценки, часто не закладывается в график. В результате люди начинают проводить такие оценки, только осознав их важность. А даже если они запланированы, оказывается, что у людей нет времени на них. Отказ от экспертных оценок и других методов обеспечения качества означает не отсутствие дефектов, а то, что кто-то найдёт их позже, когда последствия будут более серьёзными.
Масштабные неудачи чаще всего являются результатом плохого управления, а не технических проблем. Недооценка объёмов работ в сочетании с нереалистичной надеждой на то, что разработчики смогут работать быстрее, чем в прошлом, приводит к отставанию от графика и снижению качества. И простые разработчики, и руководители должны предусматривать время и действия, необходимые для достижения успеха, чтобы избежать потенциально огромных затрат времени и денег.
Достижение баланса
Почти все технические специалисты хотят добросовестно трудиться и предоставлять высококачественные продукты и услуги. Иногда это желание вступает в противоречие с внешними факторами, такими как смехотворно короткие сроки, продиктованные руководством, или правила, установленные руководящими органами. Специалисты-практики не всегда знают о бизнес-мотивах или причинах такого давления. Качество и целостность тоже должны быть частью обсуждения, когда команда обдумывает, что можно сделать, чтобы уложиться в сроки, достичь бизнес-целей и реализовать правильную и надёжную функциональность.
Как и у многих, у меня тоже не всё получается идеально, но я стараюсь сразу сделать свою работу хорошо, чтобы избежать финансовых потерь, затрат времени, позора и потенциальных юридических последствий, связанных с необходимостью переделывать всё заново. Если для этого потребуется больше времени, пусть будет так. Выигрыш в долгосрочной перспективе стоит первоначальных инвестиций.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
👍13👎1
День 2251. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 46. Помните, что разница между плохим и хорошим может быть малозаметной
Во многих случаях разницу между качественным и некачественным продуктом определяют небольшой дополнительный анализ, опрос, проверка или тестирование. Это не обычные ошибки, которые время от времени совершают все, а проблемы, возникающие из-за поспешности, небрежности или невнимания к деталям.
Чтобы избежать малозаметных разрывов между плохим и хорошим, часто нужно лишь немного подумать, прежде чем продолжать. Все мы встречали множество программных продуктов с ошибками, которые должны были быть обнаружены во время тестирования, или с плохим дизайном, по которому было видно, что пользовательскому опыту не уделили должного внимания. Например, сайт сообщает, что у вас есть непрочитанное уведомление. Но при нажатии на значок уведомления появляется сообщение: «У вас нет сообщений». Или форма на сайте, которая из-за ошибки в Javascript не проходит валидацию, и клиент не может её отправить. Подобные дефекты мелкие, но очень раздражают и заставляют задуматься: «А что, если во всём остальном эта компания тоже работает спустя рукава»?
Вот некоторые категории проблем, ухудшающих качество ПО, которых разработчики могут избежать:
1. Предположения
Бизнес-аналитик может ошибиться в своих предположениях или записать предположение, сделанное клиентами, но затем забыть проверить, насколько оно верно.
2. Идеи решения
Клиенты часто предлагают бизнес-аналитикам свои идеи решения вместо требований. Если бизнес-аналитик не заглянет за пределы предложенного решения, чтобы понять реальную потребность, то может взяться за решение неправильной задачи или выбрать неадекватное решение, которое придётся исправлять позже.
3. Регрессионное тестирование
Если не выполнить регрессионное тестирование после быстрого изменения кода, то можно пропустить ошибку в изменённом коде. Даже небольшое изменение может неожиданно сломать что-то ещё.
4. Обработка исключений
Разработчики могут настолько сосредоточиться на «счастливом пути» в ожидаемом поведении системы, что могут забыть о распространённых ошибках. Отсутствующие, ошибочные или неправильно отформатированные данные могут привести к неожиданным результатам или даже сбою системы.
5. Воздействие изменений
Иногда люди внедряют изменения, не задумываясь о том, как они повлияют на другие части системы или сопутствующие продукты. Изменение одного аспекта поведения системы может привести к нарушению взаимодействия с пользователем, если аналогичная функциональность, имеющаяся в других местах, не будет изменена соответствующим образом.
Качество не бесплатно в смысле стоимости. Предотвращение, обнаружение и исправление дефектов требуют дополнительных ресурсов. Тем не менее устранение малозаметных разрывов между плохим и хорошим обязательно окупится, так как вам не придётся тратить ещё больше ресурсов на устранение проблем.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
Уроки 50 Лет Разработки ПО
Урок 46. Помните, что разница между плохим и хорошим может быть малозаметной
Во многих случаях разницу между качественным и некачественным продуктом определяют небольшой дополнительный анализ, опрос, проверка или тестирование. Это не обычные ошибки, которые время от времени совершают все, а проблемы, возникающие из-за поспешности, небрежности или невнимания к деталям.
Чтобы избежать малозаметных разрывов между плохим и хорошим, часто нужно лишь немного подумать, прежде чем продолжать. Все мы встречали множество программных продуктов с ошибками, которые должны были быть обнаружены во время тестирования, или с плохим дизайном, по которому было видно, что пользовательскому опыту не уделили должного внимания. Например, сайт сообщает, что у вас есть непрочитанное уведомление. Но при нажатии на значок уведомления появляется сообщение: «У вас нет сообщений». Или форма на сайте, которая из-за ошибки в Javascript не проходит валидацию, и клиент не может её отправить. Подобные дефекты мелкие, но очень раздражают и заставляют задуматься: «А что, если во всём остальном эта компания тоже работает спустя рукава»?
Вот некоторые категории проблем, ухудшающих качество ПО, которых разработчики могут избежать:
1. Предположения
Бизнес-аналитик может ошибиться в своих предположениях или записать предположение, сделанное клиентами, но затем забыть проверить, насколько оно верно.
2. Идеи решения
Клиенты часто предлагают бизнес-аналитикам свои идеи решения вместо требований. Если бизнес-аналитик не заглянет за пределы предложенного решения, чтобы понять реальную потребность, то может взяться за решение неправильной задачи или выбрать неадекватное решение, которое придётся исправлять позже.
3. Регрессионное тестирование
Если не выполнить регрессионное тестирование после быстрого изменения кода, то можно пропустить ошибку в изменённом коде. Даже небольшое изменение может неожиданно сломать что-то ещё.
4. Обработка исключений
Разработчики могут настолько сосредоточиться на «счастливом пути» в ожидаемом поведении системы, что могут забыть о распространённых ошибках. Отсутствующие, ошибочные или неправильно отформатированные данные могут привести к неожиданным результатам или даже сбою системы.
5. Воздействие изменений
Иногда люди внедряют изменения, не задумываясь о том, как они повлияют на другие части системы или сопутствующие продукты. Изменение одного аспекта поведения системы может привести к нарушению взаимодействия с пользователем, если аналогичная функциональность, имеющаяся в других местах, не будет изменена соответствующим образом.
Качество не бесплатно в смысле стоимости. Предотвращение, обнаружение и исправление дефектов требуют дополнительных ресурсов. Тем не менее устранение малозаметных разрывов между плохим и хорошим обязательно окупится, так как вам не придётся тратить ещё больше ресурсов на устранение проблем.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
👍5👎1
День 2258. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 47. Не поддавайтесь уговорам руководителя или клиента сделать работу наспех
Мы не должны позволять руководителям, клиентам или коллегам уговаривать нас делать работу плохо. Все мы должны взять на себя обязательство следовать лучшим профессиональным практикам, адаптируя их так, чтобы получать наибольший положительный эффект в каждой ситуации. Оказавшись в ситуации, вызывающей дискомфорт в профессиональном плане, постарайтесь описать, что вам нужно для того, чтобы сделать что-то, что не будет считаться плохой работой. Как и многое другое, эту философию можно довести до крайности. Ищите баланс в достижении профессионального мастерства, не впадая в чрезмерный догматизм и жёсткость.
Умение противостоять силе
Люди, наделённые властью, могут пытаться повлиять на вас разными способами, чтобы заставить сделать то, что вы считаете плохой работой. Клиенту не нравятся ваши оценки сроков и стоимости. Он пытается надавить на вас, чтобы сбалансировать бюджет или достичь личных целей. Мотивация понятна, но это не повод менять оценку.
Он сам может испытывать давление, о котором вы не подозреваете. Он имеет право знать, как вы получили вашу оценку, и обсудить возможность её корректировки. Однако менять оценку только потому, что она кому-то не нравится, означает отказываться от вашей интерпретации реальности.
Спешка в программировании
Предположим, у вашей команды появляется новый проект. Ваши партнёры по бизнесу могут попытаться потребовать немедленно приступить к программированию, не имея экономического обоснования и чётких требований. Возможно, у них выделены финансы на проект, которые они хотят быстрее потратить, прежде чем потеряют их. IT-персонал тоже может испытывать желание как можно быстрее приступить к работе. Разработчики могут не захотеть тратить время на обсуждение требований, поскольку те, скорее всего, все равно изменятся.
В таких случаях пишется много бесцельного кода, а результат неясен. Слишком часто никто не несёт ответственности за отсутствие цели, поскольку она всё равно не была чётко определена. Не лучше ли IT-отделу попытаться противостоять давлению со стороны бизнеса и не «идти туда, не знаю куда»?
Нехватка знаний
Люди, которые не зарабатывают этим на жизнь, не понимают разницы между написанием кода и разработкой ПО и могут не понимать подходов к разработке, которые вы пропагандируете. Например, считать ненужным код-ревью, отказываться тратить время на обсуждение требований, настаивать на доставке продукта, даже если он не соответствует всем критериям выпуска.
Но клиенты вряд ли оценят ускоренную поставку продукта, полноценное использование которого может потребовать масштабных исправлений.
Если ваш руководитель отказывается от предложенного вами методичного подхода, у вас есть 3 варианта:
1. Объяснить подход так, чтобы его преимущества стали более очевидными.
2. Всё равно использовать подход, несмотря на отказ руководителя.
3. Следовать указаниям руководителя и применить неоптимальный подход.
Лучше попробовать вариант 1, а если не удастся, то 2.
В обход процессов
Процессы разрабатываются и устанавливаются не просто так. Возможно, вам придётся объяснить, почему необходимо следовать подходу, который вы отстаиваете. Укажите, насколько это повышает качество и ценность проекта. Эта информация поможет другому человеку понять, почему вы сопротивляетесь его просьбам. Однако иногда встречаются просто неразумные люди. Они могут пожаловаться вашему руководителю, что вы тратите время на ненужные действия или отказываетесь сотрудничать. Руководитель может поддержать вас или оказать на вас дополнительное давление. Во втором случае вам придётся выбирать: уступить давлению, согласившись с потенциальными негативными последствиями для проекта и вашей психики, или продолжить использовать известные вам лучшие профессиональные подходы.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
Уроки 50 Лет Разработки ПО
Урок 47. Не поддавайтесь уговорам руководителя или клиента сделать работу наспех
Мы не должны позволять руководителям, клиентам или коллегам уговаривать нас делать работу плохо. Все мы должны взять на себя обязательство следовать лучшим профессиональным практикам, адаптируя их так, чтобы получать наибольший положительный эффект в каждой ситуации. Оказавшись в ситуации, вызывающей дискомфорт в профессиональном плане, постарайтесь описать, что вам нужно для того, чтобы сделать что-то, что не будет считаться плохой работой. Как и многое другое, эту философию можно довести до крайности. Ищите баланс в достижении профессионального мастерства, не впадая в чрезмерный догматизм и жёсткость.
Умение противостоять силе
Люди, наделённые властью, могут пытаться повлиять на вас разными способами, чтобы заставить сделать то, что вы считаете плохой работой. Клиенту не нравятся ваши оценки сроков и стоимости. Он пытается надавить на вас, чтобы сбалансировать бюджет или достичь личных целей. Мотивация понятна, но это не повод менять оценку.
Он сам может испытывать давление, о котором вы не подозреваете. Он имеет право знать, как вы получили вашу оценку, и обсудить возможность её корректировки. Однако менять оценку только потому, что она кому-то не нравится, означает отказываться от вашей интерпретации реальности.
Спешка в программировании
Предположим, у вашей команды появляется новый проект. Ваши партнёры по бизнесу могут попытаться потребовать немедленно приступить к программированию, не имея экономического обоснования и чётких требований. Возможно, у них выделены финансы на проект, которые они хотят быстрее потратить, прежде чем потеряют их. IT-персонал тоже может испытывать желание как можно быстрее приступить к работе. Разработчики могут не захотеть тратить время на обсуждение требований, поскольку те, скорее всего, все равно изменятся.
В таких случаях пишется много бесцельного кода, а результат неясен. Слишком часто никто не несёт ответственности за отсутствие цели, поскольку она всё равно не была чётко определена. Не лучше ли IT-отделу попытаться противостоять давлению со стороны бизнеса и не «идти туда, не знаю куда»?
Нехватка знаний
Люди, которые не зарабатывают этим на жизнь, не понимают разницы между написанием кода и разработкой ПО и могут не понимать подходов к разработке, которые вы пропагандируете. Например, считать ненужным код-ревью, отказываться тратить время на обсуждение требований, настаивать на доставке продукта, даже если он не соответствует всем критериям выпуска.
Но клиенты вряд ли оценят ускоренную поставку продукта, полноценное использование которого может потребовать масштабных исправлений.
Если ваш руководитель отказывается от предложенного вами методичного подхода, у вас есть 3 варианта:
1. Объяснить подход так, чтобы его преимущества стали более очевидными.
2. Всё равно использовать подход, несмотря на отказ руководителя.
3. Следовать указаниям руководителя и применить неоптимальный подход.
Лучше попробовать вариант 1, а если не удастся, то 2.
В обход процессов
Процессы разрабатываются и устанавливаются не просто так. Возможно, вам придётся объяснить, почему необходимо следовать подходу, который вы отстаиваете. Укажите, насколько это повышает качество и ценность проекта. Эта информация поможет другому человеку понять, почему вы сопротивляетесь его просьбам. Однако иногда встречаются просто неразумные люди. Они могут пожаловаться вашему руководителю, что вы тратите время на ненужные действия или отказываетесь сотрудничать. Руководитель может поддержать вас или оказать на вас дополнительное давление. Во втором случае вам придётся выбирать: уступить давлению, согласившись с потенциальными негативными последствиями для проекта и вашей психики, или продолжить использовать известные вам лучшие профессиональные подходы.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
👍17
День 2265. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 47. Стремитесь к тому, чтобы дефект нашли коллеги, а не покупатели
Независимо от того, насколько хороша ваша работа, когда другие просматривают её результаты, они улучшаются. Показать своё творение другим людям и просить их подсказать вам, что с ним не так, — это не инстинктивное, а приобретаемое поведение. Всегда неловко, когда рецензент замечает вашу ошибку, но в голове сразу всплывает «молодец, что заметил!». Но лучше, чтобы ошибки находили друзья или коллеги до выпуска, а не клиенты после.
Код-ревью — проверенный метод повышения качества и продуктивности. Он улучшает качество, позволяя обнаруживать дефекты раньше, чем они могли бы быть выявлены в противном случае. Раннее обнаружение дефектов повышает продуктивность, поскольку члены команды тратят меньше времени на исправление дефектов на более поздних этапах разработки или даже после релиза. Даже обзор незаконченного продукта позволяет потребителям оценить, насколько хорошо этот продукт удовлетворит их потребности. А если вы пригласите рецензентов, не входящих в проектную команду, они смогут узнать о некоторых аспектах вашего продукта, а также увидеть, как работает другая команда. Это взаимное обогащение помогает распространять эффективные практики по всей организации.
Разработчики ПО создают множество других артефактов, помимо кода: планы, требования, несколько видов дизайна, планы тестирования и сценарии, экраны UI, документацию и т.п. Всё, что создает человек, может содержать ошибки, поэтому будет очень полезно, если кто-то ещё просмотрит результаты его труда.
Разновидности ревью ПО
1. Проверка коллегой. Попросите одного из коллег просмотреть ваш код и внести предложения по улучшению или исправлению.
2. Круговое обсуждение. Передайте фрагмент своей работы нескольким коллегам и попросите каждого написать отзыв.
3. Пошаговое обсуждение. Автор начинает обсуждение, объясняет, как работает продукт, просит дать обратную связь. Пошаговые обсуждения часто используются для проверки проектного решения, когда требуется мозговой штурм с коллегами.
4. Командный обзор. Автор заранее передаёт продукт и вспомогательные материалы нескольким рецензентам, чтобы у них было время изучить его и обозначить любые проблемы. Во время встречи рецензенты высказывают замечания.
5. Инспекция. Наиболее формальный тип подразумевает участие нескольких персонажей: автор, ведущий (модератор), секретарь, инспектор и т.п. Лучше всего подходит для рецензирования продуктов с повышенным риском.
Даже если вы не практикуете ни один из перечисленных методов рецензирования, просто попросите коллегу посмотреть на вашу работу и помочь найти ошибку или улучшить дизайн. Любой отзыв лучше, чем его отсутствие. Если члены команды не решаются поделиться результатами своего труда, опасаясь критики, — это тревожный сигнал. Еще одним таким сигналом является критика рецензентами автора за ошибки или просто за то, что он выполнил работу не так, как сделали бы они. Плохо продуманные процедуры рецензирования могут нанести ущерб культуре команды разработчиков.
В здоровой культуре разработки члены команды не только предлагают, но и принимают конструктивную критику. Это пример взаимовыручки: ты помогаешь мне, я помогаю тебе — и все выигрывают.
Рекомендации для отзывов:
- сосредоточьтесь на продукте, а не на авторе;
- формулируйте комментарии как замечания, а не обвинения;
- сосредоточьтесь на содержании недостатков, а не на стиле;
- если вы автор, отбросьте своё эго и будьте более восприимчивы к предложениям по улучшению.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
Уроки 50 Лет Разработки ПО
Урок 47. Стремитесь к тому, чтобы дефект нашли коллеги, а не покупатели
Независимо от того, насколько хороша ваша работа, когда другие просматривают её результаты, они улучшаются. Показать своё творение другим людям и просить их подсказать вам, что с ним не так, — это не инстинктивное, а приобретаемое поведение. Всегда неловко, когда рецензент замечает вашу ошибку, но в голове сразу всплывает «молодец, что заметил!». Но лучше, чтобы ошибки находили друзья или коллеги до выпуска, а не клиенты после.
Код-ревью — проверенный метод повышения качества и продуктивности. Он улучшает качество, позволяя обнаруживать дефекты раньше, чем они могли бы быть выявлены в противном случае. Раннее обнаружение дефектов повышает продуктивность, поскольку члены команды тратят меньше времени на исправление дефектов на более поздних этапах разработки или даже после релиза. Даже обзор незаконченного продукта позволяет потребителям оценить, насколько хорошо этот продукт удовлетворит их потребности. А если вы пригласите рецензентов, не входящих в проектную команду, они смогут узнать о некоторых аспектах вашего продукта, а также увидеть, как работает другая команда. Это взаимное обогащение помогает распространять эффективные практики по всей организации.
Разработчики ПО создают множество других артефактов, помимо кода: планы, требования, несколько видов дизайна, планы тестирования и сценарии, экраны UI, документацию и т.п. Всё, что создает человек, может содержать ошибки, поэтому будет очень полезно, если кто-то ещё просмотрит результаты его труда.
Разновидности ревью ПО
1. Проверка коллегой. Попросите одного из коллег просмотреть ваш код и внести предложения по улучшению или исправлению.
2. Круговое обсуждение. Передайте фрагмент своей работы нескольким коллегам и попросите каждого написать отзыв.
3. Пошаговое обсуждение. Автор начинает обсуждение, объясняет, как работает продукт, просит дать обратную связь. Пошаговые обсуждения часто используются для проверки проектного решения, когда требуется мозговой штурм с коллегами.
4. Командный обзор. Автор заранее передаёт продукт и вспомогательные материалы нескольким рецензентам, чтобы у них было время изучить его и обозначить любые проблемы. Во время встречи рецензенты высказывают замечания.
5. Инспекция. Наиболее формальный тип подразумевает участие нескольких персонажей: автор, ведущий (модератор), секретарь, инспектор и т.п. Лучше всего подходит для рецензирования продуктов с повышенным риском.
Даже если вы не практикуете ни один из перечисленных методов рецензирования, просто попросите коллегу посмотреть на вашу работу и помочь найти ошибку или улучшить дизайн. Любой отзыв лучше, чем его отсутствие. Если члены команды не решаются поделиться результатами своего труда, опасаясь критики, — это тревожный сигнал. Еще одним таким сигналом является критика рецензентами автора за ошибки или просто за то, что он выполнил работу не так, как сделали бы они. Плохо продуманные процедуры рецензирования могут нанести ущерб культуре команды разработчиков.
В здоровой культуре разработки члены команды не только предлагают, но и принимают конструктивную критику. Это пример взаимовыручки: ты помогаешь мне, я помогаю тебе — и все выигрывают.
Рекомендации для отзывов:
- сосредоточьтесь на продукте, а не на авторе;
- формулируйте комментарии как замечания, а не обвинения;
- сосредоточьтесь на содержании недостатков, а не на стиле;
- если вы автор, отбросьте своё эго и будьте более восприимчивы к предложениям по улучшению.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
👍14
День 2272. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 49. Разработчики программного обеспечения любят инструменты, но дурак с инструментами — это вооруженный дурак
Опытные программисты имеют множество инструментов и знают, как их эффективно применять. Но тому, кто не понимает, что он делает, инструменты дают возможность сделать это быстрее и порой более опасным образом. Инструменты могут повысить продуктивность квалифицированных членов команды, но не улучшат работу неподготовленных людей. Если люди не понимают того или иного приёма и не знают, когда можно, а когда нельзя его использовать, то инструмент, позволяющий выполнять работу быстрее и эффективнее, не поможет.
Инструмент должен добавлять ценность
Инструменты моделирования легко использовать не по назначению. Аналитики и дизайнеры иногда уделяют чересчур много времени совершенствованию моделей. Визуальное моделирование облегчает итеративное мышление и выявление ошибок, но люди должны создавать модели выборочно. Моделирование хорошо изученных частей системы и детализация до мельчайших подробностей не делают проект пропорционально более ценным.
Неправильно могут использоваться не только автоматизированные инструменты, но и специализированные методы проектирования. Например, варианты использования помогают понять, что пользователи должны делать в системе, после чего можно определить перечень функций для реализации. Но некоторые пытаются впихнуть каждую известную часть функциональности в вариант использования просто потому, что таков метод работы с требованиями. Если вам уже известна какая-то необходимая функциональность, то нет смысла в её переупаковке только ради того, чтобы сказать, что у вас имеется полный набор вариантов использования.
Инструменты должны использоваться разумно
Если люди не понимают, как эффективно применять инструмент, то он для них бесполезен. Например, если крупная программа никогда не проходила проверку статическим анализатором кода, то при первой проверке наверняка будет выдано множество предупреждений. Многие из них будут ложными или несущественными. Но среди них, скорее всего, обнаружатся настоящие проблемы. Если есть возможность, настройте инструменты так, чтобы можно было сосредоточиться на действительно важных вопросах и не отвлекаться на мелкие проблемы.
Инструмент — это не процесс
Иногда люди думают, что использование хорошего инструмента решает проблему. Однако инструмент не заменяет процесс, он лишь поддерживает его. Без сопутствующего практического процесса инструмент может внести дополнительную неразбериху, если не использовать его должным образом.
Инструменты могут заставить людей думать, что они делают свою работу лучше, чем есть на самом деле. Инструменты автоматизированного тестирования ничем не лучше запускаемых ими тестов. Возможность быстро запускать автоматические регрессионные тесты не означает, что эти тесты эффективно отыскивают ошибки. Инструмент, вычисляющий покрытие кода тестами, может сообщить о большом проценте покрытия, но это не гарантирует, что проверен весь код, все логические ветви и все варианты выполнения.
Инструменты управления требованиями — ещё одна яркая иллюстрация. Инструмент не знает, являются ли требования точными, ясными или полными. Он не способен обнаруживать отсутствующие требования. Некоторые инструменты могут анализировать набор требований и отыскивать конфликты, дубликаты и неоднозначности, но эта оценка ничего не говорит о логической правильности или необходимости требований. Лучше сначала освоить ручную процедуру и доказать себе, что в полной мере владеете ею, прежде чем автоматизировать её.
Правильное применение инструментов и методов может повысить ценность проекта, качество работы и продуктивность, поднять планирование и сотрудничество на новый уровень, а также навести порядок в хаосе. Но даже лучшие инструменты не помогут преодолеть слабость процессов, неподготовленность членов команды, сложность инициатив по преобразованию или культурные проблемы.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
Уроки 50 Лет Разработки ПО
Урок 49. Разработчики программного обеспечения любят инструменты, но дурак с инструментами — это вооруженный дурак
Опытные программисты имеют множество инструментов и знают, как их эффективно применять. Но тому, кто не понимает, что он делает, инструменты дают возможность сделать это быстрее и порой более опасным образом. Инструменты могут повысить продуктивность квалифицированных членов команды, но не улучшат работу неподготовленных людей. Если люди не понимают того или иного приёма и не знают, когда можно, а когда нельзя его использовать, то инструмент, позволяющий выполнять работу быстрее и эффективнее, не поможет.
Инструмент должен добавлять ценность
Инструменты моделирования легко использовать не по назначению. Аналитики и дизайнеры иногда уделяют чересчур много времени совершенствованию моделей. Визуальное моделирование облегчает итеративное мышление и выявление ошибок, но люди должны создавать модели выборочно. Моделирование хорошо изученных частей системы и детализация до мельчайших подробностей не делают проект пропорционально более ценным.
Неправильно могут использоваться не только автоматизированные инструменты, но и специализированные методы проектирования. Например, варианты использования помогают понять, что пользователи должны делать в системе, после чего можно определить перечень функций для реализации. Но некоторые пытаются впихнуть каждую известную часть функциональности в вариант использования просто потому, что таков метод работы с требованиями. Если вам уже известна какая-то необходимая функциональность, то нет смысла в её переупаковке только ради того, чтобы сказать, что у вас имеется полный набор вариантов использования.
Инструменты должны использоваться разумно
Если люди не понимают, как эффективно применять инструмент, то он для них бесполезен. Например, если крупная программа никогда не проходила проверку статическим анализатором кода, то при первой проверке наверняка будет выдано множество предупреждений. Многие из них будут ложными или несущественными. Но среди них, скорее всего, обнаружатся настоящие проблемы. Если есть возможность, настройте инструменты так, чтобы можно было сосредоточиться на действительно важных вопросах и не отвлекаться на мелкие проблемы.
Инструмент — это не процесс
Иногда люди думают, что использование хорошего инструмента решает проблему. Однако инструмент не заменяет процесс, он лишь поддерживает его. Без сопутствующего практического процесса инструмент может внести дополнительную неразбериху, если не использовать его должным образом.
Инструменты могут заставить людей думать, что они делают свою работу лучше, чем есть на самом деле. Инструменты автоматизированного тестирования ничем не лучше запускаемых ими тестов. Возможность быстро запускать автоматические регрессионные тесты не означает, что эти тесты эффективно отыскивают ошибки. Инструмент, вычисляющий покрытие кода тестами, может сообщить о большом проценте покрытия, но это не гарантирует, что проверен весь код, все логические ветви и все варианты выполнения.
Инструменты управления требованиями — ещё одна яркая иллюстрация. Инструмент не знает, являются ли требования точными, ясными или полными. Он не способен обнаруживать отсутствующие требования. Некоторые инструменты могут анализировать набор требований и отыскивать конфликты, дубликаты и неоднозначности, но эта оценка ничего не говорит о логической правильности или необходимости требований. Лучше сначала освоить ручную процедуру и доказать себе, что в полной мере владеете ею, прежде чем автоматизировать её.
Правильное применение инструментов и методов может повысить ценность проекта, качество работы и продуктивность, поднять планирование и сотрудничество на новый уровень, а также навести порядок в хаосе. Но даже лучшие инструменты не помогут преодолеть слабость процессов, неподготовленность членов команды, сложность инициатив по преобразованию или культурные проблемы.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
👍10👎2
День 2279. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 50. Сегодняшний проект, требующий немедленной реализации, завтра может превратиться в кошмар для службы сопровождения
После релиза системы начинается этап её поддержки. Основные категории поддержки ПО:
- адаптация — модификация в целях работы в операционной среде;
- корректировка — диагностика и устранение дефектов;
- совершенствование — добавление новых функций, повышение производительности и т.п.;
- профилактика — оптимизация и рефакторинг для повышения эффективности, простоты, удобства сопровождения и надёжности.
Добавляемые улучшения могут по-прежнему требовать корректирующей поддержки в целях устранения дефектов. Помимо недостатков требований и кода, недостатки проектирования будут продолжать поглощать ресурсы и при поддержке.
Технический долг и профилактическая поддержка
Команды разработчиков иногда допускают снижение качества, что приводит к образованию технического долга. Быстро написанный код может быть недостаточно продуманным, работать только в данный момент, выполняться неэффективно или быть малопонятным сопровождающих. Быстрые исправления кода могут давать неожиданные побочные эффекты.
Как и любой другой, техдолг рано или поздно должен быть погашен, причём с процентами. Выплата техдолга в ПО включает рефакторинг, реструктуризацию или переписывание кода. Чем дольше долг сохраняется в системе, тем больше процентов начисляется по нему. Каждая минута, потраченная на не совсем правильный код, считается процентом по этому долгу. Значительная доля профилактической поддержки связана с устранением техдолга. Ваша цель - оставить код в лучшем состоянии, чем когда он попал к вам.
Осознанный технический долг
Иногда разумно накопить некий объём техдолга, если команда осознаёт, что переделка несовершенного проекта в будущем обойдется дороже. Если ожидается, что код будет жить недолго, то, возможно, не стоит тратить время на его детальную проработку. Но часто это ожидание не оправдывается. Прототип слишком часто попадает в релиз и в дальнейшем сбивает с толку тех, кто занимается его сопровождением.
Если вы осознаёте техдолг и предусматриваете время в будущих итерациях на устранение недостатков, а не просто надеетесь, что они не вызовут проблем, то, возможно, имеет смысл отложить тщательную проработку проекта. Однако в итоге всё равно придётся улучшать проект, поэтому убедитесь в том, что понимаете это. Таким образом имеются осознанный и случайный техдолг.
Неспособность исправить недостатки проектного решения и кода усложняет работу с системой в последующих итерациях или во время эксплуатации. Эти накопленные проблемы замедляют дальнейшую разработку сейчас и потребуют чрезмерных усилий по поддержке позже.
Погашение техдолга добавляет в проект свои риски. Вы просто улучшаете то, что уже работает, но эти улучшения тоже требуют проверки и утверждения, как и любой другой код в проекте. Регрессионное тестирование и другие методы контроля качества требуют больше времени, чем написание самого кода. Чем масштабнее код и чем глубже перерабатывается проект, тем выше риск непреднамеренно нарушить нормальную работу чего-то ещё.
Всегда есть что-то более срочное, чем рефакторинг существующего кода. Порой трудно выделить ресурсы на погашение техдолга, когда клиенты требуют незамедлительно расширить возможности ПО. Основная проблема при работе с унаследованным кодом — на внесение изменений необходимо много времени. Поэтому если вы хотите, чтобы код был долговечным, то убедитесь, что будущим разработчикам будет приятно вносить в него изменения.
Сделайте профилактическую поддержку частью повседневной деятельности по разработке, улучшайте проекты и код всякий раз, когда взаимодействуете с ними. Не закрывайте глаза на встречающиеся недостатки качества — минимизируйте их.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
Уроки 50 Лет Разработки ПО
Урок 50. Сегодняшний проект, требующий немедленной реализации, завтра может превратиться в кошмар для службы сопровождения
После релиза системы начинается этап её поддержки. Основные категории поддержки ПО:
- адаптация — модификация в целях работы в операционной среде;
- корректировка — диагностика и устранение дефектов;
- совершенствование — добавление новых функций, повышение производительности и т.п.;
- профилактика — оптимизация и рефакторинг для повышения эффективности, простоты, удобства сопровождения и надёжности.
Добавляемые улучшения могут по-прежнему требовать корректирующей поддержки в целях устранения дефектов. Помимо недостатков требований и кода, недостатки проектирования будут продолжать поглощать ресурсы и при поддержке.
Технический долг и профилактическая поддержка
Команды разработчиков иногда допускают снижение качества, что приводит к образованию технического долга. Быстро написанный код может быть недостаточно продуманным, работать только в данный момент, выполняться неэффективно или быть малопонятным сопровождающих. Быстрые исправления кода могут давать неожиданные побочные эффекты.
Как и любой другой, техдолг рано или поздно должен быть погашен, причём с процентами. Выплата техдолга в ПО включает рефакторинг, реструктуризацию или переписывание кода. Чем дольше долг сохраняется в системе, тем больше процентов начисляется по нему. Каждая минута, потраченная на не совсем правильный код, считается процентом по этому долгу. Значительная доля профилактической поддержки связана с устранением техдолга. Ваша цель - оставить код в лучшем состоянии, чем когда он попал к вам.
Осознанный технический долг
Иногда разумно накопить некий объём техдолга, если команда осознаёт, что переделка несовершенного проекта в будущем обойдется дороже. Если ожидается, что код будет жить недолго, то, возможно, не стоит тратить время на его детальную проработку. Но часто это ожидание не оправдывается. Прототип слишком часто попадает в релиз и в дальнейшем сбивает с толку тех, кто занимается его сопровождением.
Если вы осознаёте техдолг и предусматриваете время в будущих итерациях на устранение недостатков, а не просто надеетесь, что они не вызовут проблем, то, возможно, имеет смысл отложить тщательную проработку проекта. Однако в итоге всё равно придётся улучшать проект, поэтому убедитесь в том, что понимаете это. Таким образом имеются осознанный и случайный техдолг.
Неспособность исправить недостатки проектного решения и кода усложняет работу с системой в последующих итерациях или во время эксплуатации. Эти накопленные проблемы замедляют дальнейшую разработку сейчас и потребуют чрезмерных усилий по поддержке позже.
Погашение техдолга добавляет в проект свои риски. Вы просто улучшаете то, что уже работает, но эти улучшения тоже требуют проверки и утверждения, как и любой другой код в проекте. Регрессионное тестирование и другие методы контроля качества требуют больше времени, чем написание самого кода. Чем масштабнее код и чем глубже перерабатывается проект, тем выше риск непреднамеренно нарушить нормальную работу чего-то ещё.
Всегда есть что-то более срочное, чем рефакторинг существующего кода. Порой трудно выделить ресурсы на погашение техдолга, когда клиенты требуют незамедлительно расширить возможности ПО. Основная проблема при работе с унаследованным кодом — на внесение изменений необходимо много времени. Поэтому если вы хотите, чтобы код был долговечным, то убедитесь, что будущим разработчикам будет приятно вносить в него изменения.
Сделайте профилактическую поддержку частью повседневной деятельности по разработке, улучшайте проекты и код всякий раз, когда взаимодействуете с ними. Не закрывайте глаза на встречающиеся недостатки качества — минимизируйте их.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
👍8
День 2283. #УрокиРазработки
10 Уроков Качества Разработки ПО. Начало
1. Поймите разницу между внутренним и внешним качеством
Одна из самых сложных частей нашей работы как разработчиков и архитекторов — помочь менеджерам и нетехническим владельцам продукта понять, что мы подразумеваем под плохим качеством ПО. Ключ — различать внутреннее и внешнее качество.
Внешнее качество — это то, что волнует менеджеров и владельцев продукта. Они заметят, когда отзывчивость или удобство использования будут плохими, или когда ошибки, особенно повторяющиеся, будут накапливаться. Но внутреннее качество? Это наша область. Это та часть, которую они не видят, пока технический долг не снизит скорость доставки новых функций до минимума.
Вот некоторые внутренние признаки качества:
- Читаемость
Что делает код и как он работает?
- Тестируемость
Делает ли он то, что должен?
- Изоляция
Могу ли я изменить это, не сломав что-то еще?
- Обнаруживаемость
Где в системе определено нужное поведение?
- Прослеживаемость
Почему было принято это решение (в коде, архитектуре или дизайне)?
2. Делайте код автоматически тестируемым
Знакомо ли вам то чувство, когда вы изменяете код в кодовой базе, с которой вы не на 100% знакомы, но вы полностью уверены, что автоматизированные тесты вас поддержат? Классные ощущения, правда? Теперь представьте себе похожую кодовую базу, но без такого тестового покрытия. Звучит пугающе.
А что, если вы знаете кодовую базу вдоль и поперёк? Достаточно ли вы уверены, чтобы вносить изменения, не рискуя получить катастрофическую ошибку?
Для тех, кто не чувствует себя уверенно, пришло время инвестировать в автоматизированное тестирование. Начните с создания временной страховочной сетки, используя стратегию тестирования характеристик. Затем начните проектировать код для поддержки подхода «сначала тест». Относитесь к своим тестам как к первоклассному коду. Кодовая база, где 40–50% кода является тестами – это здорово.
3. Не терпите нестабильности в автоматизированном тестировании
Каждый разработчик, который пытался создать набор автоматизированных end-to-end тестов, сталкивался с кошмаром их нестабильности. Да, вы можете гордиться тем, что у вас есть солидное количество тестов. Но если вы не можете положиться на эти тесты из-за их нестабильности, это может стать серьёзной головной болью. Определить, провалился ли тест из-за реальной проблемы в коде базе или просто из-за нестабильности, сложно, особенно когда сбой не связан с конкретным изменением кода.
Чаще всего люди просто повторно запускают тест и надеются на лучшее. Назначить кого-то для расследования этих сбоев сложно, и неопределённость может подорвать производительность. Это может показаться очевидным, но не относитесь к нестабильности как к техническому долгу, который нужно устранить позже. Относитесь к ней как к производственному сбою, требующему немедленного внимания.
Если вам повезло использовать инструмент сборки, такой как TeamCity, вы можете отслеживать нестабильность тестов с течением времени, отмечать тесты как нестабильные и отключать их из конвейера сборки. А ещё лучше — назначить нестабильный тест кому-то для анализа и исправить его, позволяя сборке успешно завершиться. Это позволит нескольким разработчикам не тратить время, пытаясь выяснить, нужно ли им что-то делать с нестабильным тестом. Если у вас нет этих инструментов, договоритесь всей командой о том, чтобы отдать приоритет исправлению нестабильных тестов, чтобы снова сделать сборку зелёной.
Продолжение следует…
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
10 Уроков Качества Разработки ПО. Начало
1. Поймите разницу между внутренним и внешним качеством
Одна из самых сложных частей нашей работы как разработчиков и архитекторов — помочь менеджерам и нетехническим владельцам продукта понять, что мы подразумеваем под плохим качеством ПО. Ключ — различать внутреннее и внешнее качество.
Внешнее качество — это то, что волнует менеджеров и владельцев продукта. Они заметят, когда отзывчивость или удобство использования будут плохими, или когда ошибки, особенно повторяющиеся, будут накапливаться. Но внутреннее качество? Это наша область. Это та часть, которую они не видят, пока технический долг не снизит скорость доставки новых функций до минимума.
Вот некоторые внутренние признаки качества:
- Читаемость
Что делает код и как он работает?
- Тестируемость
Делает ли он то, что должен?
- Изоляция
Могу ли я изменить это, не сломав что-то еще?
- Обнаруживаемость
Где в системе определено нужное поведение?
- Прослеживаемость
Почему было принято это решение (в коде, архитектуре или дизайне)?
2. Делайте код автоматически тестируемым
Знакомо ли вам то чувство, когда вы изменяете код в кодовой базе, с которой вы не на 100% знакомы, но вы полностью уверены, что автоматизированные тесты вас поддержат? Классные ощущения, правда? Теперь представьте себе похожую кодовую базу, но без такого тестового покрытия. Звучит пугающе.
А что, если вы знаете кодовую базу вдоль и поперёк? Достаточно ли вы уверены, чтобы вносить изменения, не рискуя получить катастрофическую ошибку?
Для тех, кто не чувствует себя уверенно, пришло время инвестировать в автоматизированное тестирование. Начните с создания временной страховочной сетки, используя стратегию тестирования характеристик. Затем начните проектировать код для поддержки подхода «сначала тест». Относитесь к своим тестам как к первоклассному коду. Кодовая база, где 40–50% кода является тестами – это здорово.
3. Не терпите нестабильности в автоматизированном тестировании
Каждый разработчик, который пытался создать набор автоматизированных end-to-end тестов, сталкивался с кошмаром их нестабильности. Да, вы можете гордиться тем, что у вас есть солидное количество тестов. Но если вы не можете положиться на эти тесты из-за их нестабильности, это может стать серьёзной головной болью. Определить, провалился ли тест из-за реальной проблемы в коде базе или просто из-за нестабильности, сложно, особенно когда сбой не связан с конкретным изменением кода.
Чаще всего люди просто повторно запускают тест и надеются на лучшее. Назначить кого-то для расследования этих сбоев сложно, и неопределённость может подорвать производительность. Это может показаться очевидным, но не относитесь к нестабильности как к техническому долгу, который нужно устранить позже. Относитесь к ней как к производственному сбою, требующему немедленного внимания.
Если вам повезло использовать инструмент сборки, такой как TeamCity, вы можете отслеживать нестабильность тестов с течением времени, отмечать тесты как нестабильные и отключать их из конвейера сборки. А ещё лучше — назначить нестабильный тест кому-то для анализа и исправить его, позволяя сборке успешно завершиться. Это позволит нескольким разработчикам не тратить время, пытаясь выяснить, нужно ли им что-то делать с нестабильным тестом. Если у вас нет этих инструментов, договоритесь всей командой о том, чтобы отдать приоритет исправлению нестабильных тестов, чтобы снова сделать сборку зелёной.
Продолжение следует…
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
👍10
День 2284. #УрокиРазработки
10 Уроков Качества Разработки ПО. Продолжение
Начало
4. Пишите код, который вы можете уверенно изменять
Самый важный аспект поддерживаемого кода — это возможность изменять его уверенно: уверенность в том, что вы его поняли, внесли правильные изменения и ничего больше не сломали.
Вот несколько рекомендаций:
- Код должен читаться как книга — методы упорядочены по порядку выполнения, а не по порядку видимости.
- Весь код в методе или функции должен находиться на одном уровне абстракции.
- Методы должны стараться не выходить за рамки 15 строк кода.
- Имена методов должны быть функциональными и объяснять их назначение, а не реализацию.
- Документация кода должна описывать, почему существует метод, а не как он работает.
- Встроенные комментарии допустимы, если они предоставляют дополнительный контекст.
- return либо в самом начале, либо в самом конце, но не в середине.
- Избегайте булевых параметров, используйте перечисления.
- Не вводите абстракции только ради внедрения зависимостей.
- Группируйте код по функциональности, а не по технической структуре для большей ясности.
- Обеспечьте достаточное покрытие тестами: 80% — хорошо, 90% — отлично, 95% — слишком много.
- Не тестируйте слишком подробно; тестируйте внешний интерфейс, но не детали реализации.
5. Это никогда не происходит только один раз
Вы когда-нибудь писали наспех код, а затем обнаруживали, что его используют снова и снова? Или вас просили создать прототип, который каким-то образом попадал в релиз? А как насчёт странной ошибки, которая волшебным образом разрешалась сама собой во время тестирования — только чтобы позже снова появиться в производстве?
Если вы не создаёте MVP (минимально жизнеспособный продукт), не используйте эти практики. Выделите время, чтобы заменить это одноразовое решение надлежащим долгосрочным кодом. Не соглашайтесь на ситуативные решения — будь то очистка куков, повторный запуск нестабильного теста, проблемы с разрешениями или тайм-аутами. Всегда решайте проблемы в корне. Будущий вы скажет вам спасибо.
6. Избегайте любых ручных шагов во время развёртывания
Способность команды развёртывать должным образом протестированную и версионированную программную систему на своей внутренней или облачной инфраструктуре является хорошим показателем зрелости команды. Любой ручной шаг в этом процессе (за исключением ручного запуска конвейера развёртывания) является потенциальной ответственностью и должен быть автоматизирован. Люди совершают ошибки, независимо от того, насколько они скрупулёзны.
С другой стороны, хорошо спроектированный конвейер развёртывания заботится о компиляции исходного кода, вызове любых инструментов анализа кода, запуске автоматизированных тестов, версионировании артефактов развёртывания, предоставлении инфраструктуры, обновлении схемы базы данных, развёртывании в промежуточном слоте, а затем, после подтверждения работоспособности, заменяет его на производственный слот. Всё это без необходимости сообщать разработчикам пароли производственной среды и без того, чтобы кто-либо подключался к производственной среде и вручную запускал скрипты. И если ваш руководитель не видит в этом ценности, аудит, связанный с многочисленными стандартами безопасности, которые у нас есть в настоящее время (ISO 27001, NIS и т.д.), поможет его убедить.
Окончание следует…
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
10 Уроков Качества Разработки ПО. Продолжение
Начало
4. Пишите код, который вы можете уверенно изменять
Самый важный аспект поддерживаемого кода — это возможность изменять его уверенно: уверенность в том, что вы его поняли, внесли правильные изменения и ничего больше не сломали.
Вот несколько рекомендаций:
- Код должен читаться как книга — методы упорядочены по порядку выполнения, а не по порядку видимости.
- Весь код в методе или функции должен находиться на одном уровне абстракции.
- Методы должны стараться не выходить за рамки 15 строк кода.
- Имена методов должны быть функциональными и объяснять их назначение, а не реализацию.
- Документация кода должна описывать, почему существует метод, а не как он работает.
- Встроенные комментарии допустимы, если они предоставляют дополнительный контекст.
- return либо в самом начале, либо в самом конце, но не в середине.
- Избегайте булевых параметров, используйте перечисления.
- Не вводите абстракции только ради внедрения зависимостей.
- Группируйте код по функциональности, а не по технической структуре для большей ясности.
- Обеспечьте достаточное покрытие тестами: 80% — хорошо, 90% — отлично, 95% — слишком много.
- Не тестируйте слишком подробно; тестируйте внешний интерфейс, но не детали реализации.
5. Это никогда не происходит только один раз
Вы когда-нибудь писали наспех код, а затем обнаруживали, что его используют снова и снова? Или вас просили создать прототип, который каким-то образом попадал в релиз? А как насчёт странной ошибки, которая волшебным образом разрешалась сама собой во время тестирования — только чтобы позже снова появиться в производстве?
Если вы не создаёте MVP (минимально жизнеспособный продукт), не используйте эти практики. Выделите время, чтобы заменить это одноразовое решение надлежащим долгосрочным кодом. Не соглашайтесь на ситуативные решения — будь то очистка куков, повторный запуск нестабильного теста, проблемы с разрешениями или тайм-аутами. Всегда решайте проблемы в корне. Будущий вы скажет вам спасибо.
6. Избегайте любых ручных шагов во время развёртывания
Способность команды развёртывать должным образом протестированную и версионированную программную систему на своей внутренней или облачной инфраструктуре является хорошим показателем зрелости команды. Любой ручной шаг в этом процессе (за исключением ручного запуска конвейера развёртывания) является потенциальной ответственностью и должен быть автоматизирован. Люди совершают ошибки, независимо от того, насколько они скрупулёзны.
С другой стороны, хорошо спроектированный конвейер развёртывания заботится о компиляции исходного кода, вызове любых инструментов анализа кода, запуске автоматизированных тестов, версионировании артефактов развёртывания, предоставлении инфраструктуры, обновлении схемы базы данных, развёртывании в промежуточном слоте, а затем, после подтверждения работоспособности, заменяет его на производственный слот. Всё это без необходимости сообщать разработчикам пароли производственной среды и без того, чтобы кто-либо подключался к производственной среде и вручную запускал скрипты. И если ваш руководитель не видит в этом ценности, аудит, связанный с многочисленными стандартами безопасности, которые у нас есть в настоящее время (ISO 27001, NIS и т.д.), поможет его убедить.
Окончание следует…
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
👍14👎1
День 2285. #УрокиРазработки
10 Уроков Качества Разработки ПО. Окончание
Начало
Продолжение
7. Относитесь к конвейеру сборки и развёртывания так же, как к коду
Особенно болезненный опыт обычно связан с ненадежностью конвейера развёртывания. Поскольку он основан на YAML и встроенных задачах, единственным способом устранения неполадок часто является внесение изменений, постановка конвейера в очередь и ожидание результатов. Просто нет способа проверить это по-другому.
Помимо этого, конвейер — это больше, чем просто ряд задач. Он развивается вместе с кодовой базой, может стать довольно сложным и, следовательно, должен быть простым для понимания и рефакторинга при необходимости. Слишком много компаний пытаются придерживаться конвейеров YAML, обходя ограничения, втискивая скрипты PowerShell или Bash вместе с файлами YAML — хотя есть гораздо лучшие альтернативы. Уже не говоря о необходимости перехода с одного движка сборки на другой, например, с Azure DevOps Pipeline на GitHub Actions. Можно использовать Nuke и C# Это обеспечивает доступ к возможностям навигации, рефакторинга и отладки и позволяет тестировать весь конвейер из локальной среды разработки.
8. После выпуска версии 1.0 будьте ответственны
Ваши пользователи или разработчики зависят от стабильности. Сначала выберите стратегию выпуска — будете ли вы принимать регулярные выпуски или будете выпускать новые версии только при необходимости? Чёткий план помогает согласовывать команды и устанавливать ожидания. Всегда применяйте семантическое управление версиями. Это простая система: увеличивайте основную версию при критических изменениях, второстепенную - для новых функций и версию патча для исправлений ошибок. Избегайте критических изменений, когда это возможно. Внесение серьёзных изменений может разочаровать пользователей, поэтому предоставьте чёткие исключения и альтернативы. Наконец, не забывайте о документации. Чётко документируйте свой код как для команды, так и для пользователей. Хорошо документированный код экономит время, предотвращает ошибки и способствует совместной работе.
9. Берегите историю версий
Представьте, что вы пытаетесь понять, почему кто-то увеличил таймаут для выполнения SQL-запроса до 60 секунд. Нет ничего более разочаровывающего, чем найти PR или описание коммита, в котором указано что-то вроде «Увеличен таймаут SQL». Такое описание сообщает, что было сделано, но не объясняет проблему, которую решал разработчик. Аналогично PR, содержащий один коммит, в котором смешан рефакторинг со значимыми изменениями, скорее всего, вызовет столько же разочарования.
В долго существующей кодовой базе понять, почему код ведёт себя определённым образом или написан в определённом стиле, зачастую можно только по истории изменений файла. Убедитесь, что у каждого коммита одна цель, с заголовком, объясняющим эту цель, и описанием, которое содержит обоснование изменения. Такой подход сохраняет историю изменений полезной и облегчает коллегам выполнение проверок. Просматривая коммит за коммитом, коллега может быстро понять, что все изменения в конкретном PR связаны с определённой задачей, что значительно экономит время. Просто убедитесь, что вы не сжимаете коммиты при слиянии.
10. Не бойтесь отклонять PR, если его слишком сложно просмотреть
Вас когда-нибудь просили просмотреть PR с более чем 100 файлами? Вы прокручиваете код, чувствуете себя подавленным и оставляете комментарий типа «вроде норм». Не бойтесь отклонять огромные PR. Качественный обзор кода становится невозможным при таком количестве изменений.
Попросите разработчика разделить изменения на отдельные, целенаправленные коммиты. Ещё лучше — разбить на несколько PR. Это особенно важно для масштабных изменений, таких как рефакторинг.
Помните, что меньше PR = лучше обзор = более качественный код.
См. также «Мастерство Пулл-Реквестов»
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
10 Уроков Качества Разработки ПО. Окончание
Начало
Продолжение
7. Относитесь к конвейеру сборки и развёртывания так же, как к коду
Особенно болезненный опыт обычно связан с ненадежностью конвейера развёртывания. Поскольку он основан на YAML и встроенных задачах, единственным способом устранения неполадок часто является внесение изменений, постановка конвейера в очередь и ожидание результатов. Просто нет способа проверить это по-другому.
Помимо этого, конвейер — это больше, чем просто ряд задач. Он развивается вместе с кодовой базой, может стать довольно сложным и, следовательно, должен быть простым для понимания и рефакторинга при необходимости. Слишком много компаний пытаются придерживаться конвейеров YAML, обходя ограничения, втискивая скрипты PowerShell или Bash вместе с файлами YAML — хотя есть гораздо лучшие альтернативы. Уже не говоря о необходимости перехода с одного движка сборки на другой, например, с Azure DevOps Pipeline на GitHub Actions. Можно использовать Nuke и C# Это обеспечивает доступ к возможностям навигации, рефакторинга и отладки и позволяет тестировать весь конвейер из локальной среды разработки.
8. После выпуска версии 1.0 будьте ответственны
Ваши пользователи или разработчики зависят от стабильности. Сначала выберите стратегию выпуска — будете ли вы принимать регулярные выпуски или будете выпускать новые версии только при необходимости? Чёткий план помогает согласовывать команды и устанавливать ожидания. Всегда применяйте семантическое управление версиями. Это простая система: увеличивайте основную версию при критических изменениях, второстепенную - для новых функций и версию патча для исправлений ошибок. Избегайте критических изменений, когда это возможно. Внесение серьёзных изменений может разочаровать пользователей, поэтому предоставьте чёткие исключения и альтернативы. Наконец, не забывайте о документации. Чётко документируйте свой код как для команды, так и для пользователей. Хорошо документированный код экономит время, предотвращает ошибки и способствует совместной работе.
9. Берегите историю версий
Представьте, что вы пытаетесь понять, почему кто-то увеличил таймаут для выполнения SQL-запроса до 60 секунд. Нет ничего более разочаровывающего, чем найти PR или описание коммита, в котором указано что-то вроде «Увеличен таймаут SQL». Такое описание сообщает, что было сделано, но не объясняет проблему, которую решал разработчик. Аналогично PR, содержащий один коммит, в котором смешан рефакторинг со значимыми изменениями, скорее всего, вызовет столько же разочарования.
В долго существующей кодовой базе понять, почему код ведёт себя определённым образом или написан в определённом стиле, зачастую можно только по истории изменений файла. Убедитесь, что у каждого коммита одна цель, с заголовком, объясняющим эту цель, и описанием, которое содержит обоснование изменения. Такой подход сохраняет историю изменений полезной и облегчает коллегам выполнение проверок. Просматривая коммит за коммитом, коллега может быстро понять, что все изменения в конкретном PR связаны с определённой задачей, что значительно экономит время. Просто убедитесь, что вы не сжимаете коммиты при слиянии.
10. Не бойтесь отклонять PR, если его слишком сложно просмотреть
Вас когда-нибудь просили просмотреть PR с более чем 100 файлами? Вы прокручиваете код, чувствуете себя подавленным и оставляете комментарий типа «вроде норм». Не бойтесь отклонять огромные PR. Качественный обзор кода становится невозможным при таком количестве изменений.
Попросите разработчика разделить изменения на отдельные, целенаправленные коммиты. Ещё лучше — разбить на несколько PR. Это особенно важно для масштабных изменений, таких как рефакторинг.
Помните, что меньше PR = лучше обзор = более качественный код.
См. также «Мастерство Пулл-Реквестов»
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
👍14