Какие навыки необходимы хорошему разработчику

Всем привет. Меня зовут Владислав Фурдак, я .NET-техлид и работаю c платформой .NET около 10 лет. Ранее писал на DOU на темы карьеры, а также технические статьи: «Асинхронность в C#», «Эволюция .NET-стека», «Как стать Full Stack разработчиком».

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

Сетевое взаимодействие

Понимание компьютерных сетей

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

  1. Базовое представление про модель OSI, а также протоколы, которые имплементируют эти уровни:
    • IP — адресация, маски, маршрутизация;
    • TCP — сокеты и порты, для дебага можно использовать ping/telnet;
    • HTTP — передача текста по TCP, далее о нем будет подробней;
    • SSL — хендшейки, OpenSSL;
    • DNS — resolve доменных имен;
    • что такое NAT.
  2. Умение пользоваться Wireshark/tcpdump для дебага сетевых взаимодействий локально и удаленно.
  3. Понимание работы Proxy, VPN.
  4. SSL/TLS, сертификаты.
  5. Сетевые утилиты (Windows):
    • arp;
    • netstat;
    • ping;
    • traceroute/tracert.
  6. PuTTY.
  7. Firewalls.
  8. Понимание прикладных протоколов: SMTP, HTTP, SFTP, LDAP etc.

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

Для начала убедитесь, что прокси Charles открыл сокет локально, для этого используем netstat. Далее, что ваш телефон находится в локальной сети. Через утилиту arp (Windows), если уже были запросы. Либо же можно пропинговать IP-адрес телефона с ПК. Потом, если все хорошо, проверить, а доходят ли пакеты из роутера к ПК. Для этого используем Wireshark. Проблемы могут скрываться на любом из этапов прохождения пакетов. Либо что-то не так с приватностью сети и для нее настроены правила фаервола блокировать соединения, либо же ваш роутер работает в режиме «изоляции точки доступа».

Работа с HTTP

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

  • Умение работать с Chrome DevTools (или любым другим инструментом из браузера). Мне нравится скорость работы и возможности Chrome, также там можно заниматься профайлингом, выстраивать сложные правила отладки JS-кода, работать с контекстом из консоли и многое другое.
  • Fiddler/Charles или Mitmproxy на ваш выбор. Более продвинутый инструментарий для захвата трафика. Можно дебажить как веб, так и любые другие системы, работающие по HTTP. Полезными могут быть: отладка мобильных приложений, случаи, когда вы не успеваете посмотреть, что произошло, из-за быстрых перенаправлений в браузере, а также запись сессий.
  • Анализ мобильного трафика через локальную домашнюю сеть/через прямое подключение — опять-таки об отладке связи с устройствами.
  • Postman или аналогичный софт для автоматизации HTTP-запросов. В Postman можно настроить удобную систему быстрых смен окружений, добавить поддержку переменных в полях запроса, сохранять данные, упростить получение токена через запись его в контекст Postman, из которого можно пробросить в заголовки других запросов.
  • Curl — кроссплатформенная утилита для создания запросов любых протоколов прикладного уровня.

Хорошо знать техники клиент-серверного взаимодействия: AJAX, Comet, WebSockets.

Технологии браузеров:

Чтобы проектировать API своих приложений, стоит знать:

  • HTTP-протокол: заголовки и методы;
  • концепцию REST;
  • о существовании альтернатив для API, что построены на элементах REST, это gRPC, GraphQL, OData, устаревший JSON-RPC;
  • механизмы аутентификации и авторизации: cookies, basic authentication. Можно также упомянуть о JWT/Bearer токенах, хотя они и не являются частью HTTP-протокола.

Безопасность и уязвимости

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

Популярные возможные веб-уязвимости:

  • OWASP Top 10;
  • CORS. Если вкратце, механизм защиты веб-сайта от открытия под чужим доменом.

Кроме того, надо немного знать о хешировании MD5/SHA и ключах шифрования.

3rd party интеграции

Протоколы использования сторонних поставщиков аутентификации (Google, Facebook):

  • OAuth2;
  • OpenID Connect;
  • SAML.

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

Глубоко изучать протоколы не стоит, но общее понимание не помешает.

Архитектура

Паттерны проектирования

