Как стать автором
Обновить

Комментарии 21

За что минусы-то, нормальная статья
Лично мне кажется, что первый минус ставится автоматом.

Есть предположение, что минус кто-то оставил за перевод переведённого материала:
Уважаемый Вячеслав Голованов (SLY_G) указал источник -


Перевод репозитория github.com/dwmkerr/hacker-laws

Вроде всё правильно, но почему-то не захотел упомянуть, что эта подборка переведена на несколько языков, включая русский (Alena Batitskaya solarrust).
Такие публикации вызывают у меня двойственные чувства. Вроде, человек старалсо, переводил. А с другой стороны — зачем? Популяризовать материал? Или популяризовать себя — пиарюсь (есть же спец. тег для этого)?
В общем, если бы меня кто-то пригласил в НЛО (или я бы умел сам себя приглашать), и появилось право ставить плюсы/минусы, то от меня бы тоже минус прилетел.
Боюсь вот только, что за честное мнение, мне самому что-нибудь прилетит...

Расскажите про «стрижку яков»
Надо съездить за продуктами, но у машины спустило колесо, насос в гараже, а там лампочка перегорела, а в шкафу с лампочками дверца заедает — пошёл искать баллон со смазкой.
В итоге ищу баллон со смазкой, чтобы съездить за продуктами.
Блин, гифка, залитая на ютуб. Вот уж где изврат.
Вот нормальное видео:
Интересные законы. Многие можно также хорошо отнести и к другим сферам разработки, а не только к программированию.

Например, мне понравился закон Хирама:
При достижении достаточного количества пользователей API уже неважно, какие его особенности вы обещали всем: для любой из возможных особенностей поведения вашей системы найдётся зависящий от неё пользователь


который можно было бы отнести на любой, в том числе и физический продукт: т.е. при достаточном количестве проданных экземпляров данного продукта, всегда найдется пользователь для любой из фич данного продукта. Причем даже для той, о которой не разработчик не думал. Например, вообразим, что Google Home можно прибивать гвозди — и найдутся же те, кто это в реале делал!
Преждевременная оптимизация – корень всех зол.

Я конечно не програмист, но как-то не могу согласится с этим утверждением. Не раз и не два встречался на проектах с ситуацией типа:
Лид: Ребята сегодня начинаем писать вот этот сложный модуль/отчет. Он не сколько сложный по бизнесу, сколько ресурсоёмкий потому что работает с множеством объектов. Понятно?
Команда: Понятно-понятно, идем пилить.

В итоге код пишется, тестируется на предмет работы по функционалу. А потом спустя пару месяцев на нагрузочном тестировании (или чего хуже проде), оказывается что мы заюзазали стандартные методы Java (вместо, например, прямого обращения в бд), которые на каждый объект подымают все параметры класса занимая кучу оперативки и когда количество объектов достигает пару тысячь, это все весело падает.
А поправить оказывается не так просто.

Короче к чему я веду, конечно не надо морочить голову над тем как сразу заставить сайт грузится 3 мс, вместо скажем 3 сек. Но и иметь хотя бы приблизительное представление о том, что и как быстро будет работать, что выбрать правильный подход надо.

Всё верно, в названии и есть "преждевременная". В описанном случае разработчики знали о нагрузке, но сделали криво, а значит задача не выполнена.

У них, похоже, абстракция протекла..

Можно процитировать фаулера в тему:

С рефакторингом обычно связан вопрос о его влиянии на производительность программы. С целью облегчить понимание работы программы часто осуществляется модификация, приводящая к замедлению выполнения программы. Это важный момент. Я не принадлежу к той школе, которая пренебрегает производительностью в пользу чистоты проекта или в надежде на рост мощности аппаратной части.Программное обеспечение отвергалось как слишком медленное, а более быстрые машины устанавливают свои правила игры. Рефакторинг, несомненно, заставляет программу выполняться медленнее, но при этом делает ее более податливой для настройки производительности. Секрет создания быстрых программ, если только они не предназначены для работы в жестком режиме реального времени, состоит в том, чтобы сначала написать программу, которую можно настраивать, а затем настроить ее так, чтобы достичь приемлемой скорости.

Мне известны три подхода к написанию быстрых программ. Наиболее трудный из них связан с ресурсами времени и часто применяется в системах с жесткими требованиями к выполнению в режиме реального времени.В этой ситуации при декомпозиции проекта каждому компоненту выделяется бюджет ресурсов — по времени и памяти. Компонент не должен выйти за рамки своего бюджета, хотя разрешен механизм обмена временными ресурсами. Такой механизм жестко сосредоточен на соблюдении времени выполнения. Это важно в таких системах, как, например, кардиостимуляторы, в которых данные, полученные с опозданием, всегда ошибочны.Данная технология избыточна в системах другого типа, например в корпоративных информационных системах, с которыми я обычно работаю.

