
Качество кода *
Как Макконнелл завещал
Подумайте дважды, прежде чем использовать игровые движки
Давайте рассуждать разумно
Я считаю, что не существует готового ответа на вопрос, стоит ли разработчику применять движок. Мудрый разработчик перед выбором технологии оценивает все возможные варианты.
Уровень навыков
Достаточно ли у вас навыков, чтобы эффективно использовать выбранный вариант? Если у вас нулевой опыт в программировании, то придётся многому научиться, прежде чем вы будете готовы создавать игру из набора разрозненных библиотек.
Если у вас нет ни технических навыков, ни интереса к их изучению, то вариантов и в самом деле нет — придётся работать с движком (или убедить кого-нибудь заняться технической частью за вас; удачи вам в этом!).
Есть промежуточное состояние между полным отсутствием навыков и профессиональным уровнем. В основном он находится в стране скриптовых языков: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D и т.д. Все они для тех, кто желает получить определённый уровень технических знаний, чтобы быстро достичь результатов.
Если вы опытный/профессиональный программист, способный уверенно освоить стороннее ПО, то можете воспользоваться этим навыком и решить, насколько минималистичным/максималистичным будет ваш подход (будет ли это исключительно минимальный SDL или же полностью оборудованный Unreal Engine).
Так все-таки RAML или OAS (Swagger)?

Чему я научился у ведущего программиста

Год назад я начал работать на полную ставку в Bloomberg. И тогда же задумал написать эту статью. Я думал, что буду полон идей, которые смогу выплеснуть на бумагу, когда придёт время. Но уже через месяц понял, что всё будет не так просто: я уже начал забывать то, чему научился. Либо знания настолько хорошо усвоились, что мой разум заставил меня поверить, будто я всегда это знал, либо они просто вылетели у меня из головы.1
Это одна из причин, по которой я начал вести дневник. Каждый день, попадая в интересные ситуации, я описывал их. И всё благодаря тому, что я сидел рядом с ведущим программистом. Я мог вблизи наблюдать за его работой, и видел, насколько она отличается от того, что сделал бы я. Мы много программировали вместе, что ещё больше облегчало мои наблюдения. Более того, в нашей команде не осуждается «подглядывание» за людьми, пишущими код. Когда мне казалось, что происходит что-то интересное, я поворачивался и смотрел. Благодаря постоянным вставаниям я всегда был в курсе происходящего.
Я год просидел рядом с ведущим программистом. Вот чему я научился.
Quintet data model и сотни гигабайт данных
Недавно мы протестировали подход, именуемый нами QDM, при работе с большими объемами данных — сотни гигабайт. В рамках задачи мы обрабатывали по 12-24 млн записей и сравнивали производительность квинтетного решения с аналогичным функционалом в обычных таблицах.
Мы не сделали каких-то новых открытий, но подтвердили те гипотезы, что озвучивали ранее: насколько всё таки универсальный конструктор в руках условного «чайника» проигрывает профессионально настроенной базе данных.
Также мы теперь знаем, что делать в подобной ситуации — решение достаточно простое и надежное, и имеем опыт организации компромиссного решения для сколько угодно больших данных.

Как я наводил порядок в проекте, где лес прямых рук (настройки tslint, prettier, etc)
И снова здравствуйте. На связи Омельницкий Сергей. Сегодня я поделюсь с Вами одной из своих головных болей, а именно — что делать, когда проект пишут много разноуровневых программистов на примере angular приложения.

Так повелось, что я долгое время работал только со своей командой, где мы уже давно согласовывали правила оформления, комментирования, отступы и т.п. Притерлись к ним и жили дружно и счастливо. На радостях я даже опубликовал статью на Хабр по нашему кодстайлу. Поэтому из чего-то магического мы использовали только tslint на пре-коммит.
И тут мы разрослись. Появился новый проект с унаследованным кодом, а к нему в придачу новые разработчики в размере 4-х добрых молодцев. И чет тут пошло не по плану.
Грязные хаки ассемблера 6502

Конкурсные работы публиковались в открытых твитах и личными сообщениями, которые содержали только байты PRG-файла и хэш MD5.
Разбираемся с интерфейсами в Go