Сами по себе шаблоны проектирования несут несколько функций:

  • Это язык, который дает возможность одним разработчикам показать концепцию поведения другим разработчикам. При поиске решения первично само решение, а не попытка применить шаблоны проектирования в слепую.
  • Шаблоны показывают, каким образом можно решить типичные проблемы. Более того, дают этому решению имя (предыдущий пункт).
  • Любые шаблоны, архитектурные/имплементации являются выделением определенных ответственностей и их сегрегацией.

Можно выделить такие группы паттернов:

  • Паттерны GoF, довольно универсальные вне зависимости от языков. Вот хороший ресурс для их понимания.
  • Архитектурные паттерны, их много, и они специфичны для области применения и языка. Например, для UI-разработки это либо вариации MVC/MVP/MVVM, работающие на привязках данных, либо же FLUX-подобные, где поток данных однонаправленный.
  • Паттерны функционального программирования.

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

  • N-Layers;
  • модульная архитектура;
  • Onion, Hexagonal, Clean architecture;
  • DDD;
  • CQS/CQRS подходы;
  • Event-based архитектура;
  • Event Sourcing;
  • модель акторов;
  • паттерны построения Cloud-решений;
  • антипаттерны, показывающие, как делать не надо и что за это будет.

Принципы проектирования

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

Понимание инфраструктурных элементов архитектур распределенных систем

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

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

Однако следует заметить, что использование контейнеров часто необоснованно. Если приложение не 12-факторное, ему нечего делать в контейнере.

Можно выделить самые популярные элементы инфраструктуры для распределенных систем:

  • Очереди/брокеры сообщений (Queues, Message Brokers). Могут быть как отдельно установленными системами (RabbitMQ, Kafka, etc), так и предоставляться Cloud-провайдером, например Azure Service Bus.
  • Балансировщики нагрузки.
  • Логгеры, например cloud-agnostic ELK-стек, либо сервисы, специфичные для конкретного клауд-провайдера. Например, в Azure есть Application Insight. Однако бывает, что ELK-стек ест ресурсов больше, чем сам проект. Удовлетворительная безопасность есть только в платной версии.
  • Serverless functions. Куски кода, которые могут быть вызваны в определенное время либо по определенному поводу. Хостятся в инфраструктуре облака.

На самом деле любой Cloud-провайдер предоставляет уйму сервисов, которые дублируют функционал установленных вручную либо дают какой-то уникальный, перечислить их всех будет сложно.

Понимание масштабирования систем

Масштабирование — процесс увеличения возможности системы обслуживать большее количество запросов клиентов.

Существует две основных техники масштабирования: вертикальное и горизонтальное. Вертикальное — это наращивание мощности конкретного сервера, добавление CPU и памяти, в зависимости от потребностей. Горизонтальное — увеличение количества самих серверов/развертывания какого-то из типов контейнеров.

Инструментарий повышения производительности посредством потребления памяти или CPU:

  • Кеши второго уровня: Redis, Memcached.
  • Движки полнотекстового поиска: Lucene, Solr, Elastic Search.
  • Техники репликации: повышают устойчивость и доступность кластера.
  • Техники шардинга: это разнесение таблиц/коллекций на шарды по ключу шарда в разных базах. Повышает производительность запросов по данным в рамках части таблицы.

Базовое понимание развертывания систем

  • CI/CD Pipelines, декларативный стиль через написание кода скриптов деплоймента. Для этих целей используют популярный GitLab с его пайплайнами. Но, к примеру, в Azure есть альтернатива — Azure DevOps Service.
  • Контейнеризация, например Docker & Dockerfile, Docker Compose. Для разработчика часто достаточно знать основы Docker и уметь запустить контейнер.
  • IaaC-тулы: Terraform, ARM (Azure), CloudFormation (AWS). Это больше для инженеров в DevOps-практике.
  • Виртуальные машины, hypervisor.

Оркестрация контейнеров

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

Хотя это больше работа системных инженеров в DevOps, но все же вещи вроде Kubernetes (K8s) & Docker Swarm нужно понимать концептуально. K8s может быть развернут как в клауде (как сервис), так и on-premise, если есть такая необходимость с точки зрения compliance & legal.

Умение читать UML-диаграммы

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

Работа с данными

СУБД

Понимать, что существуют реляционные/нереляционные, документные, колоночные БД, базы данных на графах.

