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

Проектирование и рефакторинг *

Реорганизация кода

Сначала показывать
Порог рейтинга
Уровень сложности

Rust — это не «memory safe C»

Уровень сложностиСредний
Время на прочтение27 мин
Количество просмотров51K

TL;DR:
— в Rust намного больше достоинств, чем просто скорость и безопасность
— в Rust по умолчанию CDD (compiler-driven development, разработка через компилирование). Это как TDD, только CDD
— Rust — не сложный язык, особенно если не гнаться за максимальной производительностью

В этой статье я бы хотел рассказать:
— почему взгляд на Rust как на "memory safe C" очень сильно сужает область его возможного применения
— почему я смотрю на Rust как на очень удобный в разработке язык высокого уровня, которому просто случайно повезло оказаться невероятно быстрым
— почему разработка на Rust быстрее, чем многие думают
— почему Rust — это один из лучших языков общего назначения

Читать далее
Всего голосов 155: ↑149 и ↓6+168
Комментарии555

Новости

Ошибки выбора MongoDB в качестве основной БД в стартапе

Время на прочтение6 мин
Количество просмотров39K

В этой статье я хочу рассказать о своих ошибках, которые я допустил, когда писал сервис, у которого MongoDB была основной БД для хранения пользовательских данных (да и не только, но об этом ниже).

Я ни в коем случае не считаю, что MongoDB это плохая БД и ее не нужно использовать. Более того, я считаю, что только мои кривые руки завели меня в ситуацию, из которой пришлось выходить переписыванием сервиса под другую БД (ушел на Postgres и кайфую).

Тем не менее, нельзя знать всего и чтение документации не спасает от катастроф во время самой реализации проекта. Особенно, если ваши ожидания от инструмента разошлись с реальностью.

На мой взгляд, маркетологи MongoDB приукрасили области применениях БД на своем сайте. MongoDB не универсальная. Далеко не универсальная и даже не пытайтесь на нее смотреть как на решение всех ваших проблем.

Встать на грабли вместе
Всего голосов 136: ↑112 и ↓24+115
Комментарии131

Разработчик с мозгом груга

Время на прочтение14 мин
Количество просмотров89K

Введение


это сборник мыслей о разработке программ собранный разработчиком с мозгом груга

разработчик с мозгом груга не очень умный, но разработчик с мозгом груга программирует много лет и научился кое чему, хоть всё равно часто запутывается

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

разработчиков с большим мозгом много, некоторым страница не понравится, скривят кислая рожа

Ещё больше-больше ДУМАЮТ, что они разработчики с большим мозгом и им она тоже не понравится

(груг раньше думал груг с большим мозгом, но потом всё понял)

это ладно!

груг надеется, что тебе понравится читать и может ты научишься на много-много ошибка груг совершил за длинную жизнь программиста
Читать дальше →
Всего голосов 223: ↑197 и ↓26+209
Комментарии81

История крови. Самая древняя проблема обратной совместимости

Время на прочтение9 мин
Количество просмотров50K

Выйдя на сушу, мы захватили с собой в дорогу немного моря. Тонкая мембрана одноклеточных так легко пропускала соленую воду с кислородом и питательными веществами, что эволюция даже не попыталась реализовать этот механизм как-то иначе. Многоклеточные обросли тканями, развили внутренние органы, освоили половое размножение, но обмен веществ продолжался через соленую жидкость с белково-металлической примесью. Металл связывался с кислородом, а сама жидкость, которая теперь называлась «кровь», оказалась немного разбавлена по сравнению с морской водой, но не более того. В качестве носителя для кислорода большинство многоклеточных предпочли железо – один из самых распространенных металлов, который легко и разнообразно окисляется. Головоногие приматы моря, а также онихофоры (бархатные черви) и некоторые членистоногие использовали вместо железа медь, поэтому кровь у них голубая (вместо гемоглобина они обзавелись аналогичным белком гемоцианином). Голотурии (морские огурцы) используют ванадий, из-за которого их кровь также синяя. До сих пор не вполне понятно, нужен ли им ванадий для дыхания (и образует аналог гемоглобина) или для питания (как магний в хлорофилле), но в Японии тем временем выращивают целые плантации голотурий для получения ванадия. Тем не менее, наиболее подходящим для крови металлом оказалось именно железо, так как оно достаточно распространенное и при этом не слишком токсичное. Поэтому кровь у всех позвоночных красная.

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

