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

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

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

Напишите тестовый код. Шутки в сторону. Я могу рассказать вам, как это работает для меня. Все всегда начинается с идеи. У меня есть представление о том, как решить проблему, как у интуиции. Итак, я начинаю создавать классы / функции, как план того, что у меня в голове. Но потом я останавливаюсь, я не реализую ничего конкретного, потому что в моем уме я имею представление о том, как мой код ведет себя, а не о том, как он реализован. Что я делаю дальше, так это пишу тест, который точно выражает мое представление о поведении кода. Теперь у вас есть кристально чистая, машиночитаемая оценка того, что у вас на уме. И снова вы придавали форму идее в своей голове. Другие люди лучше поймут, что у вас на уме, и машины смогут проверить, соответствует ли реализация, которая начинается с этого момента, ожиданиям. По сути, вы написали автоматическую оценку своей идеи, которая действительно ценна. Очень важно выполнять этот процесс во время появления идеи, а не через недели, дни или даже часы. Потому что ваша идея со временем расплывется даже для вас самих. Более того, я часто нахожу недостающие загадки своей концепции во время создания моего модульного теста, потому что теперь я вынужден точно записывать, как должен вести себя мой код.

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

  • Работайте только над тем, над чем вы должны работать.
  • Всегда знайте, над чем вы работаете.
  • Заблокируйте себя в ветке, посвященной исключительно тому, над чем вы работаете, и которая поможет вам не сбиться с пути.
  • Фиксируйте каждый раз, когда ваш код находится в рабочем состоянии.
  • Работайте над сообщениями коммитов. Постарайтесь выразить в точности то, что вы сделали. Если вы сделали много, ваше сообщение о фиксации станет длиннее. Используйте сообщение о фиксации в качестве метрики для измерения размера фиксации. Слишком длинные сообщения о фиксации указывают на то, что вам следует сократить циклы фиксации.

Вместе с необходимостью коротких циклов фиксации возникает потребность в коротких циклах слияния. Часто объединяйте свои ветки в основную ветку, иначе вы снова столкнетесь с расхождением кода и конфликтами слияния. Это влечет за собой короткие жизненные циклы веток, следовательно, ветвь не должна покрывать большие рабочие нагрузки. Обычно делаю ветку по выпуску. Решение проблемы не должно занимать больше одного-двух дней. Конечно, из этого правила есть исключения; если проблема занимает целую неделю или даже дольше, вам следует подумать о ее объединении, прежде чем она будет полностью завершена. Упростите переключение функций, если вы хотите объединить, но на самом деле скрыть реализуемую вами функцию от конечного пользователя.

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

  • Проведите тесты.
  • Стройте артефакты и контейнеры.
  • Публикуйте артефакты и контейнеры.
  • Разверните приложение.
  • Версии приращения.

Эти задачи можно так легко автоматизировать с помощью доступных сегодня инструментов. GitLab CI / CD похож на: «Что вы хотите, чтобы я делал с вашим кодом, когда кто-то совершает коммит?». Вы спрашиваете: «Хм, ну, давайте запустим мои тесты, которые я бы сделал в любом случае», поэтому GitLab такой: «А как вы обычно проводите тесты?» и вам нравится gradle test, а вам нравится GitLab:

image: gradle:5.4

stages:
  - test
test:
  stage: test
  script:
    - gradle test

Конечно, GitLab - лишь один из примеров. Я уверен, что все другие доступные инструменты снабжают вас такими же инструментами и качеством, поэтому используйте их. Мне часто говорили, что конвейер CI / CD бесполезен, пока он не проходит успешно. Это совершенно верно, но чаще всего это происходит из-за желания слишком сложных и слишком сложных задач, включенных в конвейер с самого начала. Начните с простого, например, с компиляции кода. Это очень мелкие вещи, которые могут оказаться очень ценными в долгосрочной перспективе, если они будут постоянно хорошо выполнять то, что должны делать. Как только у вас появится рабочий конвейер, вы можете приступить к его усовершенствованию, шаг за шагом. Добавьте такие вещи, как запуск модульных тестов и создание артефактов, а затем переходите к более сложным задачам, таким как запуск тестов пользовательского интерфейса или развертывание приложения. Если что-то не работает должным образом, вы всегда можете вернуться к старой конфигурации CI / CD, которая работала нормально.

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