Для реляционных баз универсальное мерило хорошего дизайна — следование нормальным формам при проектировании. Чаще всего достаточно 3-й нормальной формы. Формальное определение может вас запутать, если вы не были знакомы с реляционной базой ранее, однако идея довольно простая: выделяй и разделяй.

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

Форматы передачи и хранения данных

Форматы, которые используют для написания конфигурации файлов, общения по HTTP, хранения данных:

  • XML;
  • JSON;
  • CSV;
  • BSON;
  • YAML;
  • WSDL (устаревший).

Форматы передачи, не предназначенные для чтения вручную:

  • Protobuf — передача данных по сети, по сути, быстрый бинарный сериализатор;
  • AMQP — формат сообщений для шин данных.

А также языки микроразметки:

  • BBCode;
  • Markdown.

Работа с ОС

Базовые знания по администрированию вашей системы

Сам работаю с Windows, но все то же самое применимо к Linux:

  • настройка сетей/устройств;
  • системный лог ошибок;
  • использование Perfmon или похожих средств для поиска утечек памяти;
  • для Linux может быть полезным знание Iptables.

Знание языка автоматизации работы с объектами операционной системы

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

Для Windows это либо batch-файлы (.bat, .cmd, .btm), либо PowerShell (.ps1). Для Linux — shell-скрипты (Bash). Также нужно уметь создавать юниты для systemd и понимать, как писать приложение, чтобы оно могло работать с systemd.

Полезно знать о существовании более продвинутых средств автоматизации управления состоянием системы:

  • Ansible;
  • Puppet;
  • Salt.

Понимание системного программирования

  1. Многозадачность:
    • вытесняющая;
    • кооперативная.
  2. Многопоточность и объекты синхронизации ядра:
    • мьютекс;
    • семафор;
    • спин-блокировка.
  3. Объекты синхронизации среды, более высокоуровневые:
    • монитор.
  4. Race condition.
  5. Асинхронность в разных контекстах исполнения.

Микроязыки

Работа и текстом:

  • Регулярные выражения (regular expressions, regexp). Используются для поиска заданного шаблона в тексте либо замены по шаблону. Поддерживаются практически всеми языками программирования.
  • Wildcards — более простая альтернатива регулярным выражениям, используется в основном для поиска файлов.

Работа с датами и временем:

  • Cron expressions — универсальный язык описания времени повторяющихся действий. Многие библиотеки, отвечающие за запуск регулярных действий, могут использовать cron-выражения в качестве параметра.

Работа с XML:

  • XPath — язык запросов элементов из XML-документов. Как частный случай — парсинг HTML. Последний раз я работал с ним, когда в системах вроде Sitecore/Umbraco необходимо было запрашивать элементы дерева контента, которое было представлено в виде XML.
  • XSLT — язык написание преобразований XML-документов. Сейчас встречается редко, внутри использует также XPath.
  • XQuery — более свежая альтернатива XSLT.
  • XSD — язык описания схем XML-документов.

Работа с контейнерами. Например, для Docker существует синтаксис Dockerfile, описывающий старт контейнера.

Работа с поиском информации. Нужно уметь пользоваться операторами поиска в Google для уточнения поисковых запросов. Также есть хорошая альтернатива гугловскому поисковику — DuckDuckGo. Имеет другие алгоритмы поиска и выдачи информации, дает немного иную поисковую выдачу. Здесь тоже есть операторы поиска.

В языках программирования и фреймворках можно обойтись и без знания микроязыков, но знать об их существовании стоит.

Информатика

Сложность алгоритмов и O-нотации

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

Максимум, что вам будет полезно для понимания сложностей алгоритмов работы со структурами данных, можно прочесть в оригинале Big-O Complexity Chart (есть на русском).

Структуры данных

Каждая структура данных создана в результате решения какой-то задачи оптимизации поиска либо хранения информации.

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

  • списки, массивы (List, Array);
  • связанные списки/двусвязные списки (Linked list/Doubly linked list);
  • множества (Set);
  • хеш-таблицы (Hash tables, Dictionary);
  • матрицы (Matrix);
  • бинарные деревья/бинарные деревья поиска (Binary tree/Binary search tree);
  • N-арные деревья (tree);
  • графы (Graph);
  • очереди (Queue);
  • стек (Stack);
  • дек (Deck);
  • кортежи (Tupple).

