Comments 29
Большинство программных систем используют менее 1% ресурсов современных процессоров
Как опознать теоретика за одну фразу.
У меня в данную минуту открыто 27 окон chrome (более 500 вкладок), 4 окна PowerPoint, 2 окна Excel, Notepad++, IntelliJ IDEA с запущенным внутри сервером Structurizr, Acrobat Reader с тремя документами, клиент MatterMost. И это только моё, операционку не считаю. Общая загрузка процессора - 2-5%. А, еще WinAMP c музыкой
Дак у вас большинство сервисов в таком режиме спят, работает текущее окно ну и фоновое чуток (WinAmp).
А теперь возьмите и запустите архивацию чего-нибудь большого, штук 5 - сразу будет другая картина, характерная для серверной загрузки.
Я когда запускаю Activity Monitor посмотреть на загрузку процессора, собственно Activity Monitor отжирает 2%. MBP 2023 года, Apple M2 Max.
Это всё не дает нам никаких данных (кучка личного опыта — не данные). Давайте запустим, скажем, Cyberpunk 2077 и посмотрим среднюю загрузку процессора, пока проходим первую миссию. Cyberpunk 2077 это очень типичная программа.
А у меня открыты 4 вижуал студии, в одной я запустил тесты, во второй компиляцию, в третьей запущены сервисы (которые нужны тестам первой), а четвертая в этот момент открывается. А еще у меня сикель ворочается, на фоне вижуал студия инсталлер качает апдейт студии на 8гб, на втором монике открыта 4я цивилизация и одновременно я слушаю краем уха очередной бубнеж менеджера в тимсе. И в итоге это все совсем не 1% а скорее все 146%
После окончания этой дискуссии я видел мнения о том, что чистый код был компрометирован в её процессе и больше не заслуживает внимания
А я часто вижу, что в результате наблюдения этой дискуссии люди (особенно неопытные) впадают в очень детское заблуждение:
если код чистый, то он автоматически медленный. Поэтому гоните его, насмехайтесь над ним.
если код не чистый, то он автоматически не медленный. Поэтому отрицайте эту чепуху Мартина ради перфоманса.
А в реальности средний код он и не чистый и не быстрый, а просто кусок вонючего техдолга. Писать чисто - это скилл, писать оптимально - это тоже скилл. А чаще всего никакого скилла нет, а есть "херак херак и в продакшн". Утверждать, что только на одном из скиллов, полностью отрицая другой, можно вытащить современное приложение на миллионы строк кода - тоже бред какой-то.
Писать быстро, в стиле "херак херак и в продакшн" - это тоже скилл. Если по-русски - умение.
Я это ощутил на своем опыте: я довольно долго занимался программированием чисто в свое удовольствие, где никакие дедлайны надо мной не стояли (если кому интересно, где есть такая благодать, то это была советская наука). А потому этого умения я не приобрел. И когда я пошел работать в реальный мир, где бабло поднимают, то пришлось это умение срочно прокачивать, потому что сделать хоть как-то, но сейчас бывает необходимо для бизнеса (особенно - в эксплуатации). И теория ITSM об этом знает: это называется "обходное решение", его противоположность "структурное решение".
Но самое сложное - писать достаточно быстро, но в то же время - так, чтобы было не совсем плохо.
писать сложно просто. сложно писать просто.
Чистый код это вопрос личного вкуса и предпочтений. Для каждого есть своё понятие чистоты. Один считает break в цикле грязным кодом. Другой goto на метку в конце функции - стандартом. Поэтому всегда теряюсь на собесе, когда спрашивают, пишу ли я чистым кодом.
С одной стороны - геймдев, где (грубо говоря) нужно за 10 мс на любом процессоре и с 4 ГБ ОЗУ пересчитать состояние всего игрового мира, а потом ещё и отрендерить его в миллиард полигонов. Потом это дело зарелизить, за 2 месяца выпустить патчи и забыть навсегда.
С другой стороны - кровавый энтерпрайз, где нужно написать процессинг заявки пользователя уложившись хотя бы в 10 секунд, на 96-процессорном сервере с 256ГБ ОЗУ, но ещё нужно, чтобы другой сотрудник через 15 лет не имея документации смог добавить фичу в этот процессинг, а ещё все эти 15 лет надо будет дописывать и переписывать. А ну и ещё текучка джунов, постоянно уходят-приходят и нужно научиться погружать максимально быстро.
Так что ответ очевиден - каждому ПО свои критерии.
Эти правила конкретизируют, как написать код так, чтобы он считался "чистым".
Главное правило чистого кода - это от общего к частному (про контроль уровней абстракций, функция может вызывать только функции с более низким уровнем абстракции).
Кейси предложил Роберту теоретически представить интерфейс операционной системы для ввода/вывода, разработанный в соответствии с принципами чистого кода.
С этого момент начинается довольно интересный практический пример, который придётся потом разобрать во всех подробностях.
Пока могу сказать, что у меня имеется предубеждение против оператора switch. Всё-равно, он воспринимается громоздко. Хотя управлять им (особенно в режиме IDE) можно довольно эффективно. К тому же, можно и развить язык программирования в отношении оператора switch.
Данная дискуссия немного проливает свет на то, что, в действительности, чистым должен называться код, который обладает концептуальной чистотой. Как в приводимом примере. Вот мы предположили, что с каждым устройством можно связать понятие файла, вот вам и чистая концепция. И, при том, правильная концепция. Так это и мыслится. А уже поверх концепции файлов нужно создавать концепцию документа и, соответственно, выстроить промежуточный слой абстракций, который отображает слой документов на файлы. А что там могут быть за файлы? Например, это может быть и видео, а тут у нас уже и плеер готов. Какая разница, что проигрывать? В этом смысле, чистый код — это обобщённый код. Производительность — удел реализации. А кто сказал, что предъявленный высокоуровневый код — это код реализации. Нет! Это код декларации взаимодействия. Но одно и то же может быть реализовано множествами различных способов. (Чистый код — это код, описывающий. например, в общем виде работу интернет-магазина, а то, что у этому магазину пытаются получить доступ с различных устройств — детали реализации.)
... Эххх, хотелось бы, конечно, пофантазировать в духе второй половины статьи. Тут напрашивается следующий шаг: а можно ли организовать программный код в виде базы данных? Тогда операционную систему можно будет мыслить как систему управления базами программного кода, когда для каждой задачи оформляется свой запрос, а код упорядоченным образом лежит в базе.
Можно, хранимые процедуры. Или вы не об этом?
Не совсем. Речь идёт именно о том, чтобы сам код хранить в записях БД. Это должны быть семантически самостоятельные фрагменты, допускающие введение полей. Тут ещё надо подумать на каком языке программирования должны быть написаны эти фрагменты. В первом приближении, это может быть любой язык программирования. Возможно, это будет язык шаблонов, потому что надо быдт создавать конкретный код в памяти, а там уже все адреса и смещения должны быть явно заданными. Вообщем, тут много вопросов. Но подумать можно с общей точки зрения — с точки зрения того, как формировать запросы, что будет на выходе запросов. Так что пока это всё — мои мысли вслух.
Настоящая беда со всеми этими принципами "правильного написания кода" - то, что они не универсальны и разные авторы понимают под ними что-то свое. Это, кстати, вполне обычное явление, оно - не только в программировании, см. законы Чизхолма, открытые задолго до того, как программирование стало массовой прфессией.
И про это, помнится, ещё Эд Пост в стародавние времена (1983 год, однако) писал:
В последние несколько лет академиков от вычислительной тех-
ники вовлекли на стезю структурного программирования. Они
утверждают, что программы становятся более понятными, если
используются специальные языковые методы и конструкции. Они,
конечно, не могут договориться между собой, какие точно кон-
струкции следует использовать, а примеры, иллюстрирующие их
точку зрения, всегда помещаются на одной страничке неизвестных
журналов.
А потому они дают благодатную почву для чисто схоластических споров (типа дискуссий остроконечников и тупоконечников у Свифта).
PS И мне показалось, что дискуссия в этой статье - именно такой спор.
Настоящая беда со всеми этими принципами "правильного написания кода" - то, что они не универсальны и разные авторы понимают под ними что-то свое
Во-первых, никто и не обещает, что они будут универсальны. Мартин, Фаулер и Физерс пишут в основном про кровавый энтерпрайз на соответствующих языках. Это не декларируется, но это понятно по контексту. Поэтому смешно, когда со стороны геймдева или эмбеддеда начинают вопить, что у них там чистый код ну никак не возможен. Ну про вас и речи не было, успокойтесь уже.
Во-вторых, у всех трех авторов книги в общем-то про одно и то же. И принципы там даны тезисно, с пояснением "откуда берется" и "зачем это нужно". Большинство спорщиков эти книжки или не читали или читали по диагонали. Поэтому спор сводится к бреду вроде "вот Мартин говорит делать функции как можно короче - я так сделал и у меня получилось говно". И на этом основании делается вывод, что вся книжка тоже говно. Блин, в этих книгах в каждой по 200-400 страниц с кучей полезных советов - но их отменяют из-за какого-то одного. Это поведение пятилетних детей, а не для дядь за 30.
Авторы-то, чаще всего - разумные люди, которые пишут для разумных людей, и не изрекают истины, а обобщают опыт.
Но вот дальше их тексты попадают к тем, у кого опыта своего нет, здравый смысл в дефиците, и они превращают написнное в догму.
В результате возникют обсуждения, к примеру, про "антипатерны" (по моим наблюдениям - любимое словечко у догматиков). И так уже - более 40 лет, судя по упомянутой старой статье, разве что тогда слова "антипатерн" не было.
PS "Я спокоен, как пульс покойника"(с). Но когда такой догматик попадает в твои начальники - это уже по жизни напрягает.
...И мне показалось, что дискуссия в этой статье - именно такой спор.
Оппоненты разошлись немного по разным вопросам, поскольку одно другого не исключает. Тем не менее, вопрос понятности кода всегда останется актуальным. Следовало бы ожидать, что, сначала, система описывается на концептуально ясном языке, а, уже потом, происходит её отображение на язык реализации, где и решаются, собственно, вопросы производительности. При таком подходе, никакого противоречия не возникнет. Просто, всему должно быть указано своё место.
Тем не менее, вопрос понятности кода всегда останется актуальным.
Понятность кода - качество субъективное, зависит от субъекта, который пытается понять. Как сказано в уже цитированной статье (наполовину всерьез, как, собственно, и вся та статья)
настоящие программисты не нуждаются в комментариях : текст программы все объясняет;
Собрались два деда, поспорили о взглядах на полиморфизм
А вообще выглядит так, как будто футболист докопался до хоккеиста, со словами: "у вас мячи неправильные".
Потому что оба подхода должны использоваться там где это нужно. Экономию памяти и избегание виртуальных вызовов, для быстродействия, оставьте эмбеддед разрабам, а динамический полиморфизм оставьте энтерпрайзу на миллионы строк кода
Ну главное без фанатизма относиться к чистом коду. Знаю я один проект, который создавался по канонам дядюшки Боба. Так для добавления нового метода пришлось потратить две недели разработчика, потому что созданная архитектура не позволила просто взять и добавить.
Вторая часть статьи уже вышла! Приятного чтения!
Чистый код — дар или проклятие? Акт I. Конфронтация