![]()
Miss Content
V.I.P. |
Зарегистрирован: 05.03.2010
Сообщений: 7881
|
Обратиться по нику
|
| Miss Content |
Ответить с цитатой | | |
|
Я В СВОЕЙ РАБОТЕ НИКОГДА НЕ ПОЛЬЗУЮСЬ СЛОВОМ «ПРОГРАММИСТ». Когда я обращаюсь к людям своей профессии, я всегда стараюсь называть их инженерами. Сугубо узкая формулировка «программист» — точно так же, как и «тестер», например, — плохо отражает специфику нашей профессии. И чем дальше, тем хуже эта формулировка работает.
Возьмём такой пример. В классическом понимании есть «программисты», «тестеры», «менеджеры проекта» и другие специализации. С точки зрения ролей это разделение имеет смысл, ведь исторически любое разделение труда возникало из-за того, что средства ведения труда требовали особых знаний. Грубо говоря, чтобы стать тестером, мне надо изучить определённые инструменты — как и инженеру, который разрабатывает под определённую платформу.
ПО МЕРЕ ТОГО КАК ТЕЧЁТ ВРЕМЯ, ПОРОГ ВХОДА СТАНОВИТСЯ НИЖЕ. Например, в Microsoft сейчас нет такой роли, как «тестер» — у них есть developer in test (Специалист, который пишет программы, тестирующие другие программы. — Прим. ред.). При этом всех людей, которые занимаются разработкой, называют инженерами программного обеспечения (software engineers), просто они задействованы в немного разных сферах. Сейчас освоить инструменты стало настолько просто, что границы между конкретными специализациями стираются. В будущем вряд ли останется разделение, скажем, на JavaScript-программиста, Python-программиста и .NET-программиста — как и разделение между фронтэндом и бэкэндом.
Правда, пока что остаётся проблема со средствами выражения. На фронтэнде есть только JavaScript, а на бэкэнде удобнее выбрать другой язык. Из этой мысли возник весь тренд с Node.js (Платформа, превращающая JavaScript из узкоспециализированного языка в язык общего назначения. — Прим. ред.). Благодаря этому упрощаются стандартизация и формирование команды, знание и экспертиза которой будут примерно равны. Да, у Node.js сейчас есть проблемы, но куда важнее, что мы получаем тот же набор инструментов во фронтэнде и бэкэнде.
ВСЁ ВАЖНЕЕ СТАНОВИТСЯ ПОНИМАНИЕ ТЕХНОЛОГИЧЕСКОГО СТЭКА — технологий, которые лежат в основе того, что использует человек. Встречаются люди, которые программируют на JavaScript, и на вопрос, как работает протокол TCP, они отвечают, что это слишком низкоуровневое и они не хотят с таким разбираться. Вот это страшно: исходя из моего опыта, понимание базовых принципов, которые лежат под тем, что ты используешь, очень важно. До поры до времени это может не сказываться, но, как правило, зашоренность в одной технологии не позволяет делать нормальные решения по всему технологическому стэку.
Вот пример того, что я имею в виду под технологическим стэком в случае с браузером. Есть JavaScript, есть представление о том, что такое HTML, протокол HTTP. JavaScript-программисту никуда от этого не деться, он должен его понимать — как и то, откуда взялись правила изоляции и кроссдоменной безопасности, как работает протокол SSL, как работает безопасность, основанная на сертификатах. Дальше, если мы идём в бэкэнд, то человек обязательно должен понимать организацию структур данных. В любом более-менее сложном приложении, когда речь заходит о визуальном отображении сложных структур данных, объединении таблиц и организации выборок, интерфейс и бэкэнд становятся непосредственно связаны. Очень сложно сделать эффективное приложение, если люди, которые делают интерфейс, не понимают хотя бы базовых проблем, о которых нужно думать в бэкэнде: шардинг, организация данных, структура запросов. И наоборот: очень сложно сделать правильный API в бэкэнде, правильно предусмотреть возможность шардинга и горизонтального масштабирования, если человек, который пишет бэкэнд, не понимает проблем, которые есть на фронтэнде.
Можно опускаться ниже — и долго говорить о том, что вы не хотите думать, как устроены процессы и потоки в операционной системе. Но, когда вы, например, выбираете, как запустить своё приложение в вебе, тут же возникает вопрос процессов против потоков: нужно понимать, чем они отличаются, плюсы и минусы, как это работает. Люди, которые не понимают этого, в какой-то момент упираются в потолок профессионального роста. Это происходит часто: людей, которые думают широко, системно и изучают новые области, всегда было мало. Можно всё время делать сайты одного и того же уровня, не задумываясь о сложных вещах, но сделать сайт с большим количеством клиентов и динамическим контентом — это принципиально другое. Часто этот шаг невозможно сделать, не построив у себя в голове фундамента базовых знаний. |
|
|
|
|
