TGTGInsightтелеграм анализLIVE / telegram public index
← Такты, стеки, два колеса

TGINSIGHT SIMILAR POSTS

Намери подобно съдържание

Изходен канал @clockstackwheels · Post #721 · 26.12

Почему я люблю языки с сильной системой типов, проверяемой статическим анализом кода — хорошо написанная программа является своей собственной спецификацией и позволяет выражать через язык программирования законы существования предметной области. Когда-то давно я писал на ActionScript. Там была система типов, но вот десериализация JSON'ов по-умолчанию была в какой-то общий Object, к полям которого нужно было обращаться ["по_строковому_имени"]. В один момент мне потребовалось написать что-то на C#, который я совсем не знал, я стал гуглить, как десериализовать JSON, и с удивлением обнаружил кучу советов заранее объявить класс со всеми нужными полями и десериализовать в него. "Какой ужас!", — подумал я тогда, — "Это же дико неудобно! А если я не знаю полей JSON? А если их много? Отвратительный язык!" Теперь то я прекрасно понимаю, что JSON это контракт, и что правильная десериализация только такая и должна быть, и что в хорошем API в одном поле никогда не бывает данных принципиально разных типов, и так далее. Нет, если вы набиваете вечерами пет-проект или сидите бессонную ночь на хакатоне, нет ничего плохого в том, чтобы взять простой язык с динамическими типами вроде JavaScript или Python, не требующий описывать данные. Но вот в энтерпрайзе, особенно когда над одним проектом работает много людей (а бывает это очень часто) — хорошее использование системы типов убережёт разработчиков от огромного количества ошибок, будет бить их по рукам, когда они пытаются сделать что-то не то, и будет подсказывать, когда они не уверены в чём-то. С помощью статической типизации можно на уровне кода обозначить правила, по которым ведёт себя предметная область вашей программы в реальном мире. Разработчику не только будет сложно их нарушить, но он ещё и станет узнавать какие-то вещи, которые мог не знать раньше. Например, если мы делаем медицинскую CRM, и больница заводит новых пациентов только тогда, когда знает их группу крови, мы можем объявить тип "Пациент" (или, если точнее, "Карта пациента") и запретить создавать экземпляры этого типа, не передав в конструктор группу крови (которая, в свою очередь, тоже является типом, вероятнее всего ValueObject'ом). Если новый программист пришёл в проект, он, во-первых, не сможет записать в БД некорректную карту пациента. Понятно, мы не учитываем случаи, когда новый программист переделывает модели предметной области — это будет хорошо видно на кодревью. А, во-вторых, даже если ему никто не сказал, что пациенты должны быть с группой крови, он узнает это из кода. И уже будет понимать, что в тех процессах реальной жизни, которые он описывает кодом, карта пациента создаётся только при наличии группы крови. А, значит, нужно искать какой-то способ сначала эту группу крови получить, и только потом создавать карту. Программирование моделирует реальный процесс. В настоящей работе даже на языках с типами, конечно, без должного контроля можно написать что угодно. Нужна управленческая воля, компетентность руководства, понимание опасности техдолга, в идеале отдельные должности для архитекторов, опытные лиды и старшие разработчики. Но когда всё это есть, можно отсекать много проблем ещё на старте и проще погружать новичков. #dev

Hashtags

Резултати

Намерени 3 подобни публикации

Търсене: #dotnext

当前筛选 #dotnext清除筛选

Сегодня целый день был на офлайн-части конференции #DotNext для разработчиков под платформу .NET. Посетил две лекции, два круглых стола (это такое обсуждение несколькими экспертами на сцене, как подкаст, но вживую), поучаствовал во всех активностях, позадавал вопросы и обсудил со спикерами и другими участниками ряд проблем. Вроде всё на месте, но я понял вот что: для меня было мало точек приложения внимания в ширину, однако избыток приложения внимания в глубину. Возможно, я сам себя не слишком правильно настроил. Лето, жара, скоро отпуск: кажется, я ошибочно ожидал чего-то более казуального от мероприятия. Могу сказать, что в своё время посещение TechTrain принесло мне суммарно больше удовольствия, хотя там билеты на порядок дешевле, и выставка в целом более лёгкая и менее тематическая. Здесь же было хорошее глубокое погружение в тему, но горизонтально мне не хватило разнообразия: мало стендов (два), мало пространства по выбору лекций (в каждый момент шло две лекции в двух залах, выбор всегда из двух). На стенде от PVS-Studio поискал ошибки в коде, получил много мерча, прикольного. Но сама система у ребят только корпоративная, индивидуальных лицензий нет, а я возможно даже попробовал бы. Второй стенд от Промсвязьбанка предлагал телеграм-бота с разными заданиями. Я, кстати, Промсвязьбанку писал недавно квиз на Хабр. Они активно хантят народ. Задания были нормальные: там и коммуникация с другими участниками, и ответы на вопросы, и всякое решение задачек. Но разрыв по очкам между точками получения призов такой большой, что всю вторую половину игры я буквально вёл впустую. Из минусов организации отмечу два момента: 1. Офлайн-участников было не очень много, а онлайн-участников существенно больше. Поэтому даже офлайн-участникам предлагалось задавать вопросы спикерам с помощью чатов в Телеграме. Это не только создавало миллион чатов (по каждому докладу свой чат, потому что Телега не умеет в комнаты), но и было неудобно в процессе — ссылка на чат показывалась только в самом начале доклада, если не успел, а вопрос возник по ходу лекции, то найти ссылку проблематично. И вообще, я считаю, что правильно было бы дискриминировать онлайн-участников. Они меньше заплатили за билет, они поленились приехать. Но их удобство в итоге было приоритетным над удобством офлайн-участников просто из-за количества. 2. Дискуссии пересекались по времени с другими лекциями и с обедом. В итоге нельзя было полноценно пообсуждать что-то со спикером, не опоздав куда-то дальше. А на обед я вообще попал тогда, когда почти всё уже съели. За счёт работодателя бы ездил с удовольствием, но за личные деньги, пожалуй, не моё. #dev

