что такое дебажить код

Запись на стене

6 фраз, которые должен знать каждый IT-шник.

Означает всего лишь «поручить задание». Фраза произошла от английских слов to assign — назначать, поручать и task — задача. В ИТ‑сфере речь обычно идёт о распределении рабочих дел между сотрудниками в специальной программе‑менеджере.

Дебажить код — это антоним к слову «бодяжить». Шутка! «Дебажить» значит проверять программный код на ошибки. Разработчик запускает режим отладки и ищет «баги», от английского bug — технический дефект. Кстати, ещё bug означает «жук» и «жучок» (для прослушивания). Соответственно, глагол to debug — избавиться от дефектов.

Термины происходят от английских слов to release — выпускать и to deploy — приводить в действие, разворачивать. В ИТ‑сфере эти слова часто употребляются как синонимы и означают выпуск новой версии программы. Но некоторые специалисты их различают: «зарелизить» применяется, когда программа начинает быть доступна пользователям, а «задеплоить» — когда она переходит в любую другую среду, например переносится в тестовую систему или на другой сервер.

4. Зааджастить прогу

«Прога» говорят не только айтишники, но на всякий случай уточним, что это сокращение от слова «программа». «Зааджастить» возникло от глагола to adjust — приводить в порядок, регулировать. Айтишники говорят так, когда нужно немного поменять логику программы, слегка что‑то донастроить.

6. Черрипикнуть хотфикс

Хотфикс — это прямая транслитерация слова hotfix. Hot — горячий или горящий по срокам, fix — исправление, починка. Например, когда в программе обнаружился баг, который сильно всё ломает, — нужно его молниеносно починить, то есть сделать хотфикс. Чтобы применить только новые изменения, не трогая остальных частей программы, есть операция cherry pick — что‑то типа выборочного переноса.

Источник

Как дебажить программу

Введение

Обычный алгоритм решения задачи выглядит так:

Написать код решения (или лучше части решения).

Тестировать решение на своем компьютере (или лучше потестировать часть решения)

3+) Если не работает, то дебажить, пока не заработает на всех тестах.

4+++) Спросить преподавателя. Впрочем, этим методом можно и нужно пользоваться на более ранних стадиях, если вы только начинаете заниматься программированием

Здесь будут собраны советы о том, что делать в пунктах, начиная с 2.

Про первый пункт советов не будет 🙁 Разве что совет, что придумать решение необходимо ДО того, как писать код.

Что делать, пока пишешь код

Проследите путь каждой переменной и каждого цикла

Нужно для каждой переменной понимать * чему она равна изначально * как она меняется в какой части программы * какие значения она может понимать, а какие нет.

Также и для каждого цикла нужно понимать * какая будет первая итерация * в какой момент он закончится * сколько всего будет итераций * нет ли где-то выхода за границы массива

Пишите по кодстайлу

Зачем? * увидеть ошибку в структурированном коде гораздо проще, чем в каше * чужому человеку и вам в будущем читать ваш непонятный код будет гораздо сложнее и неприятнее * в промышленном программировании именно так все и пишут, полезно привыкнуть

Делите код на функции как можно более сильно

Почему? * в длинном сплошном коде легко не заметить ошибку * отдельные функции очень просто тестировать * если функция применяется несколько раз, то не нужно копировать код, что хорошо, так как при копировании кода можно скопировать ошибку, увидеть ее, исправить в одном месте, а в другом она * в промышленном программировании именно так все и пишут, полезно привыкнуть

Вот пример, когда в программе без функций найти ошибку тяжело: (код Сережи Карпышева)

Если все это сделать, то код станет понятным, в функции из одной строчки ошибиться очень тяжело. А еще каждую функцию можно легко потестировать отдельно, разобрать крайние случаи для каждой отдельной функции.

Как дебажить, если знаешь тест, на котором не работает

TODO описать процесс и виды дебага

Самые частые ошибки, если у вас все работает, а в тестирующей системе нет

Выход за границы массива

Поэтому: * C++ чаще всего не видит эту ошибку и работает дальше. * Ваша программа может работать по-разному у вас и на сервере.

Слишком маленький тип данных

