Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>27 мар 2020</li>

3 <li>0</li>

4 </ul><h2>Что такое плохой код и что с этим делать</h2>

5 Что такое качество кода, как его улучшить, и почему иногда хороший код - это плохо. Статья подготовлена на основе нашего вебинара с Глебом Михеевым.

6 vlada_maestro / shutterstock

7 В бэкграунде - программирование, французский язык, академическое рисование, капоэйра. Сейчас учит финский. Любит путешествия и Балтийское море.

8 ВРЕМЯ ПРОСМОТРА

9 1 ч. 19 мин.

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

11 Признаки некачественного кода:

12 <ul><li>в нём тяжело ориентироваться;</li>

13 <li>части, которые можно написать двумя строчками, написаны десятью;</li>

14 <li>по названию функции нельзя понять, что она делает (xyz, function, n);</li>

15 <li>если в него что-то добавить, остальное перестанет работать.</li>

16 </ul>Вот такой логикой, как на картинке, всё-таки лучше не пользоваться: если программа работает, это ещё не значит, что с ней всё в порядке.

17 На первый взгляд, плохой код - не катастрофа. Программа же работает, разве это не главное? На самом деле он приносит много проблем, особенно в долгосрочной перспективе. И вот почему:

18 <ul><li>чтобы внести изменения в некачественный код, нужно много времени и стоит это дорого, причёмсо временем цена и продолжительность только увеличиваются;</li>

19 <li>добавить что-то новое тоже сложно;</li>

20 <li>код непредсказуем - вы никогда не знаете, что и когда перестанет работать;</li>

21 <li>командный дух падает, если людям приходится работать с такими шедеврами("Да кто это вообще писал?!").</li>

22 </ul>В итоге скорость разработки снижается, сроки удлиняются, стоимость изменений растёт. Если это критично для потребителя или заказчика, то плохой код может похоронить проект.

23 Чтобы писать качественный код, надо знать, что он из себя представляет. Вот его основные качества:

24 <ul><li>код легко читается, у него чёткая структура, в ней нет путаницы;</li>

25 <li>он легко поддерживается: небольшие изменения не вызывают желания написать его заново;</li>

26 <li>его можно расширять;</li>

27 <li>код прошёл тестирование;</li>

28 <li>он документирован;</li>

29 <li>производителен.</li>

30 </ul>Журналист спрашивает программиста:- Какой код плохой?Программист:- Без комментариев.Комментарии действительно очень важны, чтобы код легко читался. Это поможет не только другим программистам, когда они будут работать с вашим кодом, но и вам в будущем.

31 Подробнее почитать об этом можно здесь: Как писать техническую документацию для программ на <a>C#</a>

32 Вот пять действий, которые улучшают код.

33 <ol><li>Соблюдайте стандарты оформления кода.Это один из самых простых и важных ориентиров - когда вы заранее договариваетесь с коллегами, как оформлять код и как поступать в некоторых ситуациях. Тогда код, написанный разными программистами, будет визуально похож: вам будет проще работать с чужим кодом и наоборот.Еще естьобщепринятые стандартыоформления кода и даже платформы для программирования, которые вам подскажут, как этим стандартам следовать. Это важно и при работе в команде, и в том случае, если вы пишете код в одиночку.

34 </li>

35 <li>Рефакторинг.Это переработка кода программы без изменения её поведения. То есть сначала у вас креативный процесс: вы пишете так, чтобы программа работала, а потом "убираете за собой", приводите код в порядок, к нужному виду. В качестве бонуса рефакторинг помогает переосмыслить архитектурные решения программы.</li>

36 <li>Типизация.Поясним на реальном примере. Разработчикам одной игры игроки писали о проблемах, а потом вдруг перестали. Сначала было разработчики обрадовались: всё настолько круто, что проблем нет. Позже оказалось, что в игре изменилсяюзернеймна никнейм,и из-за этого перестала работать форма обратной связи: жалобы просто не отправлялись.Типизация(декларирование типа данных)поможет избежать таких ошибок и упростит поддержку и рефакторинг.

37 </li>

38 <li>Код-ревью.Это когда вы с коллегой проверяете код друг друга и даете друг другу фидбэк. Такая практика помогает избежать глупых ошибок и непродуманностей. Кроме того(и это тоже важно), вы в курсе того, чем занимается другой человек, и вам не приходится дублировать функции. Замечательный бонус - этот метод поможет мягко адаптировать новичков.</li>

39 <li>Автоматические тесты - о них мы поговорим чуть подробнее. Это простые программы, которые запускают код с разными параметрами и сверяют с уже известными результатами. Какие бывают тесты?</li>

40 </ol><ul><li>Unitтестируют отдельные части программы.</li>

41 <li>e2eтестируют систему в целом.</li>

42 <li>Нагрузочныепроверяют, насколько хорошо программа справляется с нагрузками.</li>

43 <li>Скриншотныесравнивают скриншоты до и после, реагируют на изменения.</li>

44 <li>Прочие: мутационные, пенетрационные…</li>

45 </ul>Мой код и правда так плох?.. Не-е-е, это тесты не правы!С тестами действительно нужно быть внимательными, чтобы не получилось, что вы часами ищете ошибку в коде, а проблема в самих тестах. Поэтому полезно сначала писать тесты, а потом уже браться за сам код, когда у вас в голове есть чёткая структура и понимание, что надо делать и что вы хотите получить.

46 Есть и другие способы улучшить код(например, парное программирование). Самые лучшие результаты можно получить, если использовать сразу несколько способов: так надёжнее.

47 Если хотите улучшить свой код, то советуем почитать эту статью: Ужасы чужого кода: как найти смысл и не умереть. Там много полезных советов и личного опыта.

48 Мы сейчас столько говорили о том, как важен качественный код, а теперь заявляем обратное? Да.Иногда хороший, "правильный" код - это не так уж и замечательно.

49 Причина очень простая: в программировании, к сожалению, приходится выбирать междукачествоми скоростью работы, и в некоторых случаях скорость важнее.

50 Чтобы понять, насколько важна скорость, представим себе двух программистов: Петю и Васю. Один обстоятельный, педантичный, а второй - его полная противоположность. Обоим пришла в голову идея сделать какой-то продукт. Петя сел, придумал архитектуру и начал делать хорошо и неторопливо. И делает уже полгода. Вася сделал всё за месяц, с ошибками, багами - но сразу запустил, нашёл клиентов, сделал второй релиз… В итоге через полгода, когда Петя только доделал свой замечательный продукт, у Васи уже много пользователей и название продукта уже на слуху. А часть багов он почистил во втором релизе.

51 Мораль этой истории:иногда важнее быстрее выйти на рынок и занять нишу, чем сделать идеально.

52 Как тогда быть? Плохой код - плохо, хороший - тоже не всегда хорошо… Дело вот в чём:

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

54 Если же вы делаете лендинг, который просто расскажет о временной акции и соберёт мейлы в базу данных, то тут уже важна скорость. Вы знаете, что, как только акция закончится, ваш код больше не понадобится. Дорабатывать и поддерживать его не нужно, и другие разработчики его использовать тоже не будут - тут достаточно написать быстро и проверить, что он работает, остальное не важно.

55 Это основные принципы создания качественного кода: не забывать про стандарты, оглядываться на то, что вы уже написали, не бояться фидбека от коллег и не забывать тестировать. Но в самом начале стоит взвесить: важно вам сейчас качество, или надо закончить разработку как можно скорее.

56 <a>Бесплатный курс по Python ➞Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу</a>