Второй подход предполагает постоянное внимание. В этом случае каждый программист в любой момент времени делает все от него зависящее, чтобы поддерживать высокую производительность программы. Это распространенный и интуитивно привлекательный подход, однако он не так хорош на деле. Модификация, повышающая производительность, обычно затрудняет работу с программой. Это замедляет создание программы. На это можно было бы пойти, если бы в результате получалось более быстрое программное обеспечение, но обычно этого не происходит. Повышающие скорость усовершенствования разбросаны по всей программе, и каждое из них касается только узкой функции, выполняемой программой.С производительностью связано то интересное обстоятельство, что при анализе большинства программ обнаруживается, что большая часть времени расходуется небольшой частью кода. Если в равной мере оптимизировать весь код, то окажется, что 90% оптимизации произведено впустую, потому что оптимизировался код, который выполняется не слишком часто. Время, ушедшее на ускорение программы, и время, потерянное из-за ее непонятности — все это израсходовано напрасно.

Третий подход к повышению производительности программы основан как раз на этой статистике. Он предполагает создание программы с достаточным разложением ее на компоненты без оглядки на достигаемую производительность вплоть до этапа оптимизации производительности, который обычно наступает на довольно поздней стадии разработки и на котором осуществляется особая процедура настройки программы.Начинается все с запуска программы под профайлером, контролирующим программу и сообщающим, где расходуются время и память. Благодаря этому можно обнаружить тот небольшой участок программы, в котором находятся узкие места производительности. На этих узких местах сосредоточиваются усилия, и осуществляется та же самая оптимизация, которая была бы применена при подходе с постоянным вниманием.Но благодаря тому, что внимание сосредоточено на выявленных узких местах, удается достичь больших результатов при значительно меньших затратах труда. Но даже в этой ситуации необходима бдительность. Как и при проведении рефакторинга, изменения следует вносить небольшими порциями, каждый раз компилируя, тестируя и запуская профайлер. Если производительность не увеличилась, изменениям дается обратный ход.Процесс поиска и ликвидации узких мест продолжается до достижения производительности, которая удовлетворяет пользователей. Мак-Коннелл [McConnell] подробно рассказывает об этой технологии.Хорошее разделение программы на компоненты способствует оптимизации такого рода в двух отношениях. Во-первых, благодаря ему появляется время, которое можно потратить на оптимизацию. Имея хорошо структурированный код, можно быстрее добавлять новые функции и выиграть время для того, чтобы заняться производительностью. (Профилирование гарантирует, что это время не будет потрачено зря.) Во-вторых, хорошо структурированная программа обеспечивает более высокое разрешение для анализа производительности. Профайлер указывает на более мелкие фрагменты кода, которые легче настроить.Благодаря большей понятности кода легче осуществить выбор возможных вариантов и разобраться в том, какого рода настройка может оказаться действенной.

Я пришел к выводу, что рефакторинг позволяет мне писать программы быстрее. На некоторое время он делает программы более медленными, но облегчает настройку программ на этапе оптимизации. В конечном счете достигается большой выигрыш.
… в начале 1980-х Уорд Каннингем дал ему совет: «Лучший способ найти правильный ответ в Интернете...

А ведь точно, еще Ленин что-то там говорил о цитатах из Интернета

Так Каннингем и не говорил про интернет, там был Usenet, появившийся как раз в 1980. Про Интернет уже потом перефразировали и приписали ему.
В технологическом секторе доминируют два типа людей: те, кто разбирается в том, что они не контролируют, и те, кто контролирует то, в чём они не разбираются.

Чем то коррелирует с принципом Питера
«В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности»

Сразу пришел в голову первый закон Ома: схема без питания не работает.
Вот о чём статья, догадался я.

А мне первое правило механики: не мешай механизму работать.
Бритва Хэнлона — на самом деле Бритва Хайнлайна.
Я бы еще добавил «Парадокс Блаба» в список.
Его сущность состоит в том, что программист, знающий некоторый язык («Блаб»), «думает на Блабе» — выражает решение любой задачи в средствах Блаба, а имеющиеся в более мощном языке дополнительные средства в его глазах ничего не стоят, так как он не умеет их применять. Только когда программист по каким-то внешним, дополнительным причинам изучит более мощный язык, он получит возможность смотреть на Блаб «сверху вниз» и увидит его ограниченность. Таким образом, ограниченность Блаба сама по себе не может стать стимулом для изучения более мощного языка, так как для осознания этой ограниченности необходимо уже знать такой язык.
kiss — милая аббревиатура для фразы про «дурика»)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории