> For the complete documentation index, see [llms.txt](https://braydie.gitbook.io/how-to-be-a-programmer/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://braydie.gitbook.io/how-to-be-a-programmer/ru/1-beginner/team-skills/06-how-to-work-with-poor-code.md). # Как работать с плохим кодом Иногда приходится работать с чужим плохо написанным кодом. Не стоит плохо думать об авторах этого кода, пока вы не поймете полностью их ситуацию. Возможно, они работали быстро и под давлением, чтобы успеть по графику. Как бы то ни было, чтобы работать с плохим кодом, вам надо его понять. Чтобы понять его, нужно время, и его надо откуда-то взять из вашего текущего графика. На этом следует настаивать. Чтобы понять код, вам придется читать исходники и экспериментировать с ним. Это отличный момент начать документировать, даже если пока только для себя. Попытка задокументировать код вынудит вас посмотреть на него с разных точек зрения, которые вы до этого не рассматривали, и конечный документ может получиться очень полезным. Пока вы занимаетесь этим, прикиньте, сколько займет переписать весь код или его некоторую часть. Сохранит ли время переписывание части кода? Сможете ли вы больше доверять коду, если вы перепишите его? Здесь опасайтесь самоуверенности. Если вы перепишете код, то вам будет проще, но будет ли проще следующему человеку, который будет работать с кодом? Если вы перепишите код, то как много придется тестировать? Не перевесит ли необходимость тестирования нового кода все преимущества, которые он принесет? В любой оценке времени, которую вы делаете для работы с чужим кодом, качество этого кода должно влиять на ваше восприятие рисков проблем и неизвестных факторов. Важно помнить, что абстракция и инкапсуляция, два лучших средства программиста, особенно применимы к плохому коду. Возможно, вы не сможете переделать целиком большой блок кода, но если вы добавите новый уровень абстракции к нему, то сможете добиться некоторых преимуществ без переделки всего кода. В частности, вы можете отделить особенно плохие части кода, чтобы отрефакторить их независимо от остального кода. Следующее: [Как использовать системы контроля версий](/how-to-be-a-programmer/ru/1-beginner/team-skills/07-how-to-use-source-code-control.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://braydie.gitbook.io/how-to-be-a-programmer/ru/1-beginner/team-skills/06-how-to-work-with-poor-code.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.