Читать далее
Всего голосов 88: ↑83 и ↓5+102
Комментарии50

Истории

Ты добавил всего две строчки. Почему на это ушло два дня?

Время на прочтение3 мин
Количество просмотров64K
На первый взгляд вопрос кажется разумным, но он делает некоторые ужасные предположения:

  • строки кода = усилие
  • строки кода = значение
  • все строки кода равны

Ничто из этого не является истинным.

Почему исправление, которое кажется таким простым, заняло два дня?
Читать дальше →
Всего голосов 127: ↑122 и ↓5+147
Комментарии225

Почему Discord переходит с Go на Rust

Время на прочтение7 мин
Количество просмотров81K


Rust становится первоклассным языком в самых разных областях. Мы в Discord успешно используем его и на серверной, и на клиентской стороне. Например, на стороне клиента в конвейере кодирования видео для Go Live, а на стороне сервера для функций Elixir NIF (Native Implemented Functions).

Недавно мы резко улучшили производительность одной службы, переписав её с Go на Rust. В этой статье объясним, почему для нас имело смысл переписать службу, как мы это сделали и насколько повысилась производительность.
Читать дальше →
Всего голосов 131: ↑127 и ↓4+166
Комментарии307

Я в одиночку отрефакторил 15 тысяч строк легаси. Это были худшие две недели в жизни

Время на прочтение10 мин
Количество просмотров103K


Несколько месяцев назад я работал в аутстафе. Это не то место, где нужен энтузиазм и вера в великую цель проекта. Меня вместе с командой просто продавали заказчикам, а на митингах было важно, сколько тикетов я закрыл. Приступы перфекционизма — скорее вредная штука для такого места, но я ничего не мог с ними сделать. За один из них я знатно поплатился, попал в адский кранч и провел худшие две недели в моей жизни.
Читать дальше →
Всего голосов 427: ↑369 и ↓58+311
Комментарии401

Как мы запустили 2ГИС под CarPlay и до сих пор расхлёбываем

Время на прочтение14 мин
Количество просмотров50K


Привет! Меня зовут Ваня, я пишу мобильное приложение 2ГИС под iOS. Сегодня будет история о том, как наш навигатор появился в CarPlay. Расскажу, как с такой себе документацией и недоделанными инструментами мы создали рабочий продукт и разместили его в AppStore.

Поехали!
Всего голосов 107: ↑106 и ↓1+105
Комментарии88

Вы — не Google

Время на прочтение7 мин
Количество просмотров103K
Мы, программисты, иногда почему-то сходим с ума. Причём по каким-то совершенно нелепым причинам. Нам нравится думать о себе, как о супер-рациональных людях, но когда дело доходит до выбора ключевой технологии нового продукта, мы погружаемся в какое-то безумие. Вдруг оказывается, что кто-то слышал что-то об одной классной вещи, а его коллега читал комментарий о другой на Хабре, а третий человек видел пост в блоге о ещё чём-то похожем… и вот мы уже пребываем в полнейшем ступоре, беспомощно барахтаясь в попытках выбора между совершенно противоположными по своей сути системами, уже и забыв, что мы вообще пытаемся выбрать и почему.

Рациональные люди не принимают решения таким образом. Но именно так программисты часто решают использовать что-то вроде MapReduce.

Вот как комментировал этот выбор Joe Hellerstein своим студентам (на 54-той минуте):

Дело в том, что в мире сейчас есть где-то 5 компаний, обрабатывающие данные подобных объёмов. Все остальные гоняют все эти данные туда-сюда, добиваясь отказоустойчивости, которая им на самом деле не нужна. Люди страдают гигантоманией и гугломанией где-то с середины 2000-ых годов: «мы сделаем всё так, как делает Google, ведь мы же строим один из крупнейших (в будущем) сервисов по обработке данных в мире!»