Полезно знать алгоритмы работы со структурами данных, в целом все они сводятся к таким:

  • обход структуры данных (например, для бинарного дерева это поиск в глубину и в ширину);
  • поиск и замена элементов в структуре данных;
  • приведение структуры данных к какому-то виду, своеобразные сортировки.

Стоит прочесть: «Алгоритмы и структуры данных в C#», 8 Common Data Structures every Programmer must know.

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

Базовые понятия дискретной математики

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

  • Множества, операции с множествами.
  • Предикат.
  • Булевы операции.
  • Идемпотентность.
  • Транзитивность.
  • Конечные автоматы (стейт-машины).

Организация разработки

Умение работать с текстовыми редакторами

Любые инструменты повышения производительности при работе с текстом. Например, во фронтенд-разработке есть плагины, помогающие писать верстку быстро, по ключевым словам. Для C# есть Rider/Resharper, позволяющий значительно ускорить тривиальные действия и навигацию по коду.

Умение работать с Git & Gitflow

Подсказка по Gitflow. Кроме базовых commit/pull/push/merge, можно освоить rebase, cherry pick, работу с сабмодулями.

Методологии тестирования

Можно выделить такие подходы к мануальному тестированию:

  • Smoke testing;
  • Sanity testing;
  • Regression testing.

Подходы к автоматизации тестирования:

  1. Unit Test и AAA-методология.
  2. Integration test (интеграционные тесты).
  3. UI-test (автотесты).

Методологии разработки

  • Гибкие методологии, построенные как следствие фундаментального Agile Manifesto.
  • Waterfall-методология, классика для построения сложных систем с заранее прописанными жесткими требованиями.
  • Экстремальное программирование. Одна из полезных техник — парное программирование. Вдвоем проще решать сложные задачи либо обмениваться опытом. Парное программирование может помочь новичкам начать быстро приносить ценность на проекте.

Понятие SDLC и его артефакты, такие как: SysRS, SRS, Traceability Matrix, матрица RACI.

Методологии оценки проектов

Предлагаю прочесть неплохую статью по общим принципам. Самой же техникой может быть, например, Scrum poker.

UI/UX

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

Фундаментальная книга по UX — «Интерфейс. Новые направления в проектировании компьютерных систем». Дает базовое понимание, как строить интерфейс машины для человека и какими принципами руководствоваться для его проектирования.

В заключение

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

Если у вас есть чем дополнить статью — не стесняйтесь, пишите в комментарии, буду благодарен.

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

С вопросами, пожеланиями или замечаниями пишите мне на фейсбук.

👍НравитсяПонравилось35
В избранноеВ избранном46
Подписаться на тему «разработка»
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


49 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Спасибо, интересная статья.
Добавил бы к скилам бекенд разработчика умение работать с инструментами:
nmap, socat, curl, openssl, burp suit, fiddler, wireshark, tcpdump, bmon, dig, traceroute, ping — анализ трафика;
process hacker, hxd, cff explorer, binwalk, dotpeek, dnspy, api monitor, ida pro, ghidra, olydbg, windbg — анализа процессов/либ/модификация либ/памяти;
wsl(cygwin)[ bash, grep, sed, git, mc + vim ] - навигация, редактирование файлов;
gimp, imagemagick, ffmpeg — анализ/редактирование/конвертирование картинок, видео;
qemu/kwm — поднятие вирт машин для тестирование third party либ/софта;
firejail/selinux, iptables, docker — sandboxing apps.

process hacker, hxd, cff explorer, binwalk, dotpeek, dnspy, api monitor, ida pro, ghidra, olydbg, windbg — анализа процессов/либ/модификация либ/памяти;
gimp, imagemagick, ffmpeg — анализ/редактирование/конвертирование картинок, видео;
qemu/kwm — поднятие вирт машин для тестирование third party либ/софта;

Да, без этого сейчас никуда=)

