Чтобы стать хорошим инженером-программистом, нужно время, усилия и отношение. Эти тщательно подобранные методологии и практики - основа успешного разработчика приложений. Они выведены пионерами и лучшими умами в области информатики и доказали свою эффективность разработчиками программного обеспечения по всему миру. Простое знание и ежедневное выполнение хотя бы некоторых из них уже улучшит вашу производительность и сделает вас более эффективным инженером-программистом.
Аббревиатуры
"СУХОЙ"
Не повторяйся. Это, безусловно, самая распространенная проблема, но ее легче всего обнаружить и исправить. Вы видели этот код где-нибудь еще? Вы видели эту структуру каталогов раньше? Разработайте мысленный триггер для обнаружения копируемых вещей в вашем коде. Остановитесь и подумайте, как можно лучше разместить этот кусок. Может быть, его можно перенести в функцию, в библиотеку?
Используйте вашу IDE и инструменты качества кода для обнаружения дубликатов в вашей кодовой базе. Научитесь замечать дубликаты. Используйте свой конвейер CI, чтобы выполнять эти проверки для вас при каждой фиксации.
"ЦЕЛОВАТЬ"
Делайте это просто, глупо. С самого начала ничего не создается надежного и сложного. Проекты всегда начинаются с простого и экономичного. И они становятся более сложными по мере взросления и добавления новых функций. Большинство систем работают лучше всего, если они остаются простыми, а не усложненными. Их легче понять и уместить в голове. Их легче отлаживать, тестировать и воспроизводить. Меньше движущихся частей, меньше вещей, которые ломаются. Быстрее делегировать, перебирать или переписывать с нуля.
Не все вещи достижимы с помощью простых систем, но начните с них и используйте их как общий подход ко всему, что вы делаете. В конце концов, мы неизбежно усложним наш код или дизайн по ходу проекта. Постарайтесь отложить этот момент.
"ТВЕРДЫЙ"
Для всех ваших объектно-ориентированных потребностей используйте это как основу для дизайна ваших объектов:
- Принцип единственной ответственности: у каждого класса должна быть только одна ответственность. У класса никогда не должно быть более одной причины для изменения. «Соберите воедино вещи, которые меняются по одним и тем же причинам. Разделяйте те вещи, которые меняются по разным причинам. »
- Принцип открытости-закрытости: программные объекты (классы, модули и т. д.) должны быть открыты для расширения, но закрыты для модификации. Подумайте о зеркальной камере: вы можете поменять линзы, чтобы расширить ее, но вы не можете изменить способ ее работы.
- Принцип подстановки Лискова: производные классы должны расширяться без замены функциональности старых классов. Дочерний класс можно использовать так же, как и его родительский, с предсказуемыми результатами. Windows расширяет свою предыдущую ОС новыми функциями и выпускает ее как новую версию ОС, но вы все равно можете использовать ее точно так же, как старую.
- Принцип разделения интерфейсов. Многие клиентские интерфейсы лучше, чем один интерфейс общего назначения. Ни один клиент не должен зависеть от методов, которые он не использует. Рассмотрим системы автопилота для самолетов, автомобилей и лодок.
- Принцип инверсии зависимостей: модули более высокого уровня не должны зависеть от модулей более низкого уровня. Конструкция экскаватора не зависит от навесного оборудования.
Методологии
"Худой"
Оптимизируйте людей, ресурсы, усилия и энергию организации для создания ценности для клиента. Вот его принципы:
Избавьтесь от ненужных затрат: пропустите функции или действия, которые сейчас не приносят пользы.
Повышение эффективности обучения: ускорение процесса сбора знаний. Получайте обратную связь быстрее. Попробуйте разные идеи с кодом и сборкой. Используйте короткие итерационные циклы. Часто синхронизируйтесь с клиентами.
Примите решение как можно позже: сначала помогите клиентам лучше понять их потребности. Откладывать важные обязательства. Решения, основанные на фактах, а не на предположениях.
Доставьте как можно быстрее: высоко ценится клиентами. Более быстрая доставка = более быстрая обратная связь. Более короткие итерации = лучшее обучение и общение.
Расширьте возможности команды: менеджеры поощряют прогресс, выявляют ошибки, устраняют препятствия. Не занимайтесь микроуправлением. Создавайте проекты вокруг мотивированных людей и доверяйте им выполнение работы.
Обеспечение целостности. Обеспечьте баланс между гибкостью, ремонтопригодностью, эффективностью и быстродействием системы. При необходимости отредактируйте код. Обеспечьте автоматическое тестирование.
Оптимизировать все: разбейте задачи. Стандартизируйте этапы разработки. «Думайте масштабно, действуйте мелко, быстро терпите поражение, быстро учитесь». Бережливое мышление в масштабах всего проекта. Совместно реализуйте все принципы бережливого производства. Оптимизируйте все сегменты, чтобы добиться максимальной эффективности.
12-факторное приложение
Это методология создания приложений «программное обеспечение как услуга». Эти передовые методы предназначены для создания приложений, обеспечивающих переносимость и отказоустойчивость при развертывании в Интернете.
Он основан на 12 «факторах»:
- База кода: должна быть ровно одна база кода для развернутой службы, причем база кода используется для многих развертываний. 12-факторное приложение хранит свой код в одной VCS и может быть развернуто в нескольких средах.
- Зависимости: должны быть объявлены все зависимости без явной зависимости от системных инструментов или библиотек. Новый разработчик должен иметь возможность клонировать репозиторий, запустить команду детерминированной сборки и немедленно начать разработку, для чего требуется только локальная установка среды выполнения языка программирования. Одним из примеров этого может быть использование команды curl.
- Конфигурация: конфигурация, которая различается в зависимости от развертывания, должна храниться в среде. Если код станет общедоступным прямо сейчас, он не должен подвергать риску никакие учетные данные. Код не должен знать, в какой среде он работает, или заботиться о ней.
- Вспомогательные службы. Все вспомогательные службы обрабатываются как подключенные ресурсы и подключаются и отключаются средой выполнения. База данных, шина сообщений, сторонний API - все обрабатываются через URL-адреса. Не делается различия, является ли ресурс локальным или удаленным. Развертывание с локального на производственное просто означало бы замену URL-адресов.
- Сборка, выпуск, запуск: конвейер доставки должен строго состоять из сборки, выпуска и запуска. Сборка - объедините код в развертываемый артефакт. Выпуск - комбинация артефакта сборки и конфигурации среды, готовая к немедленному выполнению в целевой среде. Выполнить - запускает выбранный выпуск в среде исполнения. Всегда должен генерироваться идентификатор выпуска, и должна быть возможность откатить развернутый выпуск назад.
- Процессы: приложения должны быть развернуты как один или несколько процессов без сохранения состояния с постоянными данными, хранящимися в резервной службе.
- Привязка порта: автономные службы должны становиться доступными для других служб через указанные порты.
- Параллелизм. Параллелизм обеспечивается за счет масштабирования отдельных процессов. Приложение никогда не должно демонизировать или записывать файлы PID, а должно полагаться на диспетчер процессов ОС. Горизонтально разделяемая природа 12-факторных процессов приложения без совместного использования ресурсов означает, что добавление большего количества параллелизма является простым и надежным.
- Возможность использования. Быстрый запуск и завершение работы рекомендуются для создания более надежной и отказоустойчивой системы. Минимизируйте время запуска. Завершение работы изящно.
- Соотношение разработчиков и продуктов: все среды должны быть как можно более похожими. Сопротивляется желанию использовать разные сервисы поддержки между разными разработками и производством. Стремитесь использовать одни и те же инструменты, запускайте приложение везде одинаково. Примером этого может быть запуск веб-сервера dev для локальной разработки, но запуск экземпляра веб-сервера nginx в производственной среде.
- Журналы: приложения должны создавать журналы в виде потоков событий и оставлять среду выполнения для агрегирования. Приложения никогда не должны пытаться записывать файлы журналов или управлять ими. Просто эхо регистрируется в потоке вывода.
- Процессы администрирования: любые необходимые административные задачи (например, миграция базы данных) должны храниться в системе контроля версий, упаковываться вместе с приложением и выполняться вместе с приложением.
Практики
Непрерывная интеграция: эта практика предполагает, что вы фиксируете код в общей основной ветке (главная / основная / магистральная, а не функциональная ветка) репозитория вашего проекта не реже одного раза в день. Каждая фиксация проверяется (стиль кода, модульное тестирование и т. Д.) Автоматизированным конвейером CI для максимально быстрого обнаружения проблем. Практика значительно снижает проблемы интеграции и позволяет команде быстрее разрабатывать связное программное обеспечение.
Непрерывная доставка: этот метод основан на автоматической подготовке развертываемого артефакта, который автоматически развертывается в промежуточной среде, где приложение может быть протестировано с помощью пользовательских приемочных тестов, тестов безопасности, нагрузочных тестов и другие. Практика гарантирует, что программное обеспечение может быть выпущено в любое время безопасно и надежно. Его можно обновить до непрерывного развертывания с автоматическим переводом в рабочую среду после прохождения всех тестов.
Будьте в курсе
Разработка программного обеспечения - это нестабильная область. Практики, методы, инструменты и языки постоянно меняются. Держать себя в курсе и быть в курсе - одна из вещей, которые вам нужно делать. Всегда есть вещи, которые нам не удалось извлечь из прошлого и недавние вещи, которые мы еще не усвоили.
- Thoughtworks Insights - По моему скромному мнению, это лучшее место, на которое стоит обратить внимание как разработчик.
- Hacker news - новостная лента основных технологий, стартапов и программирования.
- Meetup - (Если только не корона) Лучший способ потереть локти и посмотреть, что происходит в непосредственной близости.
- Суть - поиск фрагментов кода других разработчиков и / или их решений общих проблем.
- Прочтите книги - учитесь у лучших.
- Работайте над побочными проектами - иметь дневную работу по программированию - это здорово. Но вы можете дать себе преимущество, начав собственный проект.
—
Надеюсь, эта статья дала вам пищу для размышлений и направила вас на верный путь, как улучшить свои навыки. Конечно, это лишь верхушка айсберга. Это действительно кроличья нора, на изучение которой нужно потратить время и усилия в своем собственном темпе.
