Чему я научился во время своей первой стажировки по разработке программного обеспечения

chemu ya nauchilsya vo vremya svoej pervoj stazhirovki po razrabotke?v=1656573615

автор Вирад Чаван

0*IPx0r2K1gi55ZWAx

Я был студентом инженерного колледжа в Индии. После 3 с половиной лет академического изучения информатики у меня была возможность проверить свои знания в реальном мире через стажировку.

В этой статье я поделюсь своим опытом стажировки в Josh Software, Пуна, надеясь, что он пригодится другим студентам по ИТ и компьютерной инженерии, которые ищут стажировку.

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

К счастью, мне назначили живой проект, который базировался на Ruby on Rails, к чему я уже заинтересовался.

После того, как я изучил PHP и MySQL на 2-м году обучения, я создал базовую веб-программу, и все, что она делала – это некоторые операции CRUD (Создание, чтение, обновление, уничтожение). Я помню, как разговаривал с другом, у которого были подобные навыки, как и я, и сказал: «Даже мы можем создать Facebook теперь, когда знаем PHP и MySQL!»

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

Вот чему я научился во время стажировки во время работы над живым проектом.

Общие уроки

Масштаб имеет огромную разницу

1*SsdGma80xb-AXYYFbEle5A
  • Сколько пользователей собирается использовать программное обеспечение?
  • Сколько данных будет обработано?
  • Каково ожидаемое время ответа функции?

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

Работа с большой кодовой базой

Еще в колледже мы работали над проектами, которые имели около 15-20 файлов. Построенный менее чем через неделю, можно сделать весь проект понял через несколько часов.

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

Написание поддерживаемого кода

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

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

Это привело к зашифрованному коду, который однажды работал в то время. Но два дня спустя даже я не понял, почему я написал определенный фрагмент кода именно таким образом. И изменение какой-то части кода почти всегда нарушало другие части. ?

Ремонтопригодность кода легче распознать при его отсутствиинапример, когда что-то, что, по вашему мнению, должно занять час, заканчивается неделя.

Пользоваться системой контроля версий – правильно

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

Затем я узнал GitHub, но использовал его только как безопасное место для хранения своего кода. Я использовал настольное приложение GitHub, чтобы зафиксировать все изменения только в главной ветке. Я даже затруднялся использовать его через командную строку.

1*0o9GZUzXiNnI4poEvxvy8g

Сейчас не проходит ни дня, чтобы я не использовал Git. Это такой замечательный инструмент для совместного написания кода, распределенной разработки, разветвления новых функций, запросов на подъемник и т.д.

Вот небольшая статья о том, почему системы контроля версий замечательны!

Важность использования подхода к разработке, ориентированной на тестирование

Во время стажировки мне поручили работать над новой функцией, которая должна была быть добавлена ​​в основной проект.

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

Через несколько часов Rollbar, инструмент отчетности об ошибках в реальном времени, взорвался с рядом ошибок в нашем коде, развернутом в производство. Я проверил ошибки, и они, казалось, не связаны с тем, над чем я когда-либо работал.

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

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

Вот статья, чтобы понять, почему написание тестовых случаев важно.

Особенности Ruby on Rails/веб-разработка

Архитектура MVC

Еще в студенческие годы, когда я разрабатывал программы на PHP, я понятия не имел, что такое модель, представление и контроллер. Любой проект был настолько зашифрован, что я не мог найти, в каком файле была записана важная логика. HTML встроил PHP-скрипты в странных местах, и я разместил все файлы только в одной папке.

Затем я узнал о фреймворке Rails и познакомился с архитектурой MVC.

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

MVC действительно упрощает вещи и является важной частью многих основных фреймворков.

Работа с базами данных

За последние 6 месяцев я не написал прямого запроса в базу данных SQL. Однако я каждый день имею дело с базами данных, даже выполняю некоторые сложные операции. Это благодаря ORM (Object Relational Mapper), использующему Ruby On Rails.

ORM превращают объектно-ориентированный язык программирования, такой как Ruby, в жаргон базы данных, на котором можно выполнять операции. Это делает доступ к данным более переносимым и отвлеченным от необходимых запросов к базе данных, необходимых при манипулировании данными.

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

Написание/использование REST API (интерфейсы программного обеспечения)

API облегчает общение одной программы с другой.

API делает функциональные возможности некоторых других приложений легко доступными для нашей программы. Например, когда-то я разработал программу Road Trip Planner, которая использовала API Карт Google для показа разных мест на карте, которые пользователь мог посетить на определенном маршруте.

API также можно использовать для полного разделения интерфейса и бэк-энда. Например, мы можем написать бэк-энд как приложение Rails только для API, которое может использоваться веб-сайтом, приложением для Android/iOS или даже некоторыми приложениями сторонних разработчиков.

Использование ElasticSearch для поиска

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

Зачем нам это для поиска? Поскольку наличие миллионов записей в обычной базе данных может усложнить эффективный поиск.
С помощью Elasticsearch мы можем индексировать документы, необходимые для поиска, и он может выполнять запросы ко всем этим миллионам документов и возвращать точные результаты в доли секунды.

Elasticsearch имеет Restful API, благодаря которому очень легко запрашивать результаты поиска и получать результаты.

Вот учебник, который мне помог, и вот несколько случаев использования Elasticsearch.

Использование асинхронных/фоновых задач

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

Вот ссылка, объясняющая это лучше.

В Ruby On Rails я наткнулся на Sidekiq, позволяющий легко эффективно выполнять фоновые задания.

Спасибо, что прочли! Если вы нашли эту статью полезной, дайте мне несколько аплодисментов. ?

Впереди еще длинный путь!

Просмотрите мой профиль Github здесь.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *