Лорен Мендоза
Инженер-программист. Воздушная акробатка. Родилась и живу в Сан-Франциско.
Когда многие продукты являются, по существу, одним и тем же приложением с различными цветовыми схемами и кнопкой копирования, почему мы всё ещё программируем?
Файлы в вашем компьютере могут быть представлены различными способами. Средством, с помощью которого большинство людей находит свои файлы, является графический интерфейс, такой как, например, Mac Finder. Но можно сделать также всё то же самое, используя текстовый интерфейс, как, например, Terminal. Оба интерфейса представляют собой различные пути для моделирования одной и той же информации и взаимодействия с нею.
Сетевое приложение может быть представлено также многими способами: архитектурная схема, диалог, модель. Разработчики программного обеспечения обычно работают с кодом. Но является ли он наиболее интуитивно понятным и производительным подходом?
Вдохновляющая идея
Для создания электронной музыки я использовала программу, называемую Reason. Мне она нравится, поскольку она позволяет «перетаскивать» провода между различными устройствами и точно показывает, как всё там соединено. Для меня наглядно показываемые проводки имеют намного больше смысла, чем бесконечное нагромождение меню и выплывающих окон, которое господствовало в самом передовом ПО в 2000-ных. (Я тебя люблю, Adobe Flash CS3 Professional). Благодаря интерфейсу Reason я лучше понимаю, что делаю, и успеваю сделать намного больше музыки, чем флэш-роликов.
Нам нужно больше удовольствия
Я не знаю, когда или как это произошло, но в какой-то момент «IT-специалист» стал «разработчиком», который превратился в «инженера-программиста». Мне, конечно, нравится называться инженером, особенно после лишь трёх месяцев «образования». Но основная часть того, что мы делаем — не инженерная деятельность. Быть инженером означает заниматься решением новых проблем, глубоким продумыванием задач. Это, действительно, интеллектуальная деятельность.
На сегодня созданы уже тысячи CRUD-приложений. Мы уже решили эту проблему. Но по какой-то причине мы всё же продолжаем делать те же самые приложения, большей частью с нуля.
Если какая-то проблема была решена, то её решение должно быть использовано для других схожих задач. Набор инструкций передают какому-то рабочему или некоторому коллективу рабочих, чтобы воспроизводить конструкцию, как требуется. Мы не говорим каждому рабочему на автозаводе, чтобы он изготовил новый автомобиль с нуля. Вместо этого мы даём рабочим инструкции и делаем так, чтобы рабочие не могли что-то нарушить. Если инструкции настолько простые, что любой может следовать им, то имеет место низкооплачиваемая работа. Более того, её постепенно начинают выполнять роботы.
Инженеры должны решать новые и интересные задачи, а не воспроизводить одни и те же приложения снова и снова. Последнее — работа для роботов.
Тот же самый большой сайт, теперь с большим количеством CSS
Доказанный факт (вероятно), что, чем «оригинальнее» дизайн пользовательского интерфейса, тем меньше люди понимают, как его использовать. Неразумно повторно изобретать установившийся язык визуального общения. Интернет работал бы намного лучше, если бы мы договорились о некотором наборе общих элементов, а затем выражали бы наше мнение, комбинируя их. Стили должны генерировать себя на основе нескольких ключевых слов, таких как, например, «пусть будет металлический, чёрный и зловещий» или «пусть будет деловой, респектабельный и синий», «пусть будет хипповый, забавный и под Apple» или «пусть будет милый и привлекательный для мам». Категорически недопустимо вводить какой-то код, чтобы сдвинуть что-либо на 5 пикселей.
Проблемы значимости собственной личности
Написание текстов программ почитается многими как Святой Грааль разработки программного обеспечения. Настоящие инженеры пишут программы, говорят они, и именно написание программ и есть то, что делает вас великим инженером. Множество людей считает важным влияние собственной личности, индивидуальности на процесс написания текстов программ. Эти люди, скорее всего, нуждаются в консультации психолога, и я говорю это серьёзно. Я ощущаю, что становлюсь одной из таких персон.
Но знание замысловатого синтаксиса и «навыки кодирования» не делают вас хорошим инженером и тем более не делают вас умнее. Можно быть великим кодером и никаким инженером. Разработка лучших, быстрых, расширяемых, креативных способов решения реальных проблем людей — вот что ценно и что будет становиться всё более важным в ближайшие годы.
Написание текстов программ — исключительно глупое занятие
Написание текстов программ допускает опечатки. Более того, оно допускает неограниченную «креативность», также известную как типовые проблемы кода («запахи кода»). Основная масса кода сделана довольно плохо. Инженеры проводят бесчисленные часы, занимаясь синтаксисом, опечатками, структурированием расположения, проверками стиля оформления, ошибками, спорами по стилю и методам наиболее успешной практики, разработкой клавиш быстрого доступа, чтобы попытаться заставить какую-то часть кода печатать саму себя. Это — абсурд. И это — пустая трата времени.
Мы уже пришли
GraphQL устраняет внутренние маршруты и полностью заменит REST в ближайшие годы. Вы когда-либо задавались вопросом, почему нам нужен сервер, действующий как посредник между клиентом и базой данных? От этого следовало отказаться ещё вчера.
Algolia делает некоторый набор данных доступным для поиска. Я не знаю, как они делают это. Но я знаю точно, что компьютер дешевле и лучше оптимизирует структурированные данные, чем человек.
Мы должны просто направлять данные в какой-то набор, а базы данных должны организовывать и оптимизировать себя сами, используя машинное самообучение и другие модные штучки. Люди должны отойти от написания схем баз данных, потому что мы неизбежно делаем это неправильно. Разработка баз данных является оптимизационным алгоритмом, а не инженерной задачей.
Инженеры во всем мире пишут заново снова и снова такие функции как аутентификация, корзина, обмен сообщениями и бесчисленные другие, повсеместно используемые элементы. И многие из них, вероятно, воспринимают себя довольно крутыми при этом.
И это всего несколько примеров того, как инженеры напрасно тратят время, воспроизводя одни и те же базовые элементы снова и снова.
Решение
Менеджеры по продуктам, не зная, вообще, программирования, должны быть в состоянии просто заставить приложение делать то, что оно, как предполагается, должно делать. Единственное, что должна сделать компания, — создать элементы, делающие её поделку уникальной. Всё остальное было уже создано в других приложениях и должно быть лишь повторно использовано.
Что касается всего пыла и преданности вокруг открытого исходного кода, то большинство этих проектов сделано плохо, не сохраняется и не используется на уровне бизнеса. Компании «изобретают велосипеды» и дублируют сделанное.
Я сейчас хочу создать простой в использовании интерфейс, использующий «перетаскивание», в котором любой может создать полнофункциональное комплексное приложение без какого-либо программирования. Пока не знаю, как я буду делать это, но, скорее всего, я использую навыки работы с Adobe Flash CS3 Professional, упомянутым ранее. Шучу — я, вероятно, возьму React.
Преимущества
Компании экономически заинтересованы в снижении входного барьера для работ по разработке программного обеспечения, а также в уменьшении количества людей, которых требуется нанять для продвижения новых функций и демонстрации «роста». Если изготовление веб-приложений становится проще, то больше людей высвобождается для заполнения названных позиций, и зарплата снижается.
Полезно для инженерной культуры
Разработчики программного обеспечения имеют явно завышенную зарплату, и многие (как и я) считают, что имеют право на получаемые деньги и бонусы. На самом деле, эти разработчики не умнее или не лучше других типов рабочих. Со смертью программирования различие будет расти. Инженерная деятельность будет отражать остальную часть общества, а не очень малое и в социально-экономическом отношении исключительное подмножество людей.
«Moneyball» или «Человек, который изменил всё»
Вообще-то, «Moneyball» («Человек, который изменил всё») — это великолепный фильм. Я знаю, что он старый, но я просто смотрела его вчера вечером и всё пыталась связать сказанное выше с этим удивительным фильмом, но не смогла. И меня это ничуть не беспокоит.
Вы знаете, что ещё было бы неплохо?
Строительный материал в виртуальной реальности. Я только что купила кое-что, и это обман.
Комментарии (27)
AlexTest
01.07.2016 01:58+9инженеры напрасно тратят время, воспроизводя одни и те же базовые элементы снова и снова
По такой логике ДВС был придуман более 100 лет назад и крупносерийно использовался еще на Ford Model T, зачем этот базовый элемент совершенствовать?Единственное, что должна сделать компания, — создать элементы, делающие её поделку уникальной
По этой аналогии тот же Ford мог бы ставить однажды придуманный двигатель на все остальные авто и менять к примеру только кузов.
Для подобных дам движки Ford T, современной малолитражки и болида Формулы 1 ничем не отличаются — все делают одно и то же:
сжигают топливо и крутят трансмиссию, но на самом деле есть куча нюансов.
Точно также и в программировании вроде есть некие «базовые элементы» имеющие одинаковый функционал. Но в каждом конкретном проекте этот функционал реализуется разными способами просто потому, что предназначен для решения пусть и похожих, но разных задач. Вот и приходится их каждый раз «изобретать» заново.
Пока на рынке существует конкуренция между заказчиками, каждый из низ будет хотеть т.н. «базовые элементы» лучше чем у конкурентов.
А это значит, что всегда будут затребованы высококвалифицированные разработчики, которым, как бы этого не хотелось заказчикам, но придется платитьявно завышенную зарплату
т.к. типовые решения не дают никаких конкурентных преимуществ.
robert_ayrapetyan
01.07.2016 02:31+3>> Вы когда-либо задавались вопросом, почему нам нужен сервер, действующий как посредник между клиентом и базой данных? От этого следовало отказаться ещё вчера.
>> и многие (как и я) считают, что имеют право на получаемые деньги и бонусы
Ясно, человека лишили премии за внедрение «передовых идей» и он делится своей болью.
Posigrade
01.07.2016 02:52+4Девушка воду льет. Заголовок не соответствует содержанию. Мне наплевать на банальности и ереси, которые она высказала в столь объемном тексте (который я прочитал), поэтому содержание оставлю без особого внимания, а пройдусь заголовку и сделаю девушке антипиар путем выведения теории заговора из ее слов.
о заголовке:
>Прощай, программирование…
Заголовок говорит нам примерно следущее: Ассемблер появился и программисты в машкодах попрощались с программированием, С появился и программисты на асме попрощались с программированием, ..., typescript/purescript/coffeescript/etc появились и программисты на javascript попрощались с программированием.
Люди из лагеря «Прощай, программирование» умалчивают о том, что в этой сфере практически нет пределов роста, т.к. не пределов человеческим хотелкам. Каждый новый инструмент служит фундаментом для множества болееновых инструментов, построенных на его основе. Каждый год количество полезных и интересных штук, которые можно запрограммировать при помощи доступных на данный момент технологий в 2 раза вырастает. Вот когда всю вселенную запрограммируем или когда решим, что ничего полезного и интересного во вселенной больше не осталось или когда запреты/ограничения на программирование введут, то только тогда можно будет честно сказать «Прощай, программирование».
конспироложство:
>Люди должны отойти от написания схем баз данных, потому что мы неизбежно делаем это неправильно.
>инженеры напрасно тратят время, воспроизводя одни и те же базовые элементы снова и снова
если реально работающий инструмент будет, который на практике докажет, что он реально годен. Тогда люди им попользовавшись сами с удовольствием уйдут на новые фронтиры, а пока имхо девушке не следует говорить о том, чего люди должны делать. Т.к. от таких ее слов пахнет гуманитарщиной, лоббизмом и запретом на программирование (чего-то тянет меня сегодня на паранойю): некая корпорация боится утратить лидерство, поэтому заваливает всех своими бесплатными написателями схем баз данных, а законодатели принимают закон «о безопасности ПО», где прописано, что в продакшене запрешено использовать человеческий код т.к. он «неизбежно неправильный» и «возможно опасный».
Fesor
01.07.2016 02:59+4Заголовок не соответствует содержанию
Просто переводчик забил на смысл. Впрочем в последнее время на хабре это норма. В оригинале статья носит следующее название:
Coding Is Over
Что лучше перевести как "С Кодингом покончено!", а не "прощай программирование". Собственно вся статья несет одну простую мысль:
надо писать модули (если допустить что их количество ограничено, рано или поздно их все напишут), а приложения можно будет накликать в какой-нибудь мудрой примудрой програмке которую она собирается создать, хоть пока понятия не имеет как.
То есть статья делает выводы на ложных допущениях, которые к 80% задач хоть и применимы, но они и так уже решены (кучи CMS, конструкторы мобильных приложений, десктопных приложений, куча готовых сервисов). Но есть еще 20% которые формализовать так легко уже не выйдет.
Lain_13
01.07.2016 07:29+3Это примерно как те, кто считал, что наука уже знает всё и осталось изучить лишь сущие пустяки. В какой век ни ткни — везде такие были.
Чем меньше знаешь, тем меньше можешь осознать объём того, чего не знаешь.
Posigrade
05.07.2016 18:17+1>Coding Is Over
тоже имхо не вариант. И дело не в том, что она не знает как создать. Допустим появляется сервис, где быстро и правильно можно делать все, о чем заявлено. Магазинчик можно накликать за 10 минут. Юзеры кликают и складывают кубики, получают то, что хотели, хотят еще больше. Те, кто раньше не думал, тоже полезли кликать, одних магазинчиков юзерам мало, инструмент-то вышел удобный, глупо его только для магазинов использовать. Юзеры хотят делать новые вещи, они хотят самых разных кубиков. Все это порождает 100500 кодеров, которые клепают модули-кубики для юзеров. «Coding Is Over».
daiver19
01.07.2016 07:26+2По-видимому, Лорен за 3 месяца своего «образования» так и не узнала, что бывает что-то еще кроме фронтэнда и CRUD сайтецов, про фрэймворки тоже, видимо, не слышала. Про опечатки вообще смешно на фоне этих «проводков» и прочих ужасов графического программирования.
michael_vostrikov
01.07.2016 07:39+4Я сейчас хочу создать простой в использовании интерфейс, использующий «перетаскивание», в котором любой может создать полнофункциональное комплексное приложение без какого-либо программирования.
В сложных программах количество блоков, переключателей и связей между ними будет настолько большим, что это будет аналог языка программирования. В этом основная проблема таких рассуждений.Lain_13
01.07.2016 07:58Как-то занимался поддержкой одного проекта на Remedy (не то 6, не то 7). Это был ужас, состоящий на половину из ворк-эраундов для ограничений платформы и извращённой, вывернутой наизнанку логики, диктуемой самой платформой. Причём выписывать все IFы при помощи мышки было просто невероятно «удобно». Самые банальные задачи требовали часов кропотливой возни мышкой. А самое забавное было в том, что разобраться во всём этом нагромождении средствами самой платформы было вообще нереально и приходилось пользоваться сторонней (и тоже платной) утилитой, название которой запамятовал.
sshikov
02.07.2016 11:50+3Девушка вообще не программист. Она не понимает простой вещи — что софт развивается во времени. Что это развитие нужно отслеживать, чтобы понимать, какие именно проводки мы переключили, прежде чем оно перестало работать. Чтобы исправлять ошибки, и делать выводы.
И не понимает того, что во всех этих системах "без программирования", позволяющих таскать проводки мышкой, ничего этого делать нельзя. У этих картинок нет истории.
Более того — на эти грабли человечество уже наступало много-много раз. Она далеко не первая, и к сожалению не последняя.
Lain_13
01.07.2016 07:40+3Мне кажется или в этом интерфейсе с проводками может разобраться только:
* сумасшедший;
* автор (не знаю к какой из двух оставшихся групп он относится больше);
* человек, работавший с реальным оборудованием, которое данный интерфейс эмулирует.
?
Причём не факт, что последний не предпочёл бы блок-схему из необходимых эффектов вместо этой каши.
extempl
01.07.2016 07:49+1Ну, справедливости ради, оно вполне себе наглядно показывает, какой блок аппаратуры в какую прослойку включён. Да, то же самое можно представить в виде xml, например, переименовывая ID для
in{n}иoutаттрибутов, но это таки менее наглядно.
Ествественно, всё будет зависеть от сложности последовательности, надо сравнивать конкретные примеры.
Хотя вот предложенный вариант с блок-схемами тоже вполне себе ничего. Но это тоже от сложности зависит, как говорят о разных модных языках "глазу не за чтио зацепиться", так что в однотипных блок схемах может не хватать разных проводков и разного вида блоков, чего здесь, конечно, в явном избытке.
vlreshet
01.07.2016 09:24Очередной человек который считает что через несколько лет программирования как такового — не будет, и всё можно будет нащёлкать мышкой даже если ты менеджер. Так уже сейчас можно сделать отличную сайт-визитку на том же юкозе, и без единой строчки кода купить домен, поставить туда свой сайт, и радоваться. Но почему-то веб-студий которые клепают сайты-визитки меньше не стало.
bapewka
01.07.2016 10:57+2Building stuff in virtual reality. I just bought one of these and it’s dope.Строительный материал в виртуальной реальности. Я только что купила кое-что, и это обман.
Building stuff в данном контексте переводится как «делать вещи», а не «строительный материал».
Bought one of these and it's dope — переводится как «купила это(ссылка на HTC Vive), и это круто».
LukinB
01.07.2016 11:00От переводчика. Спасибо за корректировку. В тексте этой девушки, действительно, есть три места, которые завели меня и редактора в полный тупик (чрезвычайно редкая ситуация с переводами здесь). Вы показали одно из них.
dipsy
01.07.2016 11:34Сначала надо придумать единый универсальный язык программирования (ЕУЯП), который заменит все остальные, каждый из которых имеет свои очевидные недостатки, которые могут быть устранены в новом стандарте, это уже сильно упростит всем работу. И ещё желательно одну IDE, чтоб не переучиваться каждый раз.
java_lamer
01.07.2016 12:09+1Мне же не одному кажется, что это просто «спонсорский контент»?
Довольно часто на хабре можно встретить переводы подобных статей. Кричащий заголовок, чтобы привлечь побольше людей, автор, пытающийся открыть нам глаза и донести правду и самое главное, едва заметное упоминание какого-то сервиса\программы ( как правило со стандартной схемой подписки вида бесплатно | стартер | медиум | бизнес)
pyrk2142
03.07.2016 06:24+4Субъективно, отказ от базового понимания того, что ты используешь, ведет к большим потенциальным проблемам.
Наверное, «менеджеры по продуктам, не зная, вообще, программирования», могут собрать из кубиков интернет-магазин или очередной модный веб-сервис. Но в какой-то момент к ним придет специалист по информационной безопасности и скажет, что в комбинации из этих кубиков есть дыра. И менеджерам стоит молить всех богов, чтобы это произошло до взлома, а не после.
Приведу пример из недавней практики: одна чудесная компания решила создать не менее чудесный сервис, который обрабатывает ценные данные пользователей (по понятным причинам я не могу назвать компанию). Они собрали свой сервис всего из двух кубиков (один свой, другой — стороннего разработчика). И в кубике стороннего разработчика была обнаружена критическая уязвимость, которая позволяла получить полный доступ к данным всех клиентов. Но никто из сотрудников компании не может изменить код этого кубика, а разработчик не делает исправление для этой ветки.
Эта история звучит забавно, но именно такое мы будем видеть всюду, если программы и сервисы будут состоять из кучи кубиков, которые перетягивают и складывают менеджеры.
Ivan_83
«Algolia делает некоторый набор данных доступным для поиска. Я не знаю, как они делают это. Но я знаю точно, что компьютер дешевле и лучше оптимизирует структурированные данные, чем человек.» — В сад!
У тетки комп сам себя программирует, о чём с ней можно разговаривать.
А сама оно хочет программировать в лего — таская кубики мышкой.
Успехов.
yvm
Все так, с той лишь разницей, что она хочет создать эти кубики…
qw1
Которые до неё создавали десятки раз (список). Её бы подумать, почему ничего из созданного ранее не взлетело. Но пусть построит свои кубики, может что-то поймёт.