Нужно знать, что * int содержит числа примерно от \(-2 * 10^9\) до \(2 * 10^9\) * unsigned int содержит числа примерно от \(0\) до \(4 * 10^9\) * long long содержит числа примерно от \(-9 * 10^18\) до \(9 * 10^18\) * unsigned long long содержит числа примерно от \(0\) до \(18 * 10^18\)

И всегда проверять, что когда вы * складываете * умножаете * вычитаете

числа, они все еще помещаются в выбранный вами тип.

Например, в задаче про быстрое возведение в степень, по условию гарантируется, что \(x, N, P \leq 2 * 10^9.\) Это значит, что в тип int они влезут.

Крайние случаи

Вы решаете не ту задачу

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

Стресс-тестирование

Но если вы достаточно много тестировали свою задачу, то вам может помочь стресс-тестирование

Источник

Как дебажить фронтенд и бекенд: пошаговая инструкция

В этом посте мы научимся дебажить JavaScript на фронт- и бекенде с помощью Chrome DevTools и VS Code.

Ловим баги на фронтенде (JavaScript, Angular)

Очень много сервисов сейчас позволяют дебажить код над фронтенде. Chrome DevTools и Firefox Developer Tools среди них самые популярные, но и в других браузерах тоже есть свои тулзы. Мы будем использовать Chrome DevTools для примеров.

Дебажим JavaScript

Откровенно говоря, отладка кода может занимать много времени. Особенно, если использовать такие простые команды как console.log() или window.alert().

Нужно писать, а потом удалять дополнительный код, а иногда эти команды все равно попадают в коммит (даже если вы думали, что все их забрали). А если при этом использовать линты (статические отладчики), то команды console или alert будут подсвечиваться в коде.

И на этом моменте в игру вступает Chrome DevTools, позволяя нам дебажить код без утомительных команд. Среди фишек этой тулзы, редактирование CSS и HTML, тестирование сети и проверка скорости сайта — наши любимые.

Чтобы на практике познакомиться с этой тулзой, давайте создадим простенькую страничку на JavaScript с getData() методом. Этот метод будет просто собирать данные с поля ввода, создавать DOM элемент с dataSpan ID и добавлять значение с поля ввода в этот элемент.

Вот как наша страничка будет выглядеть:

В JavaScript:

Сохраним ее как app.js.

Вот как наша страничка будет выглядеть в браузере:

Чтобы проверить как метод работает до того, как сохранять данные в dataSpan, можно использовать старомодные console.log(data) или window.alert(data). Вот что мы увидим запустив файл в VS Code:

Это самый примитивный подход.

Вместо этого, мы используем брейкпоинты (точки останова) вChrome DevTools чтобы убедиться, что все работает как надо.

Брейкпоинт — это строка кода, на которой мы хотим приостановить прогонку кода, чтобы изучить как он работает (или не работает).

Возвращаясь к примеру, давайте запустим страницу в Google Chrome и сделаем следующее:

Открыв панель инструментов разработчика, давайте приостановим код на брейкпоинте:

Управление интервалами выполнения кода

Поставив брейкпоинт, ми приостанавливаем исполнение функции на нем. Поэтому нам нужно будет продолжить построчное выполнение кода, чтобы изучить изменения нашей переменной.
В верхнем левом углу панели JavaScript Debugging находятся основные команды прогонки брейкпоинтов:

Первая кнопка, Resume script execution () продолжит выполнение кода до конца или до следующего брейкпоинта.

Давайте введем hello world в поле ввода. В строку добавится data = “hello world”. Теперь давайте кликнем на кнопку Step over next function call ().

Выбранная строка с брейкпоинтом будет выполнена и дебаггер выберет следующую. Откройте вкладку Scope чтобы посмотреть значение переменной data. Оно изменилось на “hello world”, которое мы ввели ранее и просто показывает значение нашей переменной на конкретной строке кода. Кликните Step over next function call еще раз чтобы выполнить выбранный метод и перейти на следующую строку.

Если обновить страницу, значение переменной out также обновится в DOM элементе. Чтобы посмотреть значение переменной, можно кликнуть на Expand () слева от нее. Если же еще раз кликнуть Step over next function call, то текст “hello world” еще раз добавится в dataSpan.

Более сложная отладка

Предположим, что мы выполняем функцию посложнее, которую точно не помешает отладить. К примеру, мы хотим, чтобы пользователи вводили числа через пробел. Функция затем будет обрабатывать и выводить эти числа, их сумму, и результат умножения.

