В программировании есть нечто большее, чем просто алгоритмы и структуры данных

В последнее время конкурентоспособные платформы программирования, такие как HackerRank / Leetcode, набирают популярность как среди разработчиков, так и среди рекрутеров. Это потрясающие платформы, которые предоставляют простой способ отработать общие алгоритмические проблемы и проблемы со структурой данных при подготовке к собеседованию (или чему-либо еще). Но оценка (и, что наиболее важно, подготовка) навыков разработки программного обеспечения на основе этих результатов неточна и не репрезентативна, как я сейчас объясню.

Пузырьковая сортировка, сортировка вставкой, сортировка слиянием, сортировка по куче, быстрая сортировка. Поиск в глубину, поиск в ширину, алгоритм Дейкстры, алгоритм Флойда. Вы потратили много часов на алгоритмы и структуры данных и все это знаете. Вы чувствуете себя уверенно и отлично справляетесь с собеседованием, решая все их оценки. Затем наступает первый день работы, вы открываете список задач и понимаете, что вам нужно исправить 2 ошибки CSS, провести рефакторинг модульного теста и добавить обработчик ошибок к вызову API. Там не было ни одной вашей подготовки, вы чувствуете себя перегруженным изучением огромной новой кодовой базы и медленно выгораете.

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

1. Чтение чужого кода

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

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

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

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

2. Читаемость

Хотя эта проблема тесно связана с предыдущим разделом, она настолько важна, что заслуживает отдельного рассмотрения. Проблема читабельности проявляется по мере того, как ваша кодовая база растет, и вы не можете сохранить ее единообразие и легкость для понимания. Вам нужно будет использовать такие принципы, как инкапсуляция, возможность повторного использования, KISS (Keep It Simple, Stupid) и DRY (Don’t Repeat Yourself).

Не существует универсального решения для создания читаемого кода. Вы можете улучшить это, (1) читая незнакомый код, (2) реорганизуя код снова и снова, пока все не поймут его. Также помните, что комментарии не являются лекарством от плохого кода: если вашему коду нужны комментарии для удобства чтения, с ним что-то не так.

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

3. Сотрудничество

Самостоятельно решать интересные вычислительные задачи - это весело, но не очень эффективно на рабочем месте. Это требует другого типа мышления, которому нельзя научить, его можно только научить. Кроме того, вам нужно быть уверенным в использовании таких инструментов, как Git, Jira, Slack или их альтернативы.

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

4. Мышление на основе общей картины

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

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

Как разработчик, вы постоянно принимаете решения, даже на начальном / младшем уровне. Он варьируется от как вызвать эту переменную и какой HTML-элемент использовать до какой облачный провайдер лучше всего подходит для наших нужд и какое приложение framework будет работать лучше всего. Независимо от его характера, разработчики должны осознавать последствия своих действий. Этот тип мышления можно развить, работая какое-то время над одним проектом, чтобы его хватило на столько, чтобы вы увидели все последствия своих первоначальных действий.

5. Безопасность

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

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

Заключительные примечания

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

Ресурсы