Знание этих утилит помогает не страдать потому что «комп виснет» и так невозможно работать или эта либа не работает так как написано в readme.txt.
Иногда приходится использовать еще сырые либы, которые пишут другие команды-порядчик, — без дизассемблера тут никак.
Посмотреть открытые хендлеры, че студия подвисает или какая из серверлесс функций стала непомерно съедать оперативку/процессорное время или банально какой процесс залочил либу в /bin директории или к каком ip делает запрос эта либа — для быстрого анализа тут поможет process hacker.
Бывает на больших проектах надо ставить очень много проприетарного софта, который не всегда работает на твоей машине, можно конечно переустановить ос(попросить новую виртуалку) в конце-концов потратить кучу времени на бюрократию, но если умеешь в дизассемблер и process api, process hacker, то такие проблемы чаще всего решаются в считанные минуты-часы.
Обнаружить супер глупые ошибки, напр. что первая буква из слова «сat» написана кириллицей или почему в файле табы вместо пробелов или проверить зашифрован ли файл в блобе или почему файл битый — поможет hxd.
Иногда для тестов надо конвертнуть пару десятков картинок, обрезать скомпоновать в гифку и т.д. — тут поможет imagemagic. Подготовить картинки для презентации — gimp.
Тестировать, запускать скрипты, проекты с гитхаба и third-party nuget пакеты на своей главной ос — непомерно глупо, для изоляции нужно использовать виртуалку/докер/firejail в зависимости от ситуации. Или если в проекте используется third-party либа, к которой ограниченное доверие.

не знаю большинство утилит из списка, комп не виснет. Что я делаю не так?

Эту статью можно рассматривать как некий роадмап

Це не стаття, а малограмотний пост, в який, як в великий сміттєвий контейнер запихали все ІТ-технології і навички, які з’явилися за останні 20 років.
У цьому пості була якась користь, якби тут була хронологія і можна було подивитися, як змінювався список потрібних технологій з 2000 року.
А так це схоже на чергову серію мильної опери. Подивився і забув через 10 хвилин, про що там була мова.

Спасибо за фитбек, буду рад новым комментариям.

у кого-то подгорело:):)
неужели от того что кто-то не знает половины написанного и ищет себе оправдания?

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

Умение пользоваться Wireshark/tcpdump для дебага сетевых взаимодействий локально и удаленно.

Ви серйозно?
Ви дійсно думаєте, що кандидата потрібно відправляти додому з співбесіди, якщо він цього не знає?

Нет, я этот список не для собеседований писал, а для личного пользования. Вы же верите в адекватность ?

но все же вещи вроде Kubernetes (K8s) & Docker Swarm нужно понимать концептуально.

Навіщо потрібно знати і те, і інше, якщо ці два проекти конкуренти, причому Docker Swarm фактично морально застарів і всюди замінений на Kubernetes?

docker swarm проще и легче. не везде нужен k8s. Я конечно не профильный инженер в DevOps, но часто от неопытности и амбиций люди используют технологии которые несут оверхед.

Полезно знать алгоритмы работы со структурами данных, в целом все они сводятся к таким:
обход структуры данных (например, для бинарного дерева это поиск в глубину и в ширину);
поиск и замена элементов в структуре данных;
приведение структуры данных к какому-то виду, своеобразные сортировки.

Я про все це чув і розповідав тільки на співбесідах, жодного разу в роботі це використовувати не доводилося, навіщо брехати, що це всім потрібно?

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

не «всем нужно», а просто .«нужно». каждый для себя сам решит. но иметь понимание что такие вещи существуют — точно не помешает.

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

Какие навыки необходимы хорошему разработчику

Так уже справді необхідно?
Ось список того, що я ніколи не використовував у своїх проектах/роботі, тому що не потрібно було, а проектів у мене було достатньо:
1) UI-test
2) матриці (Matrix);
3) XSLT — мова написання перетворень XML-документів.
4) Cron expressions
5) Ansible;
6) Puppet;
7) Salt
8) BBCode
9) BSON
10) Terraform

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

Какие навыки необходимы хорошему разработчику

Ви в своєму пості так і не вказали, все написане — це ваша думка, чи взято з інших джерел?
А це дуже важливо, тому що впливає на сприйняття посту.
Я наприклад, дуже сильно сумніваюся, що ви особисто знаєте хоча б половину з того, що написали.

Мое личное мнение. Я не говорю что по всем пунктам нужно прямо hands-on опыт иметь, но понимание обзорное не помешает.

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

тут дана здравая информация, из которой каждый делает свои выводы своей головой. не вижу причин оглядываться на «ваша думка чи взято з інших джерел».

Важко навіть уявити, скільки буде отримувати розробник, який все це знає

