Вы работаете программистом и практически каждый день пишете код. Скажите, как часто вы чувствуете удовлетворение от выполненной работы и гордость за результаты своего труда? Случалось ли вам выпускать работающий, но некачественный и «некрасивый» код только для того, чтобы уложиться в сроки? Есть ли у вас мотивация писать оптимальный код, зная, что через пару месяцев он станет неактуальным и бесполезным?
Попробуем разобраться, как же так получилось, что программирование из красивого искусства и творчества превратилось в повседневный рутинный конвейер.
Потогонный конвейер
Если вы работаете в коммерческой фирме, то вам, наверняка, знаком термин «time to market» — временной промежуток от появления идеи продукта или функциональности до выхода на рынок готового продукта. Нынче все стараются этот промежуток сократить. В коммерческой разработке правит бал ускорение процессов.
Релизы следуют один за другим, все участники разработки ПО вечно не укладываются в намеченные сроки и работают сверхурочно. И всё это делается с одной целью — поскорее продать потребителю готовый продукт. Тут уже не до изысков разработки и не до качественного кода — конвейер не должен останавливаться.
Продукт выпускается в срок, возможно, даже без критических ошибок: цель достигнута. Но каждому, кто участвовал в разработке, прекрасно видно, что творится за красивым рекламным фасадом. В системе постоянно накапливается технический долг, увеличивается количество «хардкода», все временные решения становятся постоянными. Попытки хоть как-то исправить ситуацию обычно ни к чему не приводят: «Очень хорошо, что ты это заметил, но сейчас времени на исправления нет, но, возможно, в будущем мы это поправим». Всё остаётся по-прежнему и на основе всей этой шаткой конструкции продолжается развитие системы, реализуется новая функциональность.
Пластмассовый мир
С другой стороны, кому сейчас нужны долговечность и качество? Большая часть написанного кода будет использоваться в системе максимум несколько месяцев, а затем будет заменена или переработана. Какой тогда смысл писать этот код идеально? Представьте, что вы каждый день занимаетесь тем, что штукатурите комнату в доме, прекрасно зная, что через день этот дом снесут. Тут у кого угодно опустятся руки.
Складывается впечатление, что многим фирмам просто невыгодно выпускать качественный долговечный продукт. Если сделать смартфон удобным и надёжным, то кто из потребителей через год захочет покупать новый? Так появилось явление, которое называется «запланированное устаревание». Мы все живём в пластмассовом мире недолговечных вещей.
Вспомним, например, как Microsoft случайно выпустила довольно сносную Windows XP. Пользователям она настолько понравилась, что они ни в какую не хотели переходить на следующую версию ОС. Затем история отчасти повторилась с Windows 7. Но больше таких «ошибок» Microsoft не допускала — переход на следующую версию системы стал добровольно-принудительным.
Видимо, именно по этим причинам сегодня всё реже задумываются о красоте и об оптимальности выпускаемых систем. В коммерческой разработке главенствует принцип «Вам шашечки или ехать?»
Набор «Сделай сам»
Современная среда разработки ПО тоже не поощряет программистов к написанию быстрых и эффективных приложений. Для создания даже простейших решений и систем используются многочисленные фреймворки, платформы и тулкиты. Эти инструменты, безусловно, сильно упрощают и ускоряют разработку. Но при этом процесс программирования превращается в сборку программ из готовых кубиков-блоков. Оптимизация работы приложения при таком подходе отходит на второй план.
Это немного напоминает первые сотовые телефоны. На первый взгляд эти телефоны выглядели довольно компактно. Но на поверку эта компактность оказывалась мнимой. К телефону прилагался увесистый чемодан-аккумулятор, который постоянно нужно было носить с собой.
Программы, написанные в ранних версиях Visual Basic, тоже выглядели довольно компактно — сам исполняемый файл программы был небольшого размера. Но он был неработоспособен без дополнительного файла библиотеки MSVBVMXX.DLL с виртуальной машиной для запуска приложения.
Чем ситуация с сегодняшними приложениями лучше? От разработки на ассемблере и низкоуровневого программирования нас отделяет не один и не два, а десяток уровней абстракций и инструментов. Решение собирают из разрозненных полуготовых модулей, которые плохо подходят друг к другу. Чтобы всё это кое-как держалось и работало, используют клей и изоленту.
Судя по всему, сейчас разрабатывать коммерчески успешные приложения по-другому не получится. Приведу прекрасный комментарий с Хабра, который полностью отражает сложившуюся ситуацию: «Я раньше поражался тому, как уродливы изнутри „взлетевшие“ проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики».
Искусство программирования
Так кто же такой современный разработчик: ремесленник с удовлетворительным знанием инструмента или мастер, достигший вершин своего искусства? Этому вопросу уже много лет. Похоже, что в современном мире разработки творческих мастеров совсем не ждут. Часто приходится встречать такое отношение руководства: «По мнению моего начальника, программирование — это ремесло. И спорить с ним бесполезно. Он считает, что программист с творческим подходом к делу вообще вреден и ни в коем случае его брать на работу не надо».
Многие из мастеров, чтобы выжить, даже вынуждены маскироваться под ремесленников: иначе не получится уложиться в запредельно сжатые сроки разработки.
Безусловно, в любом деле нужны не только высококлассные мастера. Везде найдётся дело для простого работяги, окончившего полугодовые курсы программирования на одном из обучающих сайтов. Но проблема в том, что при этом неуклонно снижается качество программ. Установка новой версии какого-нибудь мобильного приложения превращается в игру «Угадай, что они ещё умудрились сломать». Если на стройке не будет знающего образованного инженера, то даже самые усердные и дисциплинированные рабочие смогут построить добротный надёжный дом разве что случайно.
Дональд Кнут назвал свою книгу «Искусство программирования». Первое издание этой книги вышло ещё в далёком 1968 году. Тогда программирование было ещё искусством. Жаль, что профессия программиста постепенно становится всё более прагматичной и приземлённой. Но хотя бы в своих pet-проектах мы всегда можем заниматься свободным творчеством и не играть по корпоративным правилам.
Статья была впервые опубликована на другом ресурсе 2 августа 2021.
Комментарии (51)
Jammarra
23.12.2021 18:02-1как же так получилось, что программирование из красивого искусства и творчества превратилось в повседневный рутинный конвейер.
Кто сказал что программирование хоть когда то в истории было искусством? Да было пару гиков которые программировали ради программирования. Но в рамках индустрии это всегда было направление которое решало сугубо прикладные задачи. До сих пор с содроганием вспоминаю Windows 95 и то как он лагал. О каком искусстве речь о откуда берутся статьи типо https://habr.com/ru/post/597217/ мне откровенно не понятно. Ну если только люди стареют сидят на лавочках и ругаются "Вот в наше то время мы танки руками гнули"
OlegZH
23.12.2021 20:25+4Вы, даже, не представляете, насколько Вы не правы. В прежние времена было так: были прикладные задачи, учёные-специалисты приждумывали решения, создавали вычислительные архитектуры и языки программирования. Однажды, был создан Алгол. На этом язке очень хорошо описывать и объяснять алгоритмы. Помнится, была такая книга "Построение и анализ вычислитлеьных алгоритмов" (Ахо, Ульман, Хопкрофт). Все примеры — на алголе. Алгол дал нам Паскать, Аду, Модулу и Оберон. Системники выдумали Си. Был ещё Рефал. Математикам очень пригодился Фортран. А ещё и Кобол. Была специализация. Было понимание того, что каждый язык должен решать свою задачу. Нельзя насыщать язык программирования средствами. Современные языки программирования монстры. Раньше было понимание того, что инструкции языка программирования должны иметь чёткий смысл, и что не надо выкуривать мануалы с описаниями библиотек. (Я застал начало этого современного ада, кагда в самом начале 90-тых была издана книжка, где специальным образом отражались особенности реализации Turbo C и Microsoft C.) Это, извините, совсем не про то, что "в наше время". Даже Ваш пример с Windows 95 — это пример, потверждающий сказанное в статье. Потому как победило, так сказать, прикладное программирование. Вот Вам вопрос "на засыпку", во что можно превратить операционную систему, если делать её по науке? Где давно обещанный "интуитивный" и "объектно-ориентированный" интерфейс? Почему ОС — это не система типа СУБД, тоолько для прогрнаммого кода? Если делать по науке, то надо программный код хранить в базе данных: нужно определённое приложение? Сделал нужный запрос к базе даннных! Всё было бы прозрачным и управлямым.
Jammarra
24.12.2021 10:04+2Ну возьмем пораньше DOS был отличной системой? Я не согласен.
Назовите хоть один идеальный софт.Математикам очень пригодился Фортран. А ещё и Кобол.
О да на них то писали идеальные программы. Вы хоть раз этот софт на фортране видели? Да от него кровь из глаз идет. Тем ни менее он решал сугубо прикладные задачи для математиков. Хоть и был ужасен. И не был ни каким искуством.
Сейчас же он просто им не особо нужен ибо есть Python и Mathcad и Mathlab которые делают тоже самое проще лучше и быстрее. Посади их обратно на ваш любимый фортран и они вас проклянут.write (*,*) Текст read (*,*) nЧто говорится очень удобный и понятный синтаксис. Прям шикарный
OlegZH
26.12.2021 11:35... ибо есть Python и Mathcad и Mathlab которые делают тоже самое проще лучше и быстрее.
Оценочное суждение. Где-то и проще. Где-то и лучше. Где-то и быстрее. Но ещё интереснее было бы узнать о надёжности и точности вычислений, об устойчивости результатов вычислений. Тут не всё так просто. Именно поэтому на занятиях по методам вычислений в вузе рекомендуют с большой осторожностью ловерять результатам современных пакетов. В этом смысле, код, написанный на старом языке програмимирования, может вызвать большее доверие: синстаксис языка гарнтирует точную семантику всех операций, а годы разработок — отлаженный и практически безошибочный код.
Jammarra
26.12.2021 12:20В этом смысле, код, написанный на старом языке програмимирования, может вызвать большее доверие: синстаксис языка гарнтирует точную семантику всех операций, а годы разработок — отлаженный и практически безошибочный код.
Ну или это просто синдром утенка у преподов которым уже под 80 лет. Кто знает.
lair
23.12.2021 18:03+4кто он — ремесленник или мастер
А почему вы противопоставляете ремесленников мастерам?
OlegZH
23.12.2021 19:16+1Как ни странно, в статье даётся четкое представление о том, каково оно, это различие, по мнению автора. Читаем:
Для создания даже простейших решений и систем используются многочисленные фреймворки, платформы и тулкиты.
Ремесленник — этот тот, кто хорошо овладел многочисленными фреймворками, платформами и тулкитами. Мастер — это, прежде всего, тот, кто грамотно ставит задачу и находит адекватные способы её решения. То есть — действует избирательно. Мастер — этот, кто способен программировать без ошибок. В том смысле, что он способен долго-долго подумать над проблемой а, затем, быстро-быстро сделает реализацию подходящего (высокого) качества. Типичный ремесленник быстро бежит к станку и быстро пытается предъявить свой первый релиз и обрекает начальсвто и заказчиков на бесконечный поток релизов. Мастер постарается до конца понять проблему.
P.S. Да, в обычной ситуации, ремесло и искусство не противопоставляют. Всякое искусство опирается на хорошее владение ремеслом. Однако, ремесло — это только необходимое, но не достаточное условие.
lair
23.12.2021 20:24+2Как ни странно, в статье даётся четкое представление о том, каково оно, это различие, по мнению автора.
Не нашел. Можете привести цитату?
Ремесленник — этот тот, кто хорошо овладел многочисленными фреймворками, платформами и тулкитами. Мастер — это, прежде всего, тот, кто грамотно ставит задачу и находит адекватные способы её решения.
Два этих определения друг другу не противоречат. Человек, который хорошо овладел и грамотно ставит задачу — он мастер или ремесленник?
Мастер — этот, кто способен программировать без ошибок.
А, это недостижимый идеал. Ок.
Типичный ремесленник быстро бежит к станку и быстро пытается предъявить свой первый релиз и обрекает начальсвто и заказчиков на бесконечный поток релизов.
А откуда у вас такое определение ремесленника? Я вот — ремесленник, но я никогда не бегу к станку, а пытаюсь понять проблему, а потом только ее решать.
Да, в обычной ситуации, ремесло и искусство не противопоставляют.
Как раз искусство и ремесло обычно противопоставляют. Мне другое непонятно: почему вы считаете, что мастер — это понятие из искусства?
Myclass
23.12.2021 21:38Он автор картины и он так решил. #ирония
С вами я согласен на все 100%. Мастер в исполнении автора- что от совершенного. К чему в принципе стремится не вредно, но это все больше абстрактно, чем конкретно.
lair
23.12.2021 21:52+1Ирония в том, что подход "от искусства" — он именно "я автор, и я так решил". Автор не обязан интересоваться (и часто и не интересуется) мнением аудитории. Хочу ли я пользоваться ПО, разработчик которого был Творцом, и которого, поэтому, интересовало только его собственное самовыражение? Наверное, не хочу.
OlegZH
23.12.2021 22:34Как раз искусство и ремесло обычно противопоставляют. Мне другое непонятно: почему вы считаете, что мастер — это понятие из искусства?
Я действую в парадигме обсуждаемой статьи. Вопрос не в конкретных словах, а в том, что имеется в виду. Например, автором статьи. Мы можем сколько угодно говорить о том, что мастер — это этап становления любого ремесленника, на в статье имеется виду другое. И это другое я (как мне кажется, чётко) обозначил выше: "Мастер постарается до конца понять проблему."
lair
23.12.2021 22:37+2Вопрос не в конкретных словах, а в том, что имеется в виду. Например, автором статьи.
Вот я и спрашиваю: зачем автор статьи понимает под словами что-то отличное от общепринятого употребления?
И это другое я (как мне кажется, чётко) обозначил выше: "Мастер постарается до конца понять проблему."
А я вот считаю, что хороший ремесленник тоже постарается до конца понять проблему. А тот, кто бросается к станку — это не ремесленник, это просто непрофессионал.
Myclass
24.12.2021 13:37+1, это просто ненепрофессионаля
И таких полным полно в современных агильных проектах, когда архитектор понятия не имеет об архитектуре, когда product owner не знает ничего об технологии или возможностях той системы, которую он представляет, а оперирует только фразами из брошюры к этой системе, scrum Master, который не знает ни основ проект манагемента ни емеет навыков работы с людьми, моделирование базы данных происходит без знаний ремесла или техн. особенностей конкретной базы итд...
Спасибо, хорошее обозначение!
lair
24.12.2021 14:25Таких вообще полно, что сейчас, что раньше было.
Myclass
24.12.2021 15:53+1Раньше непроффессионалы или выдавливались из ремесла или не получали той оценки или ранга, на который расчитывали. Только аферисты могли выдать желаемое за действительное. Сейчас аферистом не надо быть. Все намного проще. Пройди двухнедельный курс по scrum или safe и у тебя уже огромный шанс участвовать в больших бюджетных проектах, без какой-либо ответственности за сделанное или несделанное. И они верят в себя и свои 'возможности' по-настящему. И нет ни какой возможности, таких 'специалистов' из из этого ремесла выдавить, если ожидаемые результаты не получаются. Потому что это становится на каждом этапе коллективная работа, без возможности личной ответственности.
lair
24.12.2021 15:57Раньше непроффессионалы или выдавливались из ремесла или не получали той оценки или ранга, на который расчитывали.
Это когда было? Я сколько в индустрии, и сколько мне перед этим отец про индустрию рассказывал — всегда в ней были люди, которые успешно ничего не делали.
OlegZH
23.12.2021 22:45А, это недостижимый идеал. Ок.
Такой идеал (в указаном смысле) вспеолне себе достижим. Для этого надо точно следовать методологии разработки. Сначала нужна работа системного аналитика, который должен ответить на вопрос, что именно нужно сделать. Но, как только решение принято, должны вступать программисты, но тогда у каждого программиста будет чёткий круг решаемых задач, сроки их выполнения, пристекающие из существа дела (а не внешнего требования) и способы решения. На практике, системный этап пропускают и сразу бегут писать код, порождая ад релизов.
Сколько времени, сил и ресурсов было бы сэкономлено, если бы программисты не торопились писать код. В любом деле должен действовать принцип: семь раз отмерь, один раз отрежь. Чтобы случилось, если бы слесари и сантехники действовали так, как привыкли действовать программисты? Вот у ннас и получается что-то вроде этого:
lair
23.12.2021 22:47+2Такой идеал (в указаном смысле) вспеолне себе достижим.
Люди, которые не допускают ошибок, недостижимы.
Сначала нужна работа системного аналитика, который должен ответить на вопрос, что именно нужно сделать.
В моем опыте хорошие системные аналитики встречаются в 10-20 раз реже, чем хорошие программисты.
Сколько времени, сил и ресурсов было бы сэкономлено, если бы программисты не торопились писать код
… сколько полезных вещей не было бы сделано, если бы программисты ждали полных требований.
Jammarra
24.12.2021 10:27+1… сколько полезных вещей не было бы сделано, если бы программисты ждали полных требований.
Могу еще добавить что полные требования и анализ нельзя получить без MVP, А/Б тестирования, анализа аналогов у конкурентов и всего этого.
Это самое большое заблуждение когда ты думаешь что знаешь что нужно пользователю. Иногда пользователи начинают использовать что то максимально не тривиальным образом. Если даже отойти от программирования то вспоминается magic wand от Hitachi который вообще то массажер)
OlegZH
25.12.2021 21:18... что нужно пользователю
Действительно, что нужно пользователю? В каких обстоятельствах возникает этот вопрос? Если имеется некоторая задача автоматизации, то что здесь может сказать пользователь?
По-моему, выносить какой-либо вердикт по этому поводу, необходимо расписать пару-тройку практических приложений, чтобы наглядным образом показать обоснованность той или иной точки зрения.
Лично мне совершенно не понятны рассуждения о сборе каких-либо требований. Первичной должна быть задача, которая предопределяет структуры обрабатываемых данных и алгоритмы их обработки. С точки зрения программиста, есть только задача. А у пользователя должна быть самостоятельная возможность выбирать пользовательский интерфейс.
Например.
Мне, как покупателю, нужен единый сервис по подбору товаров и их дальнейшей покупке. Каждый раз, заходя на какой-то сайт сетевого магазина, я сталкиваюсь, каждый раз, со своим приложением реализующим требуемае мною функции. Спрашивается, зачем? Кто-то на своё сайте сделает очень хорошую форму, кто-то похуже и с ошибками,и нарушениям логики. Почему я не могу взять наиболее удобный вариант и всегда его использовать для доступа к другим сайтам? Далее, зачем, вообще мне нужен какой-то сайт? Мне нужен набор однотипных сервисов-поставщикв данных: фирма владеет сервером, где "крутится" база оперативных данных, а снаружи имеется стандартное API. На машине клиента реализуется единое приложение для доступа к этому API, а пользователь сам определяет способ подачи полученных данных и методы управления ими. Любой системный аналитик предложит архитектуру, в которой есть только сервер, клиент и набор регулярных сервисов.
Конечно, это всё — чистой воды теоретизирование. Но это теоретизирование позволяет понять, что же не так с управлением требованиями.
Jammarra
25.12.2021 22:26+1Каждый раз, заходя на какой-то сайт сетевого магазина, я сталкиваюсь, каждый раз, со своим приложением реализующим требуемае мною функции. Спрашивается, зачем? Кто-то на своё сайте сделает очень хорошую форму, кто-то похуже и с ошибками,и нарушениям логики.
Ну наверное потому что как минимум магазин торгующий в носками и автомобилями должен иметь разный интерфейс
OlegZH
25.12.2021 22:44+1Как интерфейс завсисит от профиля работы предприятия? Может быть, он, в большей степени завсисит от того, чего именно хочет пользователь в данный момент времени? Это означачает, что пользователь постоянно выбирает свою роль. От выбранной роли зависит и интерфейс. У одного и того же сайта, таким образом, может быть несколько интерфейсов. Но интерфейс определяется исключительно ролью, которую выбрал пользователь. Это как в программах командной строки: Вы вводите команду, попадаете в определённый режим работы, а, потом, выходите из него.
Jammarra
25.12.2021 23:23+190% пользователей сами не знают чего хотят.
Еще одна проблема айтишников, в том что они думают что вокруг такие же айтишники. Для среднего пользователя терминал это магия. А если вы им предложите настраивать браузер под себя то они выкинут комп и скажут "Сам с этой шайтан машиной работай"
OlegZH
26.12.2021 11:25Для среднего пользователя терминал это магия.
Напрашивается вопрос: как снять это магическое предубеждение?
Jammarra
26.12.2021 15:51Никак. Люди по своей сути ленивы. И это хорошо, лень это двигатель прогресса)
Вы же не просите автопроизводителя присылать вам запчасти от машины что бы ее можно было собрать. Или не идете еще дальше и не покупаете станок что бы самому сделать машину.
А вот в программировании почему то скатывайтесь к такой позиции типо "Дайте людям стамеску и дерево и пусть они делают себе шкафы сами а не покупают готовую мебель, а то она имеет слишком много ограничений" и "Каждый должен уметь собирать автомобиль из говна и палок. Делать себе мебель, шить одежду и выращивать зерно молоть его и печь хлеб"
Такой снобизм реально только у айтишников есть.При этом забавный факт сами айтишники несмотря на этот снобизм в интернете такие же ленивые в жизни. Если тем же разрабам дать сложный пайп и манифесты кубера, они почему то бегут крича "это не наша работа в этом разбираться, нам некогда. Дайте кнопку сделать хорошо что бы мы только деплоили. А не вот это все"
Сколько лет там уязвимость была Log4j? не смотря на открытые исходники? Что то не один не подорвался разбираться как работает то что ему дали. Просто брали готовое и работали.
Вы все блин хотите что бы вам кто то что то идеальное дал. Но сами даже жопу оторвать не можете. Есть огромное число опенсорса. Хотите сделать мир лучше начните с него. Там всегда рук не хватает.
lair
26.12.2021 10:15Лично мне совершенно не понятны рассуждения о сборе каких-либо требований. Первичной должна быть задача, которая предопределяет структуры обрабатываемых данных и алгоритмы их обработки
А откуда же возьмется задача, особенно полно и непротиворечиво описанная, как не из сбора требований?
Мне, как покупателю, нужен единый сервис по подбору товаров и их дальнейшей покупке
Есть маленький нюанс: вам нужен. Но вы вряд ли готовы это финансировать.
Поэтому разрабатывают не для вас, а для того, кто платит.
OlegZH
26.12.2021 11:23-2А откуда же возьмется задача, особенно полно и непротиворечиво описанная, как не из сбора требований?
Видов деятельности не так иуж и много. Наука, торговля, искусство. Все задачи перечислимы. В этих задачах много общего. Сситемный аналит должен выделить это общее — первичные сущности и элементарные операции — и разложить это всё перед программистом. В идеале, разумеется.
Есть маленький нюанс: вам нужен.
Это ещё один источник проблемы. Ошибочно полагать, что, если кто-то один хочет чего-то такого, то это проблема его одного. От профессионалов требуется оценить практическую возможность реализации единого сервиса, вмонтированного в операционную систему. Если такая практическая возможность существует, то программисты обязаны её реализовать. Соответственно, разговор должен веститсь исключительно по поводу практической возможности/невозможности.
Поэтому разрабатывают не для вас, а для того, кто платит.
Обычно за пользование сайта денего не берут. Платят сами магазины. Разработчикам. А пользователи находятся в одинаковых условиях.
lair
26.12.2021 11:28Сситемный аналит должен выделить это общее — первичные сущности и элементарные операции — и разложить это всё перед программистом.
Это и называется "сбор требований".
(приблизительно в той же степени строгости терминологии, в которой "в задачах много общего")
Ошибочно полагать, что, если кто-то один хочет чего-то такого, то это проблема его одного.
Нет, я не полагаю, что это проблемы его одного. Но какая мне разница, один он или их тысяча?
От профессионалов требуется оценить практическую возможность реализации единого сервиса, вмонтированного в операционную систему.
Кем требуется? Когда от меня, как от профессионала, что-то требуется, это обычно происходит в рамках моего контракта. Где контракт, в котором это "требуется"?
Если такая практическая возможность существует, то программисты обязаны её реализовать.
И снова: кому обязаны? Откуда вообще возникло это обязательство?
Обычно за пользование сайта денего не берут. Платят сами магазины. Разработчикам.
Вот именно поэтому сайты разрабатываются так, как хочется магазинам, а не так, как хочется пользователям.
OlegZH
26.12.2021 15:45+1Вот именно поэтому сайты разрабатываются так, как хочется магазинам, а не так, как хочется пользователям.
Хороший итог нашему обсуждению. Очень точное и меткое замечание/определение. Что и требовалось доказать.
OlegZH
25.12.2021 20:48Люди, которые не допускают ошибок, недостижимы.
Ошибка ошибке — рознь. Если Вы торопитесь, что-то сделать, то Вы совершаете ошибку. Фундаментальную. Мудрость семь раз отмерь не даром является мудростью. Отсюда возникает и разделение на тех, кто готов "резать", и на тех, кто, всё-таки, несколько раз "отмерит". К сожалению, первых гораздо больше. Иначе не было бы того обилия проблем, о которых приходится постоянно слышать.
В моем опыте хорошие системные аналитики встречаются в 10-20 раз реже, чем хорошие программисты.
Лично мне было бы крайне любопытно услышать от Вас, кто такой хороший программист. Пожалуйста, нарисуйте портерт хорошего программиста. Это поможет избежать множества слов. А мне сможет послужить хорошим ориентиром.
… сколько полезных вещей не было бы сделано, если бы программисты ждали полных требований.
А что хочет пользователь? Почему пользователь вжруг "вспоминает" о чем-то ещё?
(Хотелось бы заметить, что я с Вами не спорю. Хотело бы получше понять вашу точку зрения и поглубже воспринять Ваш опыт.)
lair
26.12.2021 10:21Ошибка ошибке — рознь
Выше вы говорили, что "мастер — этот, кто способен программировать без ошибок". Теперь, внезапно, не без всех ошибок, а без какого-то определенного их класса?
Отсюда возникает и разделение на тех, кто готов "резать", и на тех, кто, всё-таки, несколько раз "отмерит". К сожалению, первых гораздо больше.
Так вот, первые — просто непрофессионалы (или сильно худшие профессионалы, чем вторые).
Лично мне было бы крайне любопытно услышать от Вас, кто такой хороший программист.
Хороший программист — это такой программист, который [хорошо] пишет [хорошие] программы, которые [хорошо] удовлетворяют решаемой задаче. Понятие "хорошо", конечно же, слабо формализуемо.
Это поможет избежать множества слов.
Неа, не поможет. Вы просто предлагаете это множество слов написать мне.
А что хочет пользователь?
А какое это имеет отношение к обсуждению?
OlegZH
26.12.2021 11:11Понятие "хорошо", конечно же, слабо формализуемо.
Вот здесь я и вижу проблему. Должно быть наоборот.
lair
26.12.2021 11:21+1Неа, не "должно". Вам бы хотелось, чтобы было наоборот, да. Но не "должно".
Кстати, занятный парадокс: чем более творческой мы считаем работу программиста, тем менее формализуемо в ней понятие "хорошо". Творчество-то не формализуемо.
OlegZH
26.12.2021 15:44+1Вот здесь мы возвращаемся к статье и к её главному посылу: в современном программировании стало довольно много рутины. По мнению автора статьи, по крайней мере.
Рассуждения о возможных шкалах придётся отдложить до будущего разговора.
Yoooriii
24.12.2021 01:31+3Нил Стивенсон (The Snowcrash, 1992) обыграл данную ситуацию уже давно, то что мы к этому придём, было (для него) очевидно. Опять же, это всё как в реальной жизни, например: раскопали трубу, подлатали, заасфальтировали, дали давление, потекло, раскопали и так раз в пол года-год по кругу. Хотелось бы разорвать этот порочный круг, но не уверен, что это кому-то нужно. Зато все при деле.
OlegZH
25.12.2021 21:44Ключевое слово здесь "подлатали". Нет другого способа хорошо сделать свою работу, кроме как воспользоваться качественными материалами и полностью соблюсти технологию. А, уж, если случилась авария, то не латать, а полностью изъять плохую трубу и положить хорошую.
Подлатать можно только для того, чтобы поскорее дать тепло или воду. Но, у нас нет ничего более постянного, чем временное. Или, наоборот, нет ничего более временного, чем постоянное.
Я иногда думаю о том, как было бы хорошо соблюдать определённый регламент. Вот, Вы знаете, что построили дом. Значит, каждые пять лет Вы должны проводить косметический ремонт. Лет через 25 — капитальный. Каждый год ходить по квартирам и присматривать за электрикой, сантехникой, состоянием стен, полов, потолков, перекрытий и проч. и проч. Таким образом, постоянно поддерживается целостность дома. Физическая и на уровне инфраструктуры. Косметический ремонт — это замена коммуникаций, покраска. Задача — обеспечить присутствие только свежих компонентов. Это очень дорого? Ничуть. На аварийных ремонтах тратится гораздо больше. Регулярный ремонт позволит избежать постоянного стука за стенкой, когда очередные переселенцы зановго устраивают своё жильё. Причём такие локальные ремонты превращают дом в лоскутное одеяло. Будущие жильцы всегда будут знать, на каком этапе гарантийного обслуживания нахоится дом. И если он ещё не дошёл до стадии капиального ремонта, никакие другое локальные ремонты невозможны.
В случае с программным обеспечением, можно скзать так: если поступает новое требование, то нужно не пытаться встраивать его реализацию в существующую систему, а нужно проходить весь пусть разработки с самого начала. Поскольку добавление нового требования означает и новую ситему, когда прежные системые решения становятся недействительными. В этом, по сути, и зиждится корень проблемы. Системное решение — это создание компонентов, которые все взаимоувязанны.
Мастер прекрасно понимает суть данной проблемы. Поэтому у мастера остаётся, по сути, только две дороги: при поступлении нового требования заново с нуля разработать новую версию или изначально обобщить предыдущие требования, параметризовать их и предоставить пользователю некую метасистему, при помощи которой пользователь будет способен сам без обращения к программисту реализовывать своё новое требование.
lair
26.12.2021 10:22+1предоставить пользователю некую метасистему, при помощи которой пользователь будет способен сам без обращения к программисту реализовывать своё новое требование
Удивительным образом, рано или поздно эта метасистема становится языком программирования, превращая пользователя в программиста.
mad_nazgul
24.12.2021 16:23+1Бизнес, ничего личного.
Об этом давно уже отшутились/ :-)
Цитата #420672 – Цитатник Рунета (bash.im)
MAXH0
К сожалению должен согласиться. Больше всего меня печалит в современной разработке эпитафия, которую Сассман прочитал над SICP : «Программирование сегодня больше напоминает науку: вы берете часть библиотеки и «тыкаете» в нее — смотрите на то, что она делает. Затем вы спрашиваете себя, «Могу ли я настроить это так, чтобы оно делало то, что мне нужно?». Подход «анализ через синтез», используемый в SICP, когда вы строите большую систему из простых, маленьких частей, стал неактуальным. Сегодня мы программируем «методом тыка».
То что было справедливым в 2016 году, так же актуально и в 2021. По мере того как программирование будет превращаться в набор вырезанных из чужих программ фрагментов склееных при помощи СоПилота, код будет становиться только хуже и хуже, теряя свою математическую целостность и законченность...
amarao
Вы можете себе представить математическую целостность, например, бразуера? Начиная с вопроса о том, что может быть в hostname, а чего не может (с точки зрения DNS и с точки зрения yellowpages), и заканчивая апгрейдом с http1.1 до http/3. Хотя нет, заканчивая разницей в типах поддерживаемых тектур на intel'овой версии opengl и nvidia. Или? Нет, куда интереснее подумать о том, какой список стандартов покрывает стереовидео в mpeg4 положенном в ogv файле.
Хотя тайминги анимации gif-файлов всё-таки важнее. Или правильная композиция корейского алфавита в наклонном написании рядом с bold-эмодзи из светлокожей какашки?
Но это всё бледнеет перед вопросом о том, какая целостная модель описывает ситуацию, если окно браузера одновременно видно на экране с highdpi (4k, ретина) и частотой обновления 120Hz, и мониторе с FullHD с 60Hz и javascript хочет сделать vsync.
.. В тот момент, когда меняется профиль производительности из-за перехода на батарейку.
.... Во время пробуждения ноутбука изо сна.
..... Когда в системе меняется число ядер
....... И тип видеоадаптера.
А пользователь негодует, что у него криво игрушка в браузере работает.
OlegZH
Ваш посыл понятен. Но! Было бы удобнее, если бы Вы сформулировали свои возражения немного ровнее, чтобы была яснее суть проблемы. В каждом конкретном случае. Очень много недостказанного. Например
Что это значит? И какое значение имеет апгрейд
Если Вы высказываете какие-то возражения, то Вы должны быть готовы к встрече с прекрасным, а именно — к тому, что в мире, где исскустсво является ценностью, будет совсем другой подход и к адресации страниц, и к порождению графического вывода, и ко многому другому.
На самом деле, ответ на этот вопрос лежит на поверхности: нельзя пытаться встраивать внешним образом какое-либо ПО в уже существующее на конкретном устройстве; на устройстве должно функционировать только то ПО, которе создавалось только для данного устройства. Браузер ломает нормальную ситуацию. А действовать надо было наоборот: создавать "нативные" приложения, но обеспечивать их сетевыми возможностями, вроде удаленного вызова процедуры в CORBA.
amarao
RFC 952 vs RFC 1123 vs RFC1036.
Значение при апгрейде простое - сервер просит, а что клиенту делать?
Ваш ответ не лежит на поверхности, он сводится к "сегодня потребности в масле нет" на дверях коммунистического магазина.
Ваша позиция говорит "браузера существовать не может", позиция авторов и пользователей - "может, и даже удобно".
OlegZH
Пользователям не показали альтернативу. Не с чем сравнивать.
MAXH0
В общем вы демонстритуете ту же проблему, но с другой стороны. Современный код не просто сложен. Он переусложнен и противоречив. Как следствие своего эволюционного развития. ТОт же браузер. Вы уверены, что пользователь вообще должен играть в браузере в игры? Я имею ввиду серьезные 3D игры реального времени. Современные браузеры разрослись в неповоротливых монстров пожирающих ресурсы. Но это не самое страшное. А страшно то, что в итоге мы имеем полтора разных движка браузеров в наличии и сделать новый практически невозможно. Причины? Ну вы их и перечислили.
У нас нет спора. Это реальность. Просто вы практик и работаете с тем что есть. А я идеалист-теоретик и хочу иного...
amarao
Вы можете посмотреть на проблему с другой стороны - любой человек сейчас может написать программу уровня augmented reality и отдать её всем желающим с минимальными усилиями.
Если вы посмотрите на проблему распространения софта в условные 90ые, то вероятность, что неквалифицированный пользователь сможет такое запустить на любой из ОС стремится к нулю.
У оверинжинринга есть плюсы и минусы. Старый софт, особенно, с множественными требованиями, иногда выглядит душераздирающе.
Myclass
Ну знаете, сравнение так себе. Я вам навскидку похожее дам. Вы можете представить, сколько будет стоить сил и возможностей, если взять современную графическую карту и дать её в прошлое Стиву Вознияку, чтобы он вставил её в свой первый Apple? Мне кажется, что вы сравнивайте не то.
Заморозьте свой код сегодня и посмотрите на него через 20 лет. Вы не будете в восторге от его возможностей. Только ностальгия и исторический контекстс. Тогда почему вы сравнивайте фунциальные возможности. Сравнивайте подход, что удаётся получить, как преодаляются трудности , что при этом было возможно использовать, какие технологии итд.
amarao
Есть подозрение, что в 1980м от условной RTX было бы мало толку. Никто не смог бы сделать PCI контроллер сделать, способный её обслужить. И кода пришлось бы написать ОЧЕНЬ мнрого (посмотрите на блоб nvidia).
Вся сила современной разработки состоит в том, что человек пишет мало, а получает много - потому что он переиспользует всё более и более крупные куски всё более фичастого чужого кода.