Comments 430
Эпоха красивого кода прошла. Пришло время быдлокода
Слышу это нытьё как минимум последние 15 лет.
Автор пришёл в разработку на PHP, где из-за низкого входного порога и большого количества "примеров" из сети, качество кода очень низкое. Плюс сам язык не дисциплинирует писать "красиво". В мобильной разработке, тут надо смотреть, потому что если мобильная разработка на каком-то flutter, то там тоже веселье то еще с разработчиками, языком и фреймворком как таковым.
А вообще, есть разные команды, разные подходы к программированию и тестированию. Если компания управляется дальновидным руководством, то и качество кода будет высоким. А нытье по поводу качества кода будет всегда, но учитывая сложность проектов сейчас и 15 лет назад, вполне закономерно, что и количество ошибок будет несколько больше, хотя я прям критичный быдлокод в мире java видел пару раз, один от индийского аутсорса, а второй - просто 10-летний код, который никто не рефакторил, но что-то дополняли и тд, плюс в компании не было никаких стандартов и даже sonarcloud не включен в ci\cd
Да, в мобильной разработке использую Flutter. Но не скажу что он не дисциплинирует. Типизация, null-safety и generics очень даже дисциплинируют. А есть ли язык где или хорошо или никак? Ну, скажем, разработчики ядра SQL наверняка работают иначе чем вэб разработчики?
C++ - не могу сказать, что или хорошо или никак, но там порог входа такой, что те, кто совсем плохо делают отсеиваются сразу, а те, кто не очень делают, обычно потом испытывают большие проблемы либо со сроками либо с качеством и тоже отсеиваются. Пока видел только один проект, где жаловались на качество С++ кода и он был тоже разработан индийскими аутсорсерами.
По своему опыту, не могу сказать что порог входа в C++ выше остальных языков. Да и говнокодить там можно не хуже, чем это делают на php =) Язык даже падением производительности за это не накажет, в большинстве случаев.
но там порог входа такой, что те, кто совсем плохо делают отсеиваются сразу
В 90-е и 00-е на C++ было написано столько говнокода, что и на внуков хватит.
Посмотрите опытным взглядом на код LibreOffice, мне интересно мнение о качестве тамошнего кода, особенно из тех файлов, которые 20 лет никто не трогал и которые относятся к модулю Base (это СУБД там типа MS Access)
Я сотни проектов на плюсах видел, которые по количеству говнокода делают во все щели другие проекты на других якобы более лёгких языках.
К чему это я. Порог входа абсолютно не делает твой код лучше. И тем более не является статистической величиной, от которой коррелирует качество кода. Максимум, что этот порог даёт - возможность кидать понты во время споров.
Итого. Я стараюсь ориентироваться не на язык и порог входа, а на опыт и зрелость разработчика, который не позволяет себе такие ламерские суждения, присущие вайтишникам и джунам.
И да, порог входа влияет только на количество разработчиков в стэке. Скажем так среди ляма пыхокодеров 800к говнопыхарей а среди 500к жавистов - 400к говножавистов. Казалось бы, в абсолютных величинах действительно первых больше. Но статистически и тех, и других, 80% :)
Ой какие мы крутые.
И сотни проектов на плюсах видели и даже такие ламерские суждения себе не позволяете.
От того, сколько говнокода видал, я стал не круче, а наоборот неуверенней и осторожней =)
Раз уж ветка с понтами, надо понтануться.
В чем я действительно крут, так это в поедании картошки фри.
Говнокодом полны решения, что являют собой попущение со стороны инженерии.
Те продукты, которые приносят компаниям миллионы денег и становятся идолами, которых трогать руками нельзя! А можно лишь обмазывать слоями новых фич поверх старой облупленой оболочки.
Ритуал обмазывания ортогонален составу новых фич, который суть определяется языком.
Иными словами: говнокод привносят ритуалы не от инженерии.
>А есть ли язык где или хорошо или никак?
Haskell же! Наговнокодить и там можно, наверняка, но все таки очень строгий язык из коробки, и компилятор постоянно больно бъет по рукам.
В хаскеле можно всё делать парой десятков способов, в зависимости от извращенности фантазии и оторванности от бытия. Я бы как пример привёл go как язык в котором степень быдлокодности попытались привести к стандарту. Не совсем ответ на поставленный вопрос, скорее "или как положено или никак". Ни в коем случае не сторонник go, by the way.
Увы, но Haskell не даёт никаких гарантий по времени исполнения, поэтому без культуры делать быстрые программы получается, к примеру, stack. Как я уже писал, при запуске на полностью собранном проекте этот stack что-то делает секунду-другую, а не выходит сразу, как make.
С другой стороны, программирование - это же творческая профессия, слава богу, а не копание от забора до обеда. Ну оборотной стороной творческого труда является необходимость в жёсткой самодисциплине.
Я не говорю, что make - образец культуры, дедушка вообще очень старый, ему пора на покой. Но stack - это образец отсутствия культуры производительности, и отсутствие каких-либо compile-time гарантий производительности. Согласитесь, будь у Haskell гарантии производительности (предупреждения, когда код будет выполняться слишком долго), типичный хаскелист писал бы тогда быстрый код. Чисто из соображений warning-free.
Да, писать быстрые программы на Хаскеле - это вопрос некоторых простых практик. Но самодисциплина, заставляющая программиста применять эти практики - вопрос культуры. А культура вокруг GHC, увы, не включает в себя производительность. И это именно вопрос культуры - сообщества вокруг Ocaml и Clean (микросообщество) делают быстрые программы, базируясь на, в целом, том же технологическом фундаменте.
А такие предупреждения вообще хоть у какого-нибудь языка есть?
Наиближайшее - во всяких верилогах есть проверки на скорость. Но вообще-то это же ваша область деятельности - следующий шаг за всякими тотальностями. Я "на эту кухню только кушать хожу". :-) :-) :-)
Я в прошлом треде о производительности давал ссылки — включает, вполне себе.
Я же без наездов. Ну вот такой факт, печальный для меня.
Я, конечно, ни разу не программист и не математик, и могу сильно ошибаться, но насколько я понимаю, проблема оценки времени исполнения <на этапе компиляции> похожа на проблему остановки. Компилятор не сможет оценить эффективность алгоритма исходя из самого алгоритма. Классический пример — поиск совершенных чисел среди множества нечетных чисел, в данный момент не доказано, и не опровергнуто, есть ли такие или нет. Единственный метод поиска — грубый перебор. Соответственно, у <любого> компилятора не существует никаких критериев для оценки времени исполнения такой функции. И таких задач немало.
Способов определить сходимость произвольной функции не существует.
И опять-таки, откуда компилятору знать, что циклопическое количество времени, необходимое на проверку очередного кандидата на совершенное нечетное число — это вполне оптимальный срок выполнения?
Конечно, сферический компилятор в вакууме в определенных известных случаях мог бы оценивать класс сложности функции. Например, подсказывая, что данный в коде алгоритм сортировки неэффективен в общем случае. Но что это даст на практике? Выбор оптимального в конкретном случае алгоритма сортировки это все таки — проблема программиста, и она совершенно не лежит в области задач компилятора, мне кажется.
Я, конечно, ни разу не программист и не математик, и могу сильно ошибаться, но насколько я понимаю, проблема оценки времени исполнения <на этапе компиляции> похожа на проблему остановки.
Да, конечно.
Способов определить сходимость произвольной функции не существует.
Разумеется. Поэтому соответствующие программы не могут вызывать абсолютно произвольные функции. В общем, это же уже реализовано с проверкой тотальности в том же F*, к примеру. Грубо говоря, компилятор F* пытается проверить функцию на тотальность, но если у него это не получается, то он требует её переписать так, чтобы ему стало очевидно.
И опять-таки, откуда компилятору знать, что циклопическое количество времени, необходимое на проверку очередного кандидата на совершенное
нечетное число — это вполне оптимальный срок выполнения?
Очевидно, надо задавать примерные ограничения на кол-во тактов/кол-во операций доступа к памяти, кол-во операций считывания с диска и т.д.
Это всё совершенно неразработано, но некоторые подвижки есть. Например, сейчас hot topic - это так называемы "эффекты". Это когда в языке программирования операции ввода-вывода, исключения и т.д. классифицируются и описываются для компилятора так, чтобы он что-то с этим мог сделать (например, слить серию последовательных printf'ов в один или переупорядочить).
Вообще, я слышал что были методы для решения оптимизации кода, проблема что там было 100500 правил, какие-то сложные математические модели и хелловорлд мог по нескольку часов собираться. В итоге всё ожидаемо заглохло
Тотальность важна для метатеоретии, даже если соответствующая функция выполняется очень долго, или не выполняется вообще никогда в рантайме.
Ну раз французы делают, а они фактически работают на министерство обороны, то какое-то практическое применение тотальности явно есть. Ограниченное, конечно.
и рассуждать о ней в присутствии оптимизаций сложнее.
Всё простое сделано во времена Дейкстры.
Только не говори, что искусство
Про быстродействие не спорю, но пример не очень корректный.
stack на 3 уровня абстракции выше, чем make.
Ну так там два уровня лишних.
В экосистеме Ocaml, например, управление репозитариями и сборка разделены между OPAM и dune. В результате, когда мы работаем в цикле "изменил-скомпилировал-прогнал-проверил", мы запускаем быструю dune, а не медленный OPAM. А когда раз в день или реже обновляем репозитарии, тогда запускаем медленный OPAM.
В экосистеме Haskell можно было бы сделать то же самое, но это не в приоритете - см. коммент @0xd34df00d неподалёку, если не верите мне.
Поэтому пример 146% корректный, и именно про культурные различия. Никаких технических препятствий сделать так, как у французов, нет.
Да, аналогичная культурная разница в apt-get и yum. В apt-get разделены операции скачивания оглавления репозитария и установки-удаления пакетов, а в yum они совмещены.
Поэтому в ALT и Debian можно скачать список текущих пакетов репозитария один раз (apt-get update), а потом относительно быстро устанавливать пакеты, запуская apt-get install. В RedHat же (последний раз, когда я это видел), при каждой установке проверяется, что каталог свежий.
Зато в ALT можно нарваться на ошибку при попытке скачать устаревший пакет, а в RH простые операции очень медленны.
Тоже подумал о PL SQL
Также - Delphi последних лет
Но сам же могу накидать контр примеры. Язык на то и язык чтобы позволять и стихи, и базарную брань
Плюс сам язык не дисциплинирует писать "красиво"
Это уже меняется... постепенно. Но большое количество легаси-библиотек и странных легаси-решений все еще позволяют выстрелить себе в ногу там, где казалось бы, это невозможно.
Вот один из моих последних таких случаев:
$this->count = $query_count->execute()->fetchNum(); //кол-во строк в результирующем наборе
if ($this->count === 0) {
throw new Exception('Ничего не найдено. Укажите другие критерии отбора.');
}
Казалось бы, что могло пойти не так? Внезапно, fetchNum() возвращает целое число, а... строку. А я такой губу раскатал, решил строгую типизацию завезти...
Если мне не изменяет склероз, Idea (IDE для Java) подчеркнет подобный код и выдаст предупреждение, что лучше использовать не полный подсчет, а конструкцию вида query.hasElements(). С обоснованием, что первая линейно зависит от количества элементов, а вторая выполнится за константу.
Разумеется, подсказки имеют ограничения, но если все в одной строке или с использованием streams, то такие подсказки помогают. Особенно неопытным программистам.
PHPStorm точно так же валит кучу подсказок, возможно и ваш вариант подсветит. Мне больше интересно почему автор коммента пишет про строгую типизацию, при том что даже PSR не придерживается судя по неймингу переменных через _ вместо camelCase, как бы уже стандарт языка и подобный нейминг как в комменте уже моветон. Следующий момент - метод fetchNum() - это либо легаси-легаси из древних версий языка, либо самописный метод-обертка над PDO, ибо в официальной доке по языку такого нет, может еще в каком фреймворке такое есть, но в symfony подобного не присутствует, есть в либах fetchNumeric() но это не оно, в зенде тоже подобного не нашел, а для задачи автора вполне подходит PDOStatement::rowCount() который как раз строго типизирован и всегда вернет int. Короче говоря данная проблема скорее из-за устаревшего фреймворка или же самописного решения, а не из-за языка как такового. Плюс личный опыт говорит о том, что перевод легаси проекта на новую версию языка с типизацией не так тривиален как обычное строгое сравнение результата легаси метода с интом
при том что даже PSR не придерживается
Вы путаете теплое и мягкое.
Нэйминг - это мягкое. Это соглашения о том, как хорошо бы писать. Потому что мы так договорились, а не потому, что все, кто пишут иначе - ЕРЕТИКИ КОТОРЫХ НУЖНО СЖЕЧЬ.
Строгая типизация - это теплое. Это совсем другое.
либо самописный метод-обертка над PDO
Да, и это не мой метод-обёртка, к сожалению. Глубже, под капотом - библиотека для работы со сфинксом over PDO. И почему, когда для метода в комментарях указано 'returns int' он возвращает что угодно (на самом деле он возвращает array { 0 => count } - я не постигаю.
Напоминаю, из PSR-1:
4.2. Properties
This guide intentionally avoids any recommendation regarding the use of
$StudlyCaps,$camelCase, or$under_scoreproperty names.Whatever naming convention is used SHOULD be applied consistently within a reasonable scope. That scope may be vendor-level, package-level, class-level, or method-level.
Обязательное требование к camelCase относится к именам методов.
По поводу соглашений о стиле можем в принципе проехать, видимо у всех по-своему, но я за все годы коммерческой разработки не встречал ни на одном проекте чтобы нейминг методов был в camelCase, а переменных иначе, когда такое встречаешь, это явный запашок легаси и читать довольно больно, однако с чего вы решили что аннотация return обязана говорить правду?) Вам не повезло - либа устарела и возможно эта аннотация имела место быть до введения строгой типизации, когда по сути 1 и '1' еще являлись одним и тем же благодаря приведению типов, а == в проекте не считалось зашкваром. В вашем случае я бы лично посоветовал отказаться от либы, либо посмотреть в гите разрабов, может все же появилась поддержка новых версий языка. Но в любом случае это не проблема языка как такового, а проблема проекта и сторонней либы, на которую проект завязан
нейминг методов был в camelCase, а переменных иначе, когда такое встречаешь, это явный запашок легаси и читать довольно больно,
Понимаете, на самом деле всё это - сахар, причем даже не синтаксический :)
Интерпретатору-то плевать, как я буду методы называть (хоть с помощью эмодзи), это все делается для человека. Для моего потенциального преемника.
Поэтому я буду называть методы или поля так, как удобно. Если мне удобно назвать переменную `query_count` - я назову её так. Потому что так удобнее читать, чем queryCount , потому что знак подчеркивания послужит заменой пробелу. Визуальной заменой. Мне в коде будет проще отличить queryCount от queryData. Понимаете?
И, правило с camelCase приходится осознанно нарушать, например, в случае метода по имени getItemsIDSet . Да, для наглядности - get_Items_ID_set гораздо нагляднее, чем слипшиеся буквы разных регистров.
Повторюсь: code style - для людей.
Хорошо бы его соблюдать. Нарушать его - можно, если это сделано определенной целью.
посоветовал отказаться от либы,
Это невозможно. Альтернативы просто нет (есть официальная от разработчиков, но там еще страшнее). Проще переписать либу, тем более она года 3 уже не обновлялась.
Но - время, время! :(
это все делается для человека. Для моего потенциального преемника. Поэтому я буду называть методы или поля так, как удобно. Если мне удобно назвать переменную query_count — я назову её так. Вот любопытно: а вы считаете, что вашему потенциальному преемнику будет удобно так же, как удобно вам?
Честно говоря, сомневаюсь, что ему придется лезть в этот код (зачем? метод атомарен, комментарий + параметры строго соответствуют тому, что он делает, тип возвращаемого значения строго определен, метод назван понятно ).
Более того, сомневаюсь, что он вообще будет (хотя и учитываю эту вероятность, все мы смертны).
Подозреваю, что если он появится - он не будет разбираться в моем коде, выкинет на мороз всю кодовую базу от первой до последней строчки и напишет её заново на каком-нибудь ларавеле.
Это мне приходится поддерживать чужое легаси и медленно, очень медленно переписывать его на современный манер.
Честно говоря, сомневаюсь, что ему придется лезть в этот код [...] Более того, сомневаюсь, что он вообще будет [...] Подозреваю, что если он появится — он не будет разбираться в моем коде, выкинет на мороз всю кодовую базу от первой до последней строчки и напишет её заново на каком-нибудь ларавеле.
Тогда зачем было писать "это все делается для [...] моего потенциального преемника"? По вашему описанию вы пишете исключительно для себя.
Вы выдираете слова из контекста. Еще раз:
Интерпретатору-то плевать, как я буду методы называть (хоть с помощью эмодзи), это все делается для человека.
Но даже если преемник у меня будет - я очень сомневаюсь, что он будет слепо требовать соблюдения PSR-1. В конце концов, ему ничего не помешает автозаменой переименовать методы.
В чем ваша претензия, сударь?
Судя по тому куску кода что вижу я в вашем примере - это обычная обертка над PDO и не думаю что будет сильно сложно использовать напрямую PDO если даже на другую либу перейти проблема
У вас недостаточно информации для суждения, поверьте.
Использовать напрямую PDO можно... но неудобно. Эта переменная - вообще - инстанс Query Builder'а
Открою небольшую тайну - query builder точно так же работает с адаптером, в той же доктрине в зависимости от адаптера на финальном этапе обработки полученной dql query оно все равно перегоняется в pdo или mysqli и выполняется абсолютно так же как описано в доке, все что не включено в инструментарий языка - не более чем обертки для упрощения жизни, если вам эту либу нельзя удалить, наверните на нее свою обертку сверху, которая будет тем самым грязным местом, которое будет служить прослойкой между легаси и вашим строго типизированным кодом, ваш метод getRowCount() будет дергать тот же метод либы, а на выход давать (int)$this->client->getRowCount() или что-то вроде того
Соглашусь с тем, что подчеркивание более читабельно. Читается быстрее, так как выглядит так же, как и обычный текст.
Тут главное - найти золотую середину. А то можно утонуть в красивых и правильных километровых именах.
Мне раньше тоже нравилось подчеркивание, но сейчас наоборот, больше нравится camelCase. Имя переменной для меня все равно не очень важно, они достаточно разные, чтобы я их различал, да и как известно важны только первая и последняя буквы :) а вот что важно, так это картинка кода. Когда имя переменной одним куском, мне легче понимать общую структуру, чем когда имя случайным образом разбито на несколько единиц. Код -- это нотация, а не литература.
Ну я так-то всегда по заветам Симфонии писал и пишу все в camelCase.
Просто увидел код с подчеркиванием и он мне понравился больше)
Причем в языке все еще сотни функций с подчеркиванием (и сотни без него вообще):
random_int, mb_strlen... но - strtr.
И даже strip_tags, но - stripslashes!
И ни одной в camelCase.
Там, похоже, совсем не было принципа. Кто как хотел, так и называл.
strripos, strnatcasecmp - поломай себе глаза)
str_word_count - куда читабельней и понятней
Моя прям мечта - чтобы все методы лежали внутри классов :)
И надо было писать String::length($s).
или Array::have_key()
Или даже use Array::*; ... have_key()
полифиллы для такого есть, в количестве, но что-то меня останавливает...
У меня такого поведения не наблюдается. Ни подчеркивания, ни предупреждения. Только для `$this->count == 0` рекомендуется использовать строгое сравнение.
Ну, я послушался. Зря.
Есть еще один аспект, который я возможно не смог явно выразить в своем комментарии.
В приведенном вами коде с if ($this->count === 0) ствол уже направлен в ногу: если результатом $query_count окажется не сотня, а миллион записей, то время выполнения метода вырастет линейно.
Получится ли "выстрелить в ногу"? Зависит от кучи факторов: локальности метода (если он используется только однажды, где строк заведомо мало), возможности что его скопипастят в более горячее место, нагруженности БД и т.д. Возможно, что даже миллиард записей не составит проблемы, кто знает?
Можно ли "направить ствол вверх"? Я не знаю, с моего дивана не видно. Просто заметил, что эта конструкция содержит-таки подводные камни. И это заметно, хоть я и не знаю PHP.
Вероятно, мне следовал бы процитировать весь код... ну, или, по крайней мере, ключевые моменты.
// хелпер для установки соединения итд
$i_count = SphinxToolkit::createInstance(...);
$i_count = $i_count
->select(SphinxQL::expr('COUNT(*)'));
// еще цепочка вызовов с $i_count
$this->count = $i_count->execute()->fetchNum()[0];
if (...)в чистом PDO я сказал бы fetchCol() и получил бы значение count(*).
В этой библиотеке я так сделать не могу. fetchNum возвращает мне массив из единственного элемента (с нулевым индексом), который содержит count(*) как строку.
Да, так понятней. Изначально я неправильно понял код, и сделал неверные выводы.
Получается, разработчик(и) библиотеки выбрали не только странный тип возвращаемого результата, но и вводящее в заблуждение имя метода (fetchNum()[0] вместо fetchCol или более привычное мне first().getInt(0) ). Стыд им и позор! :-)
было бы не очень если бы fetchNum возвращал строку
Классика!
А зачем вообще тут строгая типизация, тем более, если вы не можете быть уверены в типе, который возвращает fetchNum()?
Автор пришёл в разработку на PHP, где из-за низкого входного порога и большого количества "примеров" из сети, качество кода очень низкое.
На самом деле тут может быть любой язык с низким порогом вхождения: dotnet, js, python.. имхо особенно python, из-за большого количества низкокачественных курсов, развратной динамической типизации, отсутствию привычки создавать стабы.. и тд.
Возрастом/опытом воспоминания о том что ты писал "красивый" код остаются, но когда смотришь на код таких же каким ты был N-лет назад, почему то он уже не кажется красивым.))
А вообще раньше и трава была зеленее..)
Нет, эта тема не о том что раньше трава была зеленей и мороженное вкусней. Эта тема о том что понятие качественный код вообще вышло из обихода.
Эта тема о том что понятие качественный код вообще вышло из обихода.
… а как вы это определяете? А то я регулярно это выражение вокруг слышу.
BTW, у вас в заголовке "красивый код", а в комментарии — "качественный". Вы разделяете эти понятия?
Php специалист рассуждает о чистоте кода? Дожили
А в чем проблема? У вас есть аргументы в сторону качества вашего кода?
А вы на каких языках разрабатываете?
Чем проще на языке выстрелить себе в ногу - тем нужнее в нём выработанные сообществом правила/рекомендации чистоты кода.
Работаю под ios последние 10 лет, если вначале XCode был крутым продуктом, по моему ощущению, то последние годы то интеграцию с git сломают, приходится из консоли работать, то сейчас вообще на любой pull или checkout он просто падает. Так что ощущение что все больше и больше кладут на качество
При этом под красивым кодом некоторые еще умудряются понимать всю эту perl магию и прочие заклинания, для чтения которых надо прям мозги напрягать.
Код должен приносить деньги бизнесу - это главная цель. Откровенно плохой код рано или поздно погубит продукт и не будет приносить денег. Баланс между скоростью / качеством.
Как будто это говорит о том, что это неверно.
это вы один пример редкого бага в одном проекте аппроксимировали на всю индустрию?
Так было раньше, также продолжается и сейчас, я в свою бытность админом какие только матерные слова не выдумывал когда пытался, особенно в линуксе чтото обновить… когда с одной стороны ИБ требует актуальных версий, а производитель гвоздями прибил всё к дистру который устарел 5 лет назад… а производитель — какойнить Oracle
Нет. Но до этого я сталкивался с этим только в процессе разработки тех продуктов, над которыми работал. Я наблюдал тенденцию. Но всегда считал что быдлокод присутствует только до определенного уровня сложности проектов. Ну, скажем, я не думал у фейсбук, или майкрософт, или гугл или оракл вообще стоит вопрос "быстро или качественно?". "Уж там-то компании тратят уйму денег чтобы разработчики создавали шедевры программного кода!" - думал я. И именно для этого делаются зеленые лужайки, ставятся плейстейшны в офисах. Но пример с этой IDE дал повод думать что даже в крупных айтигигантах о коде никто уже не заботится.
p.s. нашел
===
вообще в крупных продуктах неизбежно накапливается легаси со смесью разных архитектур и стилей кодирования из-за того что 'сейчас так не пишут, давайте порефакторим'… и так повторить раз 20 из которых до конца ни одна попытка не доходит
Не так давно Visual Studio (вроде уже какая-то ревизия 2019 версии) просто крешилась при перетаскивании окошка с одного места на другое, так что проблема имеется.
С другой стороны, это всё косяки "старой школы", такое бывало всегда. Это записывается в трекер и ремонтируется в рабочем режиме. На мой вкус куда тоскливее то, что современный софт подчас опирается на конвейеры из совершенно разных компонентов, написанных разными людьми и плохо сочетающимися между собой.
Тот же IDE легко вызовет какой-нибудь gradle, он вызовет Java, а дальше подключится llvm, или node.js, или ещё чего. И когда в самом хвосте этого карнавала выскакивает ошибка, совершенно непонятно, кто тут виноват и что делать, разве что искать комбинацию версий, которая по загадочной причине вдруг доезжает до конца без ошибок.
Так что мы уже не просто быдлокод имеем, а целый быдлоконструктор.
Ух, а когда осознанная обработка ошибок (вместо глобального try) была простым делом?
Я думал, как с этим бороться, но ничего лучше чем скопировать стабильную версию себе, отладить сборку на ней и следить, чтоб ничего не сломалось, не придумалось. При этом, конечно, переезд на следующую версию чего угодно (java, gradle, node, "ваш любимый фреймворк") превращается в приключение.
Например, я вот пробовал собрать JDK под Windows. Ниасилил. Там cygwin, и всё нужно каких-то определённых версий, со специфичными багами, которые компенсируют другие баги )
В faang все плохо с качеством кода. Не могут сотни тысяч разработчиков выкатывать фичи как можно быстрей на написав говнокод. Методы в тысячи строк кода это норма.
Но всегда считал что быдлокод присутствует только до определенного уровня сложности проектов.
По идее ведь должно быть наоборот. Когда количество кода переваливает за десятки мегабайт а разработкой занимается уже целый отдел в пару десятков человек, делать код "красивым" и без ошибок становится сложнее на пару порядков.
Когда количество строк в проекте переваливает за сотни тысяч и миллионы, говнокодить становится все сложнее. Говнокод это технический долг. А когда накоплено слишком много тех долга, добавление нового функционала становится все дороже и дороже, пока до начальства наконец не доходит что пора рефакторить. Ну или проект загибается.
Оракл до сих пор живее всех живых
Как и MS Office (про качество кода в нем тоже легенды ходят)
...ну или пора не рефакторить, а докупить серверов, написать свой собственный интерпретатор php (или что там facebook написали чтобы быстрей php выполнялся?) или xhprof как это сделали twitter. Но чтобы сказать, "будем рефакторить"... слабо вериться :-)
вот вам другой пример - по крайней мере, в windows 7 была фича - сжатие файлов для экономии места. Но когда места становилось совсем уж мало (мегабайт так 100), то сжимались даже файлы загрузчика винды. При следующем включении уже нужен был загрузочный диск с виндой, чтобы ввести какие то команды и починить это непотребство.
То есть, в миллиардной компании майкрософт ни программисты, ни тестеровщики, ни какие нибудь бета тестеры не отловили этот баг.
Вряд ли можно протестировать то, что само по себе является средой для выполнения тестов :-) я про то что Windows - среда для выполнения тестов Windows)
Эта фишка с МЕ/ХР :) и она не зависила от места, нужно просто сжать системный диск разом, через свойства диска. Причём, там с загрузочным диском были две засады и можно были весело переустанавливать систему.
В 9х был иной (схожий) способ изящно завалить систему,но за давностью лет уже не помню.
И вопрос, как быть эстетам, которые хотят получать еще и эстетическое удовольствие от программирования?
Писать свои идеальные пет-проекты
Платить за чужие идеальные проекты
Да можно и на работе писать качественный красивый код. Только надо понимать, что начальнику надо быстро и чтобы работало, а то что ты там ещё придумал красивостей по пути — это уже скорее элемент хобби, для себя.
Ну и не надо считать красивым кодом какой-нибудь перегруз абстракций. Реально крутой код — это который легко читать (даже джунам) и легко удалять/менять, когда он потерял актуальность.
Реально крутой код — это который легко читать (даже джунам) и легко удалять/менять,
Значит, типичный код на Java по этому определению не может быть "реально крутым" просто потому что состоит из 100500 интерфейсов на 5 строк каждый с ровно одной реализацией и 100500 неймспейсов, собранных в имя, длиной с товарный состав на БАМе.
Писать свои идеальные пет-проекты
Так ведь, IDE сломалась!
Ха, а это тоже не помогает! Писать свой идеальный пет-проект можно только пока он никому не нужен. Выходит идеально, правда есть один недостаток - ага, то, что он никому не нужен. Как только проект становится кому-то нужен вдруг на тебя вываливается куча хотелок, странных трудно воспроизводимых багов, кто-то тебя уже ругает за то, что не фиксишь быстро нужное, кто-то шлёт мерж-реквесты, которые что-то исправляют, но написаны левой задней лапой, кто-то предлагает денег за поддержку того, что ты бы по своей воле никогда бы не поддерживал. И всё, вся идеальность пропала.
Ну то есть голодать. Художник должен быть голодным.
вопрос даже не в этом баге. сейчас никаких проблем подправить и обновить, ведь не время сидиромов, а время гигабитных домашних каналов.
Но... low priority, надо фичи делать, иначе гонку проиграем...
Так прикол ведь в том, что у Android Studio и нет никаких конкурентов. Какая у них может быть гонка?
Android Studio - одна из почти( а может уже и более ) десятка IDE у JetBrains. Платформа и баг с плагинами у них общие. Да и других "low priority" багов там тоже хватает
А какой-нибудь Rider или Clion очень даже конкурируют как минимум со студией и с VSCode
Так а где конкуренция Андроид Студии?
VSCode сейчас уже почти такая же популярная.
Для разработки под Андроид?
В VSCode такая же популярная как Android Studio для разработки под Android? Я ничего не перепутал? Судя по расширению https://marketplace.visualstudio.com/items?itemName=adelphes.android-dev-ext оно требует установленные тулзы и представляет собой только отладчик. А установка всего фарша нужного для разработки (sdf, build-tools, platform-tools, ndk, cmake, emulator) это вы уже как-нибудь руками. И у расширения пока только 4 отзыва. :)) Окей, написали, а теперь надо ошибки искать и профилировать. Что будем делать в VSCode? :))
С момента, как плуг для Eclipse "почил в биде" - отсутствует. Что крайне печально.
Платформа и баг с плагинами у них общие.
У андроид студии конкуренции может и нет( я не в курсе ), но как это меняет тот факт, что баг находится в коде, который общий с другими IDE, у которых конкуренция есть? И чинить его надо именно в этом шареном коде. А время и человеческие ресурсы конечные. У них даже более критичные баги не чинятся месяцами
VSCode
Который как минимум ваш покорный слуга выбирает за то, что там функционала меньше, чем в WebStorm. Потому меньше точек отказа.
Так и до ed скатиться можно.
что значит можно...
для меня vi это мерило качества проекта, если без современной ide невозможно в проекте работать(типа не угадать методы, надо постоянно прыгать между кучей файлов, ньюансы сборки и запуска лежат внутри пропертей иде, и так далее) - то проект надо немношк избегать :)
если без современной ide невозможно в проекте работать(типа не угадать методы, надо постоянно прыгать между кучей файлов, ньюансы сборки и запуска лежат внутри пропертей иде, и так далее)
полно подобных проектов написанных в vi где точно такойже кошмар. особенно в сишных.
самый прикол который я видел из такого, питоновский проект написанный без ide и собирающийся через makefile гигантского размера который сам чёто выкачивает-устанавливает, компилит… надо подключиь отладку? велком разбирать его построчно, ставить зависимости вручную, вкорячивать дебаггер чтобы ничего не отсохло при этом
Ви таки путаете vi и потоковый редактор.
что у Android Studio и нет никаких конкурентов
Eclipse, Net Beans, Delphi
делать так в живых проектах это самостоятельно себе эффект автобуса строить
а потом вы будете радостно искать себе программиста для андройд приложения который умеет в делфи
Или у вас уже есть пару delphi программистов которые по готовым исходникам десктопного приложения сделают нативный клиент на мобильные платформы.
p.s. только не нужно рассказывать что вы за полгода запросто найдёте делфи-сеньора который приложения на андройд пишет и оно не будет выглядеть как десктопное на мобилке
а потом они уволятся и вы их никем не замените
Из какого пальца вы высосали этот бред? Куда они уволились? В дворники? Нет. Ушли в другое место. Есть движение специалистов значит есть рынок, есть рынок. Будет и замена.
что вы за полгода запросто найдёте делфи-сеньора
За пол года вы даже супер популярную Java сеньора не найдете.
делфи-сеньора который приложения на андройд пишет
Я не знаю вашего опыта в разработке, но конкретно в области Delphi вы знаете только его название и то что его принято поливать помоями. Для разработки андроид приложения хватит даже мидлов, а для краткосрочной поддержи башковитого джуна.
оно не будет выглядеть как десктопное на мобилке
Что и требовалось доказать, вы ничего не знаете ни про делфи, ни про разработку под мобильные платформы на нем. Имеет смысл принимать вас во внимание? Да никакого. Собака лает, а караван идет.
Делфи это такое… уволиться и не сменив работу могут.
Я встречал разок удивительную вещь — учетную систему колхоза (реального селхоз, а не обзывательство), написанную на Access, с поддержкой актуального законодательства. И всего года 4 назад. На штук 5-8 рабочих мест (то есть разных по структуре баз) которые активно обменивались между собой информацией. Реально пользователей еще побольше было.
Разработал и поддерживал эту систему один человек. Который взял и ушел на пенсию. В итоге позвали нас, внедрять 1С: Ерп в варианте Агрохолдинг командой из десятка человек.
Что и требовалось доказать, вы ничего не знаете ни про делфи, ни про разработку под мобильные платформы на нем.
вы не знаете ни про мой опыт, ничего
а про вас я знаю что вы в 22 году разрабатываете на делфи и считаете его одним из топовых языков.
Я последние лет...20 работая в ИТ был всегда крайне приближен к топменеджменту компаний и почти всегда хоятыб коственно учавтсвовал в принятии решений по выборе инструментов и просчётами рисков
вы можете сколько угодно рассказывать что кругом полно специалистов на перле, делфи, коболе, access и руби, но я даже под дулом пистолета никогда не буду за написание нового проекта на непопулярном языке.
Я разок учавствовал в проекте который срочно переписывали с рельс на питон тупо потому что за два года оттуда уволились все рубисты и тимлид в одно лицо перетянул все микросервисы на питон и только тогда они смогли найти людей… на вилку 150-300
я отлично понимаю что писать приложеньку на делфи для телефона, это просто дурдом, не с точки зрения инструмента, а с точки зрения того что из 50 мобильных разработчиков на рынке 40 будут на яве/котлине, 5 на react native, 4 на flutter и один виндовый программер на делфи который от вас только что уволился.
оно не будет выглядеть как десктопное на мобилке
я это написал к тому что среднестатистический делфист — это десктопщик, он может написать приложеньку, но структурно она будет не похожа на явовские/котлиновские софтины тупо потому что никто блин не пишет массово приложеньки на делфях и у людей зачастую очень мало опыта в этой сфере
вы будете бороть баги которые в других фреймворках даже не всплывают, вот у мен ябыл пример… дело было в начале 10х и касалось разных моделей телефонов… когда софт не работал так как по мануалу… а костыли были описаны только для явы… в глубинах SO… а для делфи вы костыли искать будете сами с ковырянием в ядре андройда и ползанием отладчиком по делфям
а про вас я знаю что вы в 22 году разрабатываете на делфи и считаете его одним из топовых языков.
Вы про меня не знаете ровным счетом НИ-ЧЕ-ГО.
Кто вам сказал что я пишу на делфи? Кто вам сказал что я считаю его ЛУЧШИМ языком? Ваша воспаленная фантазия? Ну так дед пей таблетки ато получишь по жопе. Вы не угадали. Ни по одному из пунктов. И за своими нелепыми догадками пытаетесь скрыть свое полное профанство в теме в которой решили спорить.
вы можете сколько угодно рассказывать что кругом полно специалистов на перле, делфи, коболе, access и руби, но я даже под дулом пистолета никогда не буду за написание нового проекта на непопулярном языке.
20 лет в IT и так не поняли в чем итог подобной позиции? В том что окукливаетесь среди 2-3 популярных языков и все. Из этого круга вы больше не выйдете, потому что сами уничтожили все остальное. А потом на хабре каждые две недели выходит плаксивая статья как стало плохо жить в айти, какие медленные, неповотливые и глючные программы, как мы дошли до такой жизни что стали делать текстовые редакторы используя веббраузер и JS. Так вот благодаря вам и вам подобным мы пришли к тому к чему мы пришли. Когда вместо подходящего инструмента выбирается популярный. Когда аргумент "Да я в мухосранске найду трех джунов и мидла за неделю что бы они ковыряли наше дендрофекальное поделие" перевешивает вообще любые аргументы здравого смысла. Верной дорогой идете товарищи.
я отлично понимаю что писать приложеньку на делфи для телефона, это просто дурдом, не с точки зрения инструмента, а с точки зрения того что из 50 мобильных разработчиков на рынке 40 будут на яве/котлине, 5 на react native, 4 на flutter и один виндовый программер на делфи который от вас только что уволился.
То что приложение на делфи будет работать быстрее, то что понадобится меньше народу на разработку и меньше времени..то что делфи предоставляет богатые возможности по готовому функционалу...но для вас это все пустой звук.У вас одна мысль набатом звучит в голове люди. Вы себя слышите вообще? Вы еще проект не начали, а уже знаете что надо будет искать новую команду. Менеджер с 20-летним стажем, что вы такое делаете с программистами что они от вас бегут? Подумайте об этом.
вы будете бороть баги которые в других фреймворках даже не всплывают
Вы в Deplhi - 0. Вам откуда знать какие там будут баги? Delphi сильно платный продукт и они шкурно заинтересованы что бы багов не было, в отличие от всякого бесплатного хлама за который отвественности никто не несет.
когда софт не работал так как по мануалу… а костыли были описаны только для явы
Delphi генерит код для llvm, поэтому в описаном вами случае проблема его бы не коснулась. Такие дела. А пугать делфистов отладчиком не стоит, это их основной рабочий инструмент.
Тоже иду к тому, чтобы окуклиться с такими языками. Оффтоп:@sshikov, как вам потенциальное совмещение Java и Haskell в одном проекте?
Менеджер с 20-летним стажем, что вы такое делаете с программистами что они от вас бегут?
У человека может быть 100500 причин, по которым он захочет поработать в другом месте после 3 лет у Вас. Вот такая сложившаяся практика на ИТ рынке - быть летуном и заботиться о своем послужном списке путем своевременного покидания рабочего места.
Ах, старый добрый срач между поклонниками С++ и Delphi. Словно в 2013-й год вернулся, славные были деньги, программисты мерились мастерством, каждый умелец применял возможности стилизации (кто ещё помнит, что в Visual Studio можно поменять стили всех системных компонентов?!), а веб крутился где-то рядом. Когда ещё люди понимали, что такое CSS, и ни о каких веб-фреймворках не было даже мысли. Спасибо, мы на минуту вернули мне юность!
именно
сейчас никаких проблем подправить и обновить
Чот я не увидел в посте ссылки на пулл-реквест с фиксом.
И вопрос, как быть эстетам, которые хотят получать еще и эстетическое удовольствие от программирования?
Эстеты могут устраиваться в компании на проекты такого масштаба и сложности что не могут быть написаны иначе как качественно.
Если хватает квалификации — устраивайтесь в компании, где качественный код сэкономит/заработает в месяц больше чем вы получаете за год.
Если не хватает — эстетствуйте в своём личном репозитории, нарабатывая навык быстрого написания эстетичного кода, и применяйте в своей работе.
Стоны о "при Брежневе код был красивее и мороженное вкуснее" может и не лишены оснований, но на реальность увы никак не влияют.
Эстеты могут устраиваться в компании на проекты такого масштаба и сложности что не могут быть написаны иначе как качественно.
и охренеть от того КАК это написано в реальности и от того что оно вообще работает ;))))
… у меня такое было разок…
Угу, а также словить лет через 5 от прихода в контору ее поглощение очередным "эффективным/дефективным" с выставлением всего авторского коллектива на мороз в рамках оптимизации штатного расписания.
Кто хочет ощутить это чувство, но не хочет никуда устраиваться, советую зайти почитать полчасика исходники Telegram под Android.
А можно пример таких проектов?
А то как-то офигеваешь часто, как ЭТО до сих пор не развалилось. Про оракл тут уже писали :)
И вопрос, как быть эстетам, которые хотят получать еще и эстетическое удовольствие от программирования?
Подправить свои эстетические ориентиры. Писать идеальный расширяемый код вечность, который увидит пользователей слишком поздно (если вообще увидит) - это такая себе эстетика. А вот плавный рефакторинг большого проекта, по всем правилам, с тестами, который не блочит новые релизы, когда новый и правильный код аккуратно встраивается в нужные места, не ломая ничего критичного, а наоборот - добавляя надежности, вот это как по мне настоящая эстетика.
В итоге неквалифицированные разработчики быстро создают и быстро развивают программные продукты.
Дело не в неквалифицированных разработчиках — найди хоть одного квалифицированного разработчика, который никогда не допускал ошибок? Часто бывает так, ошибку в программе нашли тестировщики, но нужно ли её исправлять решает, как правило, бизнес. Так как для бизнеса важно исправление других более критичных ошибок или супер важных для бизнеса фич, то естественно проблема остаётся и, возможно, она никогда не будет поправлена, или пропадёт сама, когда возникнет необходимость полностью переписать этот кусок логики по новым требованиям.
Вообще в подобных тредах всегда обсуждается наличие "супер-важных для бизнеса фич", и то в целом справедливо, но. Конкретно здесь примером служит Android Studio. Можно привести аналогичные примеры бесящего поведения и банальных ошибок в Xcode, Visual Studio и других подобных инструментах. У них нет никаких "супер-важных для бизнеса фич" и вообще конкуренции по сути нет. Хотите писать под мак, велком ту Xcode, и плевать, что у неё три звезды рейтинг на Аппсторе.
Есть же вещи, которые просто невозможно рационально объяснить. Типа "а давайте запретим в Windows 11 drag-n-drop на панель задач". Или "а давайте вы будете только вручную вбивать логин-пароль для вайфая, потому что если вы уберёте фокус с окна ввода, оно исчезнет".
Видимо, как-то система принятия решений иначе работает, а к нуждам бизнеса и пользователя всё это имеет косвенное отношение.
хм, интересная мысль. Осмелюсь предположить что система принятия решений начала работать по-другому потому что в сферу программирования пришли не программисты. Может быть раньше подавляющее большинство основателей айти компаний сами были программистами, ну как Цукерберг, например. И они принимали решения как программисты. А потом в сферу попали "стивы балмеры", которые сказали: "стоп, мне пофиг как вы это сделаете, но нам нужен апдейт через неделю."
По правде говоря, я даже не знаю, что думать. Ладно бы на смену "программистам" пришли "балмеры", тогда можно было бы себе сконструировать в голове, что вот тут компилятор ускорили ("программист" решил), а тут кнопочку перерисовали ("балмеры"). Разное представление о полезности чего-либо для продукта, но и то, и другое имеет право на жизнь. Но кому drag-n-drop на панель помешал? Или копипаст wifi credentials из почты? Таких же примеров полно, когда либо чистая вкусовщина, и вместо А получаем аналогичный Б, либо вообще вред. Вот ещё простой пример: Unity Hub -- это программа с интерфейсом из одного окна с несколькими вкладками, по сравнению с которой Калькулятор -- сложнейший продукт. Так вот, они сначала добавили в него тёмную тему, потом выпилили светлую и уже год обещают её вернуть. Совершенно неясно, какие business values все эти манипуляции имеют.
Всё куда прозаичней друг мой. Есть понятие "профессиональная этика", и среди программистов очень много неравнодушных людей. Но когда появляются равнодушные, для которых ничего кроме "мне сказали написать так, а что оно может работать по другому не говорили" не существует, то такое поведение мягко говоря нервирует. Вмешательство менеджеров с их Jira, tusk-ами и прочей хернёй меньшее зло, но то же не сладкий хлеб.
Не раньше трава была зеленее, а менеджеры меньше вмешивались в процесс разработки.
О, времена! О, нравы!
Меня, помню, поразило как после супербыстрого эмулятора Siemens телефонов для отладки мобильных ява-программ я запустил это лагучее поделие от гугла "эмулятор андроида". Эта штука работала в миллион раз медленней нормальных эмуляторов телефонов, имела десятки непонятных настроек, кучу файлов, была раздроблена в две проги - менеджер устройств и сам эмуль. Запустить просто exe-шник с удобной настройкой масштаба вывода, выбором нужной версии андроида и собственно вирт.клавой и экраном? нее, только через командную строку с разнообразными ключами, с предварительным медленным созданием толстых файлов образов устройств, (хоть потом и можно выбрать один из образов и закинуть его по кнопке из менеджера устройств в эмуль, предварительно поставив 25 небрежно раскиданных флажков на форме настройки образа, но все это тормозно, неуклюже, с лагами от любого чиха). Выбрать нужную версию андроида просто в списке установленных из коробки образов ОС? нее, выставляй наугад миллион галок в дереве и качай 1000 файлов из инета с помощью третьей отдельной проги - скачивальщика. Скормить apk просто указав на него или положив в локальную папку, эмулирующую ФС телефона? нее, только через другие команды adb, в котором еще надо предварительно запросить список запущенных эмулей, увидеть что эмуль не виден, остановить и перезапустить adb, увидеть что эмуль наконец-то виден....
Вот тут я и понял что на смену разработчикам супербыстрых эмулей пришли ребята, лепящие тормозной неоптимизированный проект из 1000 мелких файлов, разбросанных в 100 папок, и управляемых через командную строку вместо нормального графического удобного Windows-интерфейса с набором готовых пакетов настроек из коробки.
Хорошо что сегодня хоть Bluestacks появился.
тормозной неоптимизированный проект из 1000 мелких файлов, разбросанных в 100 папок[...]расширяемость[...]чистый код[...]ты просто не понимаешь[...]ок бумер[...]
Я когда-то тоже начинал с разработки под J2ME. И справедливости ради, не стоит сравнивать эмуляторы сименса, где эмулировалась только дна программка, с эмулятором всей ОС, которая сделана на базе Qemu.
В эмуляторах Сименсов эмулировалась полностью ОС телефона со всеми настройками, с браузером, можно было таким образом пощупать телефон перед покупкой, посмотреть что в нем поменялось по сравнению с предыдущими сименс-телефонами. Это как если бы гугл выложил на сайте десяток-другой setup.exe под каждую из версий android. Просто устанавливаешь ее и запускаешь, через 20 сек она готова к установке и запуску прог или отладке приложений из среды разработки.
Есть большое подозрение что это были не эмуляторы а симуляторы. Тогда сравниваем мягкое с тёплым.
Это как если бы гугл выложил на сайте десяток-другой setup.exe под каждую из версий android.
То есть для теста под разными версиями андроида придётся качать кучу setup.exe и нажимать кучу кнопок "Далее", вместо одного докачивальщика компонентов? Нет, спасибо. От этого давно везде избавились и не нужно это возвращать.
Там Qemu под капотом, как раз для покрытия всего зоопарка архитектур и потребностей разработчика программы. Пока не появилась нативная поддержка х86/64 в ведре, оно все работало как раз на скорости транспилятора. Конечно, это сильно медленней тестирования на железе, но повода для истерики не было ни тогда, ни сейчас.
Вот тут я и понял что на смену разработчикам супербыстрых эмулей пришли ребята, лепящие тормозной неоптимизированный проект из 1000 мелких файлов, разбросанных в 100 папок, и управляемых через командную строку вместо нормального графического удобного Windows-интерфейса с набором готовых пакетов настроек из коробки.
Добро пожаловать в мир Unix. По какой-то причине именно такой подход к пользовательскому окружению тут прописался. Вроде бы он из 70-х годов прошлого века, когда компьютеры занимали отдельную комнату, а программированием занимались бородатые инженеры-программисты с дипломами MIT и зашкаливающим уровнем высокомерия.
По какой-то причине именно такой подход к пользовательскому окружению тут прописался.
Любят разработчики терминал и текстовые файлы, что поделать. Ибо универсально, поддаётся автоматизации и вообще hackable, как говорится.
Далеко не все :) но куда деваться, стиснув зубы пользуются тем, что есть
Особенное удовольствие - парсить текстовый вывод консольной утилиты, чтобы понять, что она натворила. Слабоструктурированный поток текста, прерывающийся варнингами в случайных местах - это просто сказка для машинной обработки.
Консольный вывод прекрасен тем, что никто не стесняется писать вменяемый вывод, который легко парсится элементарным grep'ом. С gui-only же сильно повезёт, если приложение соизволит куда-то сохранить нормальный отчёт об ошибке.
Элементарный греп быстро ломается при минимальных изменениях в выводе. А более-менее надёжный греп - весьма не элементарен.
Ну вот, я недавно показывал пример:
При этом, когда рассказываешь программистам, что можно же сделать красиво, чтобы и человек мог читать, и программа, и обрабатывалось это быстро, и код упростился. Тебя в лучшем случае не слышат. А в худшем - хейтят за непривычный синтаксис. И это не менеджеры, а обычные программисты. Просто выученная беспомощность.
Promtail -> Loki -> Grafana
Сейчас оно меня немного выручает
Что хотели грепнуть из картинки выше?
Потому что если запихнуть этот вывод в более машиночитаемый формат, то ничего не изменится, он не станет более удобным. Вы пытаетесь решить совершенно не ту проблему.
В этом логе очень мало контекста, нет разделения на события, недостаточно фиксированный формат вывода. Совершенно естественно, что это невозможно нормально отфильтровать.
Сталкиваюсь с противоположной стороной медали
Есть система, теперь все логи в Json, погрепать в консоли логи уже проблема - сильно длинные строки, изучать только если еще jq для парсинга json и цепочек запросов
Старый формат логов - просто глазами Error выделяется в перечне, а если еще и стактрейс - всё супер, глаз сразу падает просто при быстром листании с PgUp
ELK стэк решает проблему, но он оверкилл для простых задач.
По какой-то причине именно такой подход к пользовательскому окружению тут прописалсяЛёгкость костылестроения.
Если у вас есть три GUI-программы, то вам будет сложновато собрать из них продукт, использующий по одной из функций каждой этой программы.
В консоли же вы просто сматываете их синей изолентой, и всё это работает — криво, косо, убого, как и положено набору костылей. А потом приходит новый программист с MIT-дипломом и из трёх таких костыльных поделок в свою очередь собирает мета-костыль. В конечном итоге получается именно то, что демонстрирует любой юниксовый софт — кошмарная в плане юзабилити, не переносимая без полка майнтейнеров штука с полным отсутствием вертикальной совместимости, из которой во все стороны торчат какие-то углы, а шлифовкой можно заниматься бесконечно, и всё равно оно будет выглядеть отвратительно.
C++ тулчейн — блестящий образчик подобного костыльного инструментария, который в конце концов и похоронил язык, потому что сборка чужого кода при помощи этого поделия — настоящий кошмар, с которым при наличии альтернатив мало кто захочет связываться.
для окупаемости и даже выживания программного продукта являются такие вещи как внедрение новых фич, обновление дизайна, реализация поддержки новых технологий
А это возможно делать с некачественным кодом, продолжительное время и не сойти с ума?
Есть люди, которых вполне нормально с этим работают. Удивительнее другое - есть люди которые за это платят) Зачем нужно было развиваться 10 лет? Чтобы работать по принципу "херак-херак и в продакшн", я вот о чем.
Удивительнее другое - есть люди которые за это платят)
Ничего удивительного тут нет. Экономическая ситуация такова, что конечным выгодоприобретателям (тем, кто прямо или косвенно нанимает программистов) нужно именно такое положение вещей.
За хороший код программисту сегодня не заплатит никто. Монополистов всё устраивает. А тех, кто заплатил бы - рынок уничтожит ещё в начале пути.
И вопрос, как быть эстетам, которые хотят получать еще и эстетическое удовольствие от программирования?
Так вы хотите эстетическое удовольствие получать или деньги зарабатывать?
ИМХО, такое противопоставление подтверждает правоту автора. :-)
В каком конкретно утверждении?
Если вопрос ставится в форме «или эстетическое удовольствие или деньги», то ровно в такой же форме он встаёт перед любым разработчиком. И он, разработчик, в подавляющем большинстве случаев выбирает деньги. Что логично.
А если разработчики выбирают деньги, а не удовольствие от написания качественного кода, то они пишут не очень качественный код. Следовательно, автор прав: разработчики пишут некачественный код, который идёт потребителю.
А если разработчики выбирают деньги, а не удовольствие от написания качественного кода,
А почему вы приравниваете "написание качественного кода" к "эстетическому удовольствию от программирования"?
Мне кажется, что эстетическое удовольствие при программировании люди испытывают от написания качественного кода. Который настолько хорош, что в нём просто нечему ломаться. Как идеальная скульптура, от которой больше нельзя отсечь ничего лишнего.
Конечно, это моё субъективное мнение, то бишь ИМХО.
Вам кажется.
Люди при программировании испытвают "эстетическое удовольствие" от чего-то, что им нравится. Оно совершенно не обязательно "качественное" или "нечему ломаться" или еще что-то. Оно просто удовлетворяет эстетическому чувству автора — которое, внезапно, может еще и не совпадать с эстетическим чувством другого программиста или пользователя (привет пользовательским интерфейсам).
А еще, внезапно, можно писать качественный код и не испытывать эстетического удовольствия.
Ну, значит, ваше чувство прекрасного не совпадает с моим. Это тоже вариант нормы. :-)
Именно поэтому нельзя приравнивать "получение эстетического удовольствия от программирования" к "написанию качественного кода".
… так в каком же конкретно утверждении прав автор статьи?
По-моему, я это уже писал несколькими комментариями ранее. Процитировать?
Да, пожалуйста.
Если вопрос ставится в форме «или эстетическое удовольствие или деньги», то ровно в такой же форме он встаёт перед любым разработчиком. И он, разработчик, в подавляющем большинстве случаев выбирает деньги. Что логично.
А если разработчики выбирают деньги, а не удовольствие от написания качественного кода, то они пишут не очень качественный код. Следовательно, автор прав: разработчики пишут некачественный код, который идёт потребителю.
Следовательно, автор прав: разработчики пишут некачественный код, который идёт потребителю.
Во-первых, не "следовательно", потому что нет следования из "эстетическое удовольствие" в "качественный код". Уже обсудили.
Во-вторых, в неквалифицированной форме ("[некоторые] разработчики пишут некачественный код, который идёт потребителю") это утверждение настолько тривиально, что не нуждается в обсуждении. Нет, серьезно? Кому-то хочется это оспорить или доказать?
А в максимальной форме ("все разработчики пишут некачественный код, который идёт потребителю") это утверждение заведомо неверно (точнее, формально недоказуемо, но это тоже скучно обсуждать).
Во-первых, почему нет следования из «эстетическое удовольствие» в «качественный код»? Для вас, допустим, нет. А для меня, допустим, есть. Как я и написал в самом-самом начале. :-)
Во-вторых, почему вы считаете, что я хочу оспорить или доказать утверждение, что «[некоторые] разработчики пишут некачественный код, который идёт потребителю»?
В-третьих, почему вы думаете, что я где-то написал «все разработчики пишут неправильный код...»?
Во-первых, почему нет следования из «эстетическое удовольствие» в «качественный код»? Для вас, допустим, нет. А для меня, допустим, есть. Как я и написал в самом-самом начале.
Это значит, что автор для вас прав, а для меня — нет. Вам это не кажется странным?
Во-вторых, почему вы считаете, что я хочу оспорить или доказать утверждение, что «[некоторые] разработчики пишут некачественный код, который идёт потребителю»?
Нет, я так не считаю. Я считаю, что это утверждение настолько тривиально, что не стоит статьи и обсуждения.
В-третьих, почему вы думаете, что я где-то написал «все разработчики пишут неправильный код...»?
Я как раз думаю, что вы этого не написали. А это значит, что мы имеем дело с неквалифицированной формой выше, а она не стоит обсуждения.
Нет, мне это не кажется странным. Это вполне в порядке вещей. Собственно, самое первое моё слово в этом треде было аббревиатурой «По моему скромному мнению». У вас, понятное дело, мнение может быть другим — почему бы и нет?
Если бы я написал: «Ха! Автор несомненно и тотально прав на 100% для всех людей на поверхности планеты Земля», то тут имело бы смысл спорить. А ломать копья, обсуждая субъективные мнения, как мне кажется, бессмысленно.
Если разработчики выбирают деньги, а не удовольствие от написания качественного кода, то они пишут не очень качественный код.
Поддерживаю!
Некрасивые самолёты плохо летают. Уродливый код плохо работает.
Если человек, работая в любой отрасли, не получает от своей деятельности удовлетворения, а тем более - если получает негативные эмоции - эту отрасль ждёт стагнация и регресс.
Уродливый код плохо работает.
А в обратную сторону это тоже верно? Ну то есть если код хорошо работает, то он по определению не уродливый? :)
И как быть в ситуации если я счтиаю уродливым код моего коллеги, а свой хорошим. А он считает уродливым мой код, а хорошим свой. А работает и тот и другой одинаково хорошо/плохо? :)
Всё_в_одну_строку, магические числа, неинформативные имена переменных, множественные переходы от одного стиля к другому (результат бездумной копипасты) - вот примеры плохого кода. Даже если случайно это будет работать после написания, то при очередной доработке что-нибудь сломается, а понять принцип работы уже будет практически невозможно.
Предпочтения в стиле - дело вкуса. Считать чужой код уродливым только потому, что Вы написали бы иначе - дурной тон. По моему мнению, качество кода вполне поддаётся объективной оценке.
Даже если случайно это будет работать после написания
То есть "уродливый" для кого-то там код оказывается всё-таки кожет нормально работать?
то при очередной доработке что-нибудь сломается
Точно сломается? А доработка точно будет?
Считать чужой код уродливым только потому, что Вы написали бы иначе — дурной тон
Но вы то так почему-то делаете :)
Всё_в_одну_строку, магические числа, неинформативные имена переменных, множественные переходы от одного стиля к другому (результат бездумной копипасты) — вот примеры плохого кода.
Вот смотрите. Все, что вы привели как пример — это кодстайл. Я беру работающий код, а потом просто порчу в нем кодстайл. Код становится на ваш взгляд уродливым — но работать-то он не перестал. В этот момент ваше "уродливый код плохо работает" перестает быть верным, не находите?
По моему мнению, качество кода вполне поддаётся объективной оценке.
Ммм, не поделитесь объективной методикой, которая бы при этом реально отражала качество кода?
Уродливый код плохо работает.
Как быть с тем фактом, что один и тот же код для одного программиста уродливый, а для другого — нормальный?
(с самолетами, кстати, та же фигня)
Вам кажется :)
Удовольствие скорее от того, что ты сделал что-то рабочее и полезное. Элегантность кода это дело десятое, все равно никто не оценит.
Если вы по каким-то причинам до настоящего момента всё еще считали, что где-то в кровавом энтерпрайзе вам будут платить 300кк/нс за красоту кода — то сейчас самое подходящее время для того, чтоб уже перестать верить в сказки.
Проблема в росте общей сложности, а не в падении качества кода. Это просто хаос, объективное явление. Когда кода слишком много, в нем неизбежно начинают встречаться "странные" места, и у некоторых странностей, которые вы сгоряча назовете плохим кодом, даже будут какие-то обоснования. Не льстите себе, думая что смотря на ВАШ код, кто-то не делает очередной фейспалм. Идеальный код - это код которого нет.
во всем виновато желание менеджмента получить финансирование за продукт.
первый пример:
для проверки идеи и неоходимой комплектации и схемы пишется небольшой набор функции для работы. потом ввиду нехватки людей-времени попытка написания нормальной библиотеки сталкивается с какими либо проблемами, что случается "иногда". на время берется черновой вариант с надеждой что по-позже сделаем нормально, а в реальности работает-не трогаем.
второй задание сверху спустили но сроки обозначаются настолько сжатые что зачастую если берется известное железо то не всегда будет дейтвительно новинка, а если берем новейшее то даже представителе производителя или затрудняются или не успевают ответить все кому требуется техподдержка, и разработчикам приходится зачастую решать проблемы методом "научного тыка".
Вспоминается шутка еще из 90хх: если бы строители строили дома также как пишут программы программисты, то первый же залетевший дятел разрушил цивилизацию.
Плюсую
Пока что — лишь в виде «умной техники» вроде кондиционеров, которые не работают без связи с сетью, смарт-телевизоров, что через три года превращаются в тыкву и могут окирпичиться штатным автоматическим обновлением прошивки, и автомобилей со всякими «умными» функциями, которые тоже работают через пень-колоду.
И это только начало, потому как у нас уже «умные дома» на подходе, а там и умная инфраструктура в городах. Недалёк тот день, когда начнутся массовые блэкауты или отключения отопления посреди зимы в минус 40, потому что где-то отвалилась сеть или обновилась прошивка.
умные дома в стиле быстрее сделать и впраить уже побеждают: вон дурные колонки с наборами девайсов менее чем за 3 т. руб, которые не работают без сбабильного интернета...подавай центральную колонку с алисой-марусей или кого там еще можно вызвать-заказать......идет вторжение дешевых сервисов в отрасли где была высокая стоимость из-за необходимости прорабатывать детали...а сейчас уже вовсю народ начинает жаловаться на бытовые выключатели, розетки которым больше подходит приставка "дурные" уже за то что некоторые модели после снижения или пропадания питания (что в наших домах весьма не редкость) не запоминая свое состояние сразу включаются после сбоя: ничего так получить все включено
Вспоминается шутка еще из 90хх: если бы строители строили дома также как пишут программы программисты, то первый же залетевший дятел разрушил цивилизацию.
Если б стоители строили дома, которые по планам должны были бы стоять "вечно", но по факту уже через год-два только доли процента этих домов были бы хоть кому-то нужны — то строители бы строили вот точно так же, как и программисты пишут.
так это, УЖЕ -СЛУЧИЛОСЬ, достаточно посмотреть обзоры как принимаются квартиры от застройщиков
p.s. 40, ага. я не ошибся, мой дом построенные в начале 80х был построен на отвали и во время стройки два года тупо стоял брошенным… а потом часть стен и коммуникаций строили из отбраковки чтобы тупо сдать зависшую стройку (до сих пор помню кривые потолки, неровные стены, промерзающие до черноты углы...)… со времен СССР оно такое тянется
Там же не осматривают несущие конструкции и фундаменты :)
Плюс в нормы заложены дикие коэффициенты по защите от дурака, если такое вводить в программирование, то блокнот, жрущий гигабайты памяти с пустым файлом, будет обычным явлением :)
Шутка не из 90-х, а из "Закона Мерфи" Артура Блоха, из 70-х!
когда для возведения дома, стены формируют не укладкой кирпичиков слой за слоем, а просто насыпая кирпичи друг на друга по контурам.
Только не кирпичи, а цемент. И на самом деле так и возводится. Делают опалубку, наливают цемент, немножко трясут для уплотнения - и вуаля, новый монолитный дом готов. Быстро, технологично, и от криворукости каменщиков почти ничего не зависит, опалубка тоже "библиотечная" ровная. И кстати штукатурки надо на порядок меньше, чем в кирпичном, построенном 50 лет назад.
И не надо, что раньше было лучше. Так же было - по разному. И качественный код, и так себе, и очень странно плохой. Просто плохие программы забылись как дурной сон. А верни вас в то время - удивитесь, как это можно было использовать и радоваться. Посмотришь на старинное легаси и только один вопрос возникает "как это вообще смогло работать столько лет?!". Не всегда, но часто.
— и вуаля, новый монолитный дом готов. Быстро, технологично, и от криворукости каменщиков почти ничего не зависит, опалубка тоже «библиотечная» ровная. И кстати штукатурки надо на порядок меньше, чем в кирпичном, построенном 50 лет назад.
И жить в нём нельзя. Сосед в ванной моется, а ты слышишь, что он колпачок от шампуня уронил.
Угу, берешь трехметровое правИло, проходишь по квартире и радуешься, какие ровные стены. А потом приходят ребята с инструментами и оказывается, что почти все стены завалены. И нужно по 4 сантиметра штукатурки, с одной стороны стены - сверху, а с другой стороны - снизу. И нужен этой штукатурки целый грузовичек.
Это проблема не только программирования. Любое производство тоже в той же ситуации, любая человеческая деятельность. Скорее получить как можно более примитивно понимаемый результат, выражаемый в тоннах, штуках, минутах. А ведь любое действие в этом мире бесконечно многогранно. В результате не знаем, что делать с отвалами руд, отработанным ядерным топливом, испорченной почвой, подсаженной на химические удобрения. Также и программист при хорошей работе осознаёт многие вещи, ему приходят в голову ценные мысли - но они работодателю не нужны. Не нужно и развитие самого программиста! Пусть скорее применяет то, что уже знает. Это всё относится к той же серии, про которую Карл Маркс говорил: капитализм будет побуждать людей брать всё больше кредитов, пока они не станут невыплачиваемыми. Все сложности выносятся в будущее, а сейчас подайте примитивный резлуьтат. Стоит ли удивляться тому, что у нас мало детей? Это ведь инвестиция в будущее, а кому оно нужно? Та же идея с вакцинацией. Правительство считает, что надо скорее остановить эпидемию, а что все люди превратятся в больных дохляков, которым постоянно надо будет капать вакцины, это уже другой вопрос. Я думаю, и печать антихриста тоже будет иметь этот аспект: получи печать и ешь пряники с варением, а проблемы будут потом. Я читал, что в экспериментах с животными выяснили: животное никогда не выбирает большое вознаграждение потом, всегда маленькое поскорее. Я думаю, выход возможен только в полном изменении человеческих представлений. Результат нашей деятельности на Земле - комплексный и многообразный, и главная награда - служение Господу.
Еще добавлю для ночных кошмаров: почитайте Эдвард Йордон Путь камикадзе (Сертельный марш). - там [спойлер] "Шеф все пропало"...
Прочитал все обсуждения, у меня такой вопрос. Мыжпрограммисты, что мешает писать красивый код за те же деньги? Ну вот требует от нас бизнес фичу, платит за неё. Давайте выкатывать красивый код за те же деньги. Давайте поспим на пару часов меньше. С девушкой проведём на одну ночь меньше. Семья пару выходных обойдется без нас. Нет?
Я просто не понимаю этого плача Ярославны. Хотите писать красивый код - пишите. За свой счёт. Если вы не готовы жертвовать для красивого кода который нужен ВАМ - что вы ждёте от бизнеса, который никогда и не лицемерил по поводу своего отношения, к прекрасному, в отличие от...
Мыжпрограммисты, что мешает писать красивый код за те же деньги?
То, что код часто пишется не одним человеком, а у разных людей разное понимание "красивого".
То есть все эти ценители прекрасного готовы писать красивый код, просто не могут между собой договориться что считать красивым кодом? Это единственная проблема и если её решить то автоматом получим в большинстве случаев красивый код? (Кто сказал code style?)
То есть все эти ценители прекрасного готовы писать красивый код, просто не могут между собой договориться что считать красивым кодом?
Ну да. Вам чтение статей на хабре, где обсуждаются практики кодирования, этого не демонстрирует?
Это единственная проблема и если её решить то автоматом получим в большинстве случаев красивый код?
Если вам удастся ее решить, индустрия разработки ПО вам поставит памятник.
Кто сказал code style?
… человек, который сказал code style применительно к этой проблеме, глубоко ошибался. Потому что code style "красивый код" покрывается на весьма малую часть (и это не говоря о том, что выработать принятый всеми code style — тоже нетривиальная задача).
Банальный пример. Мне нравится писать вот так:
void Foo()
{
}а моему коллеге — вот так:
void Foo() {
}Это именно о красивом коде. Нет никакого способа нас примирить — какой бы код-стайл не ввели в компании, один из нас будет считать, что пишет некрасивый код.
Ну смотрите. Вы мне рассказываете про ситуацию в которой большинство программистов пишет красивый код но их окружение с ними не согласно в плане красоты этого кода. По мне - это процесс ревью и тут у меня никаких решений нет. И программисты которые с этим столкнулись будут ныть что то вроде - мы пишем красивый код но он нах никому не нужен. Я похлопаю из по плечу, обниму, скажу - крепитесь мужики и пойду дальше.
Я же озвучиваю ситуацию которую вижу - какое то множество программистов которые жалуются на то что им не дают писать красивый код (хз, кто не даёт, очень разные и мутные аргументы) . И вот именно для этих программистов у меня вопрос - кто не даёт то? Что мешает? Лично моё мнение - ничего не мешает, просто поныть хочется.
А по поводу скобочек - если вы не в состоянии писать по кодстайл то как вы себя вообще профессионалом считаете? По поводу подобной мишуры имхо у нормального программиста вообще своего мнения быть не должно - как в команде пишут так и он пишет и точка. Нет там никакой красоты, есть только принцип наименьшего удивления.
А по поводу скобочек — если вы не в состоянии писать по кодстайл то как вы себя вообще профессионалом считаете?
Я в состоянии писать код по код-стайл. Я просто не буду считать этот код красивым.
Что, кстати, лишний раз говорит нам о разнице между красивым кодом и качественным кодом.
По поводу подобной мишуры имхо у нормального программиста вообще своего мнения быть не должно — как в команде пишут так и он пишет и точка. Нет там никакой красоты
Вот именно это и не дает людям писать красивый код: "у тебя не должно быть своего мнения по этому поводу, пиши как все в команде пишут".
Ну наконец то. Ок, сорян, мы с Вами вообще о разном. Я под красотой кода больше архитектуру подразумевал. То о чем Вы говорите мне вообще никогда жить не мешало так что тут моё мнение особо никому не поможет.
А с архитектурой все то же самое: мне "красиво" использовать DI, а моему коллеге — статические классы. Нет никакого формального способа нас разрулить.
Нет, с архитектурой я с Вами так легко не соглашусь. Кто отвечает за сопровождение? Кто будет потом допиливать? Что они думают по этому поводу? Зачастую банальное большинство - это вполне себе формальный способ решить. Потому что код должен быть сопровождаемым, легко читаемым, легко удаляемым. Если этого нет - нет никакой красоты в таком коде. А все три параметра зависят не только от кода но и от команды.
Ну и на десерт - далеко не каждый код должен быть или хотя бы стремиться быть красивым.
Кто отвечает за сопровождение? Кто будет потом допиливать?
Оба.
Что они думают по этому поводу?
Один думает, что лучше DI, второй думает, что лучше статики.
Зачастую банальное большинство — это вполне себе формальный способ решить.
В этом случае те, кто останется в меньшинстве, будут писать вынуждены писать некрасивый код.
Потому что код должен быть сопровождаемым, легко читаемым, легко удаляемым. Если этого нет — нет никакой красоты в таком коде.
Это ваше мнение о красоте кода.
Это ваше мнение о красоте кода
У вас другое мнение о красоте? Формализовать сможете?
В этом случае те, кто останется в меньшинстве, будут писать вынуждены писать некрасивый код.
Естественно. Если параметр зависит от команды а команда поменялась - меняется и параметр. Или мы про абсолютную и непогрешимую красоту без наблюдателя?
Оба.
Так не бывает. Или кто то один или никто. И гоните своего тимлида, он явно не отрабатывает свой хлеб.
Проблема в том, что даже в крупных и крутых компаниях есть огромное количество работы, которую приходится отдавать на откуп не очень компетентным людям. То есть это не вопрос договорённости или "жертвы", а банальной квалификации.
В самом деле, не пойдёте же вы работать в Майкрософт, чтобы писать Калькулятор Windows или улучшать Notepad. Соответственно, пишут их те, кому ядро операционки не доверить. Вот и получается неравномерное качество.
Мыжпрограммисты, что мешает писать красивый код за те же деньги?Непонимание того, что код сам по себе не имеет смысла, и пишется он не просто так, а для пользователей. Интересы разработчиков и пользователей к сожалению не совпадают, и разработчики всегда пытаются сделать так, как удобнее им, разработчикам, в ущерб интересам пользователей. Когда сюда подключаются ещё и интересы бизнеса, всё становится совсем печально — пользователь на 100500-м месте, о нём вообще не думают, напрочь забывая, что софт — это не вещь в себе, и он хорош ровно настолько, насколько закрывает потребности конечного пользователя. И этим самым пользователем в итоге оплачивается.
А «нытьё» начинается именно в тот момент, когда программист сам вынужден пользоваться тем, что тут наговнокожено им или его коллегами.
Ух, помню полгода назад намаялся с ведроид студией. При запуске двух инстансов (например, если хочется открыть параллельно второй проект), интерфейс случайным образом зависал намертво. Судя по логам, там какой-то дедлок происходил. Естественно, можно прибить студию через диспетчер задач, но при запуске она пытается восстановить все закрытые окна: получается два инстанса и снова зависание намертво. Процесс повторялся, пока не удавалость быстро закрыть одно из окон до дедлока.
А вот скажите, если Вы наговнокодите, кто-то серьезно пострадает? Ну кроме Вашего "чувства прекрасного".
Самолет упадет? АЭС взорвется? Ведь нет.
Т.е. ответственности за качество кода у Вас по сути никакой. Никто с Вас не спросит. Вы вообще пришли туда чтобы деньги зарабатывать. А это значит надо скорее спихнуть задачу и схватить другую. А через полгода вообще свалить с проекта в другое место и что там дальше будет вообще не Ваше дело придет следующий "Вася" и будет крыть матом Ваш код потому что он не совпадает с его пониманием идеала. А после него еще один. А черед трех "Вась" все это вообще объявят "легаси" и будут переписывать на новый, пока еще модный, стек.
Ну и чего Вы хотите в такой постановке задачи?
А вы точно не перепутали красивый код и рабочий? Потому что проблему которую вы тут так смачно описывали стопудово можно было бы решить бахнув пяток if'ов тут и там. Работало бы прям хорошо. Правда почему-то другие глядя на такое называют это legacy, да ещё и говорят так, как будто это что-то плохое...
Интересно что за люди пишут такие статьи вообще, у меня есть два варианта и оба крайние - это когда люди считают что если всё по PSR, отступы, стиль кодирования, DI, интерфейсы и наследование то такой код в принципе не содержит багов. И другой тип когда считают что если задача выполнена то продукт в принципе готов. Если код работает и проходит все тесты - это уже полный продакшн реди и в комментариях не нуждается.
Оба типа сильно ошибаются...
> А вы точно не перепутали красивый код и рабочий?
в этой дискуссии вообще много путаницы, начать с того, как Вы пишите красоту кода люди понимают по-разному, одному это типа скобочки, другому архитектура, естественно и архитектура по-разному понимается, если не договориться о терминологии дело безнадежное, типа пар выпустили и разошлись, но по опыту нормально договориться можно только для однородных проектов, или например в рамках одного достаточно большого, но даже в этом случае потребуется усилие, а универсальная красота только на картинах и в учебниках встречается, да и то старых мастеров :)
Надо не о терминах договариваться и спорить чьё определение правее, а учиться понимать что имеет ввиду автор. Из статьи вполне понятно, что имел ввиду автор под красотой совсем не форматирование кода, если читать её не по диагонали, выхватывая знакомые слова.
Если программист будет излагать свои мысли (и писать код) так, что надо учиться понимать что он имеет ввиду, я сильно скептически отношусь к тому что ему стоит писать критические статьи про других.
> Надо не о терминах договариваться и спорить чьё определение правее, а учиться понимать что имеет ввиду автор.
поздновато учиться в моем случае, начинал в конце 60х, вообще самый красивый код который пришлось наблюдать это burroughs mcp :)
Ну то есть все-таки некое общее понимание красоты есть и старые мастера как-то до него добирались :) Наверное оно и имеется в виду. Архитектуру, конечно, все понимают по-разному, но кроме поверхностных концепций там тоже есть некое основание. Скажем, в геометрии Эвклида пять постулатов -- четыре красивых, а один нет. Слишком сложный. Столетия люди пытались его вывести из оставшихся четырех не потому, что сомневались в нем, а чисто из эстетических соображений. Потом уже засомневались и в самом постулате -- Гаусс, например, специально измерял углы больших треугольников, взяв для этого вершинами гор, мало ли что. Пока не поняли, что постулат просто верен в частном случае и что для остального достаточно четырех -- это дает неэвклидовы геометрии. Ощущение красоты и завершенности (или наоборот) -- очень важное ощущение на самом деле.
> есть все-таки некое общее понимание красоты есть и старые мастера как-то до него добирались
типа на интуитивном уровне, что для технологии не очень подходит
> Ощущение красоты и завершенности (или наоборот) -- очень важное ощущение на самом деле
кто же спорит, конечно так, только к коду ощущение применить затруднительно, потому как люди разные, с разным опытом, приоритетами и пр., на мой взгляд принципиальный вопрос это - считать качество кода частью спецификации проекта или нет, в первом случае необходимы договоренности, стандарты и процедуры обеспечивающие, в том числе достаточное взаимопонимание между участниками, желательно формализованное, приходилось участвовать, в том числе в разработке внутренних стандартов, если проект достаточно важен так делали и делают сейчас, но не обязательно публикуют, как нетрудно понять
На интуитивном и трудно формулируемом, это да. Насчет не подходит для технологии -- может быть проблема в технологии? Не все можно описать словами.
Есть книга "The Timeless Way of Building" Кристофера Александера (у нас переведен его "A Pattern Language", "Язык шаблонов"), и вот там он пишет о "quality without a name". "There is a central quality which is the root criterion of life and spirit in a man, a town, a building, or a wilderness. This quality is objective and precise, but cannot be named." (Выделение моё.) Такое же есть и в коде, разумеется. Не вкусовое предпочтение, а именно объективное качество, отличающее хорошее здание или хороший код от плохого. Код, в конце концов, просто машина. Хорошую машину от плохой мы же отличаем.
Сейчас побеждает тот, кто быстрее выведет свой продукт на рынок, займет нишу и начнет набирать пользователей и получать прибыль.
Баги при этом неизбежны, но их можно потом пофиксить.
А упустишь окно возможностей - потеряешь все.
Как? Скажите мне, как можно было допустить такой код в продакшн?
Абсолютно такой же вопрос стоит задать каждому "разработчику" на Хабре, и особенно тем для кого ничего кроме того, что написано в ТЗ, более не существует.
Напомните пожалуйста, в каких годах была та самая эпоха красивого кода?
Эпоха красивого кода прошла.
Честно, очень смешно читать такие заявления в контексте Андроид Студии. Автору бы попользоваться красиво накоженным эклипсом, эдак восьмилетней давности, где отваливалось вообще всё от малейшего чиха, и чтобы просто импортировать проект надо было приседать и бить в бубен.
Как? Скажите мне, как можно было допустить такой код в продакшн?
Нужно ли это трактовать так, что многоуважаемый оп ни разу за свои 12 лет практики не допускал багов в проде? Прям все продукты идеально работали?
Именно по этому я и возмутился багу в Android Studio. В начале карьеры баги в продкш делал. Но я, во-первых, седел. А во-вторых, я ростом программиста считал заботу о том чтобы писать предсказуемый, контролируемый и отказоустойчивый код. Чем дольше ты в профессии тем больше ты знаешь не очевидных ситуаций, которые приведут к багам и дырам в безопасности. И я думал, что над продуктами у которых миллионы пользователей работают программисты высочайшего класса, мыслящие абстракциями и могущие любую конструкцию написать битовыми операторами просто "для спорта". А что получается? Что тот факт, что я не выучил три лишние фроеймворка, а вместо этого знаю 100500 подводных камней при написании сайта - нафиг никому не нужный скил. Нет больше цели - вот устроюсь в большую компанию и начну применять всё, что я узнал за свою карьеру.
А что получается? Что тот факт, что я не выучил три лишние фреймворка, а вместо этого знаю 100500 подводных камней при написании сайта - нафиг никому не нужный скил. Нет больше цели - вот устроюсь в большую компанию и начну применять всё, что я узнал за свою карьеру.
Были бы ещё умнее, то не устраивались в такие компании совсем. Работать на галерах, которые отнимают работу у фрилансеров - далеко не самая лучшая перспектива.
В начале карьеры баги в продкш делал.
А сейчас нет? Вот это да, у нас тут сверхразработчик.
И я думал, что над продуктами у которых миллионы пользователей работают программисты высочайшего класса, мыслящие абстракциями
Продуктов, которыми пользуются миллионы — как грязи, на всех даже хороших программистов с трудом хватает.
Ну и напомню, что современные продукты, особенно IDE — очень сложны.
и могущие любую конструкцию написать битовыми операторами просто «для спорта»
Ага. Печатая ногами. Отличный критерий, надеюсь, вы собеседования не проводите.
А что получается?
А получается, что люди сделали хороший продукт, который на голову выше того, чем пользовались до этого, но кому-то жемчуг мелок.
Причем ладно бы серьезная проблема, краши там, или в безопасности дыра — но нет, минорный баг, с которым столкнется хорошо если один из тысячи юзеров, и который любой пользователь может починить сам за 5 минут. Караул, все полимеры просрали.
Баг-то минорный. Но детский. Его быть не должно по-определению. Если провести мысленный реверс-инжениринг, то получится примерно так:
1) при реализации функционала отключения плагинов выбрали хранить их список в конфиг файле (норм идея, чего уж).
2) но где-то в IDE кроме этого конфига хранится список ПОСЛЕДНИХ отключенных/включенных плагинов, который.
3) список последних включенных/отключенных плагинов ВООБЩЕ обрабатывается, только если файл существует if (file_exists(CONF_DIR . "disabled_plugins")) На первый взгляд всё логично, зачем выполнять код выборочной загрузки плагинов, если заранее известно что пользователь никаких плагинов не отключал. О - оптимизация.
4) однако, если был отключен критический плагин, то IDE крашится раньше чем успевает разобрать файл пользовательских настроек отключения плагинов "disabled_plugins" и следовательно не может презаписать второй конфиг с последними отключенными плагинами.
Минорный баг скажите вы. Но это по счастливому стечению обстоятельств файл с настройками может найти юзер и удалить его. А елси бы настройки хранились где-нибудь в SQL-lite или просто были частью другого конфига, то легкого решения бы не было.
Слова ничего не стоят. Просто покажите ваш код.
Ошибки в бесплатной Android Studio...
А не хотите ли получить при старте сервера сообщение "Error 10.", а в FAQ прочитать "Если вы при старте сервера видите бокс с сообщением Error 10, удалите пустую строку в конце конфиг-файла"?
Это при том, что конфиг-файл генерится инсталлятором...
И это при том, что софтина стоила (на тот момент, не знаю, сколько сейчас) около 30к евро, а недельные курсы по работе с ней - около 100к.
Вы скажете "имя, сестра, имя?" Извольте - IBM WebSphere Commerce Suite. Должен уточнить сразу - это было 20 лет назад, надеюсь, такие "фичи" давно исправлены. Но это было, факт.
Хорошо что FAQ был. А то видишь Error 34, который нигде не описан… И все.
В случае open source софта хоть можно в исходники полезть, посмотреть что там могло пойти не так. А в случае проприетарщины остаётся только ждать ответа от саппорта...
Ну вот как?? То есть ребята нашли баг, но решили что дешевле написать об этом FAQ чем вносить изменения в код?
Видимо, да.
Я не знаю, к примеру, как можно объяснить, почему инсталлятор при одном запуске пишет путь как "D:\\WCS", а в следующий раз "D://WCS".
Запустишь еща раз - опять "D:\\WCS".
После таких сюрпризов удивляться пустой строке, которая валит запуск сервера, я уже перестал.
Занятный был софт, да...
Ну кто-то поймал ошибку при использовании конфига, хорошо проанализировал и нашел способ обхода. Ошибка со способом обхода сразу получает пониженный приоритет, так как не блокирующая.
Все, встаёт в хвост бэклога. А в код генерации конфига к этому моменту еще никто вообще не смотрел.
Смотря на инсталяторы подобных детищ кровавого энтерпрайза, я бы предположил, что там было добавлено ещё 20 подобных "фич". Просто теперь с инсталятором поставляется торрент-клиент, который после создания конфига скачивает бинарник, который патчит сгенерированный конфиг и убирает лишнюю строку
Не понимаю, о какой эпохе идет речь, потому что качество кода за 20 лет только улучшилось, по субъективным ощущениям. Установились какие-никакие best practices, появилось куча линтеров и статических анализаторов, есть нормальные фреймворки для всего на свете, да и на современных языках гораздо легче писать красивый структурированный и лаконичный код.
Даже взять pull requests, штуку, которая еще лет 10 назад не была стандартом в разработке – она как-никак дисциплинирует, потому что неприятно отдавать говнокод на ревью.
Другое дело, что сам софт усложнился на порядки, стало больше moving parts, а стало быть точек отказа, и теперь кажется что кругом баги и ничего не работает.
Как бы это сказать. В общем, то о чем вы говорите, бэст практис, линтеры, анализаторы - это о том как пользоваться if-ами, ставить отступы и правильно использовать спред оператор. А не о том как написать рекурсивную функцию, передавать переменные по ссылкам и использовать static вместо self. Если еще грубее, да, инструментов для программирования для домохозяек появилось уйма. А не должны были. Потому что сложные проекты должны были писать квалифицированные программисты не нуждающиеся в подобных инструментах, которым эти инструменты, может быть, больше мешали бы, чем помогали.
Большинство разработчиков думают, что в этой истории они д'Артаньяны, и пишут исключительно красивый и качественный код. А вот программист Петя, который до меня тут работал — ну и говнецо после себя оставил. Проходит время, д'Артаньян увольняется, на его место приходит новый д'Артаньян. Оказывается, предыдущий д'Артаньян на деле был самозванец, и писал он не красивый и качественный код, а быдлокод. И так ad infinitum, круговорот говнокода и д'Артаньянов… Нужно как-то по-философски к этому относиться :)
... например, стараться писать поменьше и попроще. Тогда карма будет не такая запачканная. Да, это приходит с годами.
xxx: мне регулярно попадаются автомеханики, считающие своим долгом обложить херами всех других автомехаников, которые ремонтировали мою машину до них.
xxx: круг уже не раз замыкался.
(с) баш, простите, не удержался...
:-) прошло то время. К сожалению, я считаю себя тем Петей. А статью написал, потому что смысла становиться д'Артаньеном и смысла нет.
Во вторых накопившееся выгорание от этого всего и как следствие полное безразличие и отстраненность к происходящему, теперь вот пытаюсь в очередной раз собрать оставшиеся силы и найти работу мечты где всё будет «правильно».
Забавно видеть обобщения подобного уровня на примере продукта Jetbrains.
На моём PC возникает близящееся к нулю количество проблем со всем используемым ПО. Когда есть выбор, его нужно делать. Фактически весь софт, который изначально был сравнён с конкурентами, тщательно протестирован и настроен, работает идеально, за исключением разве что визуальных багов и проседания кадров при перетаскивании окон.
Так, между б-гомерзкой Windows, хайповым Linux и macOS для "профессионалов" была выбрана именно Windows: оказывается, именно она в 2020-ом году представляла для меня идеал системы, где всё работает из коробки, есть нужные возможности и всё такое. Нет, кто бы что ни говорил, на линуксе многих привычных вещей действительно было не реализовать (ну, по крайней мере без анализа и допиливания исходников проекта уровня PulseAudio). Нет, кто бы что ни говорил, на macOS невозможно добиться нормального user-friendly, ну просто потому что из коробки Think different, а патч не факт что существует и работает без косяков. Да, и в винде есть проблемы, среди которых сложная и проблемная организация файлов, случающиеся баги и прочие вещи, о которых все примерно знают, но первое сегодня не добавляет проблем, а второе обязательно пофиксят. Это адекватная плата за то, что ты получаешь взамен.
Аналогично, в нише редакторов кода и IDE были протестированы VS Code, Visual Studio, Qt Creator, Intellij IDEA (с оглядкой на то, что остальные редакторы от Jetbrains предлагают примерно то же). Вроде, хорошая выборка - лидирующие в своих областях, уважаемые сообществом... И, кажется, такое изобилие проблем есть только у Jetbrains - никто не позволяет себе иметь так много детских и не очень болячек, работать настолько медленно и нестабильно, хотя масштабы у конкурентов (в случае Visual Studio) не меньше. Кто бы что ни говорил, при нормальном владении средствами разработки, IDE от Jetbrains не предоставляют сильно большей производительности при написании кода, использовании инструментария, а в случаях когда всё ломается и вовсе, очевидно, что часовое решение проблемы - не слишком приятная плата за абстрактное "обилие функционала". Ну, типа, я настроил VS Code под себя, освоил буквально пару консольных команд в тех случаях, когда плагин не имеет соответствующей кнопочки, и работа в сравнении с любыми другими полновесными IDE ускорилась очень, очень ощутимо. Но это стало возможным благодаря тому, что я потратил время на все сравнения, допил под себя, и, конечно, благодаря высокому качеству оптимизации VS Code. Это отличная плата за то, что ты получаешь взамен.
Таким образом, эпоха качественного (Вы ведь это имели в виду?) кода никуда не ушла. Эпоха, когда под андроид стало сложно писать из-за качества Android Studio - возможно и наступила (хотя поговаривают, что эта проблема имеется с начала времён). Но когда есть выбор, с должным уровнем умений стоит выбрать ПО, которое будет полностью тебя устраивать, ничего не стоит. И, соответственно, найти "красивый код" всё ещё возможно.
Я вижу в этом лишь одну проблему, но проблему куда серьёзнее - монополизацию. Напомню, писать под Android, либо писать на Kotlin, можно полноценно лишь в продуктах Jetbrains. Грустно осознавать, что столь масштабной ОС присвоили основным ЯП тот, на котором нельзя писать нигде кроме AS или Ij IDEA. Но, будем честны - в случае столкновений с "быдлокодом" в промышленной разработке можно уйти от него, банально переквалифицировавшись. Не всегда приятный вариант, но, возможно, гораздо приятнее, чем ждать очистки кеша каждый день. А если проблема всё же не настолько преувеличена, плата переквалификации слишком высока, то, может, Вы зря говорите о каком-то конкретном косяке и на самом деле всё идёт своим чередом, просто не всегда так быстро, как хотелось бы? Вы же сами сказали, что
сегодня поднимать этот вопрос уже моветон
Холиварная тема, но столкнулся с таким же выбором насчёт ОС. Мне например более удобны инструменты разработки в Linux дистрибутивах (терминал, docker, kubernetes локальный, Apache Spark). Всё то же самое в Windows поднимается через эмулятор, что ест лишние ресурсы и заставляет ноутбук шуметь. С другой стороны, спустя долгое время вернувшись на Ubuntu, обнаружил, что ничего особо не поменялось с тех пор. Firefox всё так же рендерит в 60 fps вместо 144, аппаратного ускорения видео под nvidia нет, звук всё так же плох по сравнению с Windows и глючит, Optimus работает через костыли, энергопотребление выше.
Поэтому и стоит выбор - или работать с WSL, но иметь дело с виртуальной машиной, или работать в Ubuntu и есть кактус.
Один проект в моей компании пролюбили из-за лида, который всю команду настраивал делать все по "канону". Код не шел в прод, пока не был выполирован до блеска. И это была именно крайность, а не просто "хороший код".
В итоге, чтобы успевать сдать проект, команде приходилось несколько месяцев работать без выходных и больше 8 часов в день.
Когла уже все готовы были уволиться, менеджмент спохватился и встал на сторону работяг. Проект не сдали, ушли в минуса, но бо́льшая часть команды осталась в компании.
Слушайте, уважаемый, то, что вы нашли баг в IDE не означает, что код, который его вызывает, написан не красиво и не чисто.
Знавал я одного инженера - фаната чистого кода. Любил он на тот момент требовать от других идеальной чистоты в коде: идеального нэйминга, полного отсутствия повторов, декомпозиции кода, применения различных паттернов в виде фабрик, каррирования функций даже на ранних этапах реализации фичи. Но была одна проблема. Допустим, есть задача, найден хороший алгоритм решения с логарифмической сложностью. Придумано несколько путей для недопущения перегрузки памяти. Делаешь реализацию, он говорит: некрасиво! Он переделывает. Пока переделывает, убирает решение для обработки чанками, повышает сложность алгоритма. Код укладывается в меньшее число строк, он красивый, функции каррированы, но он не работает. Так что, всё относительно в этом мире. То, что для вас не красиво, для других может быть неплохим решением. В частности, удаление файла конфига - не так уж не красиво. Проблема может заключаться и в том, что файл сменил синтаксис при обновлении версии среды. В любом случае, работа через конфиг кажется мне более явным и простым алгоритмом, чем автодисковер директории с плагинами.
ту написал свои мысли по поводу этого бага:
https://habr.com/ru/post/651935/#comment_24084611
И вопрос, как быть эстетам, которые хотят получать еще и эстетическое удовольствие от программирования?
Переходить на Rust.
Сегодня конечная цель производства большинства программных продуктов - это кража данных пользователей сбор «телеметрии». Конкуренция осталась на уровне кто соберёт и продаст больше информации, а для этого не нужен качественный код, нужен код который хоть как-то работает у большего процента целевой аудитории.
Для того же делаются и «умные» дома / автомобили / телевизоры / выключатели etc.
То ли я пропустил что-то, то ли на хабре эпоха супер коротких "статей" описывающих какие-то единичные кейсы. Не первый раз открываю что-то, только начинаю читать, и вот уже и теги. Осталось только в начало добавлять "на волне постов".
Меня больше бесит модель подписки. Я бы хотел один раз заплатить и забыть. Слышал, что некоторые не могли отписаться от продуктов и им приходилось платить. Вывод один - вкладывайтесь в опенсоурс и донатьте индивидуальным разработчикам опенсоурса.
Ps: до сих пор юзаю code:blocks 10.05 - следующие версии хотя бы раз в 2-3 дня вылетают.
Все по делу, откройте любой сайт в консоли и посмотрите на 80 процентах продуктов есть ошибки в консоли, о чем тут говорить.
По всей видимости вы не застали верстку 2000-2010гг, когда валидацию HTML-кода проходил только сайт www.w3.org (и то не каждая страничка). А сейчас основную массу ошибок на сайтах оставляют блокировщики реклам и прочие расширения браузера, связанные с "улучшением" отображения web-контента.
По моему опыту, большинство ошибок это внешние модули по типу аналитики, рекламы, лайв-чатов и т.д. Настоящие ошибки на сайтах/сервисах это когда оно тихо не работает (например, нажал кнопку - запрос ушел, получил ответ, но дальше глухо), но зато консоль чистая кек.
скажи́те вы поправьте на ска́жете вы.
Повелительное наклонение тут не к месту.
Более подходящая к заголовку КДПВ:
Зажрались люди. Готовы тратить деньги на всякое "негодное". Значит деньги легко достаются. Сколько швали всякой на Ютюбе/тиктоке - снимают (и миллионы людей смотрят!! Тратят своё время! Значит много этого свободного времени.) А рекламодатели финансируют.
Сами покупаем некачественные продукты/товары/контент/софт. Тем самым поддерживаем такое "какашко". Стадное поведение. Один ломанулся, и сотня следом. А потом уже и выбора нет. Не производят уже то, что никто не покупал.
Качество продукта это вообще не про Android Studio, у меня такое впечатление, что ее выпускают вообще не тестируя! Так у нас по графику релиз, собираемся из дева и выкладываем!
Реально, почти все версии студии за последние годы выходят с фатальными недостатками, с такими, что портят жизнь просто безумно.
Ну как пример:
Бамблби: не находит переменную окружения с указанием папки с SDK как результат невозможность работы без плясок с бубном.
Бамблби пач 1: переменную окружения уже находит, но рушится при переносе типа из одного модуля в другой, причем откуда он берет старый декс, остается загадкой. Из консоли сборка идет из студии нет.
Что 32Гб и 12 Ядер? Да студия на проекте среднего размера и в этих границах тормозит и ползает, попутно убивая систему.
Реально Гугл в данном случае это не про качество, скорее про диверсити, но не про качество однозначно.
Я уже десятки проектов наговнокодил, и ничего. Никто не умер. Может даже никто и не заметил, т.к. больше половины из этих проектов вообще была никому не нужна, просто бюджет осваивался. (И это ниразу не госконторы - всё западные ентерпрайз гиганты)
Код и програмирование стало масспродуктом, быстрее, больше, главное чтобы на демо не сломалось, и инвесторы были довольны. Вот такие требования я вижу сейчас.
Качество добивается после выкатки.
Мне кажется, тут вопрос не в том, что это быдлокод, а в том, что некоторые разработчки наделают такие костылей, который потом буде держаться на добром слове и скотче. Для меня быдлокод - это нечто некрасивое, нечитабильное, которое затруднитетльно ревьювить и которое еще оспаривается разработчиком, но тут по идеи должны спасать правила написания кода в каждой компании. Соответственно, для меня проблема, указанная автором - недостаточная компететность и халатность при разработке продукта (начиная от той же IDE, и заканчивая Windows).
Возможно проблема в целях. Попробуйте уйти из компании и писать "качественный код" для удовольствия - так не долго можно протянуть. Как только попытаетесь запускать свой продукт приоритеты быстро изменятся.
Мне интересно узнать - а когда же она была, эта эпоха красивого кода?
Я постоянно занимаюсь копанием в коде игр для 8-16-32 битных платформ, исторический период с конца 70-х по конец 90-х. Есть такое расхожее мнение, что в эти времена по настоящему занимались оптимизацией и вылизыванием кода, а с тех пор все полимеры были протеряны. Но фактически в каждой игре найдётся даже не один просто критический баг, а скорее несколько багов, которые компенсируют один другой, и оно как-то худо-бедно работает, хотя и не должно бы. В некоторых играх, не так уж редко, доходит даже до того, что чисто внутриигровыми манипуляциями можно так фигурно испортить содержимое памяти, что игра, например, сразу засчитает прохождение (этим пользуются TASеры). Оптимизация кода там конечно же была, иначе бы просто не работало с имеющимися ресурсами, но местами она никакая (возможно улучшить в разы), а сам код порой просто ужасный, запутанный и неэффективный, особенно это касается японских игр.
С тех времён сложность кода игр выросла на несколько порядков, багов же субъективно (судя по внешним проявлениям, сам код из-за сложности уже не оценить) стало не на те же порядки больше, хотя некритичных легко находимых багов действительно побольше. Оптимизация плюс-минус наверное такая же - в большей части проектов она есть ровно настолько, чтобы оно просто прилично работало. Мне кажется, что мало что поменялось, и если поменялось, то всё же в сторону улучшения кода (ожидаемо, ЯВУ против ассемблера).
Исходя из этого, возникает вопрос - где же искать красивый код? До конца 70-х или в начале 2000-х? Вроде тему bloatware стали активно обсуждать с начала 2000-х, то есть и тогда тоже красивым кодом не сильно пахло.
Красивый код, IMHO, надо искать в демках 128байт, 4096 байт, 64кб.
Вот там красивый код... по своему.
Совершенно несладкий, но красивый!
Возможно в каких-то демках и есть красивый. В <=256 байт наверняка есть по своему красивый код. Но как автор демок, я знаю, что обычно это кое-как-тяп-ляп-успеть-бы-до-дедлайна сварганенное нечто, которое должно сработать один раз в жёстко заданном сценарии (без пользовательского ввода), и для слабых платформ на 90% состоящее из фигурно развёрнутых циклов. Оптимальный код в демках - да, качественный - очень вряд ли.
"Да, были люди в наше время, Не то, что нынешнее племя: Богатыри — не вы!"
Все же с среднем по больнице стало лучше: итоговый результат реже "стреляет себе в ногу", легче масштабируется и переносится, легче читается. В очень среднем.
В советское время издавался журнал "Микропроцессорные средства и системы". Мой отец был на него подписан, так что мне досталась подшивка. Помню в 90ые зачитывал до дыр...
Но сейчас не об этом. А о том, что что-то подобное я тоже там читал - и жалобы на низкое качество кода и отвратительный юазбилити и, кстати, жалобы на то, что словосочетания "аппаратное обеспечение" и "программное обеспечение" подменяются новомодными "хардвер" и "софтвер"... В советских журналах 80ых годов уже публиковались подобные крики душа. Так что, подозреваю, это не последний подобный пост. И не первый))
На секундочку важный аспект - у AndroidStudio нет конкурентов, кроме Intellij Idea, на базе которой делается студия. Это я к тому, что пример не репрезентативен - им незачем фиксить баги, потому что конкуренции нет, в первую очередь :) ну и AndroidStudio бесплатная, с чем вообще трудно будет тягаться
Главный конкурент AndroidStudio, как ни странно, это XCode. Ибо, как отмечал ещё в 2000 году Стив Балмер, для успеха любой операционной системы самое главное - разработчики, пишущие под нее.
Ну а баги... У них очередной релиз андроида на носу, новые фичи пилить важнее, чем фиксить редкие баги, с которыми сталкиваются 0.01% от пользователей. Тем более, если для них легко находится workaround на всем известном сайте.
Да и положа руку на сердце, уровень качества гугловых продуктов в целом это что-то недосягаемое для большей части остальных разработчиков :)
Вдобавок HR менеджеры также стремятся завербовать новых, именно новых, потому что от старых они не получают дивидендов
А HR менеджеры не совсем за новых сотрудников получают деньги. Они занимаются развитием карьеры текущих, формируют графики отпусков и т.д. То есть совмещают в себе психолога и кадровика.
Я, в целях экономии ресурса ssd, сделал хардлинк папки с кэшами gradle на рам-диск. На рам-диске, естественно, fat32. Но в один прекрасный момент, после очередного обновления системы сборки, собственно сборка стала завершаться с непонятной ошибкой. В поисках решения, после долгого копания по форумам, кто-то где-то вскользь упомянул, что такая ошибка возникает, если студия стоит не на ntfs разделе (дело под виндой, да). Это оно, подумал я и, скрепя сердце, отказался от линка на рам-диск и fat32 для кэшей gradle. Прошел год или что-то около, и Android Studio, после очередного обновления, стала наглухо зависать при сборке с вероятностью >50%. Я думаю, это из-за того, что intermediates проекта я таки держал на рам-диске с fat32. Я даже багрепорт накатал, ответили, что проблема известная. Где-то месяц промучался и, о чудо, в очередном обновлении (bumblebee) всё починили, даже сборку с кэшем gradle на fat32. Ума не приложу, как можно умудриться сделать так хреново работу с файлами в кроссплатформенном (на минуточку) проекте, что всё висло на "неправильной" файловой системе.
Словом, качество кода ушло на последнее место, когда программирование стало на 120% коммерческим делом, на котором делаются главные состояния.
Качество кода всегда было исключительно коммерческим делом. Все разговоры о нем появились только потому, что кто-то заметил, что более качественный код снижает затраты на развитие, поддержку и исправление ошибок.
Сейчас просто время бурного роста рынка, и во многих сферах выгода от уменьшения time to market существенно превосходит экономию от снижения издержек.
Се ля ви. Кто первый, того и тапки. Так почти во всех отраслях бывало, не только в разработке. На заре авиации, например, о безопасности никто не думал. Но рано или поздно бурный рост закончится, рынки поделят, и все начнут носиться с "качеством" и прочими способами снизить издержки хотя бы на 5%.
На мой взгляд - это просто эволюция:
красивая функция
красивый класс
красивая программа
красивая система
Красивый код остался на предыдущем этапе. Сейчас важнее компоновка и оркестрация модуля, чем его внутренности. Видимо следующий шаг будет в сторону метасистем, когда какая то OS будет позволять вам создавать всё что вы хотите для работы из виджетов и плагинов (как сейчас IDE).
Такая система уже есть, WordPress! "Мечта"
WP первый шаг. Подобных систем много. "Создай себе сам" CRM, ERP и так далее. Но все они в узких нишах. Следующий шаг - это система объединяющая эти системы. Ну вот теперь представте, что из таких вот систем мечты строят одну большую мечту. Даже не знаю сколько кавычек надо было в предыдущем предложении. Чудовищна красота чудовищ Франкенштейна.
О! Автор понял что производство кода зависит от нужд работодателя, ещё чуть чуть и поймет что с 80х годов почти любое производство основано на низком качестве для удешевления, потому производства разные и переводили буржуи в Китай. А создание кода это подвид производства. Но так как ИТ сфера стала массовой с задержкой на 20 лет и как следствие формирование рынка произошло позже а потому подобное стало тоже с задержкой. Дальше будет только хуже.
Скорее прошла эпоха статей, несущих какой-то здравый смысл.
Какое отношение пример из статьи имеет к красоте кода? Может со стороны кода там как раз было всё изящно и оптимально продумано. По крайней мере со стороны писавших саму IDE, а уж кто там плагины писал и корректно ли они себя ведут - отдельный разговор. Ну и в любом случае дело было не в красоте кода, а в том, что на какой-то из сторон было что-то не учтено.
За правильность кода можно было говорить, если видишь сам код. А не так - на уровне телепатии.
Что касается самого вопроса - из самой по себе красоты кода тоже совершенно не следует его эффективность. Можно очень симпатично и компактно разложить всё по блокам, а потом получить кучу головной боли от общей непродуманности структуры. Или закрутить такие красивые красивые рекурсивные циклы, записанные очень лаконично, в которых самому потом не разобраться, что именно они делают и при каком сценарии от них может прилететь что-то некорректное.
Хорошая архитектура кода тоже может выглядеть не очень то симпатично с виду. А некоторые вещи скорее облегчают процесс написания и переиспользования фрагментов кода для самого программиста, в то время как самой программе часто всё равно - выполнить простыню копипасты или пройти по ней же, но "красиво" свёрнутой в вызовы подфункций. Опять же с ними вполне можно такой ад наворотить и жутчайшую связанность, ударившись в другую крайность.
Так что красота - она разная бывает. И дело далеко не только в ней. Куда важнее общая продуманность структуры.
Не очень понял, зачем в статье упомянут PHP, но как раз на счет него не согласен от слова совсем. Язык настолько развился в последние годы, что писать красивый код на нем стало сильно проще. Понятное дело, что неквалифицированные разработчики никуда не делись, но уж точно не стоит говорить о росте быдлокода (по крайней мере в пропорциях, надо полагать, соотношение или сохранилось, или даже сдвинулось в сторону элегантности). ИМХО.
Хорошая позиция у автора:
брать бесплатный продукт
найти баг
жаловаться на хабре
Нет же, что бы в багтрекер пойти, да завести исус, можно просто на форуме поплакаться, что код у всех скатился в говно. Но я и кода автора не нашёл, что бы убедиться в его небыдлоте.
И вопрос, как быть эстетам, которые хотят получать еще и эстетическое удовольствие от программирования?
Для чего тогда существуют свободные проекты, развиваемые энтузиастами в своё свободное время?
Имено так я и делаю:
На работе выполняю поставленные работодателем задачи. Тут естественно, и требования к выполнению задачи, и возможно ограничение по сроку выполнения задачи, а также ещё и паника в предверии очередного показа продукта высшему руководству.
В свободное от работы время, занимаюсь своими личными проектами с открытым исходным кодом, кооперируясь с различными другими разработчиками. Здесь, в отличии от коммерческих проектов работодателей, я сам себе царь, и сам решаю, как быстро, когда и как реализовать то или иное решение, обсуждая попутно с товарищами и с пользователями об эффективности / оптимальности выбранного решения. Здесь я просто иду к цели (именно, добиться от проекта должной работоспособности), и не гонюсь за сроками. Редко бывает, когда объявляется некий коммерческий заказчик, который предлагает солидное пожертвование дабы в повышенном приоритете реализовать желаемую функциональность. Но всё же, это не так больно, как разработка будучи сотрудником какой-то компании.
У меня также есть друг, который в одиночку построил большой проект по Discord-боту с платными сервисами, и неплохо на этом зарабатывает. Тоже, сам себе царь, и сам решает, как и в каком виде реализовать ту или иную функциональность, и т.п. И также полностью сам решает о том, как распределять время выполнения своей работы. Кроме, разве что, когда происходит авария, и ему экстренно приходится восстанавливать работу своего творения.
Ну вы можете себе представить, что работяга на заводе, скажем, volkswagen, написал бы нечто такое, дескать на заводе у себя я делаю поставленную начальником задачу, а вот в свободное время уже кооперируюсь с другими инженерами и делаю в своё удовольствие красивые и хорошо сделанные автомобили?
а вот в свободное время уже кооперируюсь с другими инженерами и делаю в своё удовольствие красивые и хорошо сделанные автомобили?
помнится когда в России еще было можно, у нас делали самодельные автомобили в т.ч. и инженеры с заводов
сейчас отрасль настолько зарегулирована (и не только в РФ) что кроме как шоукара сделать ничего нельзя не затрачивая 100500млн денег
то есть отрасль программирования так же зарегулировали?
Имелось ввиду, не очень удачное сравнение. По большому счёту, вне работы тот же инженер вполне может заниматься и моддингом существующих авто (если не строить новое авто с полного нуля). И да, создать собственное авто можно легко (не только проект, но и физический прототип), но вот на дороги общего пользования его легально можно пустить после проверок на соответствие всем местным законам (и безопасности, и сигнализации, и т.п.). И, как уже сказано выше, проверки стоят недёшево, и следовательно, заплатить за них можно если денег предостаточно.
Ну вы можете себе представить, что работяга на заводе, скажем, volkswagen, написал бы нечто такое
Я не очень могу себе представить, чтобы (каждый) работяга на заводе, скажем, volkswagen получал от своей работы эстетическое удовольствие.
Добрый день, правильный код или не правильный - это проблема не кода, а проблема развития цивилизации. Известно, что каждый человек не имеет возможности передать свой опыт новым поколениям полностью, часть данных не выдается за отсутсвием времени и смысла, часть теряется во время приема-передачи, и как следствие на выходе более некачественный продукт, который до поры до времени компенсируется Природой. Кому с этим жить? Тем будущим поколения и жить! Это тот выбор который каждый делает из нас сегодня.
Следует помнить, что длительность цивилизации и уровень жизни наших потомков в ней зависит от нашего выбора сейчас. B когда перед каждым встает выбор писать красивый код или деньги зарабатывать все выбирают деньги не особо раздумывая.
Делать хорошо может только тот человек которому обстоятельства позволяют жить так чтобы о деньгах не думать и обо всем остальном тоже (семье, здоровье и себе). Это невозможный идеал, и компромисс неизбежен даже для тех кто пишет код правильно.
Или есть люди которые готовы по 6 часов в день работать бесплатно?
Или есть люди которые готовы по 6 часов в день работать бесплатно?
полно таких людей, в мире огромное количество волонтерских движений
Так опенсорсные проекты такие волонтеры и пишут, из любви к исскуству. Думаете там код красивый?
Известно, что каждый человек не имеет возможности передать свой опыт новым поколениям полностью, часть данных не выдается за отсутсвием времени и смысла, часть теряется во время приема-передачи, и как следствие на выходе более некачественный продукт, который до поры до времени компенсируется Природой.
Вы где-то здесь забыли упомянуть, что за время жизни человек получает новый опыт, так что "на выходе" все равно может прирост получаться.
А разве для Android Studio стоит вопрос окупаемости или даже выживания?
Это абсолютно нормально, поскольку главным качеством за которое нам платят является не наше чувство прекрасного, а наше умение решать проблемы бизнеса быстро и с минимальным необходимым уровнем качества. Все.
Исходя из этого - качество кода поддерживается ровно на том минимальном уровне, который необходим для добавления новых фич с нужной скоростью.
Это всё реально исправить просто подавая хороший пример. Хром ведь так и взлетел. Даже реклама говорила "смотрите, у нас всё быстро загружается и не тормозит!", и на пользователей Internet Explorer и других браузеров стали смотреть как на динозавров. И после этого Internet Explorer и другие браузеры начали оптимизировать. То же самое с сайтами. Если предлагать пользователю аналогичные сервисы, но сайт будет открываться за 0,1 секунды, то пользователь предпочтет этот сайт, а там и конкуренты подтянутся.
Как что то плохое. Оптимизированный код за пределами железа и не нужен. Потому что перфекционизм слишком часто выливается в писькомерство с обсессивно-компульсивным расстройством сжирающее время и деньги.
Когда IDE крашится из-за пустого файлика настроек - это "фи, нам не нужен перфекционизм и писькомерство"?
Когда пользователь ждёт, пока загрузится и отобразится лендинг на современных технологиях, а сайт а-ля 2000-е летает - это "фи, нам не нужен перфекционизм и писькомерство"?
Я как пользователь тогда предпочту ПО от "писькомеров", дайте два, пжалста.
Из практики видел два счастливых исключения: рефакторинг и поддержка
В моей первой команде рефакторинг проводился по чайной ложке с каждой задачкой, в параллели. Во второй где счастливо проработал больше семи лет - рефакторингом занялись на полгода ценой полной остановки проекта. Слышал о командах, где рефакторинг проводят регулярно, выделяя, условно, один спринт в году. Не суть. Когда проводится рефакторинг - красота, правильность, надёжность в лице объективных метрик вроде связности и зацепления, заменяемости и ответственности - на одном из первых мест
Техподдержка частенько инициирует задачки, в которых правильность-надёжность-красота на первых местах. Понятно, большинство из нас меряет всё-таки в объективных метриках, но смысл такой. Когда мы делаем задачки поддержки - мы стараемся жить правильно :)
Техподдержка частенько инициирует задачки, в которых правильность-надёжность-красота на первых местах.
Любопытно. Я первый раз слышу, чтобы техподдержку волновала красота кода. Обычно они хотят, чтобы баг был починен, причем как можно быстрее.
естественный отбор :)
починить одно и то же место можно раз, другой, потом придётся сделать на совесть, просто чтобы прекратился вал инцидентов про одно и то же - либо потонуть в поддержке
опять же, сотрудник поддержки обычно остро чувствует и понимает, что бизнес стоит на доверии клиентов. Когда бизнес теряет доверие клиентов - клиенты просто уходят к другому, и бизнес можно закрывать. Поэтому не бывает ни поддержки себя любимого, ни поддержки босса, ни поддержки заказчика - есть только поддержка пользователей. Отсюда и особые права поддержки, и вес, а с ним - возможность потратить чуть больше времени, зато сделать раз и навсегда
естественный отбор
Вот как раз его я и не наблюдаю.
починить одно и то же место можно раз, другой, потом придётся сделать на совесть
Так делают и поддерживают разные люди же.
Отсюда и особые права поддержки
Это какие такие "особые права"?
с ним — возможность потратить чуть больше времени, зато сделать раз и навсегда
Не понимаю вас. У поддержки вот прямо сейчас клиент в стадии "у меня не работает жизненно важный продукт", и есть два варианта решения проблемы: починить сегодня, но костылем, или через месяц, но "красиво". Вы утверждаете, что поддержка выберет второй вариант только на основании слов разработчика, что так будет красивее?
Извините, не был точен: я лишь про то, что важно разрешать себе полчаса-час подумать-пораскапывать-посовещаться, как бы ни наседали
И тогда скорее всего получится надёжно, и по этому поводу больше не придут
Насчёт месяца и красиво - это очень хлопотно согласовать, но если все согласны, от владельца бюджета до эксплуатации, то почему бы и нет. Так у нас обычно начинались переговоры, из которых рождалась следующая версия системы
Извините, не был точен: я лишь про то, что важно разрешать себе полчаса-час подумать-пораскапывать-посовещаться, как бы ни наседали [...] И тогда скорее всего получится надёжно, и по этому поводу больше не придут
Так я вам результат "час подумать" и рассказываю: либо быстро закостылить сейчас, либо месяц переписывать "как красиво". Что выберет поддержка?..
Насчёт месяца и красиво — это очень хлопотно согласовать, но если все согласны, от владельца бюджета до эксплуатации, то почему бы и нет.
То есть дело все равно упирается во владельца бюджета (который изначально уже не давал на это денег, когда проектировали).
либо быстро закостылить сейчас, либо месяц переписывать "как красиво"
О, классно. Вот как вы цитируете :) Вот этого не понимаю я :)
Чтобы понимать, на что уходит месяц, мне не хватает специфики проекта. Месяц это очень большой срок
У нас (боевые случаи):
разраб поднимает своего тимлида, тот разводит руками, разраб обращается к аналитику - 20 минут. Аналитик открывает базу, чинит одно место в коде, второе показывает разрабу - 30 минут. Разраб чинит указанное место - 5 минут. Поддержка отписывается что всё готово, согласуйте вывод - 5 минут. Вот один час
поддержка берётся за раскопки, предлагает готовый кусочек кода разрабу - 30 минут. Разраб крутит пальцем, предлагает поменять, условно, больше на меньше и больше ничего не трогать. Поддержка и разраб идут к аналитику, перетирают - 10 минут. Ловят большое начальство, совещаются; решение: сейчас не делать ничего, войдёт в следующий заказ. Клиенту отписываются пока решать обходным путём, скоро будет хорошо - 20 минут. Один час
Чтобы понимать, на что уходит месяц, мне не хватает специфики проекта. Месяц это очень большой срок
Ну проект большой, стоимость некоторых изменений тоже большая.
У нас (боевые случаи):
В других компаниях бывают совсем другие сроки.
думается мне, поможет рефакторинг, декомпозиция, доки-логи и ответственность
чётко договориться в команде, что есть архитектурный баг, есть баг постановки, баг бизнес-функциональных требований - и программный баг. И все поровну тянут баги в своей ЗО
дробить задачки. Цель - доработку программы в своей ЗО самый золоторукий программист делает не более 8 часов напряжённой работы
логировать и документировать (желательно автоматически), рефакторить. Если не согласуют, то тихо, фоном - потом спасибо скажут.
Тогда и баги в коде будут чиниться за час, со всеми "подумать как лучше"
думается мне, поможет рефакторинг, декомпозиция, доки-логи и ответственность
Это то, что традиционно считается признаками хорошего кода?
Ну да, чтобы иметь хороший код поможет хороший код, это вроде бы понятно. Что делать, если хорошего кода нет?
рефакторить. Если не согласуют, то тихо, фоном — потом спасибо скажут.
Вы пробовали "тихо, фоном" рефакторить репозиторий, в котором 10+ программистов, из которых не все в этом рефакторинге заинтересованы? В лучшем случае ваш рефакторинг не пройдет PR-review.
Не, я понимаю, что вы за все хорошее. Вот только так получилось, что далеко не всегда это хорошее так легко доступно, как вы пишете.
Хе, да, в восьмером пробовал :) совещались недели три, представления о прекрасном так и не пришли к общему знаменателю. Оставили это дело и смирились, что есть у нас серая зона, в которой всё долго. Ребята до сих пор стараются её вообще не трогать
Один бунтарь, который считал что мы все неправильные, отсел на полгода, и переписал в одного полпроекта на своих любимых инструментах, с учётом всех прошлых и части будущих хотелок. Когда мы это вывели с очередным обновлением - эксплуатация была в шоке, а заказчик - счастлив! Работы шли через операционные расходы, т.е. по линии техподдержки, потом задним числом впечатлённый владелец бюджета всё покрыл в очередном договоре
Один бунтарь, который считал что мы все неправильные, отсел на полгода, и переписал в одного полпроекта на своих любимых инструментах, с учётом всех прошлых и части будущих хотелок.
… и ему дали это вмержить?
ну, это был процесс :)
наш начальник держал в курсе директорат наш и заказчика, и получил неформальное добро на денежку, но только в случае успешного успеха
аналитик и поддержка вместе раз в неделю рассказывали о продвижении архитектору, РП и ребятам заказчика, раз в месяц - стейкхолдеру
а разраб имел полноценную тестовую зону идентичную проду, на которой он мог полгода пробовать кусочки в любое время
код ревью делал лично тимлид разработки, после него глянули все разрабы кто хотел примерно за месяц
ещё месяц пробовали это выкатывать на тестовую зону и разраб допиливал
как получилось вывести на тестовую зону - попробовали на прод. Выводили неделю: первые два раза откатывались, потом на третий всё взлетело
как взлетело - разраб смержил в мастер
код ревью делал лично тимлид разработки, после него глянули все разрабы кто хотел примерно за месяц
Я вот про это спрашивал. В вашей ситуации всех код устроил, его вмержили.
А я говорю про ситуацию, в которой половина ревьюверов не заинтересована в рефакторинге, поэтому PR будет отклонен.
Может, облегчить этот кусок, перенести в другие части?
У нас был как-то период, когда один гений ушёл, и кусок проекта вообще невозможно стало трогать. Все были примерно равной квалификации, гений к нам пришёл годом позже, и просто никто не решался. Тупо добавляли сбоку-сверху и не шевелили внутри
Я тогда как сотрудник техподдержки объяснил эксплуатации, что есть баги, которые мы не правим совсем, только компенсируем. И согласовал, что часть функционала мы перенесём на бэк и в базу.
База у нас стала "мудрой" - она научилась понимать любую входящую ерунду, и исходя из известных багов принимала решение, что на самом деле случилось и как это разложить по табличкам
Потом, когда ситуация с багами сдвинулась с мёртвой точки - мы облегчили базу обратно до "умной"
Мне просто казалось важным, чтобы проект был непрерывно адекватен команде разработчиков, и сообразно переносил функциональность из части где затык в другую где работа кипела
Может, облегчить этот кусок, перенести в другие части?
PR будет отклонен по тем же причинам.
Нужно как-то изменить ситуацию в вашу пользу. В текущем виде это нерешаемо
Лично я за прозрачность, но никому не навязываю. Со всеми поговорить, или зайти сверху, или сделать чтобы заказчик хотел именно ваш код на проде
Шансы саботажа все равно будут, но это уже решаемые проблемы.
Можно пойти более тёмной дорожкой, так у нас один товарищ делал. Втихаря выкладывал на прод, прятал концы, валил на других, не вёл версионность, не все пушил в ветку чтобы никто не разобрался, что он обновил. Это имеет свои минусы, но даёт свободу действий на некоторое время. В нашем случае он потихоньку переполз на другую должность, где все эти качества оказались полезны команде
В текущем виде это нерешаемо
Ну вот об этом и речь: что далеко не всегда ситуация решаема легко или решаема вообще.
Если честно, ситуация, когда у одного из членов команды возникло понимание, что нужно менять язык/фреймворк, а остальные говорят что это нецелесообразно (например, некому будет поддерживать, или по другим причинам) - довольно редка
Всё же большинство вещей можно написать на принятых в команде инструментах, любо перейти всей командой на новые
В моей практике был только один такой случай.
На одном заводе использовали Sparc Fortran на Solaris OS. Тогда это был язык понятливый как Javascript - в том плане, что работает вообще всё что угодно
Баги приходилось ловить только по выполнению. При этом инструменты отладки были только "родные" от Solaris.
Когда пришёл очередной баг - я просто заправил принтер пачкой бумаги и распечатал список "шероховатостей" в коде. Список был в 3002 записи, с выдержками из кода - стопка в пару сантиметров бумаги
Я положил этот "талмуд" на стол начальнику и сказал: одна из этих "шероховатостей" является причиной бага. А может и несколько. Давайте починим их все?
Начальник собрал тимлидов, мы обсудили проблему, и нам дали добро, параллельно с другими задачами и не двигая никакой из сроков, устранить все "шероховатости" ("inconsistencies", дело было в Дерби, РР)
Затем аналогично - снизу вверх - выбрали язык
Остановились на C++. Solaris Sparc C++ рассказывал, что не так, не давал собрать приложение пока с его точки зрения всё не придёт в порядок, и это настраивалось ещё строже. Я выкрутил все настройки на максимум, и просто переписал на C++ одну из программок, добившись, чтобы не было ни одного предупреждения
И баг пропал сам собой
Кончилось тем, что РР поручил своему индийскому отделу переписать свои фортрановские программки на C++
Если честно, ситуация, когда у одного из членов команды возникло понимание, что нужно менять язык/фреймворк, а остальные говорят что это нецелесообразно (например, некому будет поддерживать, или по другим причинам) — довольно редка
Это в смысле "вы ее редко видели"?
Ну и да, в моем примере речь шла не о смене языка, а всего лишь о "мелочах" типа "давайте DI добавим".
Всё же большинство вещей можно написать на принятых в команде инструментах,
Можно. Но это как раз будет некрасивый, по мнению пишущего, код. Речь-то, напомню, именно об этом: что заставляет людей писать некрасивый код.
в смысле конкретных действий - взяться за изменение и его провести
всё же мы предпочитаем чтобы командовали нами. Это даёт возможность работать как принято, а свобода слова есть всегда
Хотя, конечно, я с вами согласен: каждый отдел уникален, каждый коллектив не похож на другой
вот сейчас я работаю в конторе, где изначально самые главные руководители - командовали разработчиками напрямую. И внедрение в команду всяких продактов, аналитиков и тестеров - заставляет властью делиться. У нас изменений, наверное, даже чуточку чересчур на единицу времени. И процесс неизменно построен так, что разработчики главные, и по своему желанию привлекают аналитический блок. Это, кстати, позволяет следить за красотой и правильностью кода, делает рефакторинг - задачей бизнеса
Ну например чтобы на Хабре оставить комментарий надо сначала промотать все 374 комментария и тогда тебе доступна форма комментария, а ты там про какой-то файлик. Это уже обыденность
А если бы этот баг попался автору на заре карьеры, кричащий заголовок говорил бы противоположное? Как бы мне ни хотелось считать, что раньше трава был зеленей, а сеньоры сеньористей, но причинно-следственная связь тут видится самую малость натянутой.
Ощущение относительного снижения качества программных продуктов, это только ощущение. Просто доступность и распространенность информационных систем растет, и соотвественно вероятность наткнуться на отказ в одной из таких систем растет. Это очень похоже на т.н. "систематическую ошибку выжившего".
Чтобы получать эстетическое удовольствие, думаю нужно решать алгоритмические задачи типа Проекта Эйлера и иже с ними. Потому что там дается задача в чистом виде. A в профессиональной разработке тебя всегда нагружают контекстом. Поэтому на упражнениях можно чисто медитировать и наслаждаться мыслительным процессом и его результатами.
Видимо, мы сейчас находимся на гребне волны - и инструменты создаются и совершенствуются прямо по ходу их использования.
Android Studio поставил совсем недавно, хотел Flutter попробовать -- и уже просто на этапе установки IDE столкнулся с тем, что приходится копаться в устаревших мануалах, методом тыка искать нужные пункты меню, что-то где-то скачивать и устанавливать самостоятельно, и всё только для того, чтобы запустить Hello World!
Причём IDE намертво висла вместо того, чтобы хотя бы выдать предупреждение, то есть качество когда действительно отвратительно низкое.
А потом.. я, честно говоря, надеялся, что это такие "Delphi 2022" с удобным визуальным конструктором, где в 3 клика можно швырнуть компонент Browser на формочку и заставить аккуратно грузить нужное, но - увы! - искусство создания нормальных IDE, видимо, утеряно. Возможно, годиков через 5 кто-то задолбается и сделает всё как надо, но это не точно.
Но качество кода - это общая проблема "гребня волны". Возьмём другую область - веб-разработку и вполне популярный фреймворк Vue.js. Настройте VS Code, поставьте официально рекомендуемый плагин Volar, получите загрузку CPU 300%. Обновите сам Vue, получите в стек глючный сборщик Vite вместо Vue-CLI+WebPack.
Сейчас вся разработка направлена на скорость доставки фич, это требование бизнеса. Поэтому следить за стабильностью в ущерб скорости никто больше не хочет... Это действительно очень сильно отличает "старую" разработку от "новой".
Привыкаем и стараемся писать быстро, но хорошо.
Сейчас вся разработка направлена на скорость доставки фич, это требование бизнеса.
Может, это все-таки зависит от бизнеса, какие требования от предъявляет? Вы уверены, что для атомного бизнеса или кода для спутников требования такие же?
На мой взгляд, количество бизнесов, которым важна скорость доставки фич, растет. Но хотя число "торопыг" велико, я совсем не уверен, что их доля в общей разработке растет также быстро. Потому что чаще всего им надо не только "быстро", но и "просто" — они хотят успеть реализовать (относительно) простые фичи (сайт, android-приложение — это не rocket science). А сложные задачи, где цена ошибки стоит как Curiosity, — таких мало количественно, но в человеко-часах годах они могут до сих пор преобладать над "миллионом проектов на Vue.js".
Но это неточно :-) Даже не представляю, есть ли где-нибудь такая статистика.
Эпоха красивого кода прошла. Пришло время быдлокода