> 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/3-advanced/serving-your-team/07-how-to-grow-a-system.md).

# Как развивать систему

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

У нас есть роскошь относиться к программному обеспечению похожим образом. Мост не похож на программное обеспечение. Не бывает мостов-детей, бывают недостроенные мосты. Они гораздо проще, чем программное обеспечение.

Полезно думать о программном обеспечении как о чем-то растущем, это позволяет нам добиться существенного прогресса до того, как у нас сложится идеальный мысленный образ того, что мы делаем. Мы можем использовать обратную связь от пользователей, чтобы скорректировать развитие системы. Всегда полезно обрезать слабые и ненужные ветки.

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

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

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

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

Один из читателей, Роб Хаферник, прислал комментарий к этой части, который я не могу не привести полностью:

> Я думаю, что вы недооценили важность этого вопроса. Он касается не только системы, но и алгоритмов, пользовательских интерфейсов, моделей данных и так далее. При работе над большой системой жизненно важно иметь измеряемый прогресс в достижении промежуточных целей. Ничто не сравнится с ужасом, когда вы доходите до конца и обнаруживаете, что все это просто не работает. Я бы пошел дальше и сформулировал бы это как природный закон: нельзя с листа построить большую и сложную систему. Ее можно только развить из небольшой в сложную через серию последовательных шагов.

На это можно только ответить "Истинно так!"

Следующее: [Как качественно взаимодействовать](/how-to-be-a-programmer/ru/3-advanced/serving-your-team/08-how-to-communicate-well.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/3-advanced/serving-your-team/07-how-to-grow-a-system.md?ask=<question>&goal=<endgoal>
```

`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.