Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 80
Возможно раньше программировали по призванию, а сегодня на волне хайпа, программируют ради денег, плюс требования рынка, фреймворки и стандарты, в которых есть рамки фрейворков, оформление кода и комментариев. Творчество возможно, есть в пет проектах, и даже в них, код для себя и код для публикации, отличаются по оформлению.
Были ли люди раньше более человечны?
Более чем. В литературе разных времён хорошо отражено как менялся человек и нормы морали. Да и в кино заметны изменения. Сравните финалы оригинальных фильмов "Ограбление по-итальянски" и "11 друзей Оушена" с финалами римейков. Думаю ещё найдутся такие пары.
Творчество это именно пет-проекты и не более, потому что в бизнесовых задачах тебе особо никто и не даст эксперименты свои в жизнь воплощать, по-крайней мере по той причине, что есть сроки и базовые потребности клиентов, которые достаточно шаблонные
А это интересная грань понимания. С одной стороны, сотрудник этовинтик, ведь он пишет на готовом фреймворке, где стиль уже определён, где за него всё сделали. Работа где ему ставят задачи и контролируют его код. Работа где нет творчество, есть пустая работа.
Другая позиция, когда разработчик, сам строит архитектуру проекта, выбирает компоненты системы. Создаёт её сам, в том числе и дизайн и функционал админ панелей. Где он решает бизнес задачи. Это другая грань. Творческий подход имеет место быть.
Пет проект, в большинстве случаев, не про бизнес.
Дело не столько в хайпе, сколько в специализации. Раньше программист был человек-оркестр, сейчас есть фронтендер, бэкендер, девопс, QA... Каждый работает в своем узком коридоре, по своим стандартам. Места для личного почерка просто не остается, потому что твой код должен быть понятен десятку других специалистов
Я могу привести свой пример, в 2011 году я писал свою систему учета домашних финансов на VB. Но она настолько прозрачно показала траты семьи, что и я и жена решили что ну его нафиг. Потому что у всех есть свои небольшие слабости) Но это ладно. Меня впечатляет - то как я это сделал тогда. Я писал на VB, с DB Acsess , и там все настолько вылизано что спустя время я не знаю что добавить. Я бы сказал, что это писал совсем другой чел, если бы у меня не остались бумажки про архитектуру этой штуки. И вот... Кем был я тогда в то время, когда это все разрисовал, закодил? Сам собой? А сейчас я кто? Смотрю на это как полный бездарь на произведение гения, и такое странное ощущение. Отупел? Вроде нет, даже много больше стал знать и уметь. Но такой код я уже хрен бы написал. Старею или просто сам себя лишний раз критикую?
Я сохраняю свой код в бекап, и часто также думаю, что как круто все сделано, неужели это делал я. Этот эффект, когда с прошествием времени, ты забываешь весь тот контекст в котором создавал программу, и когда смотришь снова на прошлый код, у тебя появляется страх, из-за того что ты забыл контекст, код и как ты это делал. Тема сложная на, самом деле. Есть состояние потока, это когда ты работаешь без времени, полностью в процессе, когда мозг оперирует огромными объемами информации. Поток, это не, всё, откуда он, если ясно что мозг не может по физическим каналам, передавать такие обьемы информации в голове, есть дугой принцип передачи. Если смотреть ещё глубже, станет ясно, что мы обращаемя к информации, куда-то в другое место, и получаем ответы и видения процесса, образа своих шагов (далее вопрос, открыт, куда и как (есть эксперимент, с лягушками, в полностью закрытом металлическом резервуаре и немного открытом)).
Хочется, чтобы через 30 лет кто-то, открыв наши исходники, почувствовал то же самое, что чувствовал я, читая эти старые программы: что здесь писал человек, не инструмент.
Сколько там процентов AI кода в гугле?
Думал, что аналогия с пластмассой будет о том, что они ломаются под нагрузкой, а тут опять луддитские тейки про "душу".
Ну, аналогия с пластмассой тут как раз к месту. Современный софт собирается из готовых "пластмассовых" компонентов (библиотек, фреймворков) - это быстро, дешево, масштабируемо. Но когда что-то ломается внутри такого компонента, починить это почти невозможно - ты просто меняешь "деталь" целиком. А раньше, когда все было "из железа", ты мог починить что угодно, потому что сам это сделал
Один из лучший примеров кода, с которым мне довелось поработать -- библиотека SQLite. Желающие могут причаститься.
Посмотрел. И странно, нет пробелов операторов в if, for и т. д. Это плохо и странно для меня. I don't know, так делать.
Чем плохо?
Символы считываются медленнее, если не выглядят знакомо.
Наоборот. Пример:
print( ... )
func( ... )Но почему
if (...)
for (...)
Потому что первое - вызов функции, а второе - управление потоком
Вероятно потому, что операция оперирует операндами, в отличии от процедуры и функции, которые принимают аргументы. С точки зрения синтаксического дерева, это разные узлы. Поэтому и правила могут отличаться.
В вашем примере, для операций приведен не полный набор операндов:
if (...) ...
for (...) ...
Не предлагаете ли писать и опущенный операнд без пробела или переноса строки, как в случае отсутствия разделителя между оператором и последующими операндами? Иначе создаётся ощущение что операция заканчивается вместе со скобкой.
В целом это жесть. Всё слиплось воедино. Нет культуры написания кода. Там где необходимы пробелы их нет. Код поход на "индус код". Короче я был удивлен когда открыл случайный файл с котом на Си.
Видимо, нехваткой "воздуха".
Один из лучший примеров кода, с которым мне довелось поработать -- библиотека SQLite. Желающие могут причаститься.
У SQLite ещё и очень интересный этический кодекс: https://sqlite.org/codeofethics.html. Без него, боюсь, впечатление может оказаться несколько неполным. :)
через 30 лет кто-то, открыв наши исходники
Это запрещено авторским правом.
Когда код был лицом инженера
У каждого программиста был свой почерк. Настоящий, узнаваемый.
Я видел проекты, где можно было определить автора по тому, как он выстраивает отступы, как ставит комментарии, как называет переменные.
Когда писал программы на ПЛ1 для ЕС1035 , то операторы по одному виду листинга программы определяли кто автор.
Я не ностальгирую по перфокартам
Но согласитесь в них что то есть. Когда сидишь и набираешь программу на перфокарты на перфораторе. а потом проверяешь правильность набора . перенабиваешь заново ошибочные строки , и только потом отдаешь колоду карт на исполнение.
отдаешь колоду карт на исполнение
Какие там девушки-операторы были, с одной по имени Аэлита я работал:-)
Закладки из перфокарт (отец был динозавром СУБД на ЕС ЭВМ) до сих пор встречаю в книгах, перекочевавших из его библиотеки... Сам застав понятия "машинное время" и "пакетное выполнение" вспоминаю, что тоже когда-то умел писать код на несколько сотен строк без копипастов, автоподстановок и синтаксического контроля без единой ошибки. И да, оставлял комментарии. Я не любитель рассматривать старые фотографии (у меня даже детские видео сына-уже-студента ещё лежат на MiniDV кассетах в коробке), но знаю, где лежит моя коробка с дискетами 5.25" Dyson (да пребудет с ними сила).Пожалуй пойду в выходные присмотрю на барахолке антикварный Пентиум с флоппи-дисководом.
Обожаю я вот это мужицкое "серьезно фоткаюсь с семьей" и "я самый счастливый мужик в мире, я поймал карася"
Ваш комментарий мне прям вот это напомнил
Ну не знаю, цепляться за прошлое - нафиг нужно то? Были и у меня дискеты 5.25 и даже одна 8 дюймовая. Продал на ибее, как и все старье. А древние глюкавые машины (ЕС, СМ и прочая) без дрожи вспоминать не хочу.
Я как то раз свой недельный труд в виде почти полтыщи перфокарт понес из перфораторской на машину. По пути споткнулся и вся стопка рассыпалась по полу коридора. Поскольку я их не пронумеровал, да и перфоратор был самый простой, он только дырки пробивал, а не печатал на перфокарте дополнительно текст, то еще день потратил на приведение всей колоды в правильный порядок. Даже с распечаткой.
Вот если бы в наса, космическую программу по полёту на луну, сохранили бы на перфокартах, она бы не потерялась. А то эти ваши новомодные дискеты, ищи их теперь.
Я сам и раньше и сейчас пытаюсь поддерживать человечность. Помню как кто-то открыл мой код, а там "если не пришла жёлтая курица - то ничего страшного" и всё было понятно. Логика такая, что можно не бояться, что какие-то данные не пришли. Оно дальше как надо отработает. Но было весело это спустя время услышать что вот, мой код прочитали и эта строчка их зацепила
Не надо пах железом...
«Сколько тактов займёт эта операция?» — и получаю в ответ улыбку.
А можно, нахмурившись, про спекулятивное исполнение вне очереди на конвеере пофантазировать, инженер точных наук мой. (:
Я думаю, раньше программирование было в меньшей мере поставлено на поток как сегодня. Т.е. провожу параллель вплоть до конвееризации и разделения труда. Ядро Линукс выхолощено до максимума. Старые комментарии делали "шаги в сторону", сейчас вряд ли факи в комментариях пропустят? (делаю предположение на основе их уменьшающегося числа в коде). А где есть лишнее время, там работается легче и человечней. Был code owner, не только как ревьювер, а вообще единоличный автор всей или части программы.
Для меня человечность ныне измеряется в удобстве пользования и документации. Комментарии по-прежнему пишу мало (т.е. современное мышление), но из-за подобных статей иногда задумываюсь. А выражаю человечность через stdout. Можно сухо "Invalid input". Но почему бы машине не "разговаривать" с пользователем? "Did you forget XY?". "I can't bind to the configured port, maybe because ..." и т.п.
Я сейчас вспоминаю расчетные программы 80х, написанные на Коболе, Фортране и Паскале настоящими инженерами, и у меня волосы на жопе шевелятся. Такого зубодробительно нечитаемого и неосмыслимого кода большинство ныне живущих и не видело. Если говорить про "человечность", то этот код был больше похож на некроморфов из DS.
З.Ы. Погромисты, перестаньте называть себя инженерами.
PDP-11 это хорошо. Могу привести пример с MSP430, который вроде на неё похож. Было первое семейство MSP-шек. Там всё просто и понятно. Было второе - практически то же самое. И было пятое. В котором надо было напихать множество функционала так, чтобы сохранить совместимость с предыдущими семействами. Поэтому новый функционал был, как бы это сказать, вставлен перректально. Нет, там не костыли, просто по сравнению с первыми семействами всё было устроено заметно сложнее и неудобнее. А потом я полез в ARM-ы. Там тоже аналогичная ситуация: в Cortex-M0...M3 всё просто и понятно. А когда пытаешься на низком уровне разобраться, как работает USB на каком-нибудь Cortex A53, становится неудобно сидеть, потому что волосы на седалище начинают шевелиться.
Современный хард слишком сложен, чтобы под него можно было писать простой и понятный софт.
Поддерживаю двумя руками. Касательно почерка (хотя и не про чисто программирование):
В своё время, при пусконаладке одного из наших объектов, по-быстрому сваял расчётную схему процесса в excel. Разрисована схема процесса, все операции, стрелочки, кружочки, таблички с параметрами, все дела. Вбиваешь нужные исходные данные - рассчитываются показатели процесса. Прошло 15 лет, многое поменялось (из показателей), и вот, в очередной раз решили что-то изменить. Присылают мне на почту файлик, - посмотри, мол, так сможем нормально работать? И я вижу, что файлик-то мой, тот самый (почерк в таких делах уже тогда был выработан - имена, обозначение операций, форматы стрелок, ячеек, цветовые схемы и т. п.). Звоню на производство кому-то из "старичков":
- Пацаны, это что, тот самый файл, который я вам тогда на пусконаладке рисовал?
- Ну да.
- Так это 15 лет назад было!
- А что, там всё красиво, удобно, понятно - мы постоянно пользуемся, нафига чего-то менять?
Честно скажу, было приятно от того, что когда-то сделал полезную для людей вещь, которой до сих пор пользуются и менять не хотят.
Ну и на днях прислали для анализа производственной статистки сводку с предприятия, которым я очень давно не занимался. Открываю - очень знакомая. Смотрю, кто автор - а это я эту форму делал 11 лет назад.
Комментарии в каждой строчке были необходимостью, ибо без них чёрт ногу сломит. Писали ведь на ассемблере или чём-то другом, не очень высокоуровневом. Сейчас же абстракции современных языков программирования позволяют показывать намерения программиста средствами самого языка, так что комментарии редко нужны.
Нет, по крайней мере, в низкоуровневой разработке. Средства языка позволяют показать, что мы делаем. И возможно, даже зачем мы делаем. Но не позволяют показать, почему мы делаем именно так.
Условно говоря: по коду можно понять, что "вот тут - пауза в 100 мсек". Если писали качественно, то можно даже понять, что "мы ждём инициализации узла XXX". Но нельзя понять, что "при включении устройства надо проводить инициализацию узлов A, B и C последовательно, хотя они друг с другом никак не связаны, либо выждать паузу. Потому что если мы их врубим сразу - то у нас при подсевшей батарейке просядет питание, и устройство может уйти в перезагрузку".
С языка снял! Мы писали комментарии, превращая машинный код в алгоритм, описанный человеческим языком. Код легко читался, пока ты его помнишь и пока ты в нем варишься — я про ассемблер. «Прочитать» забытый код — это исполнить его в голове. Одна строчка когда сегодня — это (условно) могло занять несколько экранов на TASM. Без реперных точек в виде комментариев было просто невозможно работать. Ладно ещё написать, но поддерживать-тот иначе как!
Все эти милые кусочки программ на ассемблере хороши и ламповы, когда рассматриваешь их изолированно, с подробным комментарием и в ностальгическом контексте. А вот когда пытаешься пытаешься написать на ассемблере относительно сложную, контролируемую и сопровождаемую систему, то литературного слога очень скоро начинает не хватать...
за комментарии могу ответить
лично для себя всегда все комментирую "на лету" что бы потом когда вернусь было проще разбираться
но по работе пишу без коментариев, максимум формальные к методам. Очень часто сначала пишется и отлаживается кусок "для себя", а затем он вычесывается, сливается в один коммит и уже так пушится в работу
просто потому что командная работа. Это себе я могу написать "ебаный пиздец но оно работает, не лезть!" или "скопипащенно из решения http://..., вроде работает но надо погонять". Для публики или в команде это нормальная вежливость, как не присоединятся на видеосозвон в одних трусах. Вот только вычитка всех коментариев это время и силы, потому для економии я просто их удаляю. Для вещей которые еще не закончены, развожу по разным веткам для удобства.
Я однажды, в пятилетней давности коде, наткнулся на комментарий с дружеским приветствием и сочувствием от автора к тому, кто будет в его коде разбираться через года. Улыбнуло)
Система разработанная мною в в 2001 г. на SQL SERVER и DELPHI для одного дилера и содержащая CRM для менеджеров ,ЗАКАЗЫ,Снабжение,Отгрузки, Склад , хранилище документов в SQL Server и имеющая по тому времени много таких иновационных вещей как вычисляемые складские остатки , изменение приоритеов заказов с учетом скадских запасов и оплат и учетом частичных отгрузок , автоформирование спецификаций для комплектации заказов для снабжения , формирование счетов предложений и счетов на оплату, счетов фактур и накладных, импорт документов 1С бухгалтерию и т п. Система прожила 10 лет без особых проблем в связи с тем что логика все была в хранимых процедурах на сервере и клиент на DELPHI . Но к тому времени и контора стала хиреть и разваливаться, вернее стали разваливать, так как функцию дойной коровы она выполнила. Недавно посмотрел свой SQL код . В общем все неплохо выглядит, а прошло больше 20 лет.
Сегодня register ничего не даёт. А тогда — это был сигнал компилятору: "я знаю, что делаю".
Разработчик не надеялся на оптимизатор. Он думал, где переменная лежит, как устроен стек, что делает процессор.
Не из гордости — из необходимости. Это была настоящая инженерия, не программирование «на удачу».
Сегодня компилятор лучше вас знает, что надо делать. Требования выравнивания, иерархия кэшей, предсказание ветвления и тому подобное зашито в компилятор добрыми разработчиками процессора. Раньше не было ни таких навороченных процессоров, ни таких мощных компиляторов.
Я видел проекты, где можно было определить автора по тому, как он выстраивает отступы, как ставит комментарии, как называет переменные.
Спасибо, не надо. Пусть лучше весь проект будет в одном стиле, чем кто-то сможет определить автора
А там — живая связь между людьми через код.
О, да. Когда-то переписывал на сях код эквалайзера с DSP ассемблера с комментариями на немецком. Такая живая связь была, до сих пор побаливает.
А вот ещё другой случай: взяли на поддержку код на джаве от японской компании с комментами на японском. Почему-то японская компания не сумела в utf-8 и кодировка была какая-то японская. Коллега открыл код в редакторе, после чего ХР упала и подняться не смогла. Пришлось переустанавливать. В общем, ну её нафиг эту вашу живую связь.
Не всегда компилятор лучше вас знает. Слыхали про демосцену? Каждый такт и байт на счету, приходится изобретать методы, до которых не догадались создатели компилятора.
Все это очень мило, но автор упускает из виду масштаб. Код для PDP-11, который управляет одним устройством, и код современного веб-сервиса, который обслуживает миллионы пользователей - это задачи разного порядка сложности. Абстракции, фреймворки, линтеры - не от хорошей жизни, это инструменты, которые позволяют десяткам и сотням разработчиков не поубивать друг друга и хоть как-то поддерживать огромные кодовые базы. Человечность принесена в жертву масштабируемости
да, да, давайте ностальгировать по тупым копиляторам Си, которым надо было указывать какую локальную переменную стоит в регистр засунуть
и вообще, давайте писать на одном ассемблеер ради совсем уж полной "человечности"
Верх идиотизма писать комментарий к каждой строчке кода. Код должен быть понятен и читаем без комментариев (если это не касается супе сложной бизнесс логики) Т.е. мне как программисту нужно дважды читать одно и тоже : 1) сперва строку кода 2) потом строку комментария. Ведь и так понятно a = a + b что это сложение двух переменных. Зачем подобное комментировать?
Зачем разработчику знать про такты? Что они решают, когда современные процессоры,ОЗУ, диски имеют несколько уровней кэшей и в миллиард раз быстрее оптимизируют циклы, условия и от посчитанного количества тактов ничего не останется потому что cpu умеет предсказывать результат или поместит в кэш часть функций и будет их использовать.
Не нравится фреймворк - пиши в блокнотике. Да и вообще можно ручкой в тетраде писать код. Но насколько это эффективно?
Зачем в примерах используется сортировка? В любом современном языке все сортировки уже давным давно реализованы наилучшими способами - вызывай нужный метод и наслаждайся.
Сиди прокалывай дырочки в перфокартах и чувствуй себя инженером без инструментов мучающимся с сортировками массивах , а я буду наслаждаться автоматически генеративных кодом и творить мегаархиважные оптимизированные системы за считанные минуты.
Ну вот как часто кому-либо приходится оптимизировать сортировки? Есть sql, есть spark и другие инструменты где все это оптимизировано и реализовано. Зачем придумывать велосипед? Я не спорю что это нужно и важно , но менее чем в 5% случаев требуется самостоятельно реализовать собственный алгоритм поиска максимума, сортировки и т.п. Надо понимать что такое алгоритмическое программирование ,но если в твоей специализации или текущем месте работы оно не нужно то зачем его использовать?
Да, если разработка ПО ускорится в десятки раз от того что я куплю железяку на 128ГБ (256, 512) ОЗУ и забуду обо всех проблемах - то я ее куплю и буду наслаждаться и использовать везде Int32, а не мучаться с Int16 гонять байтики туда сюда , писать собственные оптимтзаторы и ради чего ? Чтобы сэкономить 2байта? Ну не смешите.
Автор предлагает деградировать и переместиться во время 640кб? Вернуться к дискетам?
Зачем столько раз повторять "душа" и "душевный"?
Я сегодня резал овощи просто ножом. Обычным бездушным массовым продуктом. А ведь раньше были ножи с душой. Хороший нож месяцами затачивается и полировался, наносился декор вручную. Вот бы все ножи были такими, чтобы через 30 лет все резали овощи ножами в которые вложена душа мастера. Это краткий пересказ статьи в лёгкой интерпретации, если кто не понял )))
У меня ножи из стали PGK, AUS8 и какие то Дамаск. Из нержи пару мультииулов только.
Точу на точилке tsprof 3мя алмазными брусками до 5000 грит. В линзовую заточку. Под 30 градусов.
Если опустить самолюбование задро..вом, то дальше по делу.
Точу раз в два месяца. Процедура занимает 5 минут на один нож. Все эти два месяца ножи фактически могут выступать в роли бритвы. Стейк или курогрудь мороженая или нет , толщиной до 4см режется за одно движение. Мороженная режется вообще давлением, без режущих движений. А ещё у меня огромный шрам на колене как раз из-за тупого ножа. При этом я не готовлю. Раз в неделю нарезал мясо, кинул в мультиварку на тушение и забыл о готовке на неделю.
Попробуйте попользоваться долго хорошими ножами, после этого пересмотрите свои комментарии.
Это я к чему - иногда аналогии - бывают ложными. Как в данном случае ироничное сравнение душевных ножей и душевных комментариев.
Инженеры будущего писали более человечный код сейчас
Конечно, у каждого свой опыт, но я работал в военке с инженерами прошлого. И код, который они писали (а некоторые до сих пор пишут), никто не мог поддерживать. Бывали случаи, когда они сами не могли поддерживать свой "человечный" код. И даже случаи, когда принималось решение полностью переписать большой кусок кода, потому что поддерживать и модернизировать его стало невыносимо сложно.
сами не могли поддерживать
Что именно мешало? В чём были проблемы?
Спасибо.
Основная, на мой взгляд, проблема указана в заголовке статьи - эти люди прежде всего инженеры, а не программисты.
Код рабочий, эффективный, местами даже красивый. Но о его поддержке особо не задумывались - функции на несколько сотен строк, однобуквенные переменный, побитовые трюки, куча глобальных переменных, магические константы и т.д. Как результат, код тяжело читать и в какой-то момент любая правка в одном месте ломает что-то в другом, код становится хрупким.
Расскажу историю из своего опыта. Переписывали кусок такого кода. Обнаружили функцию, которая переставляет местами две строки в распечатке результата. Стали разбираться, что за магия. Оказалось, автору было проще переставить итоговые строки, чем искать в собственном коде место, почему результаты оказались не на своем месте.
Другой пример - функция с шестью goto. Маленкькая, компактная, переписанный вариант был в 2.5 раза больше. Зато править его было в разы легче.
Спасибо!
Похоже, что авторы таких программ стояли перед выбором. Или программа, которая будет понятной и которую легко поддерживать. Или программа, которая выполнится сегодня и результат расчётов можно получить уже к вечеру. В этих условиях они старались уменьшить машинное время.
вероятно не стоит обобщать, для больших систем код писали качественно, включая документацию, вплоть до разработки отдельных стандартов специально под проект, бывало что наиболее важные компоненты делали разные команды, дублирование со сравнением результатов, все зависит от области применения
Я не обобщаю, просто говорю про свой опыт общения с инженерами старой школы.
Были сотни документов документации в год, которые проходили большое согласование с десятком подписей. Были отдельные алгоритмисты, которые писали псевдокод. Моей жене уходящая на пенсию бабушка передала 5 томов с сотней страниц алгоритмов. Ну и код писался эффективный, потому что железо ограничивало.
Но на момент, когда я пришел (2012 год), это все уже отмирало. В потоке согласований скорость изменений упала в разы, а серьезные изменения согласовывались месяцами. Алгоритмисты потеряли актуальность. Железо улучшилось на порядки и эффективность всех этих трюков с регистрами или битами потеряла смысл в большинстве мест, но сильно ухудшало читаемость. Зато оказалось, что поддерживать большую кодовую базу кода совсем не просто, а плохо организованного кода непросто даже для авторов.
Я без претензий пишу. Системы, которые создали эти люди с учетом ограничений по технологиям впечатляют. Но сейчас такой подход к разработке мало где применим. Можно восхищаться мастерством художников прошлого, но в реальной жизни пользоваться фотографиями.
вполне понимаю, типа Вашей бабушки, 50+ лет в программировании, художников в прошлом встречать не приходилось, плохо совместимо с высокой дисциплиной, но хороших программистов было достаточно, подход к разработке определяется уровнем ответственности, одно дело если от возможных ошибок сайт ломается, и другое дело если возможно жизнь людей зависит, требуется больше контроля над разработкой, отсюда выделение алгоритмистов, дополнительные ревью, сертификация кода и т.п., дорогое удовольствие, но необходимо,
про "функции с 6 goto" возможно тот код вообще ревью не проходил, все системы разные, и требования тоже
В давние времена код писали не только программисты. Тогда и программистов еще то никаких не было. Были ученые со своими научными формулами, были инженеры со своими расчетами,а были чуваки, которые были учеными инженерами и шарили в ЭВМ. Были и кодеры, которые готовые формулы и алгоритмы переводили в машинные коды. Вы можете вспомнить, что были и лозунги - каждый сможет себе написать программу, ученый, инженер, даже бухгалтер (превед SQL и 1С). Языков понаписали на любой лад, и вот эти все люди бросились автоматизировать свою работу, путем написания утилиток и программок. На том же фортране их понаписали столько, что актуальность имеет даже сегодня. Кобол - финансы, то же самое. Но писали их не "программисты", а например, доктора наук, студенты, профессора и академики, инженеры, теоретики-математики и в общем дофига народу писало. Ни о каком чистом коде и прочей зауми не задумывались - человек примерно понял как писать программу, что надо компу обьяснить, ну каждый и обьяснял на свой лад. Именно оттуда с этих времен уже растут корни той непролазной чащи легаси, в которой мы находимся сейчас.
верно, все кому требовалось в том числе инженеры и студенты, именно поэтому не стоит обобщать, разработкой больших систем реального времени занимались примерно с середины 50х, и технология программирования развивалась именно на больших проектах, которые имели мало общего с тем, чем занимались студенты и профессора
непролазной чащи легаси
А что плохого в том, что работа уже сделана?
И как следовало действовать, чтобы этой «чащи легаси» не было?
Да в общем то ничего плохого в легаси нет. Кроме того, что чтобы в это вникнуть (дабы добавить немного нового функционала) придется затратить чрезмерные усилия, а иногда это просто тысячи человеко-лет.
И как следовало действовать, чтобы этой «чащи легаси» не было?
Вы меня спрашиваете? Честно говоря, я не знаю. Наверное, никак это было не изменить даже тогда. Пока одни задумывались о том, как писать собственно этот код (все практики которые имеем и развились к текущему моменту), другие с пулеметной скоростью строчили свои программы без оглядки на то, что в их коде кто-то будет разбираться. Потому что их сфера интересов (за что им деньги платят в том числе) была не в программах, а в результате вычислений этих программ. Вот оттого и бардак был - но это только предположение. Да и сам я не очень-то и задумывался раньше об этом, пока не пришло время через 3 года поправить код. Вот и были лучи ненависти ко мне старому от меня нового. Сейчас пишу так, что лично я пойму код и через 10 лет, но очень не факт. что его поймет кто-то другой.
И между тем - я не программист даже близко) И да, меня интересует в основном результат. Но хотя бы общее понимание вот этого всего уже есть.
Бизнес сделал нас холодными, а зависть - жестокими.
Про комментарии в каждой строке это наоборот зло, которое пришло из ассемблера, где без этого не понятно что ты делаешь. Работал с кодом написанным ещё в 90-х и 00-х для очень ответственных железяк на C. Комментарии как раз почти на каждой строке, везде написано ЧТО делается, но у меня возникал только один вопрос - ЗАЧЕМ. И это не было написано нигде, вообще в принципе.
Каких то 25 лет назад я написал одну служебную программу по красоте на mfc и с oop. Она весила 300кб где то со статической mfc. Работала хорошо, по сравнению с конкурентами даже очень хорошо выполняла свои задачи.
Потом я зарядился парой пачек кэптен блека и за двое суток переписал ее на голый с++, даже crt отрезал. Точнее отрезал все что отрезалось, в том числе кастомно собрал секции PE файла. В итоге программа стала занимать 3.3 килобайта делала то же самое и ничуть не хуже. Для справки ехе файл стандартными средствами не может быть меньше 4096 байт тк там 4 секции по 1024. Но вот получилось сделать.
Благодаря этому продажи выросли на порядок. Т.к. наша ца в то время были adsl юзера и скорость загрузки а следовательно доступ пользователя к сервису улучшился на 2 порядка.
Поэтому да, раньше трава была зеленее.
А сейчас на каждом архитектурном звонке постоянно долблю тимлидам - ребята, не забывайте - кремний дешевле мяса. Если надо ещё серваков поставим, ядер добавим, памяти накинем. Главное быстрее выкатить фичу и чтоб там был хороший и элегантный код а не ассемблерные вставки
А меня раздражает, когда я вижу в коде личность. Личность допустимо видеть только в личном коде, а в командном проекте её быть не должно.
Во времена покорения космоса люди тоже работали в команде. И это были команды с сильными личностями во главе и на ключевых местах. Я вообще не понимаю, как вы можете называть современными "командами" это обезличенное стадо? То, что у вас отобрали личности, является шагом к вашему полному замещению.
В современном мире программы пишутся командами. Если это ваш домашний проект, вы в праве проявлять свою личность в нём как вам заблагорассудится (возможно, именно о таких проектах - проектах с одним разработчиком - пишет автор статьи). Но если вы в команде, то будьте добры играть по правилам команды! Спросите об этом участников оркестра или игроков баскетбольной команды! Я не за отмену личности в командном проекте, но за проявление в нём лишь тех её качеств, что способствуют этой командной работе, а не разрушают её (заявляю как в прошлом профессиональный баскетболист, а в настоящем - профессиональный программист). Дело в том, что личность может проявляться по-разному: можно способствовать общему делу, а можно с упорством достойным лучшего применения проталкивать в C#-проект нотацию Йоды только потому, что на заре своего становления программистом вы использовали её в С++, впечатлились ей и теперь тащите её в любой язык (тоже пример из жизни). Если вы таким образом проявляете свою личность, то для команды будет лучше, если вы засунете свою личность куда подальше и дадите другим выдохнуть. Ну или покинете проект.
Полностью поддерживаю Автора статьи. Да, я как раз из тех, кто в те времена писал тот самый аккуратный код. Мы уже никогда не станем другими. Жаль только, что наши знания и опыт будут снова востребованы только через 3-4 поколения. Это неизбежно - история повторяется. ИИ приведет к упадку цивилизации. Я не призываю отказываться от благ цивилизации. Просто нужно вернуться к советской модели методологии образования, только с учетом нынешнего духа времени и современных технологий .
Ассемблер PDP-11 – это поэзия!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я думаю, что инженеры прошлого писали более человечный код