Hashtags

Второй онлайн-день #DotNext закончился. В числе прочего был интересный разговор на тему «Страх и ненависть в Open Source», но я вам о некоторых особо заметных случаях рассказывал уже вот тут и тут. Ещё послушал про обратное соединение распиленного монолита (бывает, что и такое нужно!) и ещё пару докладов. В целом, впечатления противоречивые. Опишу кратко. Плюсы: 1. Высочайшего качества техническая организация. Ничего не глючило, чистая картинка и звук, удобный UI. 2. Были полезные и практичные вещи, интересные. 3. Реально отвечали на вопросы в чате в реалтайм-режиме. Что прошло ниже моих ожиданий (я впервые на такой дорогой IT-конференции): 1. Наверное, подсознательно я ожидал что с учётом цены билета буквально каждый доклад будет супер звёздным уровня "Торвальдс лично рассказывает подробности устройства ядра Linux, и делает это с шутками и котиками". Но доклады в среднем довольно обычные. Некоторые поверхностные, другие на очень далёкую от меня тему. И ещё их не очень много, не то, чтоб был гигантский выбор. Хотя, справедливости ради, больше 2-3 лекций в день тяжело осилить. 2. Интерактивные фишки формально заявлены: виртуальные стенды и квизы. По факту, во-первых, стенды и квизы полностью повторяют друг друга, во-вторых, их было всего два, и интересный (на мой личный взгляд) только один. Я ожидал, что их хотя бы десяток будет. 3. Часть обсуждения в Telegram, часть прямо в онлайн-чате лекции, и это, на мой взгляд, не пошло на пользу. Мне не хотелось вступать в Telegram-чат, но активность в основном чате лекции была низкой, при этом с телефона такой чат вообще не подразумевался. Я для себя убедился, что всё-таки именно мне в таких мероприятиях важна офлайновость: прийти и вживую потусить, получить мерч, поучаствовать в активностях. Чисто в онлайн-формате сугубо на мой взгляд мероприятие себя не окупает. Посмотрим, что будет в офлайне 27-го числа, напишу вам отзыв. #dev

Hashtags

Сегодня был первый день конференции #DotNext, пока в онлайне (но офлайн тоже будет, в Петербурге 27-го июня, я пойду). Конференция для разработчиков на .NET, в первую очередь C# и связанные технологии. Особенно понравилась лекция про историю C#. Вот ниже схема, где стрелками обозначено влияние одного языка на другой в некоторых аспектах (хотя не во всех: например, Kotlin тоже взаимно повлиял на C#, скажем, датаклассы из него заимствованы, в C# это тип record). Ещё я не знал, что C# создал Андерс Хейлсберг — тот самый, который в своё время сделал Delphi. Это удивительно. Я когда-то начинал свой путь разработки именно с Delphi, сделал на нём много первых шагов. А теперь вот пишу на C# от того же автора, круг замкнулся. Ещё Хейлсберг один из авторов TypeScript: в общем, умеет мужик в языки! В ходе этой лекции было любопытно узнать или вспомнить, как всё-таки плохо во многих других языках с удобством совершенно типовых действий, начиная от обобщённого программирования и заканчивая ленивой обработкой или генерацией бесконечных множеств. Понятно, что человек ко всему привыкает, но переходить на другой язык после C# было бы болезненно, мне кажется. По крайней мере, для энтерпрайз разработки, где важна архитектура и статический анализ. Завтра второй онлайн-день, посмотрим, что будет там.#dev

Hashtags