Стартап Инжиниринг 101

Рекомендации по разработке программного обеспечения для быстрорастущих стартапов.

«Двигайся быстро и ломай вещи» — это мантра, которую Facebook популяризировал на этапе своего роста. Если вы двигаетесь не так быстро, чтобы что-то ломалось, вы двигаетесь недостаточно быстро. Эту точку зрения разделяют многие стартапы, стремящиеся быстро адаптировать продукт к рынку. Но есть ли такая вещь, как слишком быстро?

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

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

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

Исходный код

  • Формат кода: используйте форматировщик кода (например, Черный) для вывода последовательно отформатированного кода. Это устраняет накладные расходы на нематериальные (но часто жаркие) обсуждения мелочей форматирования кода, таких как табуляция и пробелы, ширина отступов, одинарные и двойные кавычки и т. д. Использование средства форматирования кода означает, что разработчики могут писать код самостоятельно. style, но весь код, зарегистрированный в репозитории, автоматически переформатируется.
$ black
  • Для языков с импортированными модулями дополнительные инструменты, такие как isort, могут последовательно сортировать импорт.
$ isort --profile black
  • Линтер: используйте линтер (например, Flake8), чтобы предупредить о синтаксических ошибках и возможных ошибках. Существуют различные степени строгости, которые можно точно настроить, но пользователи обычно применяют принятый уровень строгости, например. разумным значением по умолчанию для Flake8 является:
$ flake8 --max-line-length=88 --extend-ignore=E203,E501
  • Проверка типов: используйте проверку типов (например, Mypy) с аннотациями типов для поиска ошибок, связанных с типами. Хотя Python является языком программирования с динамической типизацией, а это означает, что типы не нужно определять, аннотации типов создают код, который легче понять и поддерживать.
$ mypy
  • Контроль версий: используйте контроль версий (например, Git), чтобы гарантировать, что все файлы в одном изменении будут сгруппированы вместе в фиксации. Контроль версий позволяет разработчикам видеть, как изменяются файлы, что облегчает обмен знаниями, а также позволяет разработчикам автоматически откатывать изменения. Перед внесением изменений в кодовую базу рекомендуется иметь другого инженера для проверки кода. Это делается для корректности, понятности, одобрения и обмена знаниями.
    Перехватчик предварительной фиксации должен автоматически запускать средство форматирования кода, линтер, проверку типов и набор тестов перед фиксацией изменения в кодовой базе.
    Сообщения фиксации должны следовать определенному формату для ясности и согласованности. Сообщение о коммите должно быть в повелительном наклонении, писаться с заглавной буквы и не заканчиваться точкой, например Добавить отсев в линейный слой. Дополнительные сведения см. в разделе Как написать сообщение Git Commit.
    В науке о данных и машинном обучении используются блокноты Jupyter. Хотя записные книжки могут быть мощным инструментом для исследовательской работы, они представляют собой смесь текста, кода, мультимедийного вывода и метаданных, упакованных в формате JSON. Использование блокнотов может затруднить отслеживание изменений системой контроля версий. Распространенный способ обойти это — использовать плагин Jupytext для синхронизации записных книжек с файлами Python, чтобы только файлы Python проверялись в системе контроля версий. Выходные ячейки следует удалить, поскольку их можно восстановить из входных ячеек.

Документация

  • Документация в коде. Используйте комбинацию строк документации модуля, класса и функции/метода, а также блочные/встроенные комментарии.
    Строки документации – это строки, которые документируют модуль, класс, функцию или метод Python. Строка документации модуля описывает содержимое и использование модуля. Строка документации класса описывает класс и его атрибуты. Строка документации функции/метода состоит из описания функции/метода, ее параметров, возвращаемого значения и исключений, которые могут быть вызваны. HTML-документация может быть автоматически сгенерирована из согласованных строк документации с помощью такого инструмента, как Sphinx. Дополнительные сведения см. в разделе Комментарии и строки документации Руководства по стилю Google.
    Блочные и встроенные комментарии используются для объяснения сложных частей кода. Блочные комментарии объясняют сложные операции до того, как они произойдут, а встроенные комментарии объясняют неочевидные операции в конце строки.
  • Дизайн-документ: проектный документ — это оперативный документ, охватывающий текущий дизайн системы. Хороший проектный документ должен охватывать:
    – цели проектирования
    – стратегию внедрения
    – ключевые проектные решения с акцентом на компромиссы
    – альтернативные проекты с акцентом на плюсы и минусы
    – диаграмма архитектуры системы
    – диаграмма системного контекста
    – системные ограничения
    – методология нагрузочного тестирования

Тестирование

Автоматизированное тестирование позволяет быть уверенным в том, что код работает и соответствует задуманному дизайну. Выполнение всего набора тестов до того, как изменение будет зафиксировано в кодовой базе, гарантирует, что это изменение не нарушит какие-либо существующие функции. Существуют разные виды тестов:

  • Модульные тесты: тестирование каждого компонента системы по отдельности.
  • Системные тесты: проверка взаимодействия пользователя с системой.
  • Интеграционные тесты: проверьте, как взаимодействуют различные части системы.

Некоторые тесты, специфичные для моделей машинного обучения:

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

Первоначально опубликовано на сайте neuralswarm.com 1 августа 2022 г. Если вы хотите обсудить этот пост в блоге или любой другой технический вопрос, свяжитесь с Timothy Leung или вашим обычным контактным лицом в Neural Swarm.