Для этого мы обновим код app.js как на скриншоте выше. Обновляем страницу и приступаем непосредственно к дебаггингу.

Как еще можно поставить брейкпоинты

В большинстве случаев, ваш код намного длиннее и, вполне возможно, конкатенирован в одну строку. К примеру, предположим, что у вас 1000 строк кода. В этом случае, ставить брейкпоинты, кликая на номера строк каждый раз, не кажется такой уж отличной идеей, не правда ли?

Для этого в DevTools есть классный инструмент для установки брейкпоинтов на разные типы интеракции с браузером. На панели JavaScript Debugging, кликните Event Listener Breakpoints чтобы посмотреть доступные категории.

Как вы видите, можно поставить брейкпоинт на событие Mouse > click (клик мышкой) в любом месте нашего кода. Это означает, что, если кликнуть Get Input Data, выполнение кода остановится на событии onclick. И не нужно вручную ничего добавлять.

Клик на Step over next function call будет последовательно вести нас через код, используемый чтобы обработать клики.

Используя Event Listener Breakpoints, можно поставить брейкпоинты на кучу разных типов событий, таких как Keyboard, Touch, и XHR.

Ключевое слово “debugger”

Если ввести debugger в любом месте кода, Chrome DevTools приостановит выполнение кода на этой строке и подсветит ее также, как и брейкпоинты. Можно использовать этот инструмент чтобы дебажить JavaScript в Chrome или других браузерах. Только не забудьте удалить его, когда закончите отладку.

Код на скриншоте выше остановится на строке, которая содержит ключевое слово ​debugger и автоматически запустит Chrome DevTools. По сути, это то же самое, что и поставить брейкпоинт на эту строку. Также выполнением кода можно управлять с помощью кнопок ​Step into next function call и Step over next function call.

Выжимка

В начале мы рассмотрели команды console.log() и window.alert() и поняли, что они не слишком удобны. Нужно было их часто использовать по всему коду, что могло сделать код «тяжелее» и медленнее, если бы мы забыли их удалить перед коммитом.

Когда количество строк растет, Chrome Developer Tools намного более эффективен для отлова багов и оценки работы в целом.

Дебажим Angular

Легче всего отладить код Angular — использовать Visual Studio Code (VS Code). Чтобы начать дебаггинг, вам нужно будет установить расширение Debugger для Chrome:

Точно так же, как и в DevTools, кликните на номер строки в app.component.ts. Строка с брейкпоинтом подсветится красным кружком (слева от номера строки).

Настраиваем дебаггер

Для начала, нам нужно будет настроить дебаггер:

1. С File Explorer перейдите на Debug вкладку.
Также можно использовать для этого Ctrl+Shift+D.

2. Кликните на иконку Settings чтобы создать launch.json.
Это файл с настройками, который мы будем использовать.

4. Запустите этот файл.

5. Чтобы использовать этот файл для наших целей, в методе url замените localhost порт с 8080 на 4200.

6. Сохраните изменения.

Вот как должен выглядеть файл:

7. Нажмите F5 или кликните кнопку Start Debugging чтобы запустить Debugger.

8. Запустите Chrome.

9. Чтобы приостановить выполнение кода на брейкпоинте, обновите страницу.

Чтобы последовательно просмотреть выполнение кода и как меняются переменные, используйте клавишу F10.

README

В расширении Debugger для Chrome есть множество дополнительных конфигураций, работа з source maps и устранений всяческих неполадок. Чтобы просмотреть их прямо в VS Code, кликните на расширение и выберите вкладку Details.

Отладка бекенда (Node.js)

Здесь вы узнаете как дебажить код на Node.js. Вот самые распространённые подходы:

• Используя Chrome DevTools
На даный момент, это наш любимый подход.

• Используя IDE-шки типаVisual Studio Code, Visual Studio, WebStorm, и т.д.

Для примеров мы будем использовать VS Code и Chrome DevTools.

Chrome и Node.js используют тот же JavaScript-движок, Google V8, и это значит, что для бекенда мы будем использовать те же инструменты, что и для фронта.

1. Запустите свой проект в VS Code.

2. Перейдите на вкладку Console.

