1. Использовать простые конструкции потока выполнения. Например, рекурсия это сложный поток выполнения, который потенциально может положить всю программу.
2. Все циклы должны иметь фиксированные границы. При ошибке можно создать бесконечный цикл.
3. Не использовать динамическое выделение памяти после начала выполнения программы. Правило относится к низкоуровневым языкам где управление памятью лежит на разработчике. Существуют некоторые проблемы из-за непредсказуемости работы сборщика мусора, так же можно забыть освободить память или попытаться выделить памяти больше чем доступно.
4. Не писать большие функции (не больше 60 строк). Каждая функция должна выполнять только одно логическое действие.
5. Использовать минимум две проверки данных внутри функции во время ее выполнения. Такие проверки должны находить аномальное поведение, которое не происходит при обычном выполнении программы.
6. Объявлять переменные в минимально возможной области видимости. Таким образом после выхода из области видимости память будет освобождена от не используемых данных.
7. Проверять возвращаемые данные из вызываемых функций и проверять аргументы переданные в функцию. Нет смысла выполнять программу на заведомо не верных данных.
8. Разумно использовать препроцессоры. Правило связано с временем тестирования итогового кода (если это text-based проверки) и написано в контексте языка C. Исходный код на выходе из препроцессора может иметь множество вариаций написания (в зависимости от версии препроцессора).
9. Ограничить использование указателей одной операцией разыменования и не использовать указатели на функции. Правило так же связано со скоростью проверки кода и легкостью понимания потока данных.
10. Включить все уведомления о варнингах при компиляции кода. Все предупреждения должны быть устранены перед релизом.

Угол поворота

Стороны

Когда использовать Observable?

• Есть действие которое вызывает несколько событий
• Есть множество асинхронных операций и ты пытаешься наладить их взаимодействие

Полезно по теме

• Сэм Булатов — Введение в реактивное программирование
• Глеб Михеев — Как RxJS разделил мой мир на до и после

• «… что я буду делать в пн, вт и т. д.?»
• «… с такой технологией я еще не работал»
• «… все ли требования известны?»

• Структура проекта должна рассказывать о его задачах и самостоятельно показывать, как в проект надо погружаться. При первом взгляде на проект должно быть ясно, какие фичи и пользовательские сценарии приложение содержит. Технические аспекты проекта не должны заглушать цели и суть приложения.
• Части проекта должны уметь развиваться независимо, а разработку разных фич должно быть реально поделить между разными людьми или командами. Части приложения должно быть можно удалить без страха поломать другие.
• Распространение изменений по кодовой базе должно быть ограничено конкретной функцией, модулем или фичей, в которых изменения требовались изначально. Не связанный по смыслу с этими обновлениями код меняться не должен.
• Взаимодействие частей проекта должно быть чётким и понятным. Потоки данных должны быть контролируемы, преобразования данных и этапы этих преобразований должны быть явными.
• Код и зависимости, участвующие в каждой конкретной задаче должны быть явными. Код, который в задаче не нужен, использоваться и запускаться не должен.
• Сторонние инструменты и вспомогательные библиотеки должны иметь чёткую область и границы применения. Удерживать в голове объём кода, который с ними связан и его влияние на проект должно быть ограничено.
• Количество неявных входных данных, с которыми работает функция или модуль, должно быть минимально. Объём и размеры данных, ресурсов и зависимостей, которые участвуют в работе должны быть отслеживаемы и измеряемы, чтобы мы могли контролировать их рост и потребление. Внезапные и непропорциональные «всплески» этих ресурсов должны быть легко заметны.
• Проект не должен требовать принимать «большие решения», пока мы не изучим предметную область, ограничения и приоритеты бизнеса.
• Мы хотим понимать, какие инструменты нам стоит интегрировать в проект. Должно быть очевидно, какие инструменты подходят под нашу задачу, какие есть риски от их внедрения, и какая степень интеграции будет оправдана. Тулинг не должен диктовать принципы работы и создавать неоправданные ограничения для задач, которые приносят деньги.
• На ранних этапах мы хотим избежать лишних обобщений. Обобщения и правила должны выработаться эволюционно, в конкурентной среде, опираясь на пользу, которую они приносят.
• Тесты должны ловить регрессии и не должны мешать разработке. Желательно избежать «хрупких тестов», «тестового трения» и «урона от тестов». Тесты должны быть устойчивы к рефакторингу и расширению функциональности.
• Кода, который неясно, как тестировать, быть не должно. Каждая часть проекта должна решать чётко определённую задачу, а результат её должно быть просто и очевидно как протестировать.
• Инфраструктурный код («клей», который держит всё вместе) не должен переплетаться с бизнес-логикой (которая содержит идеи, приносящие деньги).
• Смежные задачи вроде аналитики, интернационализации, перформанс-тулинга также не должны влиять на код бизнес-логики, если это не оправдано пользовательскими сценариями.

• Главной частью приложения должна быть бизнес-логика.
• Структура проекта должна отражать суть приложения.
• Влияние инфраструктуры, UI и смежных задач должно быть минимально.
• Код должно быть легко (и понятно как) тестировать.
• Модули должны быть максимально независимы.
• Код не должен принуждать к серьёзным решениям на ранних этапах.

1. Для начала надо определиться что у тебя вызывает интерес в области IT. Это могут быть мобильные приложения, создание сайтов, серверная часть, геймдев, тестирование и т. д. Почитай чем занимаются люди из этой сферы. Довольно показательными могут быть видео на Youtube
2. Когда появился интерес к какой-то области надо найти список языков программирования которые используются в ней. Список необходим чтобы определить какие из них сейчас популярны на рынке. Востребованные языки легко определить по количеству вакансий на любом из рекрутинговых сайтов
3. Определившись с языком и сферой, надо понять с какими задачами ты столкнешься. Для этого находишь какой-нибудь популярный бесплатный курс по нему и пробегаешься глазами по содержимому. На этом этапе важно понять интересны ли те темы которые будут изучаться. Если информация представленная в курсе не вызывает интереса, то стоит вернуться к первому шагу — сменить область, потому что на других языках программирования из той же области требуются практический такие же знания
4. И вот ты нашел "свой" язык. Далее тебя ждет долгий путь обучения. Необходимо найти хороший обучающий курс (может быть как платный, так и бесплатный). Вдобавок к курсу настоятельно советую найти ментора, который будет помогать изучать особо сложные моменты из курса. А такие моменты обязательно будут, потому что невозможно найти курс который расскажет про все. Придется искать информацию самому или же заниматься дополнительно со специалистом (ментором)