Советы начинающим программистам

      Комментарии к записи Советы начинающим программистам отключены

Главная Форумы Программирование Советы начинающим программистам

В этой теме 0 ответов, 1 участник, последнее обновление  Васильев Владимир Сергеевич 5 мес. назад.

  • Автор
    Сообщения
  • #3116

    Написано огромное число статей и книг о том, как правильно писать код — это множество материалов о чистом коде, среди которых выделяются «Совершенный код» Стива Макконнелла, «Чистый код» Роберта Мартина, «Рефакторинг. Улучшение существующего кода» Мартина Фаулера. Близки по теме книги по объектно-ориентированному дизайну, например «Объектно-ориентированный анализ и проектирование с примерами приложений» Градди Буча и материалы по шаблонам проектирования — «Приемы объектно-ориентированного проектирования. Паттерны проектирования» Эриха Гаммы. Вы можете почитать аннотации и наиболее интересные для меня моменты из этих книг: Книги по разработке ПО. Кстати, я также писал ранее по этим темам: «SOLID принципы. Рефакторинг«. В этой заметке описаны некоторые советы, которые обычно пропускают (т.к. они могут казаться очевидными), но очень важны, особенно начинающим разработчикам.

    Обработка ошибок

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

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

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

    Производительность и архитектура приложения

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

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

    Сиюминутная выгода

    Избегайте любых решений, дающих вам сиюминутное удобство, но заставляющих вас отступать от канонов. Например, глобальные сущности, нарушение инкапсуляции или «прыганье» по уровням абстракции, приведение вниз по иерархии, отмена константности, модификатор mutable, и так далее. Старайтесь решать задачи «как правильно», а не «как быстрее, лишь бы работало». И не вздумайте полагать, что «сейчас я сделаю как быстрее, а потом, когда все заработает, переделаю на „как надо“». Нет, вы обязательно что-нибудь упустите. Пишите правильно!

    Читайте статьи о чистом коде

    Обязательно прочитайте про принципы SOLID. Для совсем новичков очень важным является принцип единой ответственности (SRP), т.к. если они раньше не сталкивались с ООП, то, скорее всего, возлагают на один класс кучу разнородных обязанностей (это называется антипаттерном Божественный объект, God object) — отлаживать и тестировать такой код крайне сложно. Другие принципы показывают как сделать ваш код более гибким (удобным для доработки).

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

Для ответа в этой теме необходимо авторизоваться.