4. Проигнорируйте предлагаемый “chrome-devtools://…” URL (существует метод получше).

5. Запустите Chrome и введите “about:inspect”.

Это перенаправит вас на вкладку Devices на DevTools.

6. Кликните линк Open dedicated DevTools for Node.

Процесс отладки такой же, как и для фронтенда, то есть с использованием брейкпоинтов. На самом деле, очень удобно то, что не нужно переключаться на IDE. Таким образом, можно дебажить и фронт- и бекенд на одном интерфейсе.

Спасибо за чтение и надеемся, что вам понравился этот пост. Подписывайтесь на обновления — у нас в рукавах еще полно полезностей 🙂

Источник

Кто как дебажит код?

Поделитесь как дебажите код? — вернее, как проверяете на корректность работы в целом — ну типа каждый блок, каждый кусок кода отдельно и сразу при написании, или не сразу но отдельно, если не сразу, то когда? — не важно, стратегию ли кодите или софт.

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

Дважды вычитываю каждый логически обособленный кусок кода (процедура, функция): первый раз — сразу по окончанию его написания, пока свежа в памяти вся логика и подразумеваемая функциональность, второй — когда заканчиваю работу над основной задачей, частью которой является данный блок — помогает против ошибок, когда скопипастил что-то, но поменял не все что нужно было.
Иногда практикую первый проход новой задачи делать в режиме пошагового исполнения с контролем значений, но, как правило, предпочитаю внимательно вычитывать код несколько раз (больше двух) — перерасход затраченного времени все равно окупается против ситуаций, когда просто пытаешься выявить, что же работает не так.

Раньше пробовал новые блоки тестить примерами, но это слишком долго, мне лень. Проще дать коду отлежаться длительное время, потом со свежим взглядом еще раз все осмотреть.

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

Бросайте дебажить, пишите юнит тесты.

тестирую в демо квике

написал часть — запустил — проверил-пишем дальше

практически к каждой строке коментарий

запись в файл выполнение каждой функции, максимум записей

пишу на луа для квика, вернее пытаюсь)

Replikant_mih, ну в чужой программе вообще тяжело разобраться (кстати коменты очень бы помогли), а если она написана коряво — то вообще нереально

думаю многие согласятся что написать свою легче чем разобраться в чужой)

Igr, Комменты пишу, помогает «возвращаться» в код после перерыва.

В своем конечно легче копаться — ну хотя если чужой написан профессионально и стройно, а свой коряво — то может проще будет в чужом))

Replikant_mih, ага, я только ради возвращения и пишу)

если к каждой строчке будет комент — то вполне возможно

Михаил, согласен, я далеко не профи

но я например пишу комент не только к своим функциям, но и к функциям обратного вызова, т.к. тупо забываю что именно какая делает, т.е. это не относится с качеству кода

Igr, проблема с комментариями, что при изменении кода вы должны менять комментарии, что часто забывают делать.

Все зависит от языка, где есть функции первого класса — переприсвойте плохое имя сторонней функции более вразумительному. Если такого синтекса в языке нет, то просто оберните вызов сторонней функции вызовом функции с понятным для вас именем. Или поставьте нормальную среду разработки, чтобы в один клик смотреть хлеп по сторонним функциям.

Михаил, пока не забывал

функция срабатывает, например, при изменении в стакане, её не переименовать, вот к ней комент и пишу

в Notepad++ пишу, не вижу разницы, что комент что хелп смотреть, с хелпом то наверное легче забыть подправить когда меняешь кода

Replikant_mih, есть несколько классических книг про подходы к программировани:
Code complete
Clean code
Refactoring: Improving the Design of Existing Code

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

В последнее время ошибки нахожу по принципу — «что-то тут такое странное какое-то, то так то сяк», а не «тут же блин вообще всё должно быть не так, почему оно так?»

ещё помогает на бумажечке всё продумать и описать словами.
потом сделать.

ошибки будут всё равно.

ПBМ, да, тема видимо, меня цепляет — поэтому не первый пост)).

Многие баги у меня чисто на лени, с массивом, допустим, работаю — написал код, думаю: а здесь надо > или >= чтоб все элементы пройти и за границы не выйти?? — аа, ладно, так сойдет, эксепшен выпадет — починю)), а похорошему надо бы досконально все такие моменты сразу прорабатывать.

