Russian translation. Version 01 (#1)

* Initial setup for Russian version

* README and GLOSSARY translation. Version 01

* Beginner, chapters 01 and 02. Version 01

* Beginner, chapters 03-05. Version 01

* Beginner, chapters 06-08. Version 01

* Beginner, chapters 09-12. Version 01

* Beginner, Team skills, chapters 01-05. Version 01

* Beginner, Team skills, chapters 06-09. Version 01

* Beginner, Team skills, chapters 10-11, README. Version 01

* Intermediate, Personal skills, chapters 01-03. Version 01

* Intermediate, Personal skills, chapters 04-08. Version 01

* Intermediate, Personal skills, chapters 09-12. Version 01

* Intermediate, Team skills, chapters 01-05. Version 01

* Intermediate, Judgement, chapters 01-08. Version 01

* Advance3, Judgement, chapters 01-03. Version 01

* Advance, Compromising Wisely, chapters 01-03. Version 01

* Advance, Serving Your Team, chapters 01-06. Version 01

* Advance, Serving Your Team, chapters 07-11. Version 01

* Other files, README. Version 01

ru/1-Beginner/Personal-Skills/01-Learn-To-Debug.md

@@ -0,0 +1,21 @@
+# Научитесь отлаживать
+[//]: # (Version:1.0.0)
+Отладка это краеугольный камень профессии программиста. Основное значение слова "debug" это "устранять ошибки", но значение, которое имеет реальный вес, это "видеть, как исполняется программа, изучая ее код". Программист, который не умеет эффективно отлаживать, слеп.
+
+Те идеалисты, которые считают, что дизайн, анализ, теория сложности вычислений и подобное более фундаментальны, чем отладка, не являются работающими программистами. Работающий программист не живет в идеальном мире. Даже если вы идеальны, вы окружены и вынуждены работать с кодом, который написан в больших корпорациях, организациях вроде GNU и вашими коллегами. Большая часть этого кода неидеальна, и она неидеально задокументирована. Без способности видеть исполнение этого кода, малейшее несоответствие выбьет вас из колеи. Часто увидеть это можно только с помощью эксперимента, то есть, отладки. 
+
+Отладка больше занимается исполнением программ, чем самими программами. Если вы купите программное обеспечение от большой компании, то обычно вам не доведется увидеть сам код. Но все равно будут возникать моменты, когда программа не соответствует документации, либо документация просто ничего не говорит о конкретном поведении программы. Распространенный и яркий пример: сбой всей операционной системы во время работы. Обычно вы при работе создаете ошибку, изучаете собственный код и понятия не имеете, откуда возникла ошибка. Неизбежно это ведет к мысли о том, что вы делаете что-то не то, либо возникает некое обстоятельство, которое вы не учитываете в программе. Иногда трюк с изучением исходного кода помогает. Иногда нет, и тогда вы должны перейти к отладке.
+
+Чтобы понять, как исполняется программа, вы должны иметь возможность запустить ее и наблюдать ход исполнения. Иногда ошибка видна визуально, например, если она отображается на экране или между событиями в программе очевидна непредусмотренная задержка. Во многих других случаях, ошибка связана с факторами, которые нельзя наблюдать непосредственно, например, с состоянием переменных, конкретными строками кода, исполняющиеся в данный момент, либо с утверждениями внутри сложной структуры данных. Эти скрытые факторы надо выяснить.
+
+Распространенные методы изучения "внутренностей" программы можно поделить на:
+
+- Использование отладчика,
+- Printlining --- внесение временных модификаций в программу, обычно выводящих информацию о ее текущем состоянии,
+- Логирование --- создание постоянного интерфейса, который выводит ход исполнения программы в виде отчета.
+
+Отладчики это прекрасное средство, когда они стабильны и доступны, но printlining и логирование гораздо важнее. Отладчики часто отстают от развития языков программирования, так что они могут быть доступны не в каждый момент времени. К тому же, некоторые отладчики могут незначительно изменять ход исполнения программы, поэтому применять их в этих случаях непрактично. Наконец, существуют виды отладки, такие как проверка утверждений в большой структуре данных, которые требуют написания нового кода и изменения хода исполнения программы. Таким образом, это важно знать, как пользоваться отладчиками, когда они доступны, но критично важно уметь использовать два оставшихся метода отладки.
+
+Некоторые начинающие программиста боятся отладки, если та требует изменения кода. Это можно понять, это немного похоже на вскрытие с исследовательскими целями. Но вы должны научиться тыкать и дергать свой код, экспериментировать с ним и понимать, что ничего из того, что вы временно делаете с ним, не сделает его хуже. Если у вас есть такой страх, найдите наставника. Мы теряем множество хороших программистов в самом начале их обучения из-за этого страха.
+
+Следующее: [Как отлаживать, разделяя пространство проблемы](02-How-to-Debug-by-Splitting-the-Problem-Space.md)

ru/1-Beginner/Personal-Skills/02-How-to-Debug-by-Splitting-the-Problem-Space.md

@@ -0,0 +1,15 @@
+# Как отлаживать, разделяя пространство проблемы
+[//]: # (Version:1.0.0)
+Отладка это интересно, потому что она начинается с проблемы. Вы думаете, что программа делает одно, но на самом деле она делает что-то другое. Не всегда это настолько просто, все  примеры, которые я мог бы привести, будут надуманными по сравнению с реальными случаями. Отладка требует творчества и изобретательности. Если и есть какой-то один ключ к отладке, то он заключается в приеме "разделяй и властвуй" в отношении проблемы.
+
+Предположим, к примеру, что вы написали программу, которая должны выполнять десять инструкций подряд. Затем вы запускаете ее, и она вылетает. Поскольку вы не планировали вылет программы, у вас появляется проблема. Когда вы смотрите на вывод программы, вы видите, что первые семь инструкций были выполнены успешно. Оставшиеся три инструкции не видны в выводе, поэтому пространство проблемы сужается: программа вылетает либо на восьмой, либо на девятой, либо на десятой инструкции.
+
+Сможете ли вы поставить эксперимент, чтобы увидеть, где вылетает программа? Конечно. Вы можете использовать отладчик или добавить printline statements (либо их эквивалент на вашем языке программирования) после восьмой и девятой инструкций. Когда вы запустите программу снова, пространство проблемы станет еще уже, например, вы увидите, что программа вылетает на девятой инструкции. Я считаю, что помнить о точном пространстве проблемы помогает сосредоточиться на ее решении. Когда несколько человек работают под давлением над задачей, очень легко забыть о том, что является главной проблемой в ней.
+
+Ключ к отладке по принципу "разделяй и властвуй" такой же, как и при разработке алгоритмов. Вы разделяете пространство программы, в котором может быть проблема, напополам. Вам не придется делать это слишком долго, и вы быстро будете продвигаться в отладке. Но что такое то пространство, где находится ошибка? Именно здесь на помощь приходят изобретательность и опыт.
+
+Начинающим программистам кажется, что ошибка может быть в каждой строке кода. У них еще нет того видения программы, которое появится позже с опытом. Они не видят все свойства и факторы программы, такие как пространство исполняемого кода, структура данных, управление памятью, взаимодействие с внешнем кодом, рискованный код, простой код. Для опытного программиста эти факторы составляют неполную, но крайне полезную модель всего того, что может пойти не так. Наличие такой модели в голове очень эффективно помогает обнаружить точное место проблемы.
+
+Когда вы разделили все пространство программы на все места, где может быть ошибка, вы предстоит определить, где именно она находится. В простом случае, когда вопрос стоит как "В какой неизвестной мне строке падает программа?", вы можете спросить себя: "Неизвестная мне строка с ошибкой находится до или после этой строки, которая по моему мнению должна исполняться в середине программы?" Как правило, вы будете не настолько удачливы, чтобы обнаружить, что ошибка кроется в одной строке или даже в одном блоке кода. Чаще проблема будет звучать как "Либо в этом графе есть указатель на некорректный объект, либо мой алгоритм некорректно складывает переменные в этом графе". В этом случае, возможно, вам придется написать небольшую программу для проверки указателей, чтобы решить, какую из частей этого пространства проблемы можно исключить. 
+
+Следующее: [Как устранять ошибки](03-How-to-Remove-an-Error.md)

ru/1-Beginner/Personal-Skills/03-How-to-Remove-an-Error.md

@@ -0,0 +1,9 @@
+# Как устранять ошибки
+[//]: # (Version:1.0.0)
+Я намеренно разделил исследование хода исполнения программы от исправления ошибки. Но, разумеется, отладка означает и устранение ошибки. В идеале вы прекрасно поймете код и поймаете "Ага"-момент, когда вы четко увидите ошибку и как ее исправить. Но это не всегда будет возможно, поскольку зачастую ваша программа будет использовать недостаточно документированные сторонние системы, насчет которых у вас не будет полной ясности. В других случаях сам код будет настолько сложен, что ваше понимание его будет несовершенным.
+
+При исправлении ошибки важно внести наименьшие изменения, которые ее исправят. Вы можете заметить другие места в коде, которые потребуют улучшений, но не вносите их одновременно с исправлением ошибки. Старайтесь применять научный метод: изменять только одно зараз. Лучший способ для этого: воспроизвести ошибку, внести исправления, затем перезапустить программу и убедиться, что ошибки больше нет. Конечно, иногда придется менять не одну, а несколько строк кода, но концептуально все равно старайтесь вносить точечные изменения для исправления ошибки.
+
+Иногда в программе присутствует несколько ошибок, очень похожих друг на друга. Определить их и исправить --- это ваша задача. Иногда неясно, что должна делать программа или к чему стремился автор исходного кода. В этом случае, вы должны применить свой опыт и знания и придать свой собственный смысл коду. Решите, что он должен делать и добавьте комментарии об этом, либо обозначьте это иным способом. Затем исправьте код согласно своему пониманию. Это навык разработчика среднего или продвинутого уровня, и иногда он гораздо сложнее, чем написание оригинальной функции с нулю, но реальный мир иногда бывает неряшлив. Иногда вам придется исправлять системы, которые вы не можете переписать с нуля.
+
+Следующее: [Как отлаживать, используя логирование](04-How-to-Debug-Using-a-Log.md)