Рубрика «Совершенный код» - 17

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

Напомню, что для private методов питон всего-лишь динамически изменяет имя и никак не ограничивает доступ к нему, а для protected не делает и этого, это просто соглашение об именовании методов, для тех кто не очень в курсе, есть дополнительные материалы тут и тут.
Читать полностью »

image

Это циничная, клиническая коллекция того, чему я научился за 30 лет работы в разработке программного обеспечения. Повторюсь, некоторые вещи весьма циничны, а остальное — результат долгих наблюдений на разных местах работы.
Читать полностью »

Скрытый под слоем кода, томится язык, жаждущий быть выученным.

Один язык чтобы править всеми - 1

На момент написания этой статьи запрос «программирование какой язык изучать первым» выдаёт 517 миллионов поисковых результатов. Каждый из этих сайтов будет нахваливать один определённый язык, и 90% из них, в конечном итоге, порекомендуют Python или JavaScript.

Без долгих прелюдий, я хотел бы официально декларировать, что все эти 517 миллионов сайтов неправы и заявить, что язык, который надо изучать первым — фундаментальная логика.

Просто знать как кодить уже не достаточно. Рынок настолько насыщен выпускниками институтов и курсов, что позиция джуниора практически перестала существовать*. Чтобы преуспеть в сегодняшнем мире, вы должны и кодить, и иметь продвинутое фундаментальное логическое мышление.

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

Мой первый урок Информатики

Моё первое знакомство с информатикой было факультативом, который я взял в 10 классе. В первый же день, зайдя в аудиторию, я был восхищён, увидев перед собой большое количество ведёрок мороженого и разнообразных топпингов. После того как все расселись, учительница провозгласила:

«Сегодня мы будем дегустировать самостоятельно приготовленные пломбиры. Но с одним условием: вы должны составить список конкретных инструкций, как приготовить десерт, а я — буду им следовать»

Читать полностью »

5 распространенных ошибок при использовании архитектурных компонентов Android

Даже если вы не делаете этих ошибок, стоит о них помнить, чтобы не столкнуться с некоторыми проблемами в будущем.

Читать полностью »

Стоит ли высокое качество ПО затрат на его разработку? - 1

Часто в процессе реализации проектов команды сталкиваются с вопросом: чему следует уделять больше внимания – выпуску новых фич или повышению качества кода? Обычно менеджеры делают выбор в пользу фич. Зачастую разработчики таким положением дел недовольны, считая, что им выделяется недостаточно времени для работы над архитектурой и качеством кода.

Закон Беттериджа гласит: «На любой заголовок, который заканчивается вопросительным знаком, можно ответить словом нет». Те, кто знаком со мной лично, знают, что я не разделяю эту мысль. Но в этой статье я хочу пойти ещё дальше и доказать, что постановка вопроса из заголовка этой статьи просто не имеет смысла. Такая постановка вопроса предполагает, что существует компромисс между затратами и качеством. И необходимо постоянно соблюдать баланс. В этой статье я докажу, что к миру разработки компьютерных систем этот компромисс не применим и, в действительности, создавать ПО высокого качества оказывается в конечном счёте дешевле.

Несмотря на то, что основная целевая аудитория статьи это разработчики, для её понимания не требуется специальных знаний. Мне бы хотелось чтобы эта статья принесла пользу всем, кто так или иначе связан с процессом разработки, а особенно менеджерам, которые формируют вектор развития продуктов.
Читать полностью »

image

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

Представьте такую ситуацию:

В качестве домашнего задания Хуан и Саша реализуют одинаковый рандомизированный алгоритм на C++, который будет выполняться на одном университетском компьютере и с одним набором данных. Их код почти идентичен и отличается только в генерации случайных чисел. Хуан торопится на свои занятия по музыке, поэтому просто выбрал вихрь Мерсенна. Саша, с другой стороны, потратил несколько лишних часов на исследования. Саша провёл бенчмарки нескольких самых быстрых ГПСЧ, о которых недавно узнал из соцсетей, и выбрал наиболее быстрый. При встрече Саше не терпелось похвастаться, и он спросил Хуана: «Какой ГПСЧ ты использовал?»

«Лично я просто взял вихрь Мерсенна — он встроен в язык и вроде неплохо работает».

«Ха!», — ответил Саша. «Я использовал jsf32. Он намного быстрее, чем старый и медленный вихрь Мерсенна! Моя программа выполняется за 3 минуты 15 секунд!».

«Хм, неплохо, а моя справляется меньше, чем за минуту», — говорит Хуан и пожимает плечами. «Ну ладно, мне пора на концерт. Пойдёшь со мной?»

«Нет», — отвечает Саша. «Мне… эээ… нужно снова взглянуть на свой код».