Ну и да, на бумажке это штука полезная!

Replikant_mih, сойдёт. не, это не наш метод)

потом проблем может быть куда как больше, в разы из-за этой мелочи вроде как

Replikant_mih, да, однотипность, единый принцип написания, названия, всех функций хорошее дело, облегчает дальнейшую работу

на основе старой проги можно написать что то новое, то есть использовать однотипные функции

ИМХО, подход не совсем корректный. Писать простыню — это мы проходили давно. ) Сейчас я делаю так:

1. Делю задачи, которые код должен выполнить, на функции. Если сильно надо, то пишу класс или библиотеку (редкое явление).
2. Запускаю и дебажу отдельные функции.
3. Когда они работают нормально, как ожидается, то уже складываю их в последовательность.

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

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

Баланс и решение — ДРАКОН (гуглите, мощная тема). Сначала строю блок-схему кода, а потом его пишу. Благодаря процедурной логике ДРАКОНа сложно ошибиться в реализации. А уж если ошибки всплывают, то не нужно рефакторить весь код. Всплывают баги конкретные в конкретных местах. Таким образом экономится время, и разработка становится делом техники, а не творчества.

facevalue, Интересные идеи, спасибо, обдумаю.

Не знаю, как насчет дракона, а вот больше дробить функции и кажду отдельную проверять на корректность — такое, скорее всего, возьму на вооружение.

>> «разработка становится делом техники, а не творчества»

да, наверное, хотелось бы к такому прийти)

ну типа каждый блок, каждый кусок кода отдельно и сразу при написании, или не сразу но отдельно, если не сразу, то когда?

Каждую функцию отдельно и сразу при написании. Пока мысли по этой функции сидят в голове в «оперативной памяти», а не от’swap’ились на диск.

Проверять следует для разных наборов входных параметров, — таких, чтобы функция, в результате, прошла по всем своим веткам. Следует убедиться, что ветвление происходит правильно, и каждая ветка работает, как задумано.

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

Код самой функции также полезно подвергнуть анализу на тему — могут ли возникнуть бесконечные циклы и тому подобные безобразия.

Также неплохо проверить дизайн функции на наборы «нехороших» сочетаний значений входных параметров, например противоречивых, не имеющих смысла. Если таковые обнаруживаются, следует передизайнить функцию. Как минимум хотя бы на входе обработать эти ситуации и вернуть ошибку, если обнаруживается «нехорошее» сочетание.

Вообще, до 90% программирования — обработка ошибочных ситуаций (запрограммирование правильной реакции на них).

Лениться нельзя. Можно, разве, что, в качестве баловства. В программировании «лень» не прощается. Это как раз один из моментов, когда программирование положительно влияет на индивидуума.

А тесты не только полезны, но и вредны. Причём, вредны больше, чем полезны, ибо, с одной стороны, провоцируют ту же самую лень (ведь, кажется, что тесты отловят ошибку, если что, но это только так кажется), а, с другой стороны, покрытие тестами, как правило, весьма слабо, ибо доскональные тесты писать значительно ленивее, чем просто как следует отладить код.

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

Unworldly, Хороший комментарий не грех и анонсировать)). Мне нравится ваш подход — основательный — про ветвления, предельные значения и аналогичное — запомню.

Ну и идеи про то, что такой подход может привить правильную дисциплину — как трейдинг меня поменял — знаю, а сейчас осознал, что и программирование может).

Replikant_mih, да, ещё про разбивку на функции, хотя эта мысль уже неявно звучала, но не совсем чётко.

Каждая функция должна заниматься одним делом, выполнять только одну задачу. Если в функции делается несколько дел одновременно, такую функцию следует разбить на несколько.

Также функции должны, в основном, образовывать иерархическую структуру. Самые низкоуровневые функции, которые, в основном, обходятся самим языком и обращениями к системе, потом функции более верхнего уровня, которые используют низкоуровневые функции, далее, функции третьего уровня, которые используют для своей реализации функции второго уровня и так далее. «Перепрыгивать» через уровень следует стараться избегать (дизайн всей программы — не очень, если так не получается).

Ну, и, опять же, функция каждого уровня должна решать только одну задачу, это универсальное правило, от уровня не зависит.

