Comments 53
К сожалению должен согласиться. Больше всего меня печалит в современной разработке эпитафия, которую Сассман прочитал над SICP : «Программирование сегодня больше напоминает науку: вы берете часть библиотеки и «тыкаете» в нее — смотрите на то, что она делает. Затем вы спрашиваете себя, «Могу ли я настроить это так, чтобы оно делало то, что мне нужно?». Подход «анализ через синтез», используемый в SICP, когда вы строите большую систему из простых, маленьких частей, стал неактуальным. Сегодня мы программируем «методом тыка».
То что было справедливым в 2016 году, так же актуально и в 2021. По мере того как программирование будет превращаться в набор вырезанных из чужих программ фрагментов склееных при помощи СоПилота, код будет становиться только хуже и хуже, теряя свою математическую целостность и законченность...
Вы можете себе представить математическую целостность, например, бразуера? Начиная с вопроса о том, что может быть в hostname, а чего не может (с точки зрения DNS и с точки зрения yellowpages), и заканчивая апгрейдом с http1.1 до http/3. Хотя нет, заканчивая разницей в типах поддерживаемых тектур на intel'овой версии opengl и nvidia. Или? Нет, куда интереснее подумать о том, какой список стандартов покрывает стереовидео в mpeg4 положенном в ogv файле.
Хотя тайминги анимации gif-файлов всё-таки важнее. Или правильная композиция корейского алфавита в наклонном написании рядом с bold-эмодзи из светлокожей какашки?
Но это всё бледнеет перед вопросом о том, какая целостная модель описывает ситуацию, если окно браузера одновременно видно на экране с highdpi (4k, ретина) и частотой обновления 120Hz, и мониторе с FullHD с 60Hz и javascript хочет сделать vsync.
.. В тот момент, когда меняется профиль производительности из-за перехода на батарейку.
.... Во время пробуждения ноутбука изо сна.
..... Когда в системе меняется число ядер
....... И тип видеоадаптера.
А пользователь негодует, что у него криво игрушка в браузере работает.
Ваш посыл понятен. Но! Было бы удобнее, если бы Вы сформулировали свои возражения немного ровнее, чтобы была яснее суть проблемы. В каждом конкретном случае. Очень много недостказанного. Например
что может быть в hostname, а чего не может (с точки зрения DNS и с точки зрения yellowpages)
Что это значит? И какое значение имеет апгрейд
с http1.1 до http/3
Если Вы высказываете какие-то возражения, то Вы должны быть готовы к встрече с прекрасным, а именно — к тому, что в мире, где исскустсво является ценностью, будет совсем другой подход и к адресации страниц, и к порождению графического вывода, и ко многому другому.
А пользователь негодует, что у него криво игрушка в браузере работает.
На самом деле, ответ на этот вопрос лежит на поверхности: нельзя пытаться встраивать внешним образом какое-либо ПО в уже существующее на конкретном устройстве; на устройстве должно функционировать только то ПО, которе создавалось только для данного устройства. Браузер ломает нормальную ситуацию. А действовать надо было наоборот: создавать "нативные" приложения, но обеспечивать их сетевыми возможностями, вроде удаленного вызова процедуры в CORBA.
RFC 952 vs RFC 1123 vs RFC1036.
Значение при апгрейде простое - сервер просит, а что клиенту делать?
Ваш ответ не лежит на поверхности, он сводится к "сегодня потребности в масле нет" на дверях коммунистического магазина.
Ваша позиция говорит "браузера существовать не может", позиция авторов и пользователей - "может, и даже удобно".
В общем вы демонстритуете ту же проблему, но с другой стороны. Современный код не просто сложен. Он переусложнен и противоречив. Как следствие своего эволюционного развития. ТОт же браузер. Вы уверены, что пользователь вообще должен играть в браузере в игры? Я имею ввиду серьезные 3D игры реального времени. Современные браузеры разрослись в неповоротливых монстров пожирающих ресурсы. Но это не самое страшное. А страшно то, что в итоге мы имеем полтора разных движка браузеров в наличии и сделать новый практически невозможно. Причины? Ну вы их и перечислили.
У нас нет спора. Это реальность. Просто вы практик и работаете с тем что есть. А я идеалист-теоретик и хочу иного...
Вы можете посмотреть на проблему с другой стороны - любой человек сейчас может написать программу уровня augmented reality и отдать её всем желающим с минимальными усилиями.
Если вы посмотрите на проблему распространения софта в условные 90ые, то вероятность, что неквалифицированный пользователь сможет такое запустить на любой из ОС стремится к нулю.
У оверинжинринга есть плюсы и минусы. Старый софт, особенно, с множественными требованиями, иногда выглядит душераздирающе.
Ну знаете, сравнение так себе. Я вам навскидку похожее дам. Вы можете представить, сколько будет стоить сил и возможностей, если взять современную графическую карту и дать её в прошлое Стиву Вознияку, чтобы он вставил её в свой первый Apple? Мне кажется, что вы сравнивайте не то.
Заморозьте свой код сегодня и посмотрите на него через 20 лет. Вы не будете в восторге от его возможностей. Только ностальгия и исторический контекстс. Тогда почему вы сравнивайте фунциальные возможности. Сравнивайте подход, что удаётся получить, как преодаляются трудности , что при этом было возможно использовать, какие технологии итд.
Есть подозрение, что в 1980м от условной RTX было бы мало толку. Никто не смог бы сделать PCI контроллер сделать, способный её обслужить. И кода пришлось бы написать ОЧЕНЬ мнрого (посмотрите на блоб nvidia).
Вся сила современной разработки состоит в том, что человек пишет мало, а получает много - потому что он переиспользует всё более и более крупные куски всё более фичастого чужого кода.
Вы, даже, не представляете, насколько Вы не правы. В прежние времена было так: были прикладные задачи, учёные-специалисты приждумывали решения, создавали вычислительные архитектуры и языки программирования. Однажды, был создан Алгол. На этом язке очень хорошо описывать и объяснять алгоритмы. Помнится, была такая книга "Построение и анализ вычислитлеьных алгоритмов" (Ахо, Ульман, Хопкрофт). Все примеры — на алголе. Алгол дал нам Паскать, Аду, Модулу и Оберон. Системники выдумали Си. Был ещё Рефал. Математикам очень пригодился Фортран. А ещё и Кобол. Была специализация. Было понимание того, что каждый язык должен решать свою задачу. Нельзя насыщать язык программирования средствами. Современные языки программирования монстры. Раньше было понимание того, что инструкции языка программирования должны иметь чёткий смысл, и что не надо выкуривать мануалы с описаниями библиотек. (Я застал начало этого современного ада, кагда в самом начале 90-тых была издана книжка, где специальным образом отражались особенности реализации Turbo C и Microsoft C.) Это, извините, совсем не про то, что "в наше время". Даже Ваш пример с Windows 95 — это пример, потверждающий сказанное в статье. Потому как победило, так сказать, прикладное программирование. Вот Вам вопрос "на засыпку", во что можно превратить операционную систему, если делать её по науке? Где давно обещанный "интуитивный" и "объектно-ориентированный" интерфейс? Почему ОС — это не система типа СУБД, тоолько для прогрнаммого кода? Если делать по науке, то надо программный код хранить в базе данных: нужно определённое приложение? Сделал нужный запрос к базе даннных! Всё было бы прозрачным и управлямым.
... ибо есть Python и Mathcad и Mathlab которые делают тоже самое проще лучше и быстрее.
Оценочное суждение. Где-то и проще. Где-то и лучше. Где-то и быстрее. Но ещё интереснее было бы узнать о надёжности и точности вычислений, об устойчивости результатов вычислений. Тут не всё так просто. Именно поэтому на занятиях по методам вычислений в вузе рекомендуют с большой осторожностью ловерять результатам современных пакетов. В этом смысле, код, написанный на старом языке програмимирования, может вызвать большее доверие: синстаксис языка гарнтирует точную семантику всех операций, а годы разработок — отлаженный и практически безошибочный код.
кто он — ремесленник или мастер
А почему вы противопоставляете ремесленников мастерам?
Как ни странно, в статье даётся четкое представление о том, каково оно, это различие, по мнению автора. Читаем:
Для создания даже простейших решений и систем используются многочисленные фреймворки, платформы и тулкиты.
Ремесленник — этот тот, кто хорошо овладел многочисленными фреймворками, платформами и тулкитами. Мастер — это, прежде всего, тот, кто грамотно ставит задачу и находит адекватные способы её решения. То есть — действует избирательно. Мастер — этот, кто способен программировать без ошибок. В том смысле, что он способен долго-долго подумать над проблемой а, затем, быстро-быстро сделает реализацию подходящего (высокого) качества. Типичный ремесленник быстро бежит к станку и быстро пытается предъявить свой первый релиз и обрекает начальсвто и заказчиков на бесконечный поток релизов. Мастер постарается до конца понять проблему.
P.S. Да, в обычной ситуации, ремесло и искусство не противопоставляют. Всякое искусство опирается на хорошее владение ремеслом. Однако, ремесло — это только необходимое, но не достаточное условие.
Как ни странно, в статье даётся четкое представление о том, каково оно, это различие, по мнению автора.
Не нашел. Можете привести цитату?
Ремесленник — этот тот, кто хорошо овладел многочисленными фреймворками, платформами и тулкитами. Мастер — это, прежде всего, тот, кто грамотно ставит задачу и находит адекватные способы её решения.
Два этих определения друг другу не противоречат. Человек, который хорошо овладел и грамотно ставит задачу — он мастер или ремесленник?
Мастер — этот, кто способен программировать без ошибок.
А, это недостижимый идеал. Ок.
Типичный ремесленник быстро бежит к станку и быстро пытается предъявить свой первый релиз и обрекает начальсвто и заказчиков на бесконечный поток релизов.
А откуда у вас такое определение ремесленника? Я вот — ремесленник, но я никогда не бегу к станку, а пытаюсь понять проблему, а потом только ее решать.
Да, в обычной ситуации, ремесло и искусство не противопоставляют.
Как раз искусство и ремесло обычно противопоставляют. Мне другое непонятно: почему вы считаете, что мастер — это понятие из искусства?
Он автор картины и он так решил. #ирония
С вами я согласен на все 100%. Мастер в исполнении автора- что от совершенного. К чему в принципе стремится не вредно, но это все больше абстрактно, чем конкретно.
Ирония в том, что подход "от искусства" — он именно "я автор, и я так решил". Автор не обязан интересоваться (и часто и не интересуется) мнением аудитории. Хочу ли я пользоваться ПО, разработчик которого был Творцом, и которого, поэтому, интересовало только его собственное самовыражение? Наверное, не хочу.
Как раз искусство и ремесло обычно противопоставляют. Мне другое непонятно: почему вы считаете, что мастер — это понятие из искусства?
Я действую в парадигме обсуждаемой статьи. Вопрос не в конкретных словах, а в том, что имеется в виду. Например, автором статьи. Мы можем сколько угодно говорить о том, что мастер — это этап становления любого ремесленника, на в статье имеется виду другое. И это другое я (как мне кажется, чётко) обозначил выше: "Мастер постарается до конца понять проблему."
Вопрос не в конкретных словах, а в том, что имеется в виду. Например, автором статьи.
Вот я и спрашиваю: зачем автор статьи понимает под словами что-то отличное от общепринятого употребления?
И это другое я (как мне кажется, чётко) обозначил выше: "Мастер постарается до конца понять проблему."
А я вот считаю, что хороший ремесленник тоже постарается до конца понять проблему. А тот, кто бросается к станку — это не ремесленник, это просто непрофессионал.
, это просто ненепрофессионаля
И таких полным полно в современных агильных проектах, когда архитектор понятия не имеет об архитектуре, когда product owner не знает ничего об технологии или возможностях той системы, которую он представляет, а оперирует только фразами из брошюры к этой системе, scrum Master, который не знает ни основ проект манагемента ни емеет навыков работы с людьми, моделирование базы данных происходит без знаний ремесла или техн. особенностей конкретной базы итд...
Спасибо, хорошее обозначение!
Таких вообще полно, что сейчас, что раньше было.
Раньше непроффессионалы или выдавливались из ремесла или не получали той оценки или ранга, на который расчитывали. Только аферисты могли выдать желаемое за действительное. Сейчас аферистом не надо быть. Все намного проще. Пройди двухнедельный курс по scrum или safe и у тебя уже огромный шанс участвовать в больших бюджетных проектах, без какой-либо ответственности за сделанное или несделанное. И они верят в себя и свои 'возможности' по-настящему. И нет ни какой возможности, таких 'специалистов' из из этого ремесла выдавить, если ожидаемые результаты не получаются. Потому что это становится на каждом этапе коллективная работа, без возможности личной ответственности.
А, это недостижимый идеал. Ок.
Такой идеал (в указаном смысле) вспеолне себе достижим. Для этого надо точно следовать методологии разработки. Сначала нужна работа системного аналитика, который должен ответить на вопрос, что именно нужно сделать. Но, как только решение принято, должны вступать программисты, но тогда у каждого программиста будет чёткий круг решаемых задач, сроки их выполнения, пристекающие из существа дела (а не внешнего требования) и способы решения. На практике, системный этап пропускают и сразу бегут писать код, порождая ад релизов.
Сколько времени, сил и ресурсов было бы сэкономлено, если бы программисты не торопились писать код. В любом деле должен действовать принцип: семь раз отмерь, один раз отрежь. Чтобы случилось, если бы слесари и сантехники действовали так, как привыкли действовать программисты? Вот у ннас и получается что-то вроде этого:
Такой идеал (в указаном смысле) вспеолне себе достижим.
Люди, которые не допускают ошибок, недостижимы.
Сначала нужна работа системного аналитика, который должен ответить на вопрос, что именно нужно сделать.
В моем опыте хорошие системные аналитики встречаются в 10-20 раз реже, чем хорошие программисты.
Сколько времени, сил и ресурсов было бы сэкономлено, если бы программисты не торопились писать код
… сколько полезных вещей не было бы сделано, если бы программисты ждали полных требований.
... что нужно пользователю
Действительно, что нужно пользователю? В каких обстоятельствах возникает этот вопрос? Если имеется некоторая задача автоматизации, то что здесь может сказать пользователь?
По-моему, выносить какой-либо вердикт по этому поводу, необходимо расписать пару-тройку практических приложений, чтобы наглядным образом показать обоснованность той или иной точки зрения.
Лично мне совершенно не понятны рассуждения о сборе каких-либо требований. Первичной должна быть задача, которая предопределяет структуры обрабатываемых данных и алгоритмы их обработки. С точки зрения программиста, есть только задача. А у пользователя должна быть самостоятельная возможность выбирать пользовательский интерфейс.
Например.
Мне, как покупателю, нужен единый сервис по подбору товаров и их дальнейшей покупке. Каждый раз, заходя на какой-то сайт сетевого магазина, я сталкиваюсь, каждый раз, со своим приложением реализующим требуемае мною функции. Спрашивается, зачем? Кто-то на своё сайте сделает очень хорошую форму, кто-то похуже и с ошибками,и нарушениям логики. Почему я не могу взять наиболее удобный вариант и всегда его использовать для доступа к другим сайтам? Далее, зачем, вообще мне нужен какой-то сайт? Мне нужен набор однотипных сервисов-поставщикв данных: фирма владеет сервером, где "крутится" база оперативных данных, а снаружи имеется стандартное API. На машине клиента реализуется единое приложение для доступа к этому API, а пользователь сам определяет способ подачи полученных данных и методы управления ими. Любой системный аналитик предложит архитектуру, в которой есть только сервер, клиент и набор регулярных сервисов.
Конечно, это всё — чистой воды теоретизирование. Но это теоретизирование позволяет понять, что же не так с управлением требованиями.
Как интерфейс завсисит от профиля работы предприятия? Может быть, он, в большей степени завсисит от того, чего именно хочет пользователь в данный момент времени? Это означачает, что пользователь постоянно выбирает свою роль. От выбранной роли зависит и интерфейс. У одного и того же сайта, таким образом, может быть несколько интерфейсов. Но интерфейс определяется исключительно ролью, которую выбрал пользователь. Это как в программах командной строки: Вы вводите команду, попадаете в определённый режим работы, а, потом, выходите из него.
Лично мне совершенно не понятны рассуждения о сборе каких-либо требований. Первичной должна быть задача, которая предопределяет структуры обрабатываемых данных и алгоритмы их обработки
А откуда же возьмется задача, особенно полно и непротиворечиво описанная, как не из сбора требований?
Мне, как покупателю, нужен единый сервис по подбору товаров и их дальнейшей покупке
Есть маленький нюанс: вам нужен. Но вы вряд ли готовы это финансировать.
Поэтому разрабатывают не для вас, а для того, кто платит.
А откуда же возьмется задача, особенно полно и непротиворечиво описанная, как не из сбора требований?
Видов деятельности не так иуж и много. Наука, торговля, искусство. Все задачи перечислимы. В этих задачах много общего. Сситемный аналит должен выделить это общее — первичные сущности и элементарные операции — и разложить это всё перед программистом. В идеале, разумеется.
Есть маленький нюанс: вам нужен.
Это ещё один источник проблемы. Ошибочно полагать, что, если кто-то один хочет чего-то такого, то это проблема его одного. От профессионалов требуется оценить практическую возможность реализации единого сервиса, вмонтированного в операционную систему. Если такая практическая возможность существует, то программисты обязаны её реализовать. Соответственно, разговор должен веститсь исключительно по поводу практической возможности/невозможности.
Поэтому разрабатывают не для вас, а для того, кто платит.
Обычно за пользование сайта денего не берут. Платят сами магазины. Разработчикам. А пользователи находятся в одинаковых условиях.
Сситемный аналит должен выделить это общее — первичные сущности и элементарные операции — и разложить это всё перед программистом.
Это и называется "сбор требований".
(приблизительно в той же степени строгости терминологии, в которой "в задачах много общего")
Ошибочно полагать, что, если кто-то один хочет чего-то такого, то это проблема его одного.
Нет, я не полагаю, что это проблемы его одного. Но какая мне разница, один он или их тысяча?
От профессионалов требуется оценить практическую возможность реализации единого сервиса, вмонтированного в операционную систему.
Кем требуется? Когда от меня, как от профессионала, что-то требуется, это обычно происходит в рамках моего контракта. Где контракт, в котором это "требуется"?
Если такая практическая возможность существует, то программисты обязаны её реализовать.
И снова: кому обязаны? Откуда вообще возникло это обязательство?
Обычно за пользование сайта денего не берут. Платят сами магазины. Разработчикам.
Вот именно поэтому сайты разрабатываются так, как хочется магазинам, а не так, как хочется пользователям.
Люди, которые не допускают ошибок, недостижимы.
Ошибка ошибке — рознь. Если Вы торопитесь, что-то сделать, то Вы совершаете ошибку. Фундаментальную. Мудрость семь раз отмерь не даром является мудростью. Отсюда возникает и разделение на тех, кто готов "резать", и на тех, кто, всё-таки, несколько раз "отмерит". К сожалению, первых гораздо больше. Иначе не было бы того обилия проблем, о которых приходится постоянно слышать.
В моем опыте хорошие системные аналитики встречаются в 10-20 раз реже, чем хорошие программисты.
Лично мне было бы крайне любопытно услышать от Вас, кто такой хороший программист. Пожалуйста, нарисуйте портерт хорошего программиста. Это поможет избежать множества слов. А мне сможет послужить хорошим ориентиром.
… сколько полезных вещей не было бы сделано, если бы программисты ждали полных требований.
А что хочет пользователь? Почему пользователь вжруг "вспоминает" о чем-то ещё?
(Хотелось бы заметить, что я с Вами не спорю. Хотело бы получше понять вашу точку зрения и поглубже воспринять Ваш опыт.)
Ошибка ошибке — рознь
Выше вы говорили, что "мастер — этот, кто способен программировать без ошибок". Теперь, внезапно, не без всех ошибок, а без какого-то определенного их класса?
Отсюда возникает и разделение на тех, кто готов "резать", и на тех, кто, всё-таки, несколько раз "отмерит". К сожалению, первых гораздо больше.
Так вот, первые — просто непрофессионалы (или сильно худшие профессионалы, чем вторые).
Лично мне было бы крайне любопытно услышать от Вас, кто такой хороший программист.
Хороший программист — это такой программист, который [хорошо] пишет [хорошие] программы, которые [хорошо] удовлетворяют решаемой задаче. Понятие "хорошо", конечно же, слабо формализуемо.
Это поможет избежать множества слов.
Неа, не поможет. Вы просто предлагаете это множество слов написать мне.
А что хочет пользователь?
А какое это имеет отношение к обсуждению?
Понятие "хорошо", конечно же, слабо формализуемо.
Вот здесь я и вижу проблему. Должно быть наоборот.
Неа, не "должно". Вам бы хотелось, чтобы было наоборот, да. Но не "должно".
Кстати, занятный парадокс: чем более творческой мы считаем работу программиста, тем менее формализуемо в ней понятие "хорошо". Творчество-то не формализуемо.
Ключевое слово здесь "подлатали". Нет другого способа хорошо сделать свою работу, кроме как воспользоваться качественными материалами и полностью соблюсти технологию. А, уж, если случилась авария, то не латать, а полностью изъять плохую трубу и положить хорошую.
Подлатать можно только для того, чтобы поскорее дать тепло или воду. Но, у нас нет ничего более постянного, чем временное. Или, наоборот, нет ничего более временного, чем постоянное.
Я иногда думаю о том, как было бы хорошо соблюдать определённый регламент. Вот, Вы знаете, что построили дом. Значит, каждые пять лет Вы должны проводить косметический ремонт. Лет через 25 — капитальный. Каждый год ходить по квартирам и присматривать за электрикой, сантехникой, состоянием стен, полов, потолков, перекрытий и проч. и проч. Таким образом, постоянно поддерживается целостность дома. Физическая и на уровне инфраструктуры. Косметический ремонт — это замена коммуникаций, покраска. Задача — обеспечить присутствие только свежих компонентов. Это очень дорого? Ничуть. На аварийных ремонтах тратится гораздо больше. Регулярный ремонт позволит избежать постоянного стука за стенкой, когда очередные переселенцы зановго устраивают своё жильё. Причём такие локальные ремонты превращают дом в лоскутное одеяло. Будущие жильцы всегда будут знать, на каком этапе гарантийного обслуживания нахоится дом. И если он ещё не дошёл до стадии капиального ремонта, никакие другое локальные ремонты невозможны.
В случае с программным обеспечением, можно скзать так: если поступает новое требование, то нужно не пытаться встраивать его реализацию в существующую систему, а нужно проходить весь пусть разработки с самого начала. Поскольку добавление нового требования означает и новую ситему, когда прежные системые решения становятся недействительными. В этом, по сути, и зиждится корень проблемы. Системное решение — это создание компонентов, которые все взаимоувязанны.
Мастер прекрасно понимает суть данной проблемы. Поэтому у мастера остаётся, по сути, только две дороги: при поступлении нового требования заново с нуля разработать новую версию или изначально обобщить предыдущие требования, параметризовать их и предоставить пользователю некую метасистему, при помощи которой пользователь будет способен сам без обращения к программисту реализовывать своё новое требование.
Во всем виноват бизнес с его MVP
Бизнес, ничего личного.
Об этом давно уже отшутились/ :-)
Цитата #420672 – Цитатник Рунета (bash.im)
Современный программист — ремесленник или мастер?