Merge pull request #136 from paveltovchigrechko/master

Russian translation

LANGS.md

@@ -2,4 +2,5 @@
 * [Spanish](es/)
 * [Chinese](zh/)
 * [Japanese](jp/)
+* [Russian](ru/)
 * [Chinese-Traditional](zh-traditional/)

README.md

@@ -23,7 +23,8 @@ Welcome to the tribe.
 
 ## Contents
 
-**Also available in [Chinese](zh/README.md), [Japanese](jp/README.md) and [Spanish](es/README.md)**
+**Also available in [Chinese](zh/README.md), [Japanese](jp/README.md),[Spanish](es/README.md), and [Russian](ru/README.md)**
+
 
 1. [Beginner](en/1-Beginner)
 	- Personal Skills

en/7-Contributions.md

@@ -17,6 +17,7 @@ There are a number of ways to contribute to "How to be a Programmer".
 Currently this guide has been translated from English into the following languages:
 
 - Chinese by [ahangchen](https://github.com/ahangchen)
+- Russian by [paveltovchigrechko](https://github.com/paveltovchigrechko)
 - Spanish by [Maximiliano Murua](https://gitlab.com/maximiliano.murua)
 
 **If you provide the initial translation of the guide into another language, you become legible to become a contributor on this project to help maintain and review changes made to the translation.**

jp/7-Contributions.md

@@ -17,9 +17,11 @@ There are a number of ways to contribute to "How to be a Programmer".
 Currently this guide has been translated from English into the following languages:
 
 - Chinese by [ahangchen](https://github.com/ahangchen)
+- Russian by [paveltovchigrechko](https://github.com/paveltovchigrechko)
 - Spanish by [Maximiliano Murua](https://gitlab.com/maximiliano.murua)
 
-**If you provide the initial translation of the guide into another language, you become legible to become a contributor on this project to help maintain and review changes made to the translation.**
+
+**If you provide the initial translation of the guide into another language, you become elegible to become a contributor on this project to help maintain and review changes made to the translation.**
 
 ## Contributors
 

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

@@ -0,0 +1,21 @@
+# Научитесь отлаживать
+[//]: # (Version:1.0.0)
+Отладка - это краеугольный камень профессии программиста. Основное значение слова "debug" это "устранять ошибки", но значение, которое имеет реальный вес, это "видеть, как исполняется программа, изучая ее код". Программист, который не умеет эффективно отлаживать, слеп.
+
+Те идеалисты, которые считают, что дизайн, анализ, теория сложности вычислений и подобное более фундаментальны, чем отладка, вряд ли являются работающими программистами. Работающий программист не живет в идеальном мире. Даже если вы идеальны, вы окружены и вынуждены работать с кодом, который написан в больших корпорациях, организациях вроде GNU и вашими коллегами. Большая часть этого кода неидеальна, и она неидеально задокументирована. Без способности видеть исполнение этого кода, малейший баг выбьет вас из колеи. Часто увидеть исполнение можно только с помощью эксперимента, то есть, отладки. 
+
+Отладка больше касается исполнения программ, чем самих программ. Если вы купите программное обеспечение от большой компании, то, как правило, вам не доведется увидеть сам код. Но все равно будут моменты, когда программа не соответствует документации, либо документация просто ничего не говорит о конкретном поведении программы. Распространенный и яркий пример: сбой всей операционной системы во время работы программы. Обычно вы при работе создаете баг, изучаете собственный код и понятия не имеете, как он возник. Неизбежно это ведет к мысли о том, что вы делаете что-то не то, либо возникает некое обстоятельство, которое вы не учитываете в программе. Иногда трюк с изучением исходного кода помогает. Иногда нет, и тогда вы должны перейти к отладке.
+
+Чтобы понять, как исполняется программа, вы должны иметь возможность запустить ее и наблюдать за ее ходом исполнения. Иногда баг виден визуально, например, если он отображается на экране или между событиями в программе очевидна непредусмотренная задержка. Во многих других случаях, баг связан с факторами, которые нельзя наблюдать непосредственно, например, с состоянием переменных, конкретными строками кода, исполняющиеся в данный момент, либо с утверждениями внутри сложной структуры данных. Эти скрытые факторы надо выяснить.
+
+Распространенные методы изучения "внутренностей" программы можно поделить на:
+
+- Использование отладчика
+- Вывод в консоль - внесение временных модификаций в программу, обычно выводящих информацию о ее текущем состоянии
+- Логирование - создание постоянного интерфейса, который выводит ход исполнения программы в виде отчета
+
+Отладчики это прекрасное средство, когда они стабильны и доступны, но вывод в консоль и логирование гораздо важнее. Отладчики часто отстают от развития языков программирования, так что они могут быть доступны не в каждый момент времени. К тому же, некоторые отладчики могут незначительно изменять ход исполнения программы, поэтому применять их в этих случаях непрактично. Наконец, существуют виды отладки, такие как проверка утверждений в большой структуре данных, которые требуют написания нового кода и изменения хода исполнения программы. Так что важно знать, как пользоваться отладчиками, когда они доступны, но критично важно уметь использовать два оставшихся метода.
+
+Некоторые начинающие программиста боятся отладки, если та требует изменения кода. Их можно понять, ведь это немного похоже на вскрытие с исследовательскими целями. Но вы должны научиться вызывать свой код, экспериментировать с ним и понимать, что ничего из того, что вы временно делаете с ним, не сделает его хуже. Если у вас есть такой страх, найдите наставника. Мы теряем множество хороших программистов в самом начале их обучения из-за этого страха.
+
+Следующее: [Как отлаживать, разделяя пространство проблемы](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)
+Отладка это интересно, потому что она начинается с проблемы. Вы думаете, что программа делает одно, но на самом деле она делает что-то другое. Не всегда это настолько просто, но все примеры, которые я мог бы привести, будут надуманными по сравнению с реальными случаями. Отладка требует творчества и смекалки. Если и есть какой-то один ключ к отладке, то он заключается в приеме "разделяй и властвуй" в отношении проблемы.
+
+Предположим, к примеру, что вы написали программу, которая должна выполнять десять инструкций подряд. Затем вы запускаете ее, и она вылетает. Поскольку вы не планировали вылет программы, у вас появляется проблема. Когда вы смотрите на вывод программы, вы видите, что первые семь инструкций были выполнены успешно. Оставшиеся три инструкции не видны в выводе, поэтому пространство проблемы сужается: программа вылетает либо на восьмой, либо на девятой, либо на десятой инструкции.
+
+Сможете ли вы поставить эксперимент, чтобы увидеть, где вылетает программа? Конечно. Вы можете использовать отладчик или добавить вывод в консоль (либо их эквивалент на вашем языке программирования) после восьмой и девятой инструкций. Когда вы запустите программу снова, пространство проблемы станет еще уже, например, вы увидите, что программа вылетает на девятой инструкции. Я считаю, что помнить о точном определении проблемы помогает сосредоточиться на ее решении. Когда несколько человек работают под давлением и стрессом над задачей, очень легко забыть о том, что в ней является главной проблемой.
+
+Ключ к отладке по принципу "разделяй и властвуй" такой же, как и при разработке алгоритмов. Вы разделяете пространство программы, в котором может быть проблема, пополам. Вам не придется делать это слишком долго, и вы быстро будете продвигаться в отладке. Но что такое то пространство, где находится ошибка и которое следует поделить пополам? Именно здесь на помощь приходят смекалка и опыт.
+
+Начинающим программистам кажется, что ошибка может быть в каждой строке кода. У них еще нет того понимания программы, которое появится позже с опытом. Они не видят все свойства и факторы программы, такие как пространство исполняемого кода, структура данных, управление памятью, взаимодействие с внешним кодом, рискованный код, простой код. Для опытного программиста эти факторы составляют неполную, но крайне полезную модель всего того, что может пойти не так. Наличие такой модели в голове очень эффективно помогает обнаружить точное место проблемы.
+
+Когда вы разделили все пространство программы на все места, где может быть ошибка, вам предстоит определить, где именно она находится. В простом случае, когда вопрос стоит как "В какой неизвестной мне строке падает программа?", вы можете спросить себя: "Неизвестная мне строка с ошибкой находится до или после этой строки, которая по моему мнению должна исполняться в середине программы?" Как правило, вы будете не настолько удачливы, чтобы обнаружить, что ошибка кроется в одной строке или даже в одном блоке кода. Чаще проблема будет звучать как "Либо в этом графе есть указатель на некорректный объект, либо мой алгоритм некорректно складывает переменные в этом графе". В этом случае, возможно, вам придется написать небольшую программу для проверки указателей, чтобы решить, какую из частей этого пространства проблемы можно исключить. 
+
+Следующее: [Как устранять баги](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)