Replikant_mih, в целом, да.

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

Если хочется более явно разграничить, можно использовать namespace’ы, если они есть в используемом языке. Классы в режиме namespace’ов тоже можно использовать, но это искусственно, уж лучше соответствующее именование, типа использования «префиксов» в именах.

Тут, скорее, модель «иерархии библиотек» в качестве упрощённого ООП подойдёт лучше. Каждая «библиотека» предоставляет набор функций (сервисов), или API. «Библиотека», которая находится над ней, пользуется этим набором сервисов, чтобы предоставить уже свой набор функций более высокого уровня и так далее. «Библиотека» может использовать не одну, а несколько «библиотек» уровнем ниже. Получается такой упрощённый ООП, это значительно проще с точки зрения обычного мышления.

Каждую «библиотеку» можно отладить отдельно, и это бывает удобно, поскольку каждая такая «библиотека», как правило, содержит набор логически связанных функций.

Разбивку исходной задачи на условные «библиотеки» можно выполнить сверху вниз: сначала главную задачу разбить на подзадачи. Эти подзадачи будут решаться функциями «библиотеки» (или нескольких «библиотек», если подзадачи явно распадаются на несколько разнородных групп) верхнего уровня. Далее, каждую подзадачу, в свою очередь также разбить на подзадачи… пока подзадачи не станут достаточно простыми, чтобы решаться с помощью функции, решающей одну простую задачу. Примерно таков алгоритм построения иерархии (сверху вниз).

Этот процесс многопроходный и итерационный, поскольку по мере разбивки начинают выясняться детали, которые были сразу не ясны на верхнем уровне, и которые требуют корректировки (а то и смены) дизайна программы. Но процесс полезный, поскольку разработчик, проходя его, начинает значительно лучше понимать, что и как будет происходить в разрабатываемой им программе.

Во время процесса разбивки также следует постоянно помнить и учитывать возможность возникновения ошибочных ситуаций и дизайнить их обработку тоже. Обработка ошибочных ситуаций должна быть запрограммирована явно.

Кстати, учёт ошибочных ситуаций может довольно сильно повлиять на дизайн всей программы…

Разбивка получается сверху вниз, а реализация и отладка — в обратном порядке.

Unworldly, спасибо за подробный ответ! 🙂 И предыдущие тоже).

C# — первый и единственный язык, который более или менее серьезно изучаю, поэтому хочется верить, что ООП я впитываю нативно). Namespae’ы их иерархия и в целом использование для организации это да, но все-таки мне важнее классы — я их активно использую, т.е. мне интересно как в классе все инкапсулируется и как в классе организовать иерархию.

По моим умозрительным выкладкам, правильная иерархия — делать часть полей типами классов (или как там правильней по говорить)) ) — т.е. если в классе 20 полей и ты понимаешь, что 5 из них описывают какую-то дополнительную сущность — вычленять в отдельный класс и будет 15 полей и 1 поле — объект класса. Соответственно, наверно, и методы этого объекта из 5-ти полей можно в нем инкапсулировать.

Допустим мы эти 20 полей разобьем на 3 класса и 5 полей простых типов данных — это уже мы внутренние простые логики этих 3-х классов засунем в эти классы, соответственно в самом объекте можно оставить только логики (функции) взаимодействия между этими объектами-полями — уже поинтересней, вроде). А вот классы (количество которых при таком подходе будет большим) уже можно иерархично раскидывать по нэймспэйсам.

Что-то интересное выкристализовывается).

Replikant_mih, в целом, верно, только вычленять лучше на этапе проектирования, а не по факту упирания в необходимость. Хотя, для тренировки, полезно и поупираться, чтобы начать чувствовать, когда, во что и что вычленять.

Классы по namespace’ам вряд ли придётся распихивать, достаточно самих классов.

Но с классами всё сложнее. Там не только агрегирование возможно, но и наследование. Опять же, доступ к полям/методам (private, protected, public), конструкция/деструкция, а раз — классы, то обязательно — исключения… Код должен быть безопасен с точки зрения возникновения исключений… И так далее. Стоит ли оно того, чтобы всем этим и не только этим овладевать для решения своих задач?

C# не знаю вообще, принципиально не доверяю Microsoft. И в C# могут быть свои дополнительные приколы.

Источник