Не будьте слишком радикальны с новыми идеями. Хотя я большой поклонник обучения и совершенствования, это не лучший вариант полностью заменять привычный опыт чем-то новым. Вы часто знаете о недостатках того, как вы решаете проблему прямо сейчас, но этот способ решения проблемы, по крайней мере, прошел достаточную проверку, чтобы его можно было фактически использовать. То же самое и с книгами; когда они выходят новыми, очень сложно выбрать ценные. Со временем нерелевантные книги исчезают, а действительно ценные остаются на рынке десятилетиями, веками, если не тысячелетиями! Новые идеи еще не получили подтверждения, это может легко попасть в ловушку, когда вы усугубляете ситуацию, а не улучшаете ее. Попробуйте найти середину между общим опытом и новыми идеями / знаниями. Дайте время пройти и подтвердите эту новую идею. Если ваши ожидания оправдаются, вы можете постоянно переходить к новой идее. Если нет, вы можете вернуться к старому подходу, не расстраиваясь из-за того, что ходите по кругу.

Документируйте так же, как вы кодируете. Все знают «зону», этот поток, в который иногда попадаешь при программировании. Строки кода буквально перетекают из вашего разума сквозь пальцы в компьютер. Вы не могли сказать, что делают отдельные строчки кода, но наверняка знаете, что все они вносят вклад в общую картину, которую вы представляете. Документация должна стать частью этого потока. Ваша система - это гораздо больше, чем просто код. Многие мыслительные процессы происходили, пока не возник код. Эти мыслительные процессы необходимы для понимания вашей системы. Вы можете подумать, что все можно сделать, посмотрев на код, но это сильное заблуждение. Неявная информация оставляет слишком много места для интерпретации. Соавторы могут интерпретировать вашу систему по-разному, что, как следствие, приведет к недопониманию. Лучший способ предотвратить недопонимание и получить согласие - сделать подразумеваемое явным. Называйте вещи своими именами. Напишите (или нарисуйте), что вы имели в виду. Это позволит другим подтвердить это или высказать свое мнение о другой интерпретации.

Думайте о своей системе как о чем-то, что (в любой момент) нужно подобрать, адаптировать и расширить как можно быстрее. Во время кодирования вам необходимо почувствовать, «что будет важным для понимания того, над чем я сейчас работаю?». У меня было много проектов, где я терпел неудачу. Так сложно отличить очевидную информацию от не столь очевидной. Когда вы в чем-то заняты, все кажется очевидным. Вернувшись через две недели или даже месяцы, вы поймете, что даже половина вещей не была настолько очевидной, как вы думали (что на самом деле является одной из лучших возможностей для обучения, чтобы улучшить ваше чувство того, «когда что-то задокументировать»). А теперь представьте, как другие соавторы относятся к вашей работе. Я начал переключаться на свою документацию так же часто, как переключаюсь между файлами в моем коде. Иногда только для того, чтобы изменить одно предложение. Документация должна расти, развиваться и подвергаться рефакторингу так же, как и код. В своей документации вы можете записать все, что нельзя выразить с помощью кода. Слова и изображения дают вам больше возможностей для выражения, тем самым заполняя недостающие головоломки, чтобы понять вашу систему. Я документирую следующие общие вещи:

  • Архитектурные подходы.
  • Обучение и устранение неполадок.
  • Лучшие практики, характерные для проекта.
  • Общие процедуры (сборка, развертывание и т. Д.)
  • Примеры использования, которые включают несколько частей вашей системы.
  • Рабочие процессы и процессы, которых следует придерживаться (например, запросы на слияние)

Самый простой и понятный способ начать документирование - это readme.md файл. Markdown позволяет выполнять простое форматирование текста, а файл readme можно отслеживать в вашей системе контроля версий (VCS). Кроме того, вы можете легко переключиться на readme в своей среде IDE. У каждого нового проекта, который я начинаю, есть файл readme с самого начала, даже если он пуст. По мере роста объема документации вики-система или несколько *.md файлов могут оказаться более удобными.

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

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

  1. Идея
  2. Изображения, рисунки
  3. Слова (естественный язык)
  4. Машиночитаемый код
  5. Математическая формула

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

  1. Поговорим об идее
  2. Нарисуйте идею
  3. Запишите идею
  4. Смоделируйте идею (например, с помощью UML)
  5. Запрограммируйте свою идею
  6. Выразите свою идею математически

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

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