Рубрика «код» - 4

Иногда бывает так:
— Приезжайте, у нас упало. Если сейчас не поднять — покажут по телевизору.
И мы едем. Ночью. На другой край страны.

Примеры дичи из заказов «приходите спасать» (разбор десятка инцидентов с примерами) - 1
Ситуация, когда не повезло: на графике показан резкий рост нагрузки на СУБД. Очень часто это первое, на что смотрят администраторы системы и это первый признак того, что наступила жопа

Но чаще речь идёт про какие-то типовые вещи. Например, заказчик столкнулся с низкой производительностью системы документооборота. По понедельникам и вторникам система падала, они перезагружали сервер, и потом всё поднималось. Захлёбывалась база данных. Хотели докупить оборудования (что долго и дорого), позвали нас просчитать смету. Мы им посчитали смету и заодно предложили разобраться, что же именно тормозит. За три-четыре часа локализовали источник проблемы. Выяснили, что это медленные запросы в базу данных и неоптимальные схемы индексирования. Создали недостающие индексы, поковырялись с оптимизатором запросов в Оракле, некоторые проблемы потребовали изменения кода — поменяли условия поиска (без изменения функциональности), заменили часть запросов на использование предрассчитанных представлений. Если бы у них был нормальный человек по БД — могли бы сделать то же и сами. Но вместо нормального человека был аудит базы данных раз в полгода крутыми ораклистами — они выдавали общие рекомендации по настройкам и железу.Читать полностью »

Перед вами перевод статьи из блога Better Programming на сайте Medium. В ней программист Daan делится простыми правилами, следуя которым вы сможете давать хорошие имена функциям и переменным.

Как придумывать содержательные имена для вашего кода - 1

Будучи разработчиком, вы наверняка тратите много времени на создание переменных и придумывание их имен. Имена повсюду: они нужны для файлов, классов, методов и тех самых переменных.

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

Аксель Ритчин (Axel Rietschin), инженер ядра в Microsoft, обвинил создателей ReactOS, открытой операционной системы, совместимой с Windows, в копировании кода Windows Research Kernel.

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

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

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

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

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

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

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

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

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

Главный навык разработчика, который сделает ваш код лучше - 1

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

Сказать «нет» лишнему коду. Все, что вы должны сделать, — собрать вместе три буквы и произнести это слово. Давайте попробуем сделать это вместе: «Неееееет!»

Но погодите. Зачем мы это делаем? Ведь основная задача программиста — писать код. Но нужно ли писать любой код, который от вас требуют? Нет! «Понимание того, когда не стоит писать код, вероятно, важнейший скилл для программиста». The Art Of Readable Code.
Читать полностью »

arkit (швед. arkitektur)

Дамы и господа, представляю вашему вниманию arkit — инструмент, который анализирует файлы вашего проекта и генерирует диаграмму зависимостей между ними и внешними модулями. Наверное, проще показать на примере самого arkit:

архитектурная диаграмма
Читать полностью »

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

image

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

Улучшаем внешний вид

1. Material Theme & Icons

Это прямо зверь в темах VS Code. Я думаю, что материальная тема наиболее близка к написанию ручкой на бумаге в редакторе (особенно при использовании неконтрастной темы). Ваш редактор выглядит практически гладко, переходя от встроенных инструментов к текстовому редактору.

Представьте себе эпическую тему в сочетании с эпическими иконами. Material Theme Icons — отличная альтернатива для замены значков VSCode по умолчанию. Большой каталог иконок плавно вписывается в тему, делая ее красивее. Это поможет легко найти файлы в проводнике.

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

На Pixonic DevGAMM Talks выступал еще наш DTO Антон Григорьев. Мы в компании уже говорили, что работаем над новым PvP-шутером и Антон поделился некоторыми нюансами архитектуры этого проекта. Он рассказал, как построить разработку, чтобы изменения в игровой логике клиента появлялись на сервере автоматически (и наоборот), и можно ли не писать код, но при этом минимизировать трафик. Ниже — запись и расшифровка доклада.

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

Следующий доклад с Pixonic DevGAMM Talks, который мы расшифровали, немного философский — это выступление Константина Гладышева. Он Lead Game Programmer в 1C Game Studios и рассказывал о принципе управления сложностью разработки в контексте всего продукта, а не отдельных фичей. И на примерах показал, почему главное в разработке — это определить, чего делать не надо. Про другие доклады можно почитать по ссылкам в конце статьи.

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


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