Советы по Улучшению Ваших Навыков Разработки в .NET. Продолжение
Начало
Продолжение
5. Начните решать проблемы методом грубой силы
У вас может возникнуть соблазн найти наилучшее решение с первой попытки. Не забывайте, что вы разработчик ПО, как автор текста, постоянно улучшаете результат за счёт редактирования и многократных правок. Иногда я делаю эту ошибку, когда разрабатываю систему. Когда я пишу код, я сразу пытаюсь его рефакторить, чтобы он ощущался/выглядел лучше. Начните с написания кода полностью, а затем вы сможете сосредоточиться на переписывании того, что вам кажется неправильным.
Для этого нужно как можно быстрее найти способ решения проблемы «в лоб». И очень хорошо, если вы знаете, как сделать его лучше в будущем.
Почему стоит так делать? Это представляет собой простой метод решения вашей проблемы за счёт огромной мощности машины, выполняющей ваш алгоритм. Не важно, насколько быстро будет решена проблема или сколько ресурсов будет задействовано. Вы увидите, что лучше понимаете свою проблему, когда оцениваете некоторый уже имеющийся код. Не имеет значения, что он может выглядеть плохо.
Стремитесь добиться того, чтобы что-то работало в вашей ситуации. Тогда вы можете начать видеть недостатки в исходном решении. По мере углубления ваших знаний о структурах данных вы начнёте видеть шаблоны и понимать, какой из них лучше всего подходит для данной проблемной области. Постарайтесь быть максимально прагматичным, сохраняя при этом высококачественный код. Это включает:
- Легко понятные имена имя функций/методов.
- Документирование трудных для понимания частей алгоритма.
- Проверку аргументов на граничные случаи, прежде чем манипулировать ими.
- Наличие хотя бы одного теста для функции/метода. Чем их больше, тем легче будет убедиться, что код работает должным образом.
- Отсутствие «магических значений». Все подобные значения должны быть вынесены в правильно названные константы.
6. Несмотря на гибкость, List<T> не всегда будет лучшей коллекцией для использования
Изучение структур данных - это ключевой компонент, который поможет вам постоянно совершенствоваться. От вас всегда ждут, что вы понимаете, как всё работает под капотом. От вас требуется глубокое понимание кода и систем, которые вы разрабатываете или обслуживаете. Использование правильной структуры данных может быть разницей между быстро и медленно работающим алгоритмом. Как разработчик вы бы не хотели создать систему, которая не может обрабатывать большой объём данных из-за плохой реализации.
Современные языки, такие как C#, позволяют разработчикам безболезненно писать плохо продуманный код. Например, из коллекций можно всегда использовать только
List<T>. Почему это плохо? Отличный вопрос, особенно потому, что ваша IDE не предупреждает вас о том, что вы, вероятно, могли бы сделать лучше.List<T> или, точнее, динамические массивы и массивы в целом имеют множество различных реализаций в мире ПО. Ваши навыки разработки ПО выиграют, если вы узнаете о доступных вам вариантах. Но каждая структура данных имеет свои сильные и слабые стороны. Вы, как разработчик, должны знать о них и понимать, когда какую структуру данных лучше использовать.Возвращаясь к
List<T>. Он удобен, если вы не знаете заранее размер нужного вам массива. Но в нём нет никакой магии. Под капотом он выделяет всё тот же массив (по умолчанию из 4х элементов). Когда место в нём заканчивается, этот массив копируется в новый, в 2 раза больше. Это важно понимать, что вы будете выделять избыточную память для вашей коллекции данных, добавляя элементы, каждый раз, когда вы достигаете предела ёмкости коллекции. Если у вас есть возможность узнать размер коллекции в момент инициализации, лучше всего его предоставить.Продолжение следует…
Источник: https://kevinavignon.com/2020/12/23/guidelines-to-improve-your-software-design-skills-with-net-part-i/
Автор оригинала: Kevin Avignon