Я начинаю разбираться в разработке программного обеспечения, и я надеюсь, что у меня всегда будет ощущение, что есть так много всего, что нужно узнать, и я никогда не буду близок к тому, чтобы быть удовлетворенным тем, что я знаю по этому предмету.
Я могу заключить, что нет ничего лучше, чем написать много кода за короткое время (предпочтительно в продакшене).
Не поймите меня неправильно, выкладывать много кода за один день не всегда хорошо, но ощущение, что вы регулярно выкладываете много кода за короткое время, — это хорошо.
Гордость и самодостаточность, которые я испытываю, когда занимаюсь этим, являются единственной причиной, по которой я полюбил программирование, и я думаю, что человек заслуживает того, чтобы испытывать это чувство (почти) каждый день.
Я не знаю, так ли это естественно для всех, как для меня, но это должно быть мантрой во всех технических командах. Какие действия можно предпринять для достижения высокой пропускной способности кода и какие области замедляют работу?
Тогда просто продолжайте повторять эти вопросы все время и никогда не будете полностью удовлетворены тем, как вы работаете.
Гибкая разработка программного обеспечения слишком сложна, чтобы делать ее идеально, и всегда будет что-то, что нужно улучшить, независимо от навыков команды.
Какие вопросы обсудить и повторить затем? Из моего опыта у меня есть несколько, которые я считаю наиболее интересными!
Автоматизируем ли мы все, что можем автоматизировать?
Выполнение ручной работы, которую можно было бы автоматизировать, не мотивирует и разочаровывает. Когда я отправляю свой код, все, что можно проверить, должно быть проверено, а когда я нажму «слить», он должен быть развернут непосредственно в рабочей среде.
Пакеты обновления должны выполняться автоматически, когда это возможно, переводы в системе должны автоматически обновляться, все, что происходит в системе/организации, что немного интересно, должно отправляться в Slack или подобное.
Существует так много всего и, конечно же, много-много вещей, специфичных для каждой системы, но я чувствую, что мантра должна заключаться в том, что если мы сможем это автоматизировать (и сложность автоматизации не слишком рискованна) тогда мы, вероятно, должны автоматизировать это. Это сэкономит нам время и нервы в будущем.
Повторяем ли мы себя в нашей повседневной работе?
DRY — хорошо известная тема, и обсуждение никогда не должно прекращаться.
Мы постоянно повторяемся, и мы должны свести это к минимуму. Это немного зависит от того, используете ли вы структуру микросервиса или монолит, но цель всегда должна заключаться в том, чтобы не писать одну и ту же функциональность кода более одного раза.
Если есть структура микросервиса, мы должны приложить усилия к созданию потрясающего монорепозитория, в котором создание нового пакета настолько просто, что это не кажется препятствием для нашего прогресса.
Если множество сервисов имеют очень похожую структуру, нам следует создать пакет для настройки таких сервисов.
Настройка и развёртывание пустого работающего Микросервиса с базой данных не должно занимать более 30 минут, где-то рядом это ощущается как препятствие и разработчик может задаться вопросом, можно ли ужать функционал в существующем сервисе. Все, что кажется препятствием и немного сложным, должно быть оценено и исследовано, чтобы увидеть, может ли оно быть менее сложным.
Это стратегия, о которой должны постоянно помнить все разработчики, когда мы пишем. код, рецензирование кода и проведение ретроспективы.
Оптимизируем ли мы структуру нашего кода для повышения скорости?
Это, наверное, самый сложный и самый субъективный вопрос здесь, но все же очень важный.
Какие части системы кажутся наиболее сложными? Что можно сделать, чтобы было понятнее? Что можно сделать в новых сервисах, чтобы сделать их максимально простыми и удобными в работе?
Опять же, ни одна команда или ни одна команда не идеальны, всегда будут части системы, которые со временем станут более сложными, чем другие. Единственный способ предотвратить максимальное усложнение — обсудить это, подумать и не бояться менять на что-то более подходящее.
Но если вы думаете о новой внедряемой услуге/функции, есть некоторые вещи, которые я считаю важными (это, вероятно, немного субъективно):
- Пишите как можно более простой код, старайтесь писать длинное предложение с указанием пути выполнения.
Разбивайте свой код как можно больше и не оптимизируйте строки или производительность, если в этом нет необходимости, если код становится немного сложнее читать и понимать. Вы должны гордиться, если вы пишете код, который настолько легко читается, что новичку не составит труда его прочитать. - Следующая тема — это немного противоположная стратегия по сравнению с написанием простого кода, вы должны подумать о любых будущих вещах, которые можно было бы добавить к службе, и освободить место и функциональность для этого, не создавая просто еще один оператор if.
Это очень сложно, и нам нужно понять всю систему и продукт, чтобы иметь возможность принять правильное решение, но ощущение, когда вы прыгаете в новую кодовую базу, и кто-то уже подготовил для вас добавить новую функциональность является лучшим.
Как я уже сказал, это непросто, и всегда есть риск чрезмерной инженерии, но именно поэтому я сначала говорил о написании вещей простым способом. - Последняя тема по этому вопросу — тестирование; что можно сделать, чтобы максимально упростить написание самообъяснимого теста с очень высоким тестовым покрытием? Я думаю, что вам всегда нужно иметь в виду тестирование, когда вы пишете сервис.
Какую стратегию тестирования я использую при написании этой службы, а затем придерживаюсь этой стратегии через службу.
Существует несколько разных стратегий с разными подходами и недостатками, но важно то, что мы выбрали одну и придерживаемся ее в сервисе и, возможно, документируем, как и почему.
Если есть четкая стратегия и весь код следует этому шаблону, добавлять функциональность и тесты намного проще.
Чтобы реализовать стратегию, вам нужно создать или использовать хорошие инструменты для написания тестов. Весь код должен быть самоочевидным, включая тесты, но они также должны быть достаточно простыми для написания, чтобы обеспечить очень высокое покрытие тестами.
Как оптимизировать планирование?
Я не думаю, что есть так много людей, которые работают с программным обеспечением, они верят в строгий метод водопада и что метод Agile переоценен, при этом я действительно люблю планировать, я люблю иметь свободное время. долгосрочный план, менее свободный полудолгосрочный план и не такой свободный краткосрочный план.
Долгосрочные и полудолгосрочные планы больше относятся к менеджменту и специалистам по продукту и, возможно, к самым старшим разработчикам в области разработки, но я думаю, что важно, чтобы все разработчики имели четкое представление о том, что включает в себя план, чтобы иметь возможность всегда принимать правильные решения.
Интересная тема здесь — краткосрочное планирование и то, как это сделать, чтобы вы могли выпустить много отличного кода.
Мне очень нравится Scrum-процесс для этого, подготовка бэклога, предварительное планирование и планирование спринта, и именно в таком порядке.
Команда разработчиков решает, какие технические улучшения должны быть приоритетными, владелец продукта обсуждает с командой, что и сколько должно быть в спринте, и когда это установлено, можно выполнить планирование спринта.
Вот тут-то и возникает потребность писать много кода почти каждый день, потому что я думаю, что мы должны приложить много усилий к подробному планированию того, что команда должна делать и в каком порядке, и в эти дни, вероятно, не будет быть так много нажатия кода.
Если мы работаем с историями, я думаю, что к каждой истории нужно прикреплять пост с задачами, на выполнение которых у одного человека уходит не больше половины дня (РАЗДЕЛЯЙТЕ СЛИШКОМ БОЛЬШИЕ ЗАДАЧИ!).
В каждом посте должно быть указано, где и как, в каком порядке это нужно делать и какие задачи можно выполнять параллельно. вещи, которые нужно делать в очень четком порядке, и всегда есть что-то хорошо спланированное, что кто-то может вытащить из стека и начать работать.
Задачи тоже небольшие, поэтому возникает ощущение, что пишешь код хотя бы раз в день.
Последнее преимущество заключается в том, что команда и люди, работающие вокруг команды, получают очень хороший обзор прогресса и могут легче работать над долгосрочным и полудолгосрочным планом.
Цель состоит в том, чтобы никто никогда не чувствовал, что он не знает, что делать, потому что всегда есть что-то хорошо спланированное, что можно вытащить из стека. Это не означает, что вещи нельзя перепланировать, но я думаю, что цель состоит в том, чтобы планировать как можно более конкретно в планировании спринта, как в плане А.
Оптимизированы ли наши встречи?
Люди в целом не любят встречи, и я думаю, что это немного фальшиво, людям не нравятся встречи, на которых, по их мнению, они не могут внести свой вклад, или когда встреча слишком длинная, чтобы они не могли сосредоточиться.
Встречи всегда должны быть максимально упрощены, потому что в целом разработчики хотят вернуться и отправить отличный код в производство.
Чтобы сделать их упорядоченными, им необходимо убедиться, что все люди в команде вовлечены, собрание имеет четкую повестку дня, более длительные обсуждения между небольшой группой людей могут проводиться вне собрания и что команда оценивает все встречи и как они могут быть более эффективными и лучшими.
Совещание о том, как стать лучше на совещаниях, — это, на мой взгляд, самое лучшее совещание.
Встреча и структура встречи должны быть демократичными, но в долгосрочной перспективе я думаю, что если сделать их как можно короче и эффективнее, это ускорит все и сделает всех более счастливыми.
Заключение
Я думаю, что ключ к тому, чтобы быть счастливым разработчиком, который запускает много отличного кода в производство, — это всегда оценивать и повторять все.
Оцените все, что не приносит удовлетворения или кажется препятствием в вашем процессе, и обсудите с коллегами, как его улучшить.
Затем повторите новый способ ведения дел, и пока люди открыты и талантливы, процесс будет лучше.
У меня есть кое-что, что я считаю хорошей стратегией для достижения этой цели, но, эй, я работаю с этим всего 4 года, и я на 100% уверен, что через 4 года у меня будет другой взгляд на эту тему.
