1. История первая: воспоминание
Когда я был маленьким и ходил еще в младшую школу, со мной приключилась такая история. На перемене я с несколькими друзьями находился в классе, когда с полки сам собой упал цветок. На нашу беду тут же вошла наша учительница и безо всяких разбирательств обвинила нас в хулиганстве. Красной ручкой были сделаны записи о плохом поведении в дневник, вызваны родители. Это было так обидно и не понятно, что навсегда врезалось мне в память. С тех пор я часто размышлял, что же заставило цветок упасть?
А ведь самое логичное объяснение — он сам упал. Просто он рос, выбрасывал новые побеги, развивал и наращивал массу. Тянулся к солнцу. Однажды проекция центра тяжести цветка вышла за пределы опоры и он опрокинулся.
Не знаю, зачем я это все пишу. Возможно меланхолия пришла вместе с осенью и желтыми листьями. Иногда мне кажется, что наука программирования так стремительно развивается, так идет вперед семимильными шагами, так быстро создает новые технологии, что однажды человек не сможет все это обуздать.
2. История вторая: программисты не знают точно, как работают их программы
Я довольно хорошо помню свою первую программу за которую мне заплатили деньги. Было это очень давно. В те стародревние времена компьютеров как таковых у нас в стране еще не было. По крайней мере они были очень большой редкостью. Некая коммерческая организация, а тогда такие организации назывались «кооператив», затеяла собственное производство компьютеров.
Это был улучшенный клон компьютера «Специалист» на базе 580-го процессора. Предполагалось создать полностью свое ПО для этого компьютера. Первый этап — написание БИОС. Ну а я делал для БИОСа самую первую процедуру: тест ОЗУ. Пикантность ситуации была в том, что производимый компьютер был настолько не надежен, что для процедуры теста ОЗУ нельзя было использовать временные переменные в памяти, нельзя ничего хранить в этом самом ОЗУ пока оно не протестировано. Ну это в общем логично, конечно. Однако, как можно было написать тест памяти имея всего навсего восьми битный аккумулятор A и еще шесть восьми битных регистров общего назначения B, C, D, E, H и L? При этом тест должен на графическом экране в правом верхнем углу писать сколько памяти протестировано: 8 Кб, 16 Кб, 24 Кб… Делал я эту программу долго, наверное два или три дня. Написал, получилось кажется до сотни строк ассемблерного кода, проверил и, гордый своей работой, сохранил программу на магнитную ленту. Пришел сдавать-показывать работу, а магнитная лента не читается на магнитофоне. Ну что делать: тут же в офисе на рабочем «Специалисте» по памяти (!) весь код заново набрал, запустили, проверили — ура! работает! Получил кажется рублей 30 за работу. Большие деньги.
В те очень далекие времена я в своей программе понимал АБСОЛЮТНО ВСЕ.
С тех пор, так получилось, я писал программы на ассемблере процессоров 6502, Z80, x86. Потом заболел языком Forth. Кое что получалось на FoxPro. Потом настала пора C/C++. Говорили, кто поймет MFC, тот вообще специалист высшего класса. Выучил-освоил MFC. Писал драйвера для Windows 2000/XP/w7 и для Linux. Нужно было делать сайт для компании — участвовал: html, css, js, php. Еще немного микроконтроллеров: Atmel, STM32, еще x86: MMX/SSE. Еще немного C/C++: нужен boost? нужен QT? ну ладно берем boost, берем QT. Ага… попутно где-то кому-то делаю программу для планшета Android (Java+JNI+cpp) в Eclipse, и еще собираю систему на кристалле в ПЛИС Altera — тут уже язык Verilog, тестбенчи и прочие хардверные радости.
И знаете что? Я уже не уверен, что полностью понимаю как работают все эти системы, программы, алгоритмы. От былой уверенности уже нет и следа. По моим подсчетам в год приходилось и приходится изучать, знакомиться и использовать до 2-3 новых технологий, сред программирования, библиотек и языков. При этом, конечно, нет никакой уверенности, что все знаешь и все понимаешь. На самом деле понимаешь только базовые принципы…
Более того, если когда-то, лет пять назад, я думал, что я знаю, люблю и понимаю c++, то теперь, уже с приходом новых стандартов типа c++11, с++14/17, мне приходится действительно тяжко. Мои коллеги исправляют мой код заменяя мои типизированные переменные на тип auto… И что? Неужели после этого код становится действительно более читаемым? Или вот еще не очень свежая новость: нежелательно использовать наследование, но предпочтительно использовать темплейты. И мне грустно. Я не люблю темплейты.
Я бы вероятно совсем впал в уныние, однако, в частных разговорах с другими программистами за чашечкой коньяка вдруг выясняется, что не только у меня такие проблемы, не один я такой отсталый (хотя не все в этом сразу признаются, зависит от размера чашки). Многие так же, как и я, не до конца понимают чужой код, не до конца понимают как работает вся наша система целиком, не знают, какие сторонние библиотеки мы уже подключили и используем, не понимают откуда в нашей не очень сложной программе 67 потоков и почему она занимает в памяти 350 мегабайт.
Более всего в этой истории с высокоуровневым программированием меня тревожит «эффект магической строки». Этот термин я сам недавно придумал. Речь не о багах, которые конечно были, есть и будут. Речь об одной строке кода, которая принципиально меняет свойства программы.
Например, пишем программу с использованием библиотек QT. У нас есть наш собственный класс, унаследованный от QGraphicsView. Мы используем наш класс, размещаем на нем QGraphicsScene, добавляем всякие QGraphicsItem и живем долго и счастливо, но медленно. Потом вставляем в код одну магическую строку:
QGLWidget* gl = new QGLWidget(); this->setViewport(gl);И вот уже наше приложение зашевелилось и вообще стало довольно шустрым, ведь теперь оно использует для отрисовки графики аппаратное ускорение OpenGL.
— Эй! Коллега программист! Ты знаешь, что такое OpenGL?
— Слышал, но никогда не использовал.
— Я то же. Но теперь мы используем его и это работает! Смотри как хорошо стало!
— Ура! А ведь всего лишь одна строка кода… ну и две-три дополнительных DLL в инсталляторе.
Проходит неделя или две. Слушайте, чего-то как-то не очень. Какие-то проблемы с медиа плеером и QGraphicsVideoItem… Надо что-то с этим сделать… Еще неделя и появляется еще одна магическая строчка:
QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);— Эй! Коллега программист! Это что еще за хрень?
— Ну… я не знаю точно, но вроде бы после этого используется режим трансляции запросов OpenGL в DirectX (Angle) и якобы теперь стало гораздо лучше: и CPU не так загружен и видео кажется стало без ошибок крутить…
— ???????????..
— Ладно, посмотрим, что скажет QA..
Беда N1: программисты до конца не понимают как работает их программа! А есть ли способ понять? Сколько на это потребуется времени? А как же time-to-market? Не наступила ли уже «технологическая сингулярность», когда новые технологии рождаются быстрее, чем мы можем их переварить и освоить?
История третья: Пропасть непонимания
Года три назад посчастливилось нашей компании ввязаться в очень перспективный проект. Мы так думали, что проект очень перспективный. Российская компания по производству оборудования решила снабжать свои агрегаты платой электронного управления. Нам предстояло в сжатые сроки разработать и изготовить плату и плюс программное обеспечение микроконтроллера.
Сказать по правде, я был очень рад этому проекту. Во-первых, компания российская, некий эффект патриотизма. Во-вторых, казалось, что проект весьма долговременный, поскольку ассортимент агрегатов широкий, а заказчик имел намерение идти в ногу со временем и выпускать конкурентное современное оборудование.
Однако были и нюансы:
- Заказчик абсолютно не представлял себе, что такое ПО микроконтроллера и как производятся платы. Были даже разговоры, что мол если будет нужно они сами купят линию по монтажу плат и будут сами их комплектовать и производить. Вот это масштаб!
- Мы в свою очередь не очень представляли, как работает их оборудование, ну и вообще тема управления оборудованием для нас была довольно новой. Техническое задание по алгоритму работы платы контроллера предполагалось будет передано нам после подписания договора по началу работ, мы его еще должны согласовать.
Мы почему-то сразу подумали, что возьмем денег по минимуму, все равно по проекту еще долго взаимодействовать и сопровождать его. Заказчик в лице директора с этим устно согласился.
Далее начались некоторые странности. Как оказалось, со стороны заказчика был только один инженер, который реально вникал в алгоритм, сам его описывал, часто звонил и интересовался ходом работ. При этом, мне постоянно казалось, что мы делаем что-то не то, в наших алгоритмах явно не хватало математики, здесь явно не хватает всех этих ТАУ, ПИД и прочих премудростей систем автоматического управления. Мы пытались развернуть разработку в сторону реального ТАУ, но получили ответ, что получится слишком сложно и им такое не надо. Самое странное, что кроме одного инженера, с которым мы взаимодействовали со стороны заказчика никого более никакие алгоритмы вообще не интересовали. Уже в момент сдачи работ, при демонстрации готовых плат мне наконец-то пришло понимание происходящего. Главный инженер проекта воспринимает плату микроконтроллера, как любую другую деталь агрегата, только что выточенную на токарном станке или согнутую на трубогибе.
То есть: должен быть чертеж с указанием типа материала, размеры, допуски — все. Есть деталь — устанавливаем ее на посадочное место и весь разговор.
Ну что сказать. Я пытался разговаривать и объяснять, что программное обеспечение — это не деталь, что требуется долгое и тщательное тестирование алгоритмов на реальном оборудовании. Что может оказаться, что реализованные алгоритмы могут потребовать корректировки или изменения постоянных времени, скорости реакции и т.д. Моя фраза, что в программном обеспечении возможны баги, которые нужно отлавливать и устранять наткнулась на стену непонимания. Оказалось, что наши баги — это наши проблемы. ВСЕ баги, все 100%, должны быть устранены до момента сдачи работ. Потом инженер заказчика проводит свое тестирование и приемку работ. И все. Проект сдан, никаких более изменений в ПО не предвидится и изделие после установочной партии передается в серию.
Стоит ли говорить, что сторона заказчика провела испытание плат одним инженером за один (!) день и уже через неделю после подписания акта приемки сдачи он же звонил и просил подправить два временных параметра в алгоритме.
Душа болит и сердце плачет. Мы реально вкладывались в этот проект, жили им, но мы так и не поняли, сделали ли мы всю работу так как надо. Мы так и не увидели своими глазами агрегат в сборе под управлением нашей платы.
Закончилось все так же внезапно, как и началось. По прошествии некоторого времени заказчик рассчитал, что производство печатных плат в РФ экономически не выгодно. Проект закрыт. Может оно и к лучшему, кто знает…
Отвлекусь от конкретного этого описанного выше случая. Хочу отметить важное: каждый программист в принципе знает, что в его программе есть или возможны ошибки. Да, мы пишем тесты, ведем continuous integration, но у многих из нас в баг трекере висит список незакрытых задач даже по продукту который давно уже выпущен. Иногда программа доходит до этапа «смертельная петля тестирования». Это когда свежие исправления в программе порождают новые, ранее не известные баги. QA возвращает на доработку ПО, разработчики исправляют и отдают в QA, но те, работая не покладая рук возвращают на доработку снова и снова. Если заказчик этого ПО адекватный, то он просто готов смириться с некоторыми ошибками, которые иногда объявляются фичами (feature), с целью снизить напряженность отношений.
С другой стороны, сторонний заказчик, особенно если ранее не сталкивался с процессом разработки ПО, понимает процесс совсем по другому. Для очень многих программа — это то, что можно увидеть и пощупать, то есть как правило — это только часть GUI, то что можно увидеть глазами: кнопочки, формы, диалоги. Если есть плата, то важно, как она выглядит и как ее можно подержать в руках. Что и как за этим скрыто, какая там есть логика и какие алгоритмы — неведомо. Отсюда барьер не понимания.
Беда N2: Заказчик почти никогда не в состоянии проверить качество разработанного программного обеспечения, даже если ему отдать исходные тексты.
Если теперь рассмотреть эти две описанные мною беды как единое целое: программисты не до конца понимают как работают их программы, плюс заказчик не может проверить результат, то что это вообще будет? Какое будущее нас ждет? Сколько недо-продуктов будет нас окружать? Опасно ли входить в высотные здания, проезжать по мостам, рассчитанным в инженерных CAD? Будем ли мы бояться летать на самолетах и ездить в беспилотных автомобилях? Можно ли верить медицинским приборам? Не побоимся ли мы входить в систему онлайн-банка? Программные продукты окружают нас повсюду. Возможно, не будь я программистом, мне не было бы так страшно…
Комментарии (160)
Saffron
14.09.2016 19:55+11Ладно программисты, эти ещё хоть что-то понимают. Представляете как обидно простым пользователям? Они ни ассемблера, ни фреймворка, ни устройства ОС не знают и шансов не имеют узнать, не положив на это полжизни. И как-то пользуются компьютерами, доверяют чужим компетенциям.
bigfatbrowncat
14.09.2016 21:32+6Их успешно защищает Эффект Даннинга-Крюгера. Люди, не представляющие устройства программного обеспечения либо явно (если глупы), либо подсознательно считают его чем-то простым и понятным.
Труднее всего приходится так называемым «продвинутым пользователям», то есть людям, склонным относиться к технике ответственно и изучать инструкции по эксплуатации перед тем, как пользоваться техникой. Мне всегда очень больно наблюдать страдания моего пожилого отца, который не умеет совершать простые манипуляции с собственным Андроид-смартфоном, потому что не знает, как, но который достаточно квалифицирован, чтобы жать «куда попало» (то есть использовать интуицию), на что эти интерфейсы и рассчиланы.
JamaGava
14.09.2016 20:44+10А ещё было время, когда водители авто сами их собирали и в точности знали каждый болтик и винтик, ибо были эти самые авто штучным изделием…
А ещё было время, когда великие врачи, чьи имена вписаны в историю человечества, сами своими руками изготавливали целебные настои и точно знали как они действуют на организм человека, доверяя своему опыту, а не бездушным инструкциям-вкладышам…
Уж не знаю, к сожалению ли или к радости, но сейчас наступила эпоха готовых решений. Мне это тоже не по душе. Я помню как сам писал и обучал нейронные сети, реализовывал генетические алгоритмы, точно знал все нюансы своих программ. Но современный рынок требует умения пользоваться готовыми решениями. И я пользуюсь стандартными библиотеками.
Это наша реальность и приходится с ней мириться. Хотя, знание основ — это огромный плюс, так как это возможность создать новое готовое решение для новой проблемы, которое будем использоваться многими, кто даже не задумается, как там всё устроено.bigfatbrowncat
14.09.2016 21:41+3Ваши примеры нерелевантны.
— Технически-подкованный водитель и сейчас знает об устройстве своего автомобиля ровно столько, сколько нужно, чтобы на этом автомобиле успешно передвигаться. И даже поменять колесо в экстренной ситуации.
Они доверяют ремонт авто работникам сервисов не потому, что не знают, как что работает, а потому, что справдливо полагают, что работники сервиса чинят лучше.
— Я никому не пожелаю иметь дело с врачом, не понимающим биохимические и фармакинетический свойства выписываемых им препаратов. Опять же, фармакомпания делает, а понимать должны все, кто выписывает (и, кстати, неплохо бы, чтобы хоть немного понимали даже те, кто принимает).
Не обязательно знать каждый ньюанс в том, что ты используешь. Но основоположные вещи нужно знать обязательно. Иначе случится катастрофа. За примером далеко ходить не надо. И он, к слову, произошел еще до «айтишной революции».JamaGava
14.09.2016 22:20+1А я и не утверждаю, что водитель не должен понимать как работает автомобиль и уметь провести простейшее обслуживание, а врач не понимать как действует препарат…
Но, если абсолютно всё делать самому от и до, то можно очень сильно отстать от современности. Приходится находить компромисс между своим опытом и доверием другим специалистам, предлагающим нам готовые решения.
И разработчик обязан знать как ДОЛЖЕН работать используемый им продукт. А вот работает ли он так на самом деле? В этом, приходится доверяться разработчику продукта. Ибо воссоздать все технологии одному человеку — непосильная и абсурдная задача. Вот тут-то и появляются «магические строчки»… Как механизм приспособления к окружающей нас действительности.
bigfatbrowncat
14.09.2016 22:23> разработчик обязан знать как ДОЛЖЕН работать используемый им продукт
Автор статьи посетовал на то, что существуют «боги из машины», которые «магически» делают ваш код лучше (не слишком понятно, какую цену приходится за это заплатить) и что большинство людей в индустрии не понимают, как они работают.
Так что, строго говоря, никто из этих людей определенному вами долженствованию не удовлетворяет. Не могут они знать, как их продукт должен работать. Если только вы под «должен» не подразумевали техзадание — тут даже менеджер знает, как что «должно работать».Lamaster
15.09.2016 12:14+4Тоже нет. Менеджер хочет, чтобы продукт вёл себя ожидаемым для него образом. Про «должно работать» тут и речи нет
Менеджер: Когда нибудь придёт время, когда программисты станут не нужны. Я напишу полную и точную спецификацию программы и она сама заработает.
Программист: знаешь как называется самая полная и точная спецификация программы? «Код», это называется «код».
mcgreedy
15.09.2016 10:12+3Примеры как раз релевантны и вот почему:
Мой отец может разобрать и собрать машину отечественного производства и иностранного до 90х годов. Любую, где не используется компьютер. Заменить ГРМ, перебрать клапана, починить карбюратор из подручных средств — для него не проблема, и экстренно починить заглохший двигатель с помощью гвоздя и резинки тоже (сам видел). При этом скажет сколько она проедет до следующей такой же проблемы. И он, отец, не механик, а простой советский инженер. При этом при обращении с современными машинами, он вынужден обращаться в сервис, и вынужден доверять тем специалистам которые обслужат машину, и их квалификацию, как и результат может проверить только очень поверхностно, как работают эти контроллеры и компьютеры он не знает, при этом постоянно проверяя за сервисными работниками то, что он знает. При этом мой знакомый который работает в мастерской и настраивает электронику в машинах — говорит что все делает по документации и не лезет внутрь.
Так вот, к чему я это написал. В современном мире мы все дальше уходим от понимания принципов работы системы даже среднестатистическим инженером, не говоря уже о конкретном пользователе, и дальше будет хуже.
Мы будем использовать продукты в рамках инструкций не разбираясь в запасах прочности и допусках и вариантах замены в экстренных ситуациях. Мы не сможем экстренно починить заглохший двигатель с помощью гвоздя и резинки.cheshircat
15.09.2016 13:04+1Системы усложняются и сейчас мы кажется уже приблизились в некоторых областях к той точке когда один человек не может полностью уместить всю систему в голове. Пример с автомобилями показателен, но если взглянуть скажем на ракетоноситель, то там уже давно такая ситуация.
Это не хорошо и не плохо, просто особенность любой сложной системы, переход на новый уровень абстракции. Примерно также как инженер, разрабатывающий электронную схему на базе микросхем вряд ли вникает во внутреннее устройство каждой. Аналогично с машинами — на работает блок, на замену. И да починить заглохший двигатель с помощью гвоздя и резинки теперь не получится, но это цена прогресса. Зато мы получаем на много больше плюшек )Yggaz
16.09.2016 08:00Извините, но это называется "ракета-носитель" :). Она ракета, и при этом носитель полезной нагрузки.
А по сути — вы совершенно правы. Это в самом деле цена прогресса. Преимущество гвоздя перед атомным реактором в том, что в гвозде выходить из строя совершенно нечему. Но энергию он, гад такой, не производит.
bigfatbrowncat
15.09.2016 21:17Это всё — как посмотреть. С одной точки зрения, точка «неосознания всей системы» уже давно пройдена, потому что количество идей, вложенных даже в автомобиль 50-х годов уже запредельно для осознания одним человеком (он, конечно, может разобрать/собрать «21» Волгу, но вот изготовить в ней деталь руками и заменить (как это делал на своей работе мой прадед-часовщик) — уже вряд ли. Разве что гвоздем и резинкой…
А с другой стороны, у меня есть друг, который может как ваш отец — натурально всё собрать, разобрать, — он даже модификации в конструкции своей машины сделал — теперь гаишники прикапываются. А еще для него совершенно не проблема программировать микроконтроллеры. И он чудесным образом может починить багу в системе «умного» впрыска топлива, например. Просто, он другого поколения, чем ваш отец.
В плане возможности поддержки и ремонта техники ситуация, когда один человек неспособен разобраться во всем устройстве, преодалена только в одном типе устройств — в компьютерах. Вот там сложность такова, что никто уже толком не понимает, как что работает (кроме пары гениев, которые стояли у истоков, всю жизнь разрабатывали процессоры и чипсеты и еще не ушли на пенсию). И, откровенно говоря, текущее состояние платформы PC немного удручает. Куча глюков, в том числе, — аппаратных, проблемы с софтом, тормоза… В общем, плохо, когда никто не может понять всю систему целиком и хорошенько ее «отрефакторить».
samodum
14.09.2016 21:54Про машины…
Вот мой отец например. Он привык в советское время постоянно быть в гараже, перебирать двигатель, коробку передач, все эти лебёдки, ключи, масло… И вот появилась у него японская машина 20-летней давности. И не знает, что с ней делать в гараже. Ведь по привычке надо в ней копаться, а не «докопаешься». Вот и протирает он её тряпочкой и она всегда чистенькая и блестящая. Трудно ему, непривычно.
Есть ещё такие австралопитеки, которые на полном серьёзе считают, что машину с механической коробкой передач обязан уметь управлять каждый водитель.avost
15.09.2016 04:27+320-15-летняя япошка прекрасно перебирается в гараже чуть менее, чем полностью (за исключением, разве что, коробочки с «мозгами») даже человеком не имевшим опыта десятилетий сборки-разборки автотазиков. Не гоните гусей :)
vlreshet
15.09.2016 10:06+4Видимо я — австралопитек :) Я всеръёз считаю что водитель обязан понимать как работает коробка передач, и уметь ездить на механике.
rPman
15.09.2016 10:24+2Это значит вы и такие же как вы 'австралопитеки' отчасти ездите на машине ради езды а не ради перемещения из точки А в точку Б. Полагаю, это пройдет с возрастом, как и аналогичное отношения к играм (искренне надеюсь что у меня к играм отношение не изменится как можно дольше).
Viteran33
15.09.2016 12:09Странно полагать, что человек умеющий ездить на механике не просто перемещается, а получает от перемещения еще и какое-то удовольствие. Посмотрите так называемые «машины для водителя», в их множестве не так уж и много экземпляров на механике. Значит не все так уж и взаимосвязано. Уметь ездить на ней или не уметь дело Ваше. Ваша точка зрения будет правильной только в том случае, когда автоматы и роботы будут на процентах 70 машин и механику можно будет окончательно записать в артефакты для почитателей ретро. А пока все обстоит несколько иначе, умение ездить на механике должно быть если не обязательным, то крайне рекомендуемым.
sumrakssk
17.09.2016 07:47Мне механика нравится… Какое-то чувство контроля за машиной… На автомате оно меньше, хотя удобство больше ))
esc
15.09.2016 12:15Просто, некоторым людям нравится ездить и хорошо управлять машиной, другие это терпят как вынужденное зло ради удобного перемещения и не более. Так же как кто-то в консоли предпочитает работать, другой воспринимает только графику с парой простых кнопок.
Умение водить механику нужно не столько для самого умения водить. А просто потому что пока еще встречаются ситуации, когда в доступности есть только механика. Частая история в прокатах, например. Когда механики в использовании не останется, никакой нужны уметь ей управлять и не будет. Ну и не нужно это тем, кто использует машину только передвижения с дома на работу и даже не задумывается о том, чтобы взять другую машину и где-то на ней ездить.
vlreshet
15.09.2016 12:40Машина с автоматом не предоставляет полного контроля над собой. Попробуйте где-нибудь застрять, например, а потом вылезти оттуда «раскачкой» на автомате. Или тянуть кого-нибудь на буксире (автомат очень этого не любит). Или найти грузовой автомобиль с акпп. Механика — это способ более полного контроля над поведением авто, врядли кто-то получает удовольствие просто от того что постоянно выжимает сцепление и дёргает ручку.
avost
15.09.2016 15:06Вылезать раскачкой совершенно не проблема даже на моём древнем автомате. Возможно, не так эффективно, как на механике, но вполне осуществимо.
Skinner2170
15.09.2016 17:33Вообще говоря седельные тягачи уже как много лет с АКПП. А нагрузки там много больше 10т.
esc
16.09.2016 10:41Роботы позволяют раскачивать машину. Умные роботы (типа powershift для Мерседесовски грузовиков) даже стаят одно сцепление на переднюю, второе на заднюю передачу, что дает полноценную раскачку, недоступную на механике. А тянуть на буксире автомат без проблем позволяет, лишь бы усилие было не слишком большое.
Контроль на механике обычно заключается в том, что передача в ненужный момент не сменится. На автомате это тоже достижимо (если там есть толковый ручной режим), но мало кто этим пользуется.
В любом случае, механические коробки уже даже с мотоциклов будут уходить. Лет через 5 в большинстве автошкол цивилизованных стран вряд ли будут обучать вождению на механике в рамках общей программы.vlreshet
16.09.2016 11:32+1Механика из мотоциклов не уйдёт никогда. Уже сейчас есть акпп для мотоциклов — вариатором называется (на всех скутерах стоит). Так вот, вы не найдёте мотоцикла или скутера с вариатором и объёмом больше 600 (или 800, может ошибаюсь) кубических сантиметров. Потому что контролировать все 100+ лошадиных сил в один поворот ручки газа — нереально. Мотоцикл имеет дикое соотношение кг/лс по сравнению с авто, и ему просто необходим точный контроль тяги. Именно поэтому никто в здравом уме не будет ставить акпп на мощные мотоциклы. На них наоборот сейчас разрабатывают всё более сложные коробки, на 6 и больше передач.
esc
16.09.2016 11:46Вариатор на мощные мотоциклы не ставят по одной причине — он не позволяет делать резкие ускорения. Ремень проскальзывает, моментально перегревается и рвется. Это знакомо владельцам квадроциклов и УТВ (в последних, кстати, мощность уже ушла за 150 лошадей).
Однако, вы немного отстали от жизни;) У Хонды есть коробка DCT, ее уже пару лет ставят на NC700 и VFR1200X. Это робот с двумя сцеплениями, который показал себя надежным и сейчас вот ставят на новую литровую Африку. Железно работает она прекрасно (переключения моментальные, без рывков, запутать робот, переключая передачи туда-сюда у меня не вышло). Есть проблема с алгоритмом работы при активной езде на дороге, но его со временем решат. Не Хонда, так БМВ (которая, в отличие от Хонды, в машинах автомат настраивает очень неплохо).
Хонда тут новатор, остальные ставят на мотоциклы квикшифреты — дополнение к механике, позволяющее переключать передачи без сцепления и не меняя газ. По сути, упрощающее и ускоряющее переключение по технике квикшифтинга, когда кратковременно сбрасывают газ при переключении вверх. Но это временное решение, работает оно хуже, чем робот.
Учитывая, что Хонда начала ставить робот на многие новые модели, остальные производители не будут долго с этим тянуть. Тем более, что многие имеют возможность позаимствовать решения у автомобилей и наверняка давно ведут разработки. Хонда просто умудрилась первой выпустить толковую и компактную коробку.
bigfatbrowncat
15.09.2016 21:29Вам знакомо понятие «чувствовать двигатель»?
Когда между вашей ногой, жмущей на «газ» и колесами присутствует только двигатель и зубчатая передача, передаточным числом которой вы управляете сами, чувство контроля (притом, совершенно обоснованное) гораздо выше, чем когда вас с колесами разделяет сложная, «интеллектуальная» система, которая, к тому же, имеет «наглость» адаптироваться к вашему стилю вождения (то есть менять свое поведение «на ходу»).esc
16.09.2016 10:36Увы, но на современных машинах с механикой все равно стоит электронная педаль газа, которая может вносить свои коррективы и обычно таки вносит.
bigfatbrowncat
16.09.2016 16:51Кхм. Chevrolet Aveo 2008 модельного года. Горячо рекомендую. Езжу с момента, как купил новую. Не слишком мощная, зато дешевая и очень уютная. В том числе и своей простотой.
Djeux
15.09.2016 10:12+3Управлять машиной с механической коробкой передач должен уметь каждый водитель, чтобы вдруг не возникло ситуации, что вроде как машина есть, но ехать не ней не можешь, т.к. в правах галочка стоит на автомат. Как только мануальный коробки исчезнут, проблемы само собой не станет.
С уважением, ваш Австралопитек.
bigfatbrowncat
15.09.2016 21:21Привет от австралопитека. Я не считаю, что каждый должен. Но себе лично купил (и снова куплю, если будет возможность) именно «механику». Потому что она интуитивнее — лучше чувствуется динамика.
И вообще, чем проще устройство — тем приятнее с ним иметь дело. Сложность — неизбежное зло, на которое приходится идти с целью безопасности и комфорта.
А вот брат мой — гонщик класса ралли, — покупая себе новую машину, снял с нее АБС. Потому что привык тормозить импульсами сам. И этот самый АБС ему бы мешал, а не помогал.esc
16.09.2016 10:43+1Это называется проф. деформация;) На асфальте АБС не может мешать. Если сработала, значит водитель уже перетормозил. Отключать имеет смысл на грунте или в снегу, но отключать. Зачем снимать?
bigfatbrowncat
16.09.2016 16:53Видимо потому, что «асфальт» в России зимой нужно еще поискать.
А отключать надо потому, что если человек до спинного мозга привык к импульсному торможению ногой (чему вообще-то должен был учиться любой водитель до-АБС-ной эпохи, не только профессионал), то наложение на его «долбящую ногу» алгоритма импульсов АБС-а приведет уже не к сокращению, а к увеличению тормозного пути.esc
16.09.2016 17:36то наложение на его «долбящую ногу» алгоритма импульсов АБС-а приведет уже не к сокращению, а к увеличению тормозного пути.
Или вы не знаете физику процесса работы АБС или я не знаю. Берем твердое покрытие (асфальт — сухой, мокрый или мерзлый, неважно. Где-то уж найдем его) и симулируем торможение по нему. Любая блокировка колеса тормозной путь увеличит (почему — в Вики написано в статье про АБС). Если блокировки нет, АБС не срабатывает — датчики у него достаточно точные для этого.
Как прерывистое торможение может быть ухудшено АБСом?
Повторюсь, у вашего брата проф. деформация. Раллийщики ездят по сыпучему и мягкому покрытию, там АБС может сделать хуже и тормозить лучше прерывисто. Как и в снегу. Но на асфальте и другом твердом покрытии ситуация иная.bigfatbrowncat
17.09.2016 00:05АБС создает преимущество при торможении за счет задействования Штрибек-эффекта. Суть его в том, что при зацеплении с поверхностью сила трения чуть выше, чем при проскальзывании (очевидно, здесь принимают участие межмолекулярные связи, хотя физика эффекта очень сложна; трение — вообще очень непростая вещь).
Основная идея в том, чтобы всё время держать колесо в состоянии, когда скорость движения его поверхности относительно земли была близка к нулю. То есть колесо должно немного прокручиваться. При этом, как ни странно, оно будет терять энергию движения машины быстрее, чем при проскальзывании «юзом».
1. Как этого эффекта достигает человек?
Человек нажимает на тормоз, чувствует, что машина потеряла часть скорости, машина входит в проскальзывание, человек отпускает педаль, проскальзывание прекращается, человек снова нажимает педаль…
Та самая «долбёжка по тормозу». Ее тренируют при прохождении начального курса экстремального вождения.
2. Как этого эффекта достигает система АБС?
Примерно так же. Она блокирует колесо, фиксирует напряжение на оси, когда напряжение падает, ослабляет «хватку» колодок, затем снова усиливает. Та же самая «долбежка», только без педали (возможно, более плавная/высокочастотная, но сути это не меняет).
3. А теперь вместе.
АБС включится при нажатии на «тормоз» и выключится при отпускании. Водитель, инстинктивно «долбящий» педаль не даст АБС-у найти оптимальное напряжение оси. Автоматика просто не успеет понять, насколько сильно надо тормозить. В результате тормозить толком не будет никто.
Тормозной путь станет не короче, чем при проскальзовании, а длиннее.
Теперь по последнему пункту. Опять.
Вы, насколько следует из профиля, живете не в России. Напомню, что в нашей стране зимой любая, даже самая хорошая дорога содержит на себе либо слякоть (в лучшем случае), либо полсантиметра снега. Снег бывает раскатанный и скользкий, а бывает плохопримятый. В любом случае, российские водители рассматривают вождение на сухом асфальте как роскошь. Лично мне вообще никаких улучшений моего транспортного средства в условиях сухой летней дороги и хорошей видимости не нужно. Тормозной путь в 15-20 метров при скорости в 90 км/ч — просто роскошь.
У нас все водители с ралли!
Иллюстрация:
P.S. Летом в плохую погоду эта же дорога может быть покрыта примерно таким же слоем скользкой грязи.Jump
13.01.2017 01:34А разряд до 10,8В не слишком?
Насколько я помню ниже 11,8В разряжать не рекомендуется вообще, даже кратковременно. Особенно те что с кальцием.
Godless
14.09.2016 21:22+1я думаю, что данная проблема тесно коррелирует с проблемой качества получаемого образования. Холивар про образование отставим…
вопросы подняты, конечно, интересные, жизненные, но боюсь ответы на них скорее философские нежели практические.
Про софт. Довелось поддерживать продукт 15-ти летний. Видел в нем как раз то, что новые функции открывают новые баги, и т.п. Дык вот, коли такое происходит, я считаю жизненный цикл ПО подошел к концу. Не потому он не нужен, просто нужно пересмотреть архитектуру, и да, переписать версию 2.0 с учетом хотелок и ошибок. Что-то выбросить, что-то добавить — это нормально я считаю.
И вообще — нет ничего идеального…
samodum
14.09.2016 21:46+5>Возможно, не будь я программистом, мне не было бы так страшно
Тот, кто работает в сосисочном цехе, никогда не ест сосиски.
Врачи вот тоже могут много «забавного» рассказать, но только в своём кругу.
Не надо бояться технологий и программистов. Весь этот процесс абсолютно нормален.
Так что присаживайтесь по удобнее, едем дальше.Konstontin
17.09.2016 07:47Мне стало страшнее жить, когда я начал узнавать как это все работает на уровне аппаратуры. До какого-то момента в чем, а в этом уровне был уверен и, так сказать, не лез туда. Оказалось там не все так строго, как я представлял. Потом уже я узнал, что процессор может в какой-то момент выкинуть исключение Macine Check и сказать «гудбай». Кэш память, прогнозирование переходов, спекулятивное исполнение — все это, казалось бы, обходные пути, однако это все работает на большинстве процессоров.
Еще забавен тот факт, что сложение двух чисел на C++ в некоторых случаях undifined behaviour (чисто теоретически может отформатировать жесткий диск):D
MacIn
14.09.2016 22:01+7Прогресс идет по пути разделения труда и специализации. Везде, в том числе, в сфере разработки ПО.
Точка.bigfatbrowncat
14.09.2016 22:18-3Никто и не против вашей «точки». Только вот разделение труда не означает, что правая рука не знает, что делает левая нога.
MacIn
14.09.2016 22:30+3Именно что означает. Она специализируется в своей, праворукой деятельности, и достигает в ней совершенства. А как работает левая нога — не ее дело. Сломается — будет ее чинить мастер по левым ногам. Вот и вся недолга. Чем сложнее система, тем меньше возможности у отдельного человека ее всю охватить.
Пример: В США, в некоторых штатах водителям большегрузов запрещено самим менять пробитые колеса, независимо от того, может человек, или нет. Этим занимается специальная служба, шофер — ведет машину.bigfatbrowncat
14.09.2016 22:53+2Но это не означает, что они НЕ ПОНИМАЮТ, как сменить колесо.
Еще раз, вдумайтесь. Если врачи, которые лечат ваши уши, не будут знать физиологию всего тела (а зачем?) или, скажем учитель математики вашего ребенка не будет уметь грамотно писать (или учитель литературы не будет уметь считать) — вы полагаете, это и есть то «светлое будущее» с разделением труда?
В таком случае нам с вами определенно не по пути. Потому что мир, в котором люди не понимают (хотя бы приблизительно) проблемы и задачи друг друга, похож на Вавилонскую Башню.
Вам же автор статьи привел пример проекта, который накрылся медью из-за того, что инженеры-«жестянщики» в упор не понимали, чем занимаются программисты. Или этот пример не иллюстрирует проблему?MacIn
14.09.2016 23:17+4Но это не означает, что они НЕ ПОНИМАЮТ, как сменить колесо.
Вовсе необязательно. Могут и не понимать. Разделение труда приводит к специализации. Это повышает эффективность обучения и производительность труда.
Еще раз, вдумайтесь. Если врачи, которые лечат ваши уши, не будут знать физиологию всего тела (а зачем?)
При этом они не знают другие части тела так же хорошо, как и «свои». «Знать физиологию» — это игра словами, основанная на неоднозначности слова «знать» в этом контексте.
скажем учитель математики вашего ребенка не будет уметь грамотно писать (или учитель литературы не будет уметь считать)
Это некорректный примерю Навыки письма и счета — базовые для всех людей. Мы же говорим о профессиональной деятельности, и тут — о ужас — да, учитель математики не умеет учить детей литературе.
В таком случае нам с вами определенно не по пути. Потому что мир, в котором люди не понимают (хотя бы приблизительно) проблемы и задачи друг друга, похож на Вавилонскую Башню.
Путь в обратную сторону — дорога в средневековье. Вы просто пытаетесь определить набор навыков, иметь которые по-вашему «нормально» (вида «нормальый мужик умеет починить кран и прибить полку», только в применении к другим сферам), я же говорю о профессиональной деятельности, производстве продукта/услуг.
Вам же автор статьи привел пример проекта, который накрылся медью из-за того, что инженеры-«жестянщики» в упор не понимали, чем занимаются программисты. Или этот пример не иллюстрирует проблему?
Этот пример демонстрирует проблему отсутствия человека, координирующего действия тех двоих. Потому что инженеру (не в сфере ПО) также знаком итеративный процесс решения проблемы, поиск альтернатив; это означает, что между ними нет неразрешимых противоречий, это обычная communication проблема.bigfatbrowncat
14.09.2016 23:33+2> Навыки письма и счета — базовые для всех людей.
А навыки оперирования с алгебраическими выражениями общие для всех, кто занимается точными науками.
А знание анатомии обязательно для всех, кто имеет дело с телом человека. Даже если он всю жизнь смотрит исключительно в рот.
А элементарные слесарные навыки обязательны для всякого водителя (во всяком случае если он хочет быть уверенным, что выберется из по-настоящему нештатной ситуации).
>Вы просто пытаетесь определить набор навыков, иметь которые по-вашему «нормально» (вида «нормальый мужик умеет починить кран и прибить полку», только в применении к другим сферам)
Я пытаюсь определить набор навыков, который определяет околопрофессиональный кругозор человека, занимающегося деятельностью, близкой к моей.
А вы бросаетесь в крайности.
И, кстати, поделитесь мыслью, каким таким волшебным способом этот третий человек, координирующий двоих, справится со своей задачей, не имея хотя бы базовой экспертизы в областях, которыми занимаются они оба. Я за время своей работы сменил около десятка руководителей, но такого чуда чудесного не встречал. Все они более-менее разбирались в том, чем управляли. И слава богу.MacIn
15.09.2016 01:26+4А знание анатомии обязательно для всех, кто имеет дело с телом человека. Даже если он всю жизнь смотрит исключительно в рот.
Проблема в том, что вы определяете «элементарные навыки» волюнтаристский. Я уже обозначил это, указав на использование вами слова «знание», но вы этого не поняли.
Я пытаюсь определить набор навыков, который определяет околопрофессиональный кругозор человека, занимающегося деятельностью, близкой к моей.
Так я не против, непонятно, на что вы возражаете здесь.
А вы бросаетесь в крайности.
Отнюдь, это делаете вы. Я как раз не против расширения области, захватывающей что-либо, что позволит людям разных специализаций состыковаться.
А вот ваши примеры-контраргументы — как раз полярные, крайность.
vchslv13
15.09.2016 10:11+2>А знание анатомии
Что такое «знание анатомии», что такое «элементарные слесарные навыки»? Вы бросаетесь абсолютно неопределёнными фразами — это крайне непрофессионально, если на то пошло.
Знание анатомии — что это? Профессиональный гинеколог должен знать какие участки головного мозга за что отвечают? Нейрофизиолог должен знать то, как работает человеческий иммунитет так, чтобы иметь например возможность рассказать без недельной подготовки по этой теме лекцию?
Элементарные слесарные навыки — что это? Нестандартная ситуация — какая это? В машине произошла поломка инжектора/коробки передач/бортового компьютера/электродвигатель отказал — это ещё настолько нестандартные ситуации, чтобы с ними необходимо было уметь справиться профессиональному водителю или ещё нет? И не в копейке, выпущенной лет 20 назад, а в современной среднестатистической иномарке, в которой иногда и подобраться к нужным деталям без спецоборудования не так то просто.
>третий человек, координирующий двоих >базовой экспертизы
Опять неопределённость, уточните должность и что такое «базовая экспертиза»?
Хотя это можно вообще-то долго продолжать. Я думаю, уже давно понятно, что без умения пользоваться предоставленными другими людьми абстракциями никто в современном мире не сможет успешно продолжать свою деятельность. А то, абстракциями насколько высокого уровня должен уметь оперировать человек на определённой должности, точно решит уже скорее всего только рынок.
Rap_Tor
15.09.2016 10:11-2Я солидарен с bigfatbrowncat.
Вовсе необязательно. Могут и не понимать. Разделение труда приводит к специализации. Это повышает эффективность обучения и производительность труда.
Если впадать в крайности то у нас на каждый чих, по такой логике, будет специалист.
Путь в обратную сторону — дорога в средневековье. Вы просто пытаетесь определить набор навыков, иметь которые по-вашему «нормально» (вида «нормальый мужик умеет починить кран и прибить полку», только в применении к другим сферам), я же говорю о профессиональной деятельности, производстве продукта/услуг.
а что собственно плохого в «нормальном мужике»? почему нельзя сочетать это качество и быть хорошим специалистом в своей области? В Японии, слышал, практикуется система «горизонтального» роста: каждые пять лет инженер меняет специализацию и начинает все с нуля. А самое главное Вы не должны забывать чем вызвано это производство продуктов/услуг. По-моему из-нас делают потребителей этих самых продуктов/услуг. Такое ощущение что миром начинает править маркетинг. Про путь в обратную сторону- не это имел ввиду bigfatbrowncat. Я думаю, что смысл в том что нужно оглядываться назад, двигаясь вперед. Наша нация (я не делаю здесь ударения), если помните, всегда отличалась смекалкой. Вспомните великие битвы и войны за нашу родину. Сколько раз мы выживали благодаря нашему менталитету (собственно, порою оказываемся в *опе из-за него же). Я не понимаю как можно, например, дать замерзнуть своему ребенку на трассе, зимой просто из-за того, что ты не умеешь заменить колесо (если уж речь зашла о замене колес).
Этот пример демонстрирует проблему отсутствия человека, координирующего действия тех двоих. Потому что инженеру (не в сфере ПО) также знаком итеративный процесс решения проблемы, поиск альтернатив; это означает, что между ними нет неразрешимых противоречий, это обычная communication проблема.
Нужен не просто координатор, а человек развитый во многих областях, который понимает проблемы того или иного направления/специализации. Талантливый и действительно сведущий ГИП, project manager, руководитель проекта (называйте как хотите) большая редкость нынче.
Ну и по теме статьи: эту проблему можно проецировать практически на любую область, будь то производство или проектирование. Но конкретно в сфере ПО думаю что технологии производства микропроцессоров в будущем «упрутся» в невозможность производства более производительных систем. И вот тогда наступит время кодеров которые будут по-настоящему оптимизировать код. До этого времени объем кода будет только увеличиваться.
knowgod
16.09.2016 09:37+1Специализация хороша, когда развивается эволюционным путем.
А «водителям большегрузов запрещено самим менять пробитые колеса» — это уже навязывание кем-то.
Водитель может сам решить насколько выгодно ему ждать спец. службу или же поменять колесо самостоятельно. Или же его работодатель решит, если водитель недостачно компетентен.
farwayer
16.09.2016 13:31Боюсь, не все так просто. В США очень развита страховая и законодательная система. Отчасти это хорошо, но есть и свои минусы. Если водитель поменяет колесо сам, а после этого автомобиль попадет в аварию — водителя засудят на большую сумму денег. У него не было соответствующей документально подтвержденной квалификации для этой работы, пусть даже он гуру по замене колес. Такой вот перекос.
taujavarob
16.09.2016 13:33пусть даже он гуру по замене колес.
Если есть корочки что прошёл курсы, то не засудят.
playermet
14.09.2016 22:18+6Спрошу почти в тему. Мне кажется что я постоянно забываю все, чем хоть некоторое время не пользуюсь.
Банальный и самый яркий для меня пример — умножение матриц.
Пока проходили первый раз в техникуме, сдал почти на отлично. Через год писал практическую — пришлось лезть в конспекты, потому что забыл. Еще через год писал программу строящую графики поверхностей — читал заново. Через год писал демки на OpenGL — заново. Проходили и в институте — ничего не помнил. Позже попал в геймдев контору, писали свой 2д движок — читал википедию. Через пол года писал бенчмарк для luajit с перемножением матриц — заново. С год назад писал биндинги к glfw — вспоминал заново. И если спросить меня о об умножении матриц сейчас, я все равно не смогу сказать сходу, полезу в вики.
И похожие провалы почти во всем — стоит не трогать css с пол года, и я едва помню что-либо кроме основных селекторов и свойств. Пытаюсь бороться с этим, записывая краткие конспекты в простенький outliner, всплывающий на ctrl+shift+z (Flashnote).
Это у меня реально проблема, или я просто себя накручиваю?bigfatbrowncat
14.09.2016 23:00+15Никакой у вас проблемы нет.
Проблема у тех, кто считает, что для умножения матриц требуется немного пыли пикси и щепотка тертого философского камня. Или у тех, у кого слово «матрица» ассоциируется только с творчеством братьев Вачовски.
Общая эрудиция, достаточная для нахождения необходимого решения поставленной задачи — это именно то, что достаточно специалисту. Остальное вам даст справочная литература.
А эпоха «Сайрусов Смитов» давно закончилась, да. Подготовка современного инженера не подразумевает способности восстановить технологический уровень современного обества на необитаемом острове.MacIn
14.09.2016 23:19-4Общая эрудиция, достаточная для нахождения необходимого решения поставленной задачи — это именно то, что достаточно специалисту. Остальное вам даст справочная литература.
Серьезно? Вам
определенно
непо пути
с человеком, который не знает, как перемножаются матрицы?
irony, отсылка к разговору выше, если что.bigfatbrowncat
14.09.2016 23:46+8Ну и что? Вы меня там, выше, не поняли — может хоть здесь поймете.
Я помню формулу перемножения матриц. Но при необходимости всё равно уточню в справочнике — моя память со мной уже не раз играла дурную шутку. Но я точно помню, из чего эта формула состоит — там были линейные комбинации членов строк одной и столбцов другой… как-то так ведь, правда? То есть, я точно знаю, что не нужно, скажем, возводить элименты в квадрат. Или брать экспоненту. И этого вполне достаточно.
Я могу выдавать вполне квалифицированное мнение о задаче, связанной с перемножением матриц, даже если не помню деталей.
К нашему разговору выше — я не требую от преподавателя математики знания названий правил русского языка из учебника. Всего лишь писать грамотно. И врач, который лечит меня антибиотиком, не обязательно должен в деталях знать, как этот антибиотик изготовлен. Но он должен понимать, каков принцип действия, а не просто, как многие современные врачи, увы, делают, назначать по принципу «это — от головы, а это — от живота».
Вы мне говорите о разделении труда, я не возражаю (было бы глупо), но пытаюсь вам доказать, что разделение труда — не самоцель, а суровая необходимость. Если бы возможности мозга были бы безграничны, все были бы Сайрусами Смитами. Вернее, все, кто стремится достичь вершин в своей профессии, изучали бы ее, начиная от атомов.
Я всегда старался максимально расширять свой кругозор. Со школы. Программирование — супер. Физика — интересно. Графический дизайн — почему бы нет. Звук, музыка, видео… И так далее. Я осознавал, что пяти профессий быть не может. Но вот, в чем штука — уже неоднократно оказывалось так, что на работе кто-то куда более квалифицированный, чем я, сталкивается с проблемой, которую не может разрешить в силу своей узкой специализации. А я подсказываю человеку идею, как можно обойти препятствие. Не потому, что я чем-то «круче», а просто потому, что немножко шире изучал вопрос.
Скажем, мои познания в дизайне неоднократно помогали мне убеждать в своей правоте UX команду в тот момент, когда напарники, понимая, что господа-дизайнеры придумали ересь (потому что, в свою очередь, не понимали предметную область), не имели весомых аргументов. Просто не знали, как сформулировать проблему.
Вот такое вот разделение.MacIn
15.09.2016 01:39+2Вы меня там, выше, не поняли — может хоть здесь поймете
Почему же? Я отлично понял вашу позицию; вы не поняли моего возражения.
То есть, я точно знаю, что не нужно, скажем, возводить элименты в квадрат. Или брать экспоненту. И этого вполне достаточно.
Я же написал — irony. Ваш набор необходимого субъективен — в одном случае вы говорите «это можно посмотреть в справочнике», в другом «я расширяю кругозор, потому что это нужно».
К нашему разговору выше — я не требую от преподавателя математики знания названий правил русского языка из учебника. Всего лишь писать грамотно.
Вы непоследовательны. Речь шла о разделении труда и о том, что умение писать — это не специфичный для профессии учителя навык, это навык, специфичный для всех современных людей. Он вне профессии. А вот навык преподавания математики или русского языка — специфичен, и здесь есть разделение труда, специализация. Это не я перехожу в крайности, это вы представляете мой аргумент таковым, вероятно, по ошибке.
не обязательно должен в деталях знать, как этот антибиотик изготовлен. Но он должен понимать
Принцип изготовления антибиотика не является специфичным для его профессии, применение — является. Поэтому он должен иметь это знание, а не просто «потому что» или «для кругозора».
но пытаюсь вам доказать, что разделение труда — не самоцель, а суровая необходимость.
Это очевидно, вы тратите свое и мое время. Это необходимость, вызванная ограниченными возможносятми человека.
Если бы возможности мозга были бы безграничны,
Если бы… это невозможно. Знаете байку про экзамен в физтех с шуткой о кошке?
Я всегда старался максимально расширять свой кругозор
И это замечательно. Что не отменяет того, что вы специализируетесь в какой-то области. И чем сложнее будут вещи, с которыми мы работаем, тем более глубокая специализация потребуется.bigfatbrowncat
15.09.2016 01:49+2Разумеется, мой выбор субъективен. В том и фишка. Специалист сам выбирает спектр знаний, который ему необходим для решения задачи. Его невозможно и вредно определять извне. Вот эта вся чушь с «должностной инструкцией» смехотворна, как только речь заходит о мало-мальски творческой профессии.
Возможно, я зря ломлюсь в открытую дверь в случае спора с вами, но обычно следом за утверждением об «обязательном разделении труда» идет утверждение о том, что специалист «должен заниматься только своим делом», то есть умывать руки всякий раз, когда задача выходит на миллиметр за пределы его формальной компетенции.
А это называется «итальянская забастовка».
vagran
14.09.2016 23:13Да нет проблемы, я вот ещё со школы для себя понял, что всё в голове держать не возможно и не нужно, важно понимать и помнить суть, и знать, где искать подробности. В результате так и получается — в школе ничего не зубрил, и сейчас те же матрицы в своих записях смотрю как перемножать и в каком порядке. Если постоянно с чем-то работаешь, то этот «рабочий набор» в голове держится, при переключении теряется. Я даже пришёл к выводу, что это достаточно полезный навык — уметь быстро выкидывать из головы всё лишнее, что не требуется для текущих задач, так сказать, поддерживает ясность мыслей, что важно в наше время переполняющих мозг информационных потоков.
MacIn
14.09.2016 23:20+1Память у всех разная. Я почему-то помню, как перемножаются матрицы, как они раскладываются, как решаются уравнения по методу Крамера и т.п., но не помню точно, какие задачи в коде решал вчера.
tangro
15.09.2016 00:36Автор попал в один из классических распильно-откатных проектов, где главное было сделать видимость работы и подписать акты — и, видимо, так и не понял этого. Инженер со стороны заказчика был студентом, проходящим практику, тесты «за один день» — фикцией, а на рельное железо ничего никогда не встало, как и планировалось изначально. Главный инженер смотрел на чип как на «выточенную железку с размерами и допусками» именно потому, что знал, что на неё никогда даже не будет подан ток.
Так что вся эта тревога о качестве в данном случае была совершенно ни к чему. Качества несуществующего продукта измерить нельзя.mlg
16.09.2016 05:20Про распильные традиции ещё Александр Житинский хорошо написал в рассказе «Глагол „Инженер“».
Скрытый текстМы подъехали к институту. Это было очень высокое и узкое здание. Мой пропуск уже дожидался в проходной. Меглишвили повел меня по лестнице, мы куда-то повернули и очутились в приемной Зураба Ираклиевича. Приемная была размером с баскетбольную площадку. В одном ее углу находился небольшой бассейн с золотыми рыбками. Пол был устлан коврами. Гия что-то сказал секретарше, и та исчезла за дверью, к которой была привинчена табличка: «Директор Зураб Ираклиевич Харакадзе». Табличка была из бронзы. Секретарша появилась через пять секунд и жестом пригласила нас в кабинет.
Зураб Ираклиевич сидел за столом. В руке у него была курительная трубка. Он мне напомнил одного своего соотечественника, очень популярного в свое время. В кабинете было все, что нужно для жизни. Цветной телевизор, бар, кресла, диваны, журнальный столик, книжный шкаф, натюрморты на стенах и тому подобное.
Мы тепло поздоровались, и я вынул из портфеля три экземпляра отчета.
– Вот, – скромно сказал я. – Нам удалось кое-что сделать.
Зураб Ираклиевич взял отчет и взвесил его в руке. Потом он перелистал его, выражая удивленное внимание. Меглишвили делал в это время то же самое, пользуясь вторым экземпляром отчета. Зураб Ираклиевич нажал кнопку и сказал в микрофон:
– Чхилая ко мне.
В кабинете возник Чхилая. Он почтительно взял отчет и стал рассматривать кривые, цокая языком.
– Как ви оцениваете? – спросил Зураб Ираклиевич.
– Именно то, что нам нужно, – быстро сказал Чхилая.
– Ми тоже так думаем, – сказал Зураб Ираклиевич.
Он взял все три экземпляра, подошел к книжному шкафу, открыл его ключом, поставил отчеты на полку и снова закрыл шкаф. По тому, как он это делал, я понял, что отчеты никогда больше не покинут этого шкафа.
– Ви свободны, – сказал он Чхилая. Тот провалился.
Зураб Ираклиевич взял меня за локоть и повел по направлению к бару, расспрашивая о Юрии Тимофеевиче, о его здоровье и прочем. Я стал рассказывать о свадьбе Милы. Это всех заинтересовало. Щелкнули автоматические дверцы бара, засияли зеркальные стенки, заискрились вина и коньяки.
– Что будете пить? – спросил Зураб Ираклиевич.
– Замороженный дайкири, – сказал я, вспомнив один из романов Хемингуэя.
Зураб Ираклиевич слегка склонил голову, оценив во мне знатока. Мой заказ не застал его врасплох. Двигаясь на редкость элегантно, он приготовил три дайкири, и мы уселись за столик, потягивая коктейли из соломки. На столике лежали сигареты «Филип Морис» в коричневой пачке. Разговор шел о погоде, тбилисском «Динамо» и грузинских марках коньяка. Некоторые мы тут же дегустировали. Никто не заикнулся о моей работе. Будто ее и не было.
– Да, чуть было не забыл! – сказал я. – Нужно оформить акты.
Я достал бланки. Зураб Ираклиевич изучил их и положил к себе на стол.
– Завтра вам передадут, – сказал он. – Ну что же… Вам надо познакомиться с Тбилиси. Гия, чтобы все было… понимаешь?
Гия понимающе зажмурил глаза.
…
Я пришел в нашу комнату и показал Чемогурову акты.
– Они даже отчет как следует не посмотрели, – сказал я.
– Ты наивный человек, – сказал Чемогуров. – У них оставались лишние двадцать тысяч рублей. Приближался конец года. Вот они их и потратили. Все довольны – и они, и мы.
– Я недоволен, – сказал я.
saboteur_kiev
15.09.2016 02:15IT просто становится одним из тех направлений, где порог входа не высокий, а очень высокий, и приходится пользоваться сторонними продуктами неизвестного качества.
Таже ядерная физика — можно вообще всю жизнь учиться, и не научиться проектировать ядерный реактор. А если научиться, то хрен соберешь команду, финансирование и вообще возможность построить полноценный проект.
Раньше все было как в точной науке. А теперь — бетон не такой привезли, арматура с примесями и ржавчиной, окна вроде бы те, но по размерам чуток не совпадают, и надо допиливать.
zim32
15.09.2016 02:24+1Да совремнный мир айти это ад перфекциониста. Надо просто понять, что не бывает програм без багов, не бывает идеального алгоритма и не требовать от себя слишком много. Ваш опыт в распильном проекте прекрасный пример.
К примеру очень много правил ПДД написано на крови. Если бы авторы пдд пытались предусмотреть все возможные ньюансы изначально, возможно до сих пор ходили бы пешком. Грустно но правда
rg_software
15.09.2016 02:35+2Мне кажется, автор затрагивает очень интересную тему, но немного драматизирует.
Личные воспоминания о серьёзных проектах от микроконтроллеров до Qt в очередной раз показывают, что наша индустрия всё ещё молода, ведь в самом деле, как уже отмечали, невозможно себе представить, чтобы сегодня хирург делал операцию на сердце, а завтра — на мозге.
Получается, что мы работаем несколько «по-ковбойски»: что-то делаем, оно как-то работает, никто не понимает как, и слава богу. Макконнелл считает, что всё будет двигаться в сторону более строгой бюрократической системе разделения работ на основе лицензируемости. Ну, мы уже видим это на примерах всяких сертификатов Oracle или IBM, но в целом, как мне кажется, он впадает в другую крайность.
Я думаю, что проблема будет решаться по кусочкам. Во-первых, есть вопрос денег. Если вы строите у себя амбар на участке, нет смысла нанимать архитектурное бюро и заставлять инженеров просчитывать сопромат. Упадёт — ну и ладно, новый поставим. Так и у нас, глядя на поделия, то есть, гм, инструментарий для внутренних нужд, можно потерять веру в человечество; но мы же понимаем разницу между амбаром на заднем дворе и продуктом на продажу. При этом и вопрос денег тоже решается по-разному. Скажем, китайцам, которые производят ширпотреб десятками или сотнями тысяч единиц, почему-то проще перевести инструкцию гугл-транслейтом, вместо того, чтобы нанять хорошего переводчика всего на один день (!) Видимо, не считают эти космические затраты целесообразными, что тут сказать. В IT ведь всё то же самое: ну хорошо, наймите отдельного специалиста, который разбирается досконально в Qt (и больше ни в чём), но сначала решите, стоит оно того или нет.
Во-вторых, есть вопрос интерфейсов, документированности и обязательств. Пример с «магической строкой» показывает, что не всё здесь ладно, потому что не хватает культуры производства, и это не только авторов Qt проблема, пока попросту нет всеми принятого подхода, и каждый крутится как умеет. Скажем, мне нравится (хотя бы на идейном уровне) подход к документации библиотеки C++ STL. Для каждого алгоритма указаны чёткие требования по входным данным, гарантии выходных данных и асимптотическая сложность алгоритма. При этом почти везде гарантируется, что самостоятельная реализация того же алгоритма вряд ли будет намного лучше, т.е. мысли «переписать STL» в большинстве случаев возникать не должно. То есть мы имеем чётко определённые «кирпичи» с заданными характеристиками, и лезть внутрь такого «кирпича» совершенно незачем. Сравните это с ситуацией в Python, где сам автор языка последовательно перебирает различные «волшебные» строки с целью ускорить алгоритм (не всегда представляя себе ожидаемый результат).
Иными словами, разделение ответственности и ликвидация «волшебных» строк в целом возможны. Но всё это требует больших усилий, денег и дисциплины. Кому-то удаётся лучше, кому-то — так себе. В общем, ужас, но не ужас-ужас-ужас.
i360u
15.09.2016 05:32+4О, мой любимый пример — GPS! Вам вовсе не обязательно быть специалистом в радиосвязи, ракетостроении и конструкциях спутников, чтобы получать данные от GPS в своем приложении для смартфона. Но вся система, в целом, в таком случае, становится становится некой "магической" средой, где для достижения результата нужно знать определенные "заклинания". Мы живем в интересное время, когда технологии становятся не менее абстрактными, чем идеи, но лично меня это не пугает. Главное — дружить и говорить на одном языке с теми "демонами", с которыми вы имеете дело, а остальной мир пусть остается "волшебным", это же весело! Ну и то, что называется "технологической сингулярностью", ИМХО, давно уже наступило, в глобальном плане. Это было неизбежно, и главное не тормозить с адаптацией собственного мышления к новой среде.
evocatus
15.09.2016 18:21Вы ещё забыли Специальную Теорию Относительности, поправки на которую есть в расчётах GPS
za90
15.09.2016 07:46+2С приходом осени столько нытья на хабре… Крепитесь, люди, скоро лето! :)
Не все возможно доживут, но уж точно мир не рухнет.
ЗЫ: эта статья отличается от прочих в лучшую сторону тем, что в ней хотя бы пара строк кода есть.
NayZaK
15.09.2016 08:27Напомнило доклад дяди Боба «The Future of Programming». Во всяком случае опасения у авторов одинаковы.
Nomad1
15.09.2016 08:40+2Коллегам-психам на заметку на счет чужих библиотек: когда уж сильно прижимает подозрительность и паранойя, я пишу для чужих либ тесты, бенчмарки и собственные реализации. Через день-другой сравнения прихожу к выводу, что для моей задачи библиотека работает так же или лучше, чем самописное решение и с чистой совестью использую ее. :)
Да, бывают и курьезы, например, собраный на коленке из чего-то там и палок RLE для несжатых текстур оказался выгоднее всех существующих. До сих пор не могу себя заставить от него избавиться.greendimka
15.09.2016 14:30я пишу для чужих либ тесты, бенчмарки и собственные реализации
Весьма интересный подход к насущному вопросу.
Но вот в чём другой вопрос: смысл чужих либ как раз таки в том, чтобы не писать свои самому — насколько окупается написание тестов и собственных реализаций? Всегда ли есть на это время? Если нет — то как поступаете?Nomad1
15.09.2016 14:36+1Скажу точно, на это времени никогда нет и в общем зачете почти никогда не окупается! Даже когда получается добиться выше производительности/удобства, например, в собственном физическом движке, то затраченное время никак не соизмеримо с использованием чужого кода. Но зато это весьма наглядно избавляет от шизов вроде «я бы сделал это лучше» )) Если оценивать с точки зрения психического состояния разработчика как залога успеха — выходит вполне нормально. С точки зрения эффективности — ужас-ужас.
Helium4
15.09.2016 10:11Возможно, не будь я программистом, мне не было бы так страшно…
А теперь представьте, как страшно жить химикам, особенно тем, кто связан с производством. В университетский курс входит изучение 3-7 различных направлений химии в семестр. Достаточно, чтоб разбираться в свойства всего, что нас окружает: строй материалы, отделочные, мебель, пищевая химия и экология, лекарственные средства, косметические средства и много другое.
chieftain_yu
15.09.2016 14:04Перед стройотрядом проходил обучение на монтера пути. Поработал, вернулся домой, увидел, как содержались тогда трамвайные пути. Сейчас, кстати, получше стало.
Перед другим стройотрядом прошел обучение на плотника-бетонщика. До сих пор хочу развидеть, как строятся некоторые дома.
greendimka
15.09.2016 10:11Вы правы на все 100%. И от этого грустно. Потому что всем плевать: живут здесь и сейчас, а что будет завтра — не важно: перепишем, перекодируем, пере-, пере-, пере...
zenkz
15.09.2016 10:11+1Я согласен с автором статьи в том, что для обычного программиста бурный рост технологий приводит к тому, что он не понимает что он пишет и для чего. Возможно это связано со старением и молодые джуниоры с горящими глазами и зудом в руках легко с этим всем справляются, но для программистов с опытом всё не так однозначно. Всё чаще и чаще относишься к новым технологиям с настороженностью и не тратишь время на их изучение, потому что не знаешь приживётся она или нет.
Стыдно сказать, что я даже AngularJS знаю очень и очень поверхностно просто потому что реальных проектов с ним не было, а вот-вот прийдёт 2ая версия и может сложиться так, что 1ая мне никогда и не понадобится.
Другая проблема — это компетенция самих разработчиков и команды в целом. Я работал в проектах, где были сильные программисты, середнячки и откровенно слабые. И если у части команды возникали вопросы о том, как будет работать система в целом, какие плюсы и минусы есть у данного решения и т.д, то у некоторых этих вопросов не возникало и они просто кодили или даже собирали пазл из раннее написанного кода и того, что нашли в интернете. Всё это приводило к скрытым и плавающим багам и даже к проблемам в архитектуре. И такого кода много в любой крупной системе.
Поэтому чем больше мы внедряем ПО в нашу жизнь, тем больше вероятность что какие-то из этих ошибок выстрелят и приведут к очень печальных последствиям. Конечно входить в высотные здания и летать на самолёте я пока ещё не очень боюсь, а вот пользоваться онлайн-банкингом побаиваюсь значительно сильнее. (Опять же примерно представляя качество продукта, которым приходится пользоваться).
Но тем не менее — не думаю, что всё вышеописанное — плохо. Это как с автомобилем — все знают что достаточно одного неверного решения или действия — и вы можете погибнуть, но тем не менее все продолжают ими пользоваться потому что удобство от использования перевешивает страх.
golf2109
15.09.2016 10:11+2Какой-то «левый» (перемаркированный) STM32F407VGT6 на иллюстрации
должно быть вот так примерно
/>golf2109
15.09.2016 10:25+2
numitus2
15.09.2016 10:11Сталкиваюсь с таким на работе. Когда писал на core Java. То я точно понимал как работает программа, а теперь постоянно приходится дебажить spring или camel чтобы фиксить баги, потому что я не до конца могу понять как работает тот или иной фреймворк.
Dark_Rider
15.09.2016 10:11А так всегда, и не только в программировании-я тоже так, устроился в компанию, продумывал планы, что я буду делать и как, заполнял таблицы, отчеты, не спал до 3х ночи, ездил по делам фирмы во вне рабочее время-результат? (с армянским акцентом)-пиши заулявление, нам не нрауцца, как ти работаеш.
Это происходит от нежелания людей вникать в нюансы, от непрофессионализма, от жадности, от глупости…
Encarmine
15.09.2016 10:46+1Хочу выразить несогласие с мнением автора. Оглянитесь вокруг — программное моделирование сложнейших процессов, спутники, автопилоты, суперкомпьютеры, роботехника в производстве, IoT, системы поддержки принятия решений, помощь в проектировании сложных систем, числодробилки, криптовалюты, 3D-принтинг, realtime-аналитика, фотореалистичная графика, свободное программное обеспечение.
Да, мы ограничены. Да, мы не всегда понимаем, что мы делаем. Да, сложность зашкаливает, и мы не можем её победить. Ну и что? Это мешает нам делать мир лучше? Каждый чертов день мы можем все больше и больше, и я счастлив принимать в этом участие.
dsmv2014
15.09.2016 11:13Компьютер «Специалист»!!! Как же давно это было. Я его собрал в 1989, и как большое достижение написал что-то похожее на Sokoban, конечно на ассемблере.
А по теме — с ростом сложности происходит разделение по уровням. Пример — сетевая модель OSI. Каждый из её уровней сам по себе очень сложен, но как то они уживаются вместе. И конечно включается естественный отбор. Та же Qt — библиотека смогла выжить, она поддержана большим сообществом разработчиков и позволяет разрабатывать сложные проекты.Vjatcheslav3345
15.09.2016 12:23Вообще может появиться новая научная специальность — разработка абстрактных моделей программных систем, которая позволит хоть немного причесать хаос и займёт такое же место в программировании,, которое в Большой Физике занимают ядерная и квантовая физики. Кое что есть уже сейчас — пример — сетевая модель OSI, или модель STL.
Vjatcheslav3345
15.09.2016 11:48+1У "железных" и строительных инженеров тоже есть свои баги — только называются они по другому — можно погуглить "обрушение", "потеря прочности", "Избранные проблемы прочности современного машиностроения".
Но вот идея о том что программа должна точно соответствовать спецификации — здравая, просто программированию до этого состояния ещё далеко. И у строителей и у машиностроителей была в их проф-й истории такая же "эпоха хаоса" — до того как они начали активно внедрять стандартизацию и сертификацию всего и вся. Сейчас, в связи с развитием интернета вещей, повышения уровня ответственности за жизнь и здоровье людей и повсеместное внедрение 3д принтеров (тут то — в этой точке, и повстречаются программисты с машиностроителями...:) а потом и со строителями) и прочих новомодных штук типа автопилотов или строительных роботов — попоболь от несоответствия стандартам усилится, и это положит начало новому витку стандартизации при котором, например, за применение нестандартного и неодобренного языка начнут "расстреливать на месте без разговоров и без сбора особой тройки — в простом порядке: матрос, винтарь, патрон".greendimka
15.09.2016 14:40+1Огромная разница между софто-инженерами и строителями заключается в том, что строители стараются всё просчитать, но не всё получается. Софто-инженеры же зачастую делают на "прокатит".
— О, Вась, смотри — новая либа, давай её внедрим!
— Но Иван Иванович сказал пользоваться тем, что у нас давно оттестировано и слажено работает.
— Вааась, Иван Иванович старпёр со своим С++/C#/Fortran'ом (нужное подчеркнуть) — не идёт в ногу со временем! Эту либу используют все популярные мордокниги/файлохранилки/инстаграмушки.
— Ну не знааю, ну давай…
Такая типичная ситуация: слить старое только потому, что оно не новое. Плевать на тесты, плевать на баги. Главное внедрить очередную новинку — даже не задумываясь о последствиях.
pestilent
17.09.2016 07:47Интересно, у строителей бывают ситуации, когда они исправили баг, приведший к обрушению дома, а в результате дом стал рушиться в трех других местах? И они откатили исправление и продолжили строить по-старому, объявив обрушение дома «фичей»?
Sergey_34
15.09.2016 12:09«Если теперь рассмотреть эти две описанные мною беды как единое целое: программисты не до конца понимают как работают их программы, плюс заказчик не может проверить результат»
Зависит от специфики проекта и компании.
«Будем ли мы бояться летать на самолетах и ездить в беспилотных автомобилях? Можно ли верить медицинским приборам? Не побоимся ли мы входить в систему онлайн-банка? „
В области авиации и медицины очень высокие стандарты обеспечения качества. В области банковских услуг пониже, но всё-равно больше чем в большинстве проектов, и, зачастую, потери вызванные из-за программной ошибки возмещаются банком.(торги на электронных биржах не в счёт)
anprs
15.09.2016 13:04Походие вопросы поднимались в статьях:
https://geektimes.ru/post/279548/
https://habrahabr.ru/company/pvs-studio/blog/307788/
считаю, что ПО от которого зависят жизни и здоровье людей (автопилоты самолётов, электронные помощники в авто, управление медтехникой и реакторами АЭС) должно быть либо открытым (чтобы любой заинтересованный мог проверить логику его работы), либо быть написаным специалистом, подписавшим договор о персональной административной/имущественной/уголовной ответственности за последствия работы его программы.chieftain_yu
15.09.2016 14:09+2Открытость OpenSSL не помогла уберечься от Heartbleed.
Возможность проверки кода не означает, что хоть кто-то ее будет проводить.
golf2109
15.09.2016 13:54Автор ставит вопрос — «Можно ли верить медицинским приборам? „
Желаю автору не болеть всю жизнь.
Иначе без анализов (которые делаются медицинскими приборами) доктора его
“пошлют» — и останется только что то вроде «нетрадиционной медицины»chieftain_yu
15.09.2016 14:06Медицинским приборам в целом можно верить при условии соблюдения персоналом правил их эксплуатации.
Впрочем, проблемы бывают не только при невыполнении правил, но и при некоторых предположениях, закладываемых в логику работы приборов.
LookingAhead
15.09.2016 16:07Уже есть пример из жизни: сотовый телефон через который порой невозможно поговорить из-за глюков то ли сети, то ли самого телефона. (обрыв во время разговора, тебя не слышат/ты не слышишь, отбой во время дозвона, пропала сеть)
edogs
15.09.2016 16:28+3Начали хорошего примера.
Про цветок.
Да, Вы объяснили силой тяжести и его ростом причину его падения, но разве Вы знаете откуда взялась сила тяжести и/или почему он рос? Знание причин почему что-то работает никогда полным не будет.
Так почему это это должно быть проблемой именно в программировании?
Это не проблема, это реальность, и тут самое главное суметь ее принять.
«premature optimization root of evil» по большому счету оттуда же, от желания все сделать идеально правильно, но именно поэтому эта идея и проваливается.
Некоторое количество погрешностей будет всегда и без понимания этого нет самого важного — понимания что с этими погрешностями надо работать и как надо с ними работать.
Упрощая… допустим Вы не знаете почему этот цветок падает, но раз Вы можете предусмотреть такую возможность, просто привязываете горшок веревкой.
farwayer
15.09.2016 18:33+2Я суеверный человек. Знаете, как я к этому пришел? В один прекрасный момент я осознал всю сложность окружающих нас систем. До мурашек на коже осознал.
Подумайте только, что происходит, когда вы смотрите котиков на ютубе. Огромное число элементов взаимодействуют друг с другом: железо сервера от разных производителей (оператива, процессор, сетевая карта, хранилище, шины данных), firmware для этого железа, ОС с тысячами библиотек, написаных разными людьми, веб-сервер, каналы связи, маршрутизаторы со своим ПО, железо вашего компа со всем его firmware, ОС, браузер, кодеки. Все это передает данные друг другу по разным протоколам, использует разные технологии. На самом деле это только верхушка айсберга. Если разбирать каждый элемент этой системы — он сам по себе представляет сложную систему взаимодействующих частей.
Все, что происходит, я могу назвать только волшебством. Не потому, что я не понимаю, как это работает, а как раз наоборот — потому что я более-менее знаю, что происходит. Мне не дает покоя один вопрос: какого лешего это всё не ломается уже сейчас?
Сразу отвечу насчет стандартизации и тестирования — это не панацея. Все мы знаем, что идеального ПО не существует.
Представьте себе, что в алгоритме одной библиотеки есть ошибка: при определенной последовательности входных данных на выход вылетает мусор. Сможем мы протестировать эту последовательность, если она встречается довольно редко? Нет. Мы не может потестировать все пространство входных данных, иначе в этом алгоритме не было бы смысла: достаточно было бы взять матрицу вход/выход из тестов. Все ПО, которое использует библиотеку расчитывает на корректность ее работы. Что в итоге? UB работы всей системы.
Это простой случай. А теперь более сложый. Если эту последовательность не тестировали, потому что она никогда не должна была поступить на вход? Но случилось так, что элемент системы от которого пришли данные тоже имел небольшую ошибку. Эта область пересечения нескольких ошибок разных частей и вызвала крах всей системы. Такие вещи практически непредсказуемы.
А теперь представьте, что в современных гипер-сложных системах сотни (если не тысячи) таких точек возможного слома. Просто они спят и ждут своего часа. Еще не страшно? Сейчас-сейчас… А давайте мы добавим в систему более непредсказуемые элементы навроде нейронных сетей? Сдобрим это все генетическими алгоритмами? И заставим системы больше взаимодействовать с реальным миром и друг с другом, добавив тем самым сложности и случайности?
Завидую людям, которые не заглядывают на другие уровни абстракции. Как же им проще: они уверены, что когда что-то используют — все будет хорошо. Вы как хотите, а я пойду выбирать себе талисман на удачу :)
P.S. только что наткнулся на статью, которая сильно перекливается с моими мыслямиstargazr
16.09.2016 02:56Ваши рассуждения напоминают анекдот о вероятности падения метеорита 50% — может упасть, а может и нет.
Если вы думаете, что оно должно сломаться, а оно все никак не ломается — это не волшебство, это вы неправы.farwayer
16.09.2016 04:08А оно ломается. Просто пока это единичные случаи. Думаю, существует некая граница энтропии системы, при приближении к которой вероятность возникновения ошибки будет стремиться к единице. Вопрос лишь в том, как скоро мы приблизимся к этой границе.
stargazr
16.09.2016 12:54Вообще теперь ничего делать не будем?
У каждой системы есть срок службы, в конце концов.farwayer
16.09.2016 14:18Я не имею в виду износ. Я говорю про то, что в определенный момент в созданной сложной системе вероятность возникновения ошибки будет велика. К этому просто нужно быть готовым. Мы уже давно пытаемся отсрочить этот момент, создавая новые языки, инструменты и подходы. Но, думаю, есть какой-то теоретический предел сложности, и рано или поздно мы к нему подберемся.
Хотите свежий пример? Есть смартфон от фирмы S с номером 7. Думаю, вы в курсе новостей. Тестировали ли аккумулятор во время разработки? Конечно да. Сам смартфон? Определенно. Контроллер зарядки? Да. Все вместе? Конечно!
Почему же он взрывается? Дело не в качестве отдельных частей, но в их объединение. Это объединение создало сложную систему не только с новыми свойствами, но и с новыми потенциальными ошибками.
Почему же эти ошибки не нашли во время тестирования? Отдельные части были протестированы и, думаю, работали хорошо. Насколько я помню, число бракованых смартфонов составляет 25 на миллион. Как вы думаете, какова была вероятность наткнуться на этот баг во время тестов всего смартфона? Очень мала. Смарт выпустили на рынок — и тут сработал закон больших чисел.taujavarob
16.09.2016 14:46Почему же он взрывается?
Брак при производстве. Который выразился в сильном сжатие батареи (при её производстве), что и приводит к возгоранию.
Причина: При производстве не проводился достаточный(!) контроль на деформацию батареи.
Виновные наказаны (расстреляны?) — но осадочек и не слабый то, остался.farwayer
16.09.2016 15:06Да вы правы. Я раньше читал, что проблема была в том, что контроллер зарядки давал повышенное напряжение, к которому батарея была не готова. Видимо, все оказалоось проще.
kvark
15.09.2016 18:40-2Если программисты и далее будут писать микроконтроллеры на Node.js, то да, всё плохо. Выбор языка программирования не решает всех бед, но позволяет существенно повлиять на доверие к поведеню программ. Скажем, сильная типизация Rust позволяет избежать множества ошибок ещё до тестирования, а также гарантирует определённое поведение при исключительных ситуациях (паника).
Отставив проблемы человеческих отношений в сторону (это отдельная тема), я вижу большой потенциал в развитии парадигм программирования и инструментов, их реализующих. Скажем, если вы в функциональном языке вызываете чистую функцию с определёнными параметрами, то во-первых можете быть уверены, что результат при тех же аргументах не изменится; а во вторых, что она не станет ломать пентагон и нажимать на красную кнопку.
farwayer
15.09.2016 19:06Функциональное и чистое программирование стало популярным сейчас не просто так. Современные системы становятся все более и более сложными. Это попытка снизить эту сложность, отсрочить на время ад комплексных систем.
stargazr
16.09.2016 03:06Будут, конечно, писать на node.js (openwrt там, все дела). То, что в нодах можно в одну уже тысячу раз написанную строку реализовать, вообще не задумываясь, в этих ваших ассемблерах придется отлаживать до пенсии.
s7onoff
15.09.2016 19:43+2Почему-то автор статьи и многие комментаторы искренне, как мне показалось, считают, что данная «проблема» касается только программирования и программного обеспечения.
Вот, например, автор боится идти по мосту, потому что программисты, которые писали программы проектирования мостов, не знали до конца, что именно они делают, а заказчик программы (по сути — конечный её пользователь) вообще не разбирается в программировании.
Но при этом автор забывает, что мост проектировала не только программа, но и люди. И не поверите — 99% проектировщиков мостов и других сооружений и зданий не являются специалистами в теории упругости. Да многие (очень многие) не вспоминают даже простого сопромата при проектировании строительных конструкций. А еще очень мало кто из них является специалистом в материаловедении и не представляет себе ни состава используемой стали, ни процесса прокатки двутавровых балок. Конечно, проектировщик, который знает всю подноготную строительства от добычи ископаемых до покраски фасадов ценится выше. Но таких, честно скажу, не много.
Да, у нас, у проектировщиков, все то же самое — разделение труда и совершенно слепое использование чужих наработок. Один институт разрабатывает состав бетона, второй разрабатывает технологию его укладки, третий — сталь для арматуры, четвертый — профиль арматуры, пятый — формирует серию на изготовление железобетонных плит, шестой — просто применяет их в проекте. Всё то же, что и в программировании — есть низкоуровневая разработка, есть высокоуровневая, есть библиотеки готовыхфункцийинженерных решений, есть конечныепрограммыпроекты, использующие их.
А заказчики у нас техзадание вообще писать не умеют. Совершенно. Абсолютно. Приходят и просят проектную организацию саму себе задание написать и ставят под ним подпись.
И это в любых областях нашей жизни так — терапевт в районной поликлинике — не микробиолог и может не представлять себе, как именно лекарство будет воздействовать на ваши клетки. А вы, как заказчик работы терапевта — тем более.
Так что еще можно поспорить, кто быстрее погубит мир))
PavelGatilov
15.09.2016 19:44Статья навела уныние, но так устроен мир прогресса. Каждый должен уметь делать одно дело, но хорошо и уверенно.
Я осознал это в первый раз, когда мне ученный(доктор наук) физик ядерщик не смог во время одной из дискуссии ответить, как при помощи закона Гука рассчитать прикладываемую силу к пружине, при известной степени деформации.
M_AJ
15.09.2016 19:44Однако были и нюансы:
Эти нюансы по хорошему должен разрешать специальный человек, который называется «инженер-системотехник». Именно он и должен был обеспечить коммуникацию между вами и «железячниками», и разбираться с тем, что Вы назвали «Бедой N2».
Вообще, странно, что вы задались этим вопросом только сейчас, потому что на самом деле наш мир работает так уже достаточно давно. Если взять любую сложную систему, то мы вряд ли найдем человека досконально понимающего нюансы работы всех ее подсистем. Взять даже ассемблер, когда Вы пишите команду, думаете ли Вы о том, когда конкретно процессор ее вычитает, во что преобразует ее декодер инструкций, что произойдет с ней в конвейере, в каких физических регистрах окажется результат, и так далее? Думаю, что вряд ли, и процессор для Вас тоже своего рода «черный ящик», но ящик привычный, и потому не вызывающий вопросов и опасений «а вдруг там баг», а вот библиотека — ящик непривычный, отсюда и опасения.
На самом деле, если начать задумываться о том, сколько «деталей» и процессов должно быть задействовано, чтобы отправить или прочесть это сообщение, сколько тысяч людей понадобилось, чтобы все эти «детали» создать, сколько подводных камней им пришлось обойти, чтобы заставить это заработать, и сколько во всем этом мест, где что-то может сломаться, недолго заработать тяжелую форму паранойи.
stargazr
15.09.2016 19:55-1Статья полна откровенной тупости, и автору почему-то смешно, а не стыдно, и винит он в этом кого угодно, только не себя.
>>Эй! Коллега программист! Это что еще за хрень?
Об этой «хрени» наверняка есть где-то целый раздел в документации (где, возможно, и строчечки те волшебные приведены), который эти две кодомакаки, по обыкновению, не читали. А потом им «что-то слишком сложно и непонятно все, я боюся чо-то». (Да, я знаю, что бывают баги в либах, но чаще всего виноваты все же не они, а сами макаки.)
А вообще, есть такая хорошая книжка Гради Буча, называется «Объектно-ориентированный анализ и проектирование». Он там наглядно (в смешных картинках с котиками), но очень толково объясняет, как программист может понимать, почему (не)работает система, не разбирая в деталях устройство ее компонентов, и почему пользователю сложная система может казаться простой и понятной (и это правильно). Так что снизу доверху знать, «как работает программа», не нужно.
vcooking
15.09.2016 20:24Программист знает как работает его код. Если не знает — то он не программист. Как работают всякие подключаемые библиотеки — не знает и знать совершенно не обязан. Заказчик тоже совершенно не обязан понимать тонкости написания программ. Не понимаю в чём пафос статьи.
taujavarob
15.09.2016 20:36Не понимаю в чём пафос статьи.
Были времена, где программист мог объяснить поведение своей программы с точностью до ячейки памяти.
Те времена канули в лету.
farwayer
15.09.2016 21:51Ой, ну в самом деле, зачем программисту, чтобы приложение работало стабильно и без багов? Ведь ему же деньги платят, чтобы его код работал, верно?
stargazr
15.09.2016 21:59Никто вам не даст исходники чипов и плат, из которых собран ваш компьютер.
Следовательно, знать от и до, как работает программа, вообще невозможно.farwayer
15.09.2016 22:13Я не говорю про полный контроль над всей системой. Тут товарищ даже не готов разбираться в библиотеках, которые он выбирает для своего проекта. Мне кажется, что это входит в обязанности хорошего разработчика.
stargazr
16.09.2016 02:22Это не подразумевает ковыряния в этих библиотеках. Тем более, что много хороших фреймворков вообще закрытые.
Этот «товарищ» вам все сказал правильно, слово «инкапсуляция» вам о чем-то говорит?farwayer
16.09.2016 14:39Я не буду разбираться до мелочей, как работает та или иная библиотека (при условии, что я не разрабатываю ПО, которое, возможно, будет использоваться в критически важных системах).
Но я могу оценить подходы в разработке: качество кода, покрытие тестами, общую архитектуру, число тикетов на багтрекере, насколько их быстро закрывают, кто эту библиотеку разрабатывает в конце концов. И это срабатывает в большинстве случаев.
В случае закрытого ПО я не смогу этого сделать. Мне приходится верить. Что-что, а обещать в современном мире красивых презентаци и лендингов умеют все. Вот я даже не смогу исправить ошибку в библиотеке, если на нее наткнусь.
Еще один совет: когда вы собираетесь выложить свою библиотеку в открытый доступ — помните, что какой-то чудак может использовать ее на атомной станции :) Пишите хороший код.stargazr
16.09.2016 15:52Спасибо большое за совет! Буду писать игровой движок на джаваскрипте — обязательно подумаю о новой Фукусиме!
А если серьезно, вам уже миллион раз написали, что у всего есть свои сценарии использования (т.е. интерфейс) и сфера применения.
То, что библиотека ведет себя так, как описано в доках, и используется в тысячах проектов, у вас не срабатывает? Хотя вот, например, openssl… Ах да, она же открытая.
farwayer
15.09.2016 22:20Собственноручно написаный код не выполняется в вакууме. Как минимум используются библиотеки и есть какое-то окружение. Заказчику не нужно знать, как работает приложение. А вот задача разработчика — предоставить для заказчика стабильно работающее приложение, а не написать код.
stargazr
15.09.2016 21:53-1Просто автор не в состоянии осознать свою некомпетентность. Проблема не в том, что программы сложны, запутанны и ненадежны, а в нем самом и таких специалистах, как он. Программирование тут ни при чем, это что угодно могло бы быть.
nckma
16.09.2016 17:51+1Ошибаетесь.
Я как раз таки осознаю свою некомпетентность. Я не понимаю как ее преодолеть. Преодолеть можно, но это время, которого на самом деле почти нет.
Смотрите, предположим меня просят участвовать в проекте с использованием Qt, который я ранее не использовал. Однако руководство считает, что мне нужно временно помочь коллегам с этим проектом. Естественно я как могу быстро пытаюсь понять, что такое Qt и как это работает.
По собственному опыту или по собственной не компетенции могу сказать, что некоторые компоненты Qt работают довольно загадочно. По крайней мере для меня.
Например: QMediaPlayer воспроизводит локальные видео файлы точно как описано в документации, можно делать паузу, воспроизведение и менять позицию воспроизведения. Однако, если вместо локального файла использовать QUrl указывающий на сетевой ресурс, то воспроизведение начинается, но сменить позицию воспроизведения setPosition() уже не получается. Почему? Почему QMediaPlayer не следует документации Qt? К слову в документации Qt фообще нет упоминания про воспроизведение из сетевых ресурсов. Может это вообще нельзя?
Это происходит в Windows c Qt мультимедиа бэкендом dsengine_plugin.
Если же ту же самую программу без изменений компилировать и запускать в Linux, с мультимедиа бэкэндом gstreamer, то все работает: и setPosition() так же замечательно работает. Что за такая кроссплатформенность в Qt, которая по разному себя ведет на разных платформах? И как я это должен чинить? Нам просто повезло, что оказывается Qt предлагает для виндовс на выбор второй мультимедиа бэкэнд wmfengine_plugin, который и в виндовс ведет себя достойно. Но почему он в Qt библиотеках по умолчанию не стоит? Для меня это сплошное недоумение.
Должен ли я не разобравшись до конца, почему один бэкэнд лучше другого просто плюнуть и использовать второй? Или нужно тратить время и разбираться где баг в библиотеке Qt?
Да, я согласен. Моя не компетенция. Но эта такая «не компетенция» которая занимает полторы недели безрезультатного поиска в гугле и чтения документации Qt, в которой про воспроизведение из сети вообще ничего нет.
stargazr
16.09.2016 02:46«OpenGL? Не, не слышал!»
Года три назад я себе представить не мог, что увижу такое на хабре.
Neuroware
16.09.2016 10:12Все не так уж плохо, все таки мы не работы и для нас не так важно работает ли тот или иной прибор или программа «прям так как задумано» или чуть иначе, понимание «на 100%» важно если например это управление лифтом\самолетом\медицинским оборудованием, а для прикладного софта или сайтов это не так уж и критично. К примеру у меня есть приложение, в котором ошибки возникают постоянно, это особенность архитектуры (так было задумано изначально), но это не мешает ей исполнять свое предназначение и более того, никто это даже не заметит, так что ИМХО даже в случае наступления сингулярности люди просто примут ее как должное и будут «привыкать» к тому что есть.
Sokolyuk
16.09.2016 15:15Один мой приятель, работавший когда-то администратором БД в центре авторизации банковских карточек, все держит наликом и всегда сразу снимает всю З/П со своей карточки.
vcooking
16.09.2016 16:34Почему-то вспомнился диалог, переданный мне моим бывшим непосредственным начальником (нет, начальник наверно никуда не делся — это я поменял работу)
посредственный начальник: — И чтоб через 3 месяца было готово!
непосредственный начальник: — Мы не сможем обрабатывать абсолютно все записи — и будем терять по миллиону в квартал на недовыставленных счетах
посредственный начальник: — Плевать, мы платим 3 миллиона в квартал за аренду софта, который выставляет все счета правильно
A-Stahl
>QT
Когда я был маленький и учился в школе, то как-то раз на уроке русского языка я написал слово «русский» через одну «с». Преподаватель тогда ткнула меня рожей в учебник, на обложке которого большими буквами было написано «Русский язык» и строго так спросила: «Ну как, бестолочь ты сопливая, можно было допустить эту ошибку?!»
Так к чему это я? К тому что посмотрите на свои иллюстрации, которые вы приложили к статье, и не пишите никогда «QT» в данном контексте.
alex4321
просто спросил бы, при чём тут QuickTime :-)
Cyl
Это явление закономерно, когда сапожник печет пироги, а сапоги шьет пирожник, эдакая война миров. Надо полагать, будущее программистов будет неизбежно упираться не в языковый скрипт выражающий клиентский поведенческий алгоритм, а в создание платформы нового поколения с инструментальной средой генерирования исходников в интерфейсе под конечного пользователя и пусть он там играется со своими алгоритмами до одури, симулирует свои процессы, в финале отправляет в печать готовую PCB.
A-Stahl
Вы, наверное, ошиблись веткой. Я всего лишь хотел сказать, что QT и Qt это разные вещи. И это не мелочи, как вероятно думают любители затыкать рот сраньём в карму.
Sixshaman
Таки это мелочи. Какая разница, как это было названо, если все поняли, о чём идёт речь?
A-Stahl
Нифга не млечи эт. Есл все можн пнять, то эт нихр ещ не значт.
P.S. Ну как? Всё ведь ясно и понятно.
WST
Нет, это, как раз-таки, мелочь. Многие даже не знают, что «Qt» — это не аббревиатура. Удивляет, как на это постоянно обращают внимание, а на то, что в четверти, а то и в трети, всех хабратопиков неправильно употребляется деепричастный оборот, закрывают глаза. Например, прямо сейчас на главной странице висит: «Пережив некоторые трудности, сегодня это — достаточно зрелый продукт». Не говоря уже о всяких «Нажав на кнопку, начинает звучать мелодия» и подобное. Вот где, действительно, не мелочь, но никто словно не замечает. Или правда не замечает? Видимо, куда проще показать свою «грамотность», заучив какой-нибудь шаблон, что «Qt, а не QT», что «Андроид, а не Андройд».
A-Stahl
>Или правда не замечает?
Я не замечаю там ошибки. Может ошибки и есть. А может их нет. Но в любом случае я их не вижу. А в Qt/QT вижу. И исправляю. В чём проблема?
WST
В том, что это избитая и заезженная тема. Вы не научите каждого говорить так, как считаете нужным, а если очень сильно хочется, то это можно сделать и в привате. Как я уже сказал, на Хабре полно куда более грубых ошибок, и то, что вы их не видите в приведённых мной примерах, лишь иллюстрирует плачевность ситуации. Но при этом Хабр пестрит обвинениями в одних и тех же ошибках. Это уже все видели, просто кто хотел, уже давно взял это на вооружение, остальным это бесполезно объяснять.
По поводу деепричастных оборотов читайте здесь. Есть ещё очень распространённая ошибка с мягким знаком (или его отсутствием) в глаголах, оканчивающихся на «ться» и «тся». И про это тоже есть сайт, правда, я далеко не первый, кто на него ссылается. Эту ошибку, всё-таки, хотя бы иногда замечают и исправляют.
kakoi_to_muzhik
Да, пиши так дальше. Я не против
olegy
Тоже считаю, что не мелочи. Один бывший сотрудник — программист не выключал в туалете свет. Ну как можно — включить и не выключить!
И это программист. Страшно предстаить, что там в коде :)
kekekeks
Это не мелочи. Это «нечего сказать —
доедокопайся до орфографии».Yggaz
Вот неправда ваша. Ошибки в тексте перекладывают издержки на читателя. То есть не пишущий тратит больше сил, вычитывая текст до правильного состояния, а каждый читающий должен восстановить, что же там имелось в виду.
Это нехорошо. Не надо так.
kekekeks
Про ошибки в тексте надо писать исключительно в ЛС. В противном случае сообщения о них приводят к абсолютно неконструктивным веткам комментариев на три экрана. Соответственно, целью пишущего о них в комментариях может быть только разведение флейма.
evocatus
Все поняли о чём речь, но если столкнутся с тем, что на самом деле называется QT, то будет путаница.
Я на работе уже всех выдрессировал называть I2C «ай-ту-си» или «и-два-цэ», а не «и-два-эс». Потому что есть I2S.
toxicdream
А mp3 вы как говорите?
Lamaster
> пусть он там играется со своими алгоритмами до одури
Никогда конечный юзер не будет играть с алгоритмами. Во первых он в этом не разбирается, во вторых ему это не интересно.
Cyl
LabVIEW это так, цацки — пецки?
MinamotoSoft
Псих?