Почему нужно читать исходный код инструментов Малиновский Дмитрий

Студент 5 курса ОмГУ, ИМИТ DevOps Engineer в Thumbtack

Идеальный код? •  Проектирование •  Документирование (sphinx, readthedocs) •  Статические анализаторы (flake8) •  Анализаторы цикломатической сложности (radon) •  Автоматические проверки (git hooks, :w, etc.) •  Тестирование (unittest, doctest, etc.) •  Continuous Integration (Travis, Jenkins, etc.)

Анатомия инструментов

Внутренняя кухня

•  _RSAobj •  LocalClient •  ListServers

Внешний интерфейс •  RSA.new •  salt \* test.ping •  couchbase-cli server-list

Магия

Магия

Магия

Анатомия инструментов, v2

Примеры: •  server-add myserver # OK •  server-remove myserver # FAIL: ‘myserver’ is not

a valid IPv4 address •  salt v0.17.2: pkgrepo.managed # OK •  salt v0.17.4: pkgrepo.managed # FAIL

1. Чтение исходного кода 2. ???

3. Profit!

Опыт

●  Существуют причины, по которым это сделано так, а не иначе

●  Разработчики не могли предусмотреть всё ●  Pull request

Опыт

Pull request: •  Not merged - недостаточно опыта/понимания •  Merged - удовлетворение, признание ●  Contribution

Понимание

•  Реализует все контракты o  raise NotImplementedError

•  Движется в нужном направлении o  интеграция с puppet при сломанном yum api o  преждевременная монетизация

•  Production-ready?

Реализация •  Покрыто ли тестами? •  Качество тестов •  Соблюдение DRY/KISS/etc •  Как следствие,

o  простота o  расширяемость

•  Соответствие [де-факто] стандартам

Комментарии •  long john; // silver •  // Я посвящаю весь свой код,

// всю работу своей жене Дарлин, которой // придётся содержать меня, // наших троих детей и собаку, когда // это пойдет в паблик.

•  long long ago; /* in a galaxy far far away */

Как выбираются инструменты

Как выбираются инструменты “Первая ссылка в гугле”, обзор фич

Как выбираются инструменты Сравнение фич

Как выбираются инструменты Наличие удобного GUI

Как выбираются инструменты Наличие удобного CLI

Как выбираются инструменты Наличие удобного API

urllib2 urllib2.HTTPPasswordMgrWithDefaultRealm urllib2.HTTPDigestAuthHandler urllib2.AbstractBasicAuthHandler

Подводные камни

5. Удобный API - отсутствие высокоуровневых абстракций, отсутствие логики взаимодействия

1. Обзор фич - маркетинг 2. Сравнение фич - платные, поверхностные обзоры 3. Удобный GUI - возможно, единственный грамотно написанный компонент 4. Удобный CLI - неконсистентный ввод/вывод, опции (--verbose vs --log verbose)

Вопросы, которые нужно задать Могу ли я пользоваться инструментом, который: •  не реализует маркетинговые обещания? •  не имеет внутренней логики? •  не имеет тестов? •  имеет мало тестов? •  имеет бессмысленные тесты? •  развивается от “левой пятки”?

Не реализует обещания Значит вместо можно увидеть

Не имеет внутренней логики Значит код придется писать так

Имеет проблемы с тестами Значит что-то где-то упадет

Развивается от левой пятки Значит, придется тратить ресурсы на реализацию необходимых фич и костыли

Читайте исходный код и помните, что баги

библиотек, которыми вы пользуетесь, становятся багами вашего проекта

Вопросы?