Эта неловкая вымышленная ситуация не особо и вымышлена; она основана на реальных результатах. Если ваш рандомизированный алгоритм выполняется не так быстро, как хотелось бы, и узким местом похоже является генерация случайных чисел, то, как это ни странно, проблема может быть и не в генераторе случайных чисел!
Читать полностью »

На ваш суд скорее статья-вопрос, статья-рассуждение и местами — недоумение. С одной стороны нам презентовали авторитетное мнение Лесли Лэмпорта "Programing Should Be More Than Coding", расставляющее программирование и кодирование в импровизированном табеле о рангах. С оппонирующей стороны — я, не обладающий статусом достаточным для споров с мэтром и легендарным ВУЗом, который он представляет… но отказать себе в таком удовольствии и риске я не могу. Надеюсь, более опытные товарищи поправят мои огрехи в рассуждениях.

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

Как опытные инженеры, мы — мастера абстракций. Поэтому для нас не составит труда представить условного программиста по имени Лесли Лэмпорт (все имена и совпадения не случайны) и его основной инструмент — машину Тьюринга. Он — мастер своего дела, во многом благодаря железному дао:

Читать полностью »

Если вы заботитесь о самом коде, и о том, как он написан, а не заняты лишь тем, чтобы создавать работающие программы, это означает что вы стремитесь к тому, чтобы ваш код был чистым. Профессиональный разработчик пишет код не только в расчёте на компьютеры, но и в расчёте на себя самого, встретившего этот код в будущем, и в расчёте на других программистов. Код, который вы пишете, не исчезает навсегда в недрах компьютера. Он живёт, изменяется, и, если написан плохо, вполне может сильно расстроить того, кому придётся редактировать его после того, как вы его написали. Вполне возможно, что этим «кем-то» будете именно вы.

Рекомендации по написанию чистого кода на JavaScript - 1

Исходя из этих идей, чистый код можно определить как код, написанный так, что он сам себя объясняет. Этот код без труда смогут понять люди, его легко будет модифицировать или расширять.
Читать полностью »

Мы написали самый полезный код в своей жизни, но его выкинули на помойку. Вместе с нами - 1

Я повесил у себя в подвале боксерскую грушу, приклеил на нее стоковое фото типичного менеджера и запихал внутрь динамик, чтобы он проигрывал фразы, которые меня злят. Например, груша говорит: «Бизнесу не нужен твой идеальный код. Ему нужно решить проблему так, чтобы прибыль покрыла затраты. Если для этого нужен говнокод, значит будет говнокод». И начинаю дубасить.

Недавно я добавил в грушу запись: «Типы — это сложно и ненужно». В этот момент я бью так сильно, что рука чуть не ломается. Потому что с меня хватит. Пару месяцев назад я пережил один из самых вопиющих кейсов в своей карьере.

Мой друг Антоха попросил меня помочь с решением для одной большой-большой корпорации. Я согласился, и мы влезли в бездонную пучину корпоративного абсурда, кранча, войны с ничего не понимающими JS-никами и всеми видами несправедливости. Нам ничего нельзя говорить, поэтому мы будем говорить про типы, чтобы такая фигня никогда ни у кого не повторялась.
Читать полностью »

image

Должен признаться: я читаю ACM Magazine. Это делает меня «ботаником» даже по меркам программистов. Среди прочего, я узнал из этого журнала о «метаморфическом тестировании». Раньше я никогда о нём не слышал, как и все люди, которых я спрашивал. Но научная литература по этой теме на удивление объёмна: есть множество невероятно успешных примеров её применения в совершенно разных областях исследований. Так почему же мы не слышали о нём раньше? Существует только одна статья для людей вне научных кругов. Пусть теперь их будет две.

Краткая предыстория

В большинстве письменных тестов используются оракулы. То есть вы знаете ответ и явным образом проверяете, дают ли вычисления правильный ответ.

def test_dist():
    p1 = (0, 3)
    p2 = (4, 0)
    assert dist(p1, p2) == 5

Кроме тестов-оракулов, есть и ручные тесты. Тестер садится за компьютер и сравнивает вводимые данные с результатами. В процессе усложнения систем ручные тесты становятся всё менее полезными. Каждый из них проверяет только одну точку в гораздо большем пространстве состояний, а нам нужно нечто, исследующее всё пространство состояний.

Это приводит нас к генеративному тестированию (generative testing): написанию тестов, покрывающих случайное множество в пространстве состояний. Самым популярным стилем генеративного тестирования является property based testing, или PBT. Мы находим «свойство» (property) функции, а затем генерируем входные значения и проверяем, соответствуют ли выходные значения этому свойству.

def test_dist():
    p1 = random_point()
    p2 = random_point()
    assert dist(p1, p2) >= 0

Преимущество PBT заключается в покрытии большего пространства. Его недостаток — утеря специфичности. Это уже не оракул-тест! Мы не знаем, каким должен быть ответ, и функция может быть ошибочна, но таким образом, что обладает тем же свойством. Здесь мы полагаемся на эвристики.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js