image

Сколько этажей в вашем датацентре? Google сейчас строит четырёхэтажные, как вот этот в Оклахоме.
Читать дальше →
Всего голосов 252: ↑249 и ↓3+246
Комментарии197

Шаблоны проектирования с человеческим лицом

Время на прочтение32 мин
Количество просмотров505K

image


Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.


Как сказано в Википедии:


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

image Будьте осторожны


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

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

Читать дальше →
Всего голосов 148: ↑134 и ↓14+120
Комментарии98

Ретроспектива разработки Crash Bandicoot, или как разработчики упаковывали целые игры в 2MB RAM

Время на прочтение3 мин
Количество просмотров76K
Вот вам анекдот из конца 90-ых. Я (Dave Baggett) был одним из двух программистов (вместе с Andy Gavin), разрабатывающих Crash Bandicoot для PlayStation 1.



Оперативная память была главной проблемой даже в те времена. У PS1 было всего 2MB RAM, и нам приходилось совершать безумные вещи, чтобы уместить в них игру. У нас были уровни, содержащие более 10MB чистых данных, и эти 10 мегабайт должны были постранично загружаться и выгружаться в память динамически, без каких-либо видимых задержек для игрока, при фреймрейте в 30 кадров в секунду.
Читать дальше →
Всего голосов 109: ↑107 и ↓2+105
Комментарии31

Создание API: в рамку и на стену

Время на прочтение5 мин
Количество просмотров57K
Каждый программист — проектировщик API. Хорошие программы состоят из модулей, а протокол взаимодействия модулей — это тоже API. Хорошие модули используются повторно.

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.

API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.

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

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.
Читать дальше →
Всего голосов 154: ↑143 и ↓11+132
Комментарии97

Шпаргалка по шаблонам проектирования

Время на прочтение2 мин
Количество просмотров1.4M

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

Читать дальше →
Всего голосов 192: ↑179 и ↓13+166
Комментарии66

Ближайшие события

27 августа – 7 октября
Премия digital-кейсов «Проксима»
МоскваОнлайн
20 – 22 сентября
BCI Hack Moscow
Москва
24 сентября
Конференция Fin.Bot 2024
МоскваОнлайн
24 сентября
Astra DevConf 2024
МоскваОнлайн
25 сентября
Конференция Yandex Scale 2024
МоскваОнлайн
28 – 29 сентября
Конференция E-CODE
МоскваОнлайн
28 сентября – 5 октября
О! Хакатон
Онлайн
30 сентября – 1 октября
Конференция фронтенд-разработчиков FrontendConf 2024
МоскваОнлайн
3 – 18 октября
Kokoc Hackathon 2024
Онлайн
7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн

Ущербно-ориентированное программирование

Время на прочтение6 мин
Количество просмотров88K
Ущербно-ориентированное программирование — это набор подходов, поощряющий повторное использование кода и гарантирующий долгосрочное использование производимого программистами кода в боевых системах. Количество строк кода является повсеместно применяемым показателем значимости приложения, а количество строк, которые программист пишет за рабочий день — полезная метрика, применяемая при планировании проектов и распределении ресурсов. Ущербно-ориентированное программирование — это один из наиболее эффективных способов получить наиболее объемный исходник в кратчайшие сроки.

Ущербный — имеющий изъян, неполноценный. Вредный, недостаточный.

Наследование


Наследование — это способ получить возможности старого кода в новом коде. Программист наследуется от существующей функции или блока кода, копируя этот кусок к себе и внося правки. Унаследованный код, как правило, конкретизируется под новые нужды с помощью возможностей, которые не поддерживал старый код. В таком смысле, старый код остается нетронутым, но новый наследуется от него.
Читать дальше →
Всего голосов 203: ↑174 и ↓29+145
Комментарии115

Темное программирование

