Ошибки делают тебя лучше. 😎 Я работаю программистом с 2013 года и программистом-любителем с 2005 года. За свою карьеру я работал в 5 разных компаниях. (Включая 2 стартапа, 2 компании среднего размера и одну крупную). Этот список составлен на основе моего опыта. 👐

Запишите требования

Если вы можете записать требования, это поможет вам в дизайне. Убедитесь, что вы записали требования в электронном виде. (Wiki, Google Drive Doc, Confluence, Markdown в репозитории Git и т. Д.). Не потерять его. Делайте резервные копии.

  1. Получите рассмотрение требований старшим разработчиком, линейным менеджером и т. Д. Внесите необходимые изменения.
  2. Получите требования, рассмотренные клиентом. Сделайте необходимые изменения.
  3. После всех изменений убедитесь, что обе стороны и вы согласны.
  4. Требования должны быть задокументированы таким образом, чтобы охватить бизнес-аспекты программного обеспечения.
  5. Не думайте сейчас о технологиях. (Если вы считаете, что что-то невозможно, сообщите об этом высшему руководству и обратитесь за советом к старшим разработчикам.) Сообщите о своих опасениях как можно раньше.
  6. Задавайте много вопросов. Убедитесь, что вы спрашиваете, почему определенные действия выполняются?
  7. Используйте анализ существительного и глагола и / или карточки CRC, чтобы придумать классы, свойства и функции. (Перед проектированием разбейте большой проект на функциональность)

Я не говорю вам делать водопад. Выполните следующие действия для получения начальных требований и внесения любых изменений. 😀

Начать с тестов

Однажды мне сказали сделать POC (Proof of Concept) для определенного приложения. Поскольку мне сказали, что это просто POC, я не стал писать модульные или функциональные тесты. Если вы не следуете TDD, по крайней мере, добавьте несколько тестов после того, как вы написали функцию или класс. Я не говорю нет TDD. Пожалуйста, делайте TDD (разработка через тестирование)!

Я помню, как много думал о том, как добавить больше тестов в уже созданное приложение (которое использовало тот же базовый код, что и POC). 😕

Это плохая идея 👼, однако, если по какой-то причине вы не можете начать заново и преобразовываете плохо спроектированный POC в настоящее приложение. Сделайте это: создайте новый проект (следуйте этому руководству) и добавьте логику из POC в новый. Добавьте тесты перед добавлением логики из старого проекта. (По крайней мере, потом добавьте какой-нибудь тест.)

Используйте создателей / генераторов проектов

Есть хорошие создатели программных проектов, которые могут сгенерировать для вас необходимые файлы, классы и структуру каталогов. 😃

Альтернативой создателям проектов являются шаблоны проектов (что нормально, но не так хорошо, как генераторы проектов). Пример: create-response-app.

По моему опыту, приложение create-react-app помогло мне настроить тестовый проект, который я сделал за несколько секунд. Это была огромная долгосрочная ценность. Особенно команда yarn test. Просто работает. 🐥

Организуйте проект

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

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

Разбейте проект на части

Разбейте проект на более мелкие выполнимые части. Делайте выполнимые куски. Разрабатывайте отдельно как компоненты и вместе как целую систему. Здесь вам может потребоваться дать оценку времени.

Однако это будет во многом зависеть от SDLC (жизненного цикла разработки программного обеспечения) и крайнего срока. 😃 Всегда используйте буферы, когда указываете сроки. Не расслабляться, а хорошо работать. 👐

Сделайте его настраиваемым

Я видел, как несколько человек жестко кодировали IP-адреса, имена пользователей, пароли и т. Д. В скриптах. Вероятно, это угроза безопасности, и ее будет трудно поддерживать, поскольку код нужно постоянно менять. 😠

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

Используйте собственные имена

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

Красиво написанный код должен читаться как рецепт приготовления. Содержательный, правильно структурированный и вкусный. 😋

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

Начните с Dockerfile

