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

Резултати

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

Търсене: #latinime

当前筛选 #latinime清除筛选

🇷🇺ИНТЕГРАЦИЯ НАШИХ ЯЗЫКОВ В ANDROID: РАСЧЕТ МАСШТАБА Включение Тувинской клавиатуры в AOSP (Android Open Source Project) демонстрирует возможность расширения языковой поддержки Android. Сейчас, когда Тувинская раскладка находится на этапе финального утверждения, необходимо оценить, какой ресурс потребуется для дальнейшего масштабирования — например, для 120 языков, использующих схожий принцип кириллической основы. * Оценка Ресурсов (в Байтах и Строках) Базируясь на фактическом объеме данных Тувинской клавиатуры (36 букв) и с учетом запаса на более сложные алфавиты, мы принимаем средний показатель в 25 КБ на один язык. При масштабировании на 120 языков, это дает следующие результаты: | Показатель | Объем на 1 Язык | Общий Объем для 120 Языков | | Объем данных (для AOSP) | 25 КБ | 3.0 Мегабайта | | Объем кода (добавленные строки) | ≈ 324 строки | ≈ 39 000 строк | | Количество файлов (XML-раскладки) | ≈ 6 файлов | ≈ 720 файлов | Вывод: Общий объем данных составляет всего 3 МБ! С технической точки зрения, такой размер не представляет проблемы для кодовой базы Android. Основная сложность заключается в лингвистической и логистической работе. * Ключевые Аспекты Работы с AOSP Вклад такого масштаба требует строгого подхода к организации процесса: 1. Проектирование Раскладок: Необходимо обеспечить унифицированное и эргономичное размещение уникальных символов (например, их расположение на менее используемых Русских клавишах, как это было сделано для Тувинского языка) для всех 120 алфавитов. 2. Проверка Качества (QA): Каждый из 720 файлов требует проверки на соответствие стандартам кодирования и корректность ввода символов. Этот процесс критически важен для принятия кода. 3. Стратегия Code Review: Для ускорения процесса интеграции через Gerrit, проект необходимо разделить на 20-30 управляемых Pull Request-ов. Это позволит ревьюерам AOSP проводить проверку поэтапно и снизит время ожидания. Резюме: Задача по интеграции 120 языков требует значительной организационной и лингвистической работы, но является технически реализуемой. Этот вклад напрямую обеспечивает доступность родного языка для миллионов пользователей Android. #AOSP#Android#ЯзыковаяПоддержка#LatinIME#OpenSource#Разработка

Раскладка Тувинского языка добавлена в AOSP (Android Open Source Project) Рад сообщить о важном этапе в развитии поддержки языков в Android: Патч, добавляющий раскладку Тувинского языка (Tuvan) в компонент системной клавиатуры LatinIME, был официально объединен (merged) во внутреннюю кодовую базу Android Open Source Project (AOSP). Теперь буду по вашим клавиатурам делать то же самое. Давайте сделаем это совместно – присылайте свои клавиатуры! Изменение получило все необходимые технические (Code-Review) и лицензионные (Open-Source-Licensing) подтверждения от инженеров, курирующих AOSP. Изменение внутренне слито (merged) и готовится к релизу. Что это значит для пользователей: Носители Тувинского языка вскоре получат корректную и удобную раскладку клавиатуры, интегрированную в стандартные средства ввода Android. Даты релиза: Точные сроки выпуска публичного обновления зависят от цикла релиза Android и поставщиков устройств, но, как правило, объединенные изменения появляются в ближайших крупных или ежеквартальных системных обновлениях AOSP. P.S.: В ближайшее время планируется отправка других вариантов Тувинской клавиатуры, чтобы обеспечить максимально разнообразное и удобное использование языка на устройствах Android. #AOSP#Android#LatinIME#ТувинскийЯзык#Tuvan#OpenSource#Разработка