В последние несколько месяцев я проводил исследование, в котором спрашивал людей, что им трудно понять в Go. И заметил, что в ответах регулярно упоминалась концепция интерфейсов. Go был первым языком с интерфейсами, который я использовал, и я помню, что в то время эта концепция казалась сильно запутанной. И в этом руководстве я хочу сделать вот что:
- Человеческим языком объяснить, что такое интерфейсы.
- Объяснить, чем они полезны и как вы можете использовать их в своём коде.
- Поговорить о том, что такое
interface{}(пустой интерфейс). - И пройтись по нескольким полезным типам интерфейсов, которые вы можете найти в стандартной библиотеке.
Типизируйте уже наконец свой код
Привет хабр!
На днях мне в очередной раз на глаза попал код вида
if(someParameter.Volatilities.IsEmpty())
{
// We have to report about the broken channels, however we could not differ it from just not started cold system.
// Therefore write this case into the logs and then in case of emergency IT Ops will able to gather the target line
Log.Info("Channel {0} is broken or was not started yet", someParameter.Key)
}В коде есть одна довольно важная особенность: получателю крайне хотелось бы знать, что произошло на самом деле. Ведь в одном случае у нас проблемы с работой системой, а в другом — мы просто прогреваемся. Однако модель не дает нам этого (в угоду отправителю, который зачастую является автором модели).
Более того, даже факт "возможно, что-то не так" происходит из того, что коллекция Volatilities пуста. Что в некоторых случаях может быть и корректно.
Я уверен, что большинство опытных разработчиков встречало в коде строки, в которых заключалось тайное знание в стиле "если выставлена эта комбинация флажков, то от нас просят сделать A, B и C" (хотя по самой модели этого не видно).
С моей точки зрения, подобная экономия на структуре классов сказывается крайне негативно на проекте в будущем, превращая его в набор хаков и костылей, постепенно трансформируя более-менее удобный код в legacy.
Важно: в статье я привожу примеры, которые полезны для проектов, в которых несколько разработчиков (а не один), плюс которые будут обновляться и расширяться в течении хотя бы 5-10 лет. Всё это не имеет смысла, если в проекте один разработчик лет на пять, или же если после релиза никаких изменений не планируется. И логично, если проект необходим всего на пару месяцев, нет смысла вкладываться в четкую модель данных.
Однако если же вы занимаетесь долгоиграющим — добро пожаловать под кат.
Трюк с тригонометрией
Скорее всего, вам известны следующие соотношения еще со школы:
Когда вы в детстве впервые познакомились с этой формулой, скорее всего, вашим первым чувством была боль из-за того, что эту формулу надо запомнить. Это очень плохо, потому что на самом деле вам не нужно запоминать эту формулу — она сама выводится, когда вы поворачиваете треугольник на бумаге. На самом деле, я делаю то же самое, когда записываю эту формулу. Это толкование будет очевидным к середине этой статьи. Но сейчас, чтобы оставить все веселье на потом и отодвинуть момент, когда вы скажете "Эврика!", давайте подумаем, а зачем нам вообще задумываться об этой формуле.

Избегаем тригонометрии
Вступление
Мне кажется, что нам надо использовать меньше тригонометрии в компьютерной графике. Хорошее понимание проекций, отражений и векторных операций (как в истинном значении скалярного (dot) и векторного (cross) произведений векторов) обычно приходит с растущим чувством беспокойства при использовании тригонометрии. Точнее, я считаю, что тригонометрия хороша для ввода данных в алгоритм (для понятия углов это интуитивно понятный способ измерения ориентации), я чувствую, что что-то не так, когда вижу тригонометрию, находящуюся в глубинах какого-нибудь алгоритма 3D-рендеринга. На самом деле, я думаю, что где-то умирает котенок, когда туда закрадывается тригонометрия. И я не так беспокоюсь о скорости или точности, но с концептуальной элегантностью я считаю… Сейчас объясню.
Статический анализ улучшит кодовую базу сложных C++ проектов

Постепенно и незаметно складывается ситуация, когда сложность серьёзных C++ проектов становится запредельной. К сожалению, теперь C++ программист не может полагаться только на свои силы.
Blameless environment: никто не должен писать качественный код
Работали ли вы когда-нибудь на плохой работе?
Я работал и долго. Моя компания была ужасна. Все было очень плохо, за что ни возьмись — все из рук вон. У нас были отвратительные процессы, ненавистные клиенты и неумелые разработчики. С этим ничего нельзя было поделать. Когда все так плохо, просто не знаешь, за что взяться, с чего начать. Чувствуешь себя жалким винтиком, который не может ни на что влиять.

Когда я говорю, все плохо, я имею в виду, что у нас был:
- плохой код — никто не думал о качестве кода, никто не мог даже сформулировать, что такое качество кода.
- плохие процессы.
- мы не могли нормально общаться,
- мы не делали то, что хотел клиент.
Да, это была аутсорс-разработка, но не это делало её плохой. Люди сделали ее такой.
Ближайшие события
5 заповедей TypeScript-разработчика

