Alexander Ldov

Советую брать в основу десктопного макета разрешение типичного ноутбука (1360px) + вычитать полосу прокрутки (16–17px). В любом случае учитывать полосу прокрутки нужно обязательно, чтобы избежать проблем.

А ещё лучше, чтобы ваш макет умещался в рамках ~1320px, потому что некоторые шрифты на разных ОС и в разных браузерах могут иметь различный размер значений межбуквенного расстояния. К примеру, такая шняга есть у шрифта Circe: MacOS рендерит с большим межбуквенным расстоянием, чем Windows (и это в рамках одного браузера — Chrome).

P. S. Почему за основу именно типичный ноутбук? Потому что большинство больших мониторов имеет оное разрешение, в т. ч. куча недорогих мониторов по 22 дюйма и подобные им. Лучше, конечно, продумать макеты и на разрешения выше (к примеру, 1360–1600, 1601–1920, 1921–2560). Ну и так далее. Всё зависит от дизайна.

скроллбар учитывается

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

Например, возьмем пример разных мониторов, при условии что контентная область 1170px.
1920px
1366px
1240px

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

Пример:

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

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

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

На самом деле нет каких-то зафиксированных принципиальных характеристик, которые присущи только EA. По-этому, в разговорной речи понятие "энтерпрайз" может значить весьма разные вещи. С одной стороны энтерпрайз - не про увлечение модой с переписыванием всего, как только появится новый тренд. Ибо это _дорого_, так как цена ошибки дорога. С другой стороны - совсем не обязательно, что это 20-летние технологии. Конкретный бизнес сам для себя выбирает модели развития и обновления стека технологий. С одной стороны - это сложность ПО, бизнес-логики. С другой - сложность понятие весьма относительное.

Но если все же пытаться выделить какие-то характерные черты, я бы назвал несколько:
* устойчивость к трендам (использование их, когда они пройдут стадию моды и перейдут к стадии заинтересованности крупными игроками, ибо никому не нужны технологии, которые через год умрут и их поддержка будет дорожать каждый день).
* сложная и непостоянная бизнес-логика, давление на нее из множества источников
* результат сложной переменчивой бизнес-логики в совокупности с длительным использованием продукта приводит к целям снижения стоимости поддержки за счет стоимости первоначальной разработки, производительности и потребляемых ресурсов. ООП, SOLID, Unit Test/TDD, DDD - все эти популярные буквы - последствия "энтерпрайза", когда мы готовы серьезно подходить к написанию кода для облегчения его последующего изменения.
* слабо заметный вклад конкретного программиста, проистекает из сложности ПО

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

По-этому, стоит рассматривать не энтерпрайз/не энтерпрайз, а конкретные компании с конкретными требованиями и циклами разработки.