Время на прочтение7 мин
Количество просмотров139K
imageПредлагаю перейти на сторону зла, на темную сторону программирования. Ситхи сильнее джедаев. И печенек хватит на всех. Предупреждаю, прежде чем начнете читать далее. Характер при переходе на темную сторону портится.
Прошу под кат
Читать дальше →
Всего голосов 257: ↑203 и ↓54+149
Комментарии212

Почему Pinball убрали из Windows Vista

Время на прочтение1 мин
Количество просмотров178K


Один из разработчиков Microsoft объяснил, почему замечательную игру Pinball не включили в состав Windows Vista. Ходили слухи, что это было сделано по юридическим причинам. Но нет, причины сугубо технические. Оказывается, Pinball просто не смогли портировать 64-битную платформу.
Читать дальше →
Всего голосов 222: ↑203 и ↓19+184
Комментарии174

Код CSS «с душком»

Время на прочтение8 мин
Количество просмотров107K
Недавно Крис Койер отвечал на вопросы читателей Smashing Magazine. Один из вопросов был о том, как распознать код CSS с «душком»:
Как можно определить, что ваш CSS пованивает? Какие признаки указывают на то, что код неоптимален или что разработчик писал его спустя рукава? На что вы смотрите в первую очередь, чтобы определить, плох или хорош код?

Я подумал, что могу расширить и дополнить ответ Криса исходя из собственного опыта.

Я работаю в BSkyB. Я делаю большие сайты — над последним из них я тружусь уже больше года. Плохой код CSS доставляет мне очень много проблем. Когда занимаешься одним сайтом месяцами, ты просто не можешь себе позволить плохой код, и его обязательно надо исправлять.

Я хочу поделиться несколькими вещами, на которые я обращаю внимание прежде всего, чтобы составить впечатление о качестве, сопровождаемости и чистоте кода CSS.
Читать дальше →
Всего голосов 165: ↑155 и ↓10+145
Комментарии131

Чем же занимаются программисты, и как объяснить это остальным?

Время на прочтение7 мин
Количество просмотров251K

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

Как рассказать им об этом, не пугая страшными терминами и фрагментами кода?
Под катом я воспроизведу такой рассказ, а также развенчаю несколько мифов о программировании.
Случай из жизни
Всего голосов 187: ↑156 и ↓31+125
Комментарии235

Три ключевых принципа ПО, которые вы должны понимать

Время на прочтение13 мин
Количество просмотров231K

Разрабатывая приложения, мы постоянно сталкиваемся с новыми подходами, языками и концептами. И постоянно мы мечемся в сомнениях «смогу ли я быть на волне, оставаться конкурентоспособным, учитывая все изменения и тренды?». Давайте задумаемся на мгновение, вспомнив фразу из моего любимого фильма «Касабланка» — в любви законов новых нет — так создан свет.

Все, что касается любви, применимо и к коду. Новых законов в коде нет. Если вы четко понимаете основные идеи разработки, вы способны максимально быстро адаптироваться к новым подходам. В этой статье я расскажу вам о трех основных принципах, которые, наряду с другими, позволяют регулировать сложность разработки. Я поделюсь своим видением вопроса, которое, надеюсь, поможет вам в повседневной работе.
Читать дальше →
Всего голосов 142: ↑128 и ↓14+114
Комментарии56

Жизнь без объектов

Время на прочтение5 мин
Количество просмотров21K
(Перевод)

Последние несколько лет я провел в изучении и экспериментах со многими языками программирования. В частности, я начал использовать Scala как основной язык, стараюсь использовать функциональный стиль везде где это возможно. Меня также весьма заинтересовал Haskell (чистый функциональный язык) и Clojure (современный диалект Лиспа).

Таким образом, я постепенно отказываюсь от объектно-ориентированной парадигмы, несмотря на то, что использовал в основном её последние 17 лет моей профессиональной деятельности. У меня появляется чувство, что объекты это то, что мешает нам писать лапидарный, структурированный и повторно используемый код.
Читать дальше →
Всего голосов 181: ↑160 и ↓21+139
Комментарии227
1