https://300.ya.ru/v_yW8gmDY6/
• Обсуждение выбора между сохранением обратной совместимости и ломанием стандарта. • Представление ведущих подкаста: Егор Толстой и Катя Петрова. • Введение гостя: Сев Толстопят, главный за библиотеки в команде Kotlin.
fun• Сев рассказывает о создании функции fun.
• Обсуждение её популярности и восприятия среди программистов.
• История о том, как функция стала популярной и почему.
• Сев рассказывает о своём пути в Kotlin. • Описание его работы над библиотеками и фреймворками. • Принципы и подходы к разработке библиотек.
• Цель выпуска: помочь разработчикам библиотек. • Обсуждение границ и подходов к дизайну библиотек. • Переход к теоретической части выпуска.
• История создания библиотек Моррисом Вилкисом. • Описание первых библиотек и их функций. • Важность обратной совместимости и абстракций.
• Обсуждение абстракций и их роли в программировании. • Примеры абстракций в различных областях, таких как консольные утилиты и ассемблер. • Абстракции как клей между слоями компьютера.
• В прошлом было много разных вендоров, каждый из которых предлагал свои расширения и функции. • Это создавало неудобства, так как пользователи были привязаны к конкретным производителям и операционным системам. • Американская военка решила проблему, создав стандарт POSIX, который стал обязательным для всех вендоров.
• Большие вендоры могли полностью соответствовать стандарту, но не имели способа удержать клиентов. • Разработчики, такие как создатели C, осознали необходимость общего языка для общения с операционной системой. • Это привело к созданию Lisp, который стал важным инструментом для разработчиков.
• Обратная совместимость является одной из главных проблем в дизайне библиотек. • Пример с Windows и переносом строки показывает, как старые ограничения могут влиять на новые системы. • Примеры с POSIX и C показывают, как старые ограничения могут сохраняться в новых системах.
• Наследие старых систем может создавать проблемы для новых разработчиков. • Пример с функцией rm в Unix показывает, как старые ограничения могут мешать новым разработкам. • Обратная совместимость требует осторожного подхода, чтобы не создавать новых проблем.
• Apple иногда ломает обратную совместимость, чтобы улучшить экосистему. • Некоторые языки программирования и фреймворки выпускают новые версии, решая старые проблемы. • Однако, по-настоящему успешно избавиться от наследия старых систем практически невозможно.
• Дизайнеры должны сохранять обратную совместимость, чтобы не создавать больших издержек для пользователей. • Если проблемы с обратной совместимостью становятся критическими, можно добавить новый слой или суффикс для совместимости. • В большинстве случаев лучше не ломать обратную совместимость, чтобы избежать проблем в будущем.
• Пример с библиотекой OpenCV, которая использует RGB вместо HBR для работы с пикселями. • История с оператором scan в Kotlin, который был переименован после критики пользователей. • Проблема с поиском авторов, ответственных за название оператора.
• Обратная совместимость как одна из самых сложных задач в дизайне и разработке. • Пример с проблемой двухтысячного года, когда изменение номера года могло сломать множество систем. • Разработка и поддержка ипя сталкиваются с конфликтом с обычными методами написания кода.
• Технический долг как полезная концепция, если он приносит больше пользы, чем затрат. • Проблемы с быстрым программированием и выкатыванием новых функций. • Инкрементальная сложность и невозможность переписать или заменить ипя.
• Идея semantic versioning для управления совместимостью илом. • Разделение версий на маленькие, средние и большие, чтобы минимизировать разрушения при изменениях.
• Семантическое версионирование включает три компонента: патч-версии, минорные версии и мажорные версии. • Мажорные версии могут ломать, что вызывает недовольство пользователей. • Примеры: переход на Python 3 и Scala 2.11.
• Мажорные версии могут ломать экосистему, построенную поверх языка программирования. • Переход на Python 3 занял около десяти лет и значительные ресурсы. • Любое семантическое изменение может быть ломающим.
• Программисты часто зависят от недокументированных свойств системы. • Пример: изменение поведения клавиши пробела в Windows. • Даже мелкие изменения могут вызвать проблемы у пользователей.
• Пример из Google: ускорение сортировки в C++. • Даже незначительные изменения могут вызвать зависимости, которые сложно изменить. • Программирование требует творческого подхода и внимания к деталям.
• Семантическое версионирование не является идеальным решением. • Патч-версии добавляют нестабильные изменения и баги. • Важно, чтобы пользователи не зависели от конкретных версий.
• В реальном мире производители заменяют сломанные продукты по гарантии. • В программировании пользователи должны быть ответственны за свои зависимости. • Разработчики должны использовать документированные контракты.
• Программисты плохо оценивают вероятность маловероятных событий. • Пример: изменение времени на сервере может вызвать проблемы в программе. • Важно учитывать все возможные сценарии.
• Человеческий язык сложен и неоднозначен, что влияет на программирование. • Пример: парсинг чисел из строки в Unicode. • Важно четко формулировать требования и ожидания.
• Вопрос о критериях хорошего дизайна остается открытым. • Важно учитывать, что люди могут интерпретировать требования по-разному. • Примеры из реальной жизни и программирования показывают сложность формулировок.
• Люди по-разному реагируют на искусство, активируя разные участки мозга. • Хорошее искусство вызывает желание съесть, а не убежать. • Хороший продукт, как и хорошее искусство, должен быть интуитивно понятным и легко используемым.
• Люди являются главной проблемой в программировании. • Пример с раскрашиванием контурных карт на экране, где возникли вопросы о статусе Тайваня как страны. • Разные вендоры по-разному работают с флагами стран, что создает сложности.
• Пример с тайм-зоной в Египте, где политические события изменили переход на летнее время. • Пример с Японией, где смена императора потребовала обновления программного обеспечения.
• Создание хорошего API требует компромиссов и может привести к недовольству через годы. • Важно определить абстракцию и избегать иллюзий. • Пример с NFS, который оказался неэффективным из-за проблем с частичными отказами.
• Пример с Linux, где все данные хранятся в файлах, что создает проблемы с чтением и записью. • Важно учитывать, что данные могут меняться, и это влияет на корректность чтения. • Абстракции должны быть выбраны с учетом их удобства и применимости для различных случаев.
• Важно определить, какие пользовательские проблемы будет решать библиотека. • Библиотека должна абстрагировать нетривиальную функциональность. • Примеры: удобные хелперы для строк или программный интерфейс для работы с датой и временем.
• Пример хорошей абстракции: библиотека Time в Kotlin. • Важно учитывать обратную совместимость и давать пользователям понятные пути миграции.
• Общие советы: внимательно изучить домен и задачи, которые решает библиотека. • Конкретные советы: начать с документации и спецификации, писать нетривиальные программы для выявления проблем.
• Документация должна быть понятной и не перегруженной информацией. • Пользователи часто не читают документацию, но она важна для понимания библиотеки.
• Каждая абстракция должна делать одну вещь хорошо. • Пример: класс File в Java, который выполняет много задач, что усложняет его использование.
• Если текущая библиотека не удовлетворяет требованиям, лучше создать новую. • Важно учитывать обратную совместимость и существующие ответы на Stack Overflow.
• Важно знать экосистему языка программирования или инструментов. • Пользователи предпочитают консистентность, поэтому стоит следовать общепринятым практикам.
• Выбор правильных названий для API и функций – сложная задача. • Важно не расстраиваться, если не удается сразу найти идеальное название.
• Название должно отражать суть абстракции. • Важно писать документацию, чтобы пользователи понимали, что это за штука. • Не стоит придумывать новые названия, лучше использовать общепринятые.
• Важно использовать опыт соседних языков программирования. • Операторы сравнения и проверки типов могут быть реализованы по-разному в разных языках. • Важно понимать, почему и как реализованы функции в других языках.
• Важно спрашивать пользователей о их потребностях и игнорировать их ответы. • Начинать дизайн с понимания конечных задач пользователей. • Обозревать существующие решения и писать дизайн-документы.
• Имплементация может быть менее важной на ранних этапах. • В некоторых случаях можно игнорировать имплементацию для быстрого принятия решений. • В других случаях производительность зависит от имплементации, и её нельзя изменить после релиза.
• Экспериментальные версии помогают собирать фидбек и исправлять ошибки. • Важно поддерживать обратную совместимость, особенно на поздних этапах. • Ломающие изменения должны быть агрегированы и сопровождаться миграционными путями.
• Миграционные гайды важны для нетривиальных миграций. • Документация не всегда помогает, поэтому гайды необходимы для понимания, что делать дальше. • Чем больше контроля над миграциями, тем лучше.
• Генерация кода с помощью нейросетей меняет парадигму разработки. • Документация с примерами кода становится важным датасетом для обучения языковых моделей. • Примеры кода помогают моделям лучше понимать, как использовать задокументированные функции.
• Обязательно пишите документацию для всех аспектов библиотеки. • Убедитесь, что код соответствует экосистеме и общепринятым практикам. • Проверяйте, что функции выполняют заявленные действия и задокументированы все ошибки.
• Описывайте детали реализации, если это важно для пользователей. • Если библиотека хранит настройки в мобильных приложениях, опишите формат хранения.
• Деприкетинг библиотек может быть необходим для обновления экосистемы. • Причины деприкетинга: появление новых, более прогрессивных функций, уязвимости в коде. • Деприкетинг помогает пользователям избежать уязвимостей и поддерживает экосистему.
• Если обнаружена уязвимость, проконсультируйтесь с безопасниками и следуйте их рекомендациям. • Не публикуйте уязвимости без консультации, чтобы избежать юридических проблем. • В крупных проектах есть правила работы с уязвимостями, которые нужно соблюдать.
• Авторы библиотек должны следовать правилам безопасности и лицензиям. • Используйте существующие политики безопасности и лицензии компании. • Не придумывайте свои правила, если это не предусмотрено компанией.
• Обсуждение ошибок в именовании функций в стандартной библиотеке Kotlin. • Пример функции “фест”, которая возвращает элемент или исключение. • Ошибка в именовании “рекогнишин” вместо “прикол” привела к длительным исправлениям и проблемам для пользователей.
• Трудности с иерархией контекстов в Kotlin. • Решение проблемы через лексические скопы, предложенное Нейтаном. • Ошибка в названии сущности “контекст”, что вызывает путаницу у пользователей.
• Подведение итогов выпуска и обсуждение исторических проблем. • Важность правильного выстраивания ожиданий и подготовки к худшему. • Рекомендации по созданию качественных библиотек и советы для разработчиков.
• Благодарность слушателям за участие и поддержку. • Призыв делиться подкастом и оставлять отзывы. • Важность просмотра выпусков на YouTube для увеличения охвата и вовлеченности.