Создайте Dockerfile, содержащий необходимые требования для проекта. Все тесты должны пройти после создания образа докера и запуска контейнера, созданного из образа. 😏

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

В зависимости от ваших требований их может быть несколько Dockerfile. (Или вам это вообще не понадобится)

Создать сценарий управления

Создайте сценарий управления для выполнения повторяющихся задач. Например, запуск тестов, создание образа докера, запуск тестов в контейнере докера, развертывание для тестирования, развертывание в производственной среде.

Если вы используете npm или yarn, вы можете добавить его в package.json. Для проектов python (Django и т. Д.) Вы можете создать файл manage.py.

Установка продолжает интеграцию (CI)

Установка продолжает интеграцию с самого начала. Это очень важно. Убедитесь, что это запланировано. Имейте длительные тесты, которые будут выполняться в ночное время. Итак, утром вы можете увидеть результаты. Используйте стандартные отраслевые и проверенные библиотеки для написания тестовых примеров. (Таким образом, их можно легко настроить с помощью CI). Убедитесь, что вы настроили покрытие кода и статический анализатор. 🌀

Было бы здорово, если бы все это можно было сделать одним нажатием кнопки. (По отдельности и вместе). Не забывайте про тесты производительности / стресс-тесты.

Используйте отличную среду IDE / редактор

Используйте IDE или редактор, который вам нравится, и настройте его так, как вам нравится.

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

TL; DR

  1. Напишите тесты.
  2. Пожалуйста, сделайте TDD!
  3. Попытайтесь правильно настроить POC. Сделайте его таким же хорошим, как производственное приложение, потому что ваш POC в конечном итоге может стать продуктом.
  4. Если вы не можете выполнить TDD, по крайней мере добавьте несколько тестов после добавления функции или класса.
  5. Документируйте требования, определяющие бизнес-аспекты.
  6. Храните документы с требованиями в надежном месте.
  7. Проверяйте требования клиентов, старших разработчиков и менеджеров.
  8. Поймите, почему все делается определенным образом. (Бизнес и развитие клиента)
  9. Используйте анализ существительного и глагола / карточки CRC для определения требований, чтобы разработать объектно-ориентированный дизайн.
  10. Сообщите о своих страхах как можно раньше.
  11. Используйте создателей проектов, например create-react-app.
  12. Много читайте и думайте, прежде чем придумывать структуру папок.
  13. Имейте логическое обоснование структуры папок.
  14. Разбейте проект на более мелкие задачи.
  15. Функциональность дизайна отдельно и вместе с системой в целом.
  16. Программное обеспечение должно быть настраиваемым. Однако не слишком много.
  17. Сделайте заметку о критических изменениях.
  18. Убедитесь, что имена файлов, имена классов, имена пакетов, имена служб, имена переменных можно легко понять.
  19. Избегайте венгерской записи. (Используйте его, если это абсолютно необходимо).
  20. Избегайте неясных сокращений.
  21. Есть dockerfile(s).
  22. Тесты должны проходить в докер-контейнере.
  23. Сценарий повторяющихся задач.
  24. Создайте manage.py похожий скрипт mange.
  25. Настройте CI для регрессионного тестирования.
  26. Настройте CI для статического анализа кода.
  27. Настройте CI для сбора покрытия кода. (Если вы будете следовать TDD, это будет 100%)
  28. Настройте CI для запуска тестов производительности.
  29. Настройте CI для запуска стресс-тестов.
  30. Используйте отличный IDE / редактор, который вам нравится.
  31. Используйте плагины статического анализатора для вашей IDE / Editor.
  32. Используйте плагины для проверки орфографии в своей среде IDE.

Здравствуйте, 👏. Моя учетная запись Github - https://github.com/JaDogg. Вы можете найти мой личный блог о Python 3 здесь.

Если у вас возникнут проблемы с этой историей, прокомментируйте или ответьте. 😺 Если я что-то пропущу, ответьте и дайте мне знать.