5-7к в украине, 100-200к в штатах

Не згоден.

Це для backend розробника. Слід уточнювати

Фронтендеру багато чого не треба, натомість знання UX, анімацій, роботи браузера, оптимізації куди більше знадобилися б (чого у вас нема)

(хоча сама підбірка гарна. Детально структуровано. Прям як я люблю)

и это требования на Джуна?

Не, это на годы самообразования. Тег junior не я ставил.

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

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

Хорошая техническая статья, спасибо.

Несколько замечаний\дополнений:

— WSDL — не язык для конфигурации \ хранения \ автоматизации или чего там. Просто язык описания веб-сервисов (апи по сути). Древний, как сопли мамонта

— По базам — классическое заблуждение всех backend-разработчиков, что главное — правильно спроектировать и по 3й нормальной форме. Много чего упущено, начиная от плана запроса и его элементов до того, какие объекты существуют в базе помимо таблиц. ORM vs SP. Трассировка запросов. Ну и главное — типы баз данных, точнее типы хранилищ ( OLTP vs OLAP), работа с репортингом, что такое ETL/ELT и зачем его едят

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

Как раз таки обьекты базы, OLAP/OLTP, Reporting, трассировка, план запроса, ELT/ETL применимы ко всем популярным СУБД

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

ну, планировщики в разных движках субд могут по-разному работать

Движок и на разных серверах, хостящих одну и ту же базу, может работать по-разному. Исходя из статистики, кардиналити и просто железа, настройки и тп.
Однако элементы плана запроса пракически во всех реляционных СУБД схожи. И их надо знать, равно как и способы влияния на построение плана.

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

Для того, чтобы дойти до ньюансов, надо знать основу. Сами эти обьекты

OLTP по-разному может работать,

Особенно когда на его базе без ETL строят репортинг :)

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

На самом деле проблема перформанса запросов встает перед переciчным NET Developer’ом гораздо чаще, чем конфигурация самых элементарных CI/CD.

Наконец-то хорошая техническая статья, читать которую можно долго и со вкусом :) автору респект и благодарочка! Продолжайте, пожалуйста, в том же духе. У вас получается!
Для большей наглядности по этой статье можно нарисовать майнд-карту. И ещё: гиту надо уделить намного больше времени чем вначале кажется.

Вместо Postman рекомендую попробовать Insomnia. В нем проще настраивать контекст/цепочки запросов, более качественная поддержка GraphQL, лучше интерфейс.

Спасибо, отличная статья! Я бы еще сделал больший акцент на изучение Linux и работы с консолью в частности. Освоив даже базовые команды Linux можно быстрее и эффективнее выполнять рутинные рабочие задачи.

я тоже в основном на windows работаю, но даже в windows уже есть и WSL и git-bash и встроенный openSsh, рекомендую попробовать в работе

Уже весь бекенд уходит в сторону Linux-based систем, включая мелкомягких. Конечно, если не используется Function As A Code / Serverless решения.

Если уж задели вопросы про паттерны, то не раскрыли полностью тему паттернов применительно для микросервисной архитектуры:
— BFF,
— шасси,
— наблюдаемости (логирования/журналирования, генерация исключений с нотификацией),
— gateway, etc.
Тему тестирования микросервисной архитектуры как-то вообще упустили. На пример пирамида тестирования (юнит/интегрейшен/компонент/сквозные). Какие в каком кейсе использовать.
И какие инструменты с ними использовать, на пример, для Java, как то:
— Cucumber,
— Gherkin.
На счет Lucene, если мне не зменяет память, то этот фреймворк лежит в основе Elasticsearch.

Хороший комментарий, спасибо.
Может быть добавлю,но тут смысл больше дать направления и топики, чем детализировать. «Elasticsearch is built over Lucene and provides a JSON based REST API to refer to Lucene features.», но бывает Lucene юзать и отдельно.

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

Тему тестирования микросервисной архитектуры как-то вообще упустили. На пример пирамида тестирования (юнит/интегрейшен/компонент/сквозные). Какие в каком кейсе использовать.

Это скорее для Архитектора кейсы.
Даже хорошему синьору они могут и не понадобиться.

почему мне тут видится переход на личности, а не конструктивная критика... галлюцинация наверное:)

Погодите, где именно? :)

Подписаться на комментарии