Всё больше и больше проектов и команд используют TypeScript. Однако просто применять TypeScript и выжимать из него максимум пользы — это очень разные вещи.
Представляю вам список высокоуровневых передовых практик использования TypeScript, которые помогут получить максимум преимуществ от применения этого языка.
Управление зависимостями в Python: сравнение подходов

Я пишу на питоне лет пять, из них последние три года — развиваю собственный проект. Большую часть этого пути мне помогает в этом моя команда. И с каждым релизом, с каждой новой фичей у нас все больше усилий уходит на то, чтобы проект не превращался в месиво из неподдерживаемого кода; мы боремся с циклическими импортами, взаимными зависимостями, выделяем переиспользуемые модули, перестраиваем структуру.
К сожалению, в Python-сообществе нет универсального понятия «хорошей архитектуры», есть только понятие «питоничности», поэтому архитектуру приходится придумывать самим. Под катом — лонгрид с размышлениями об архитектуре и в первую очередь — об управлении зависимостями применимо к Python.
В анализаторе все должно быть прекрасно: и функциональность, и интерфейс… Изучаем новый интерфейс Solar appScreener 3.1
Как говаривал Генри Форд, все можно сделать лучше, чем делалось до сих пор. Вот и мы так подумали, когда приступили к работе над версией 3.1 нашего анализатора защищенности приложений. Нам ОООЧЕНЬ хотелось сделать наш продукт не только самым крутым по функциональности: например, реализовать поддержку максимального количества языков программирования. Но и наиболее эргономичным, удобным, эстетически привлекательным… – ну чтобы прям глаз не оторвать! И так мы увлеклись своей задумкой, что даже название продукту поменяли. В общем, выложились по полной. А результатами своих усилий решили поделиться с вами в этом обзоре.Черновик FAQ: Почему стандарты С++ выходят каждые три года?

У WG21 есть строгий график (см. P1000) выпуска стандарта каждые три года. И никаких задержек.
В течение каждого цикла мы регулярно получаем вопросы «ну почему так строго?», особенно от новых участников комитета, которые не знакомы с его историей и причинами текущего положения вещей. И во время предварительной телеконференции с администрацией Кёльна несколько человек порекомендовали описать, почему мы так делаем и как принималось решение о принятии этого графика.
Всё это я расписал в виде вопросов и ответов для следующего черновика Р1000, и разослал копию участникам комитета, направлявшимся в Кёльн. Этот материал будет опубликован в следующей публичной версии Р1000, её мы разошлём через несколько недель начиная с текущего момента.
Однако и черновик FAQ может быть интересен публике, поэтому предлагаю вашему вниманию его копию. Надеюсь, он будет для вас по большей части полезен, в чём-то просветит, и, возможно, даже немного развлечёт.
С++, определен ли тип: предварительное декларирование нужных объектов
if constexpr и универсальными лямбда-выражениями, чтобы код мог использовать тип, если он определен, при этом все еще принимаясь компилятором (и отбрасываясь) если тип не определен.Однако в этом применении существует несколько проблем:
- Каждый раз нужно писать
struct. - Если тип не существует, то при присвоении ему имени этот тип вводится в текущее пространство имен, а не в пространство имен, в котором вы хотели, чтобы тип был.
- Нужно использовать
structс неквалифицированным именем. Нельзя использовать его для проверки типа, который вы не импортировали в текущее пространство имен.
Мы можем исправить все три проблемы с помощью одного решения: предварительно объявить тип в нужном пространстве имен.

TDDx2, BDD, DDD, FDD, MDD и PDD, или все, что вы хотите узнать о Driven Development
Просматривая статьи по проектированию ПО, я постоянно встречал тучу невиданных сокращений и вскользь упоминаемых практик разработки.

- TDD — ну, это все знают, сначала пишем тесты, а потом остальной код.
- BDD — что-то знакомое, вроде как, тоже тесты, но особенные.
- TDD — снова? Так, стоп, тут речь уже не о тестах совсем. Но почему называется так же?
- DDD — bound contexts, ubiquitous language, domain...
- FDD — да сколько можно?
- MDD — cерьезно, на основе диаграмм?
- PDD — ...
Подходы к разработке делятся по сложности, областям применения и целям.
Думаю, настало время разобраться, зачем же они нужны, почему их так много, и как они могут быть нам полезны.
Мы начнем знакомиться с ними от самых простых до довольно сложных, рассмотрим примеры использования и плюсы и минусы каждого из них.
Custom refactoring tool: Swift

Что делает инженер, когда необходимый инструмент отсутствует? Верно, сделает всё сам! Ранее мы уже рассказывали о создании своих кастомных инструментов, теперь поговорим о том, как модифицировать Xcode и заставить его работать по твоим правилам.