Представляем C.S. Weekly - Манифест

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

Слоновые проекты.

Концы с концами.

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

За исключением того, что я не Харлан Миллс, и, скорее всего, вы тоже им не являетесь.

v0.0.99-alpha.10.3

Моя учетная запись Github полна амбициозных проектов, находящихся на ранней стадии разработки. Это и красиво, и стыдно. Код обычно хорошо документирован, и возможности Github используются в полной мере, но как мне показать другим свои возможности, когда все, что у меня есть, - это сложные монорепозитории?

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

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

Еще несколько функций.

Немного измените стиль.

Почти готово.

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

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

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

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

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

3 типа проектов

Если вы вспомните ту лекцию по разработке требований 101, которую вы пропустили, в мире разработки требований есть примерно три типа проектов:

  1. Кролик
  2. Лошадь
  3. Слон

Имейте в виду, что это не обязательно связано с размером проекта или базой кода. Скорее, размер зависит от процесса требований.

Обозначим основные отличия.

Кролик проекты

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

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

Для планирования следующего цикла итераций можно использовать проблемы Github, внутренние каналы Slack или даже общую офисную доску.

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

Конные Проекты

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

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

Вот два хорошо известных шаблона для самоуверенной версии документа требований, подходящей для корпоративной среды:

  • Шаблон Volere (pdf)
  • Шаблон IEEE (pdf)

Проекты Слонов

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

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

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

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

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

Управление хобби-проектами

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

Проекты кроликов

  • Уникальная особенность или набор связанных функций
  • анализ требований не нужен
  • Если проект будет развиваться с течением времени, в основном это делается для исправления ошибок / опечаток, обновления зависимостей и других подобных исправлений.
  • Планируемое время для завершения первоначального проекта находится в диапазоне 1–14 дней.

Конные проекты

  • Набор функций Rabbit
  • Минимальный дизайн (каркас и т. Д.) Или анализ требований полезны или необходимы
  • Набор функций может быть взломан одновременно некоторыми из ваших друзей в репозитории Github.
  • Планируемое время для завершения проекта находится в диапазоне 30–90 дней.

Проекты слонов

  • Есть мыслимые итерации, которые проект может пройти с самого начала (несколько основных / второстепенных версий).
  • Необходимы этапы анализа и проектирования
  • Может обрабатывать 1 или 2 таких проекта в год
  • Хотя они не могут быть рассчитаны на длительный срок, необходимо разработать стабильный API.

Эти определения проекта подразумевают следующий примерный годовой график:

  • ~ 1 основной фокус или новый слон проект в год. Сохранение предыдущего усилия.
  • ~ 4 лошади проекта в год
  • ~ 2–4 кролика проекта в месяц

Большинство из нас постоянно занимается проектами, связанными с лошадьми или слонами. Но с учетом этого графика мы будем участвовать примерно в 24–48 проектах с кроликами в год!

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

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

Code Something Weekly: манифест

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

Итак, я представляю Еженедельный манифест Code Something:

Исследовать. Расслабиться. Код. Писать.

Исследуйте

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

Была ли какая-то тема, которую вы изучали в школе, которая вам нравилась - даже в области, не связанной с информатикой?

Следите ли вы за кем-нибудь на YouTube или за письменными руководствами, такими как Hacker News?

Вы когда-нибудь занимались программированием или программировали в гольф?

Пришло время исследовать.

Расслабиться

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

Дыши.

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

Код

В этом сценарии нет неправильных ходов. Часть кода будет не совсем идеальной или немного отрывочной. Ничего страшного - поначалу ничто не бывает идеальным. Единственное, что вы можете сделать неправильно, - это нарушить правила кроличьего проекта. Сосредоточьтесь на нескольких функциях или одной функции.

Вот несколько идей

  • реализовать математическую концепцию, которую вы изучили в университете или колледже
  • переделать полностью или частично TODO MVC или аналогичную игрушку на новом языке или фреймворке.
  • попрактиковаться в некоторых алгоритмах - переписать их в своем собственном служебном классе или со своей собственной структурой данных
  • сделайте Adobe Photoshop, иллюстратор или учебник по созданию ресурсов другого поставщика (выходите за пределы кода, но в связанной области)
  • найдите в Документах MDN что-то, чего вы не знаете, и используйте это в упражнении.
  • повторно реализовать функцию, класс или модуль из проекта с открытым исходным кодом, за которым вы следите
  • (пере) прочитать главу книги (и выполнить 1 или 2 упражнения). Этот репозиторий содержит бесплатные PDF-файлы
  • создать простой интерфейс командной строки для решения общей задачи

По сути, представьте, что вы выполняете упражнение или задание из курса колледжа.

Напишите

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

Дело не в том, чтобы рассказать другим, насколько вы хороши, или составить идеальный учебник. Скорее, способность резюмировать и объяснять что-то является неотъемлемой частью обучения (см. Технику Фейнмана).

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

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

Удачного кодирования :)