Dmitriy Azarov

Действительно ли гуглить плохо для разработчика?

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

Как снизить количество ошибок в разрабатываемом программном продукте?

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

Для более сложных, абстрактных задач, вроде векторного графического редактора следует изучить формальные методы разработки ПО. Это и всем известные шаблоны проектирования. Использование шаблона в нужном месте автоматически снижает количество ошибок. И, с другой стороны, формализованные и общепринятые алгоритмы и техники и принципы разработки (SOLID, DDD и другие).

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

При чем тут Google

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

Нет необходимости запомнить все

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

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

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

Меньше ошибок

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

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

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

  • 05 июн 2017
  • разработка, теория
0 комментариев
Ваш комментарий
адрес не будет опубликован
Текст