Нужно ли читать код используемых библиотек?

от автора

В какое прекрасное время мы живём! Вот пишешь ты программу и понадобилась тебе библиотека для чего-нибудь — она точно найдется! Многие библиотеки лежат в opensource и даже распространяются по приятным лицензиям типа LGPL, взял — и решил проблему. Делов-то: способ подключения описан в readme, библиотека предоставляет красивые интерфейсы, демка есть (она даже компилируется и работает). Вообще ООП со всеми его идеями абстракций, интерфейсов, инкапсуляции внутренних данных — мощнейшая штука (тут без иронии).

Но давайте подумаем, где и когда начинается «абстракция». Вот, например, есть у меня автомобиль, на котором я раз в неделю езжу в супермаркет. В этом случае он для меня вполне себе абстракция уровня «руль, три педали и пара рычажков», предоставляющая нужный мне функционал. Причём я могу пользоваться им долгие годы, не особо задумываясь что там под капотом — двигатель или волшебные гномы, зачем-то пьющие бензин и крутящие колёса. Но если я работаю автомехаником, конструктором автомобилей ну или попросту профессиональным водителем — я уже не могу позволить себе смотреть на машину столь «свысока», знать её внутреннее устройство — это моя работа. Покупатель молока в магазине может вообще ни разу в жизни не видеть живую корову, но вот фермер, который эту корову выращивает, просто обязан знать всё о её здоровье\содержании\питании\уходе\дойке. Ну и т.д. Есть чёткое разделение на «пользователей» продукта и его «создателей». Первые могут позволить себе не задумываться о деталях, вторые — нет.


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

Неоднозначность поведения

Давайте представим интерфейс такой себе абстрактной библиотеки на неопознанном языке:

interface IInterface { 	bool Init(); 	int Calculate(int val); 	void Release(); } 

Всё ведь понятно, правда? Вызываем Init(), потом передаём в Calculate() что-то, получаем ответ, вызываем Release().

Элементарно? Не торопитесь. Ответьте-ка что будет, если:

  1. Вызвать Init() дважды? А 1000 раз?
  2. Вызвать Calculate() без вызова Init()?
  3. Не вызвать Release()? А если вызвать дважды? А если 1000 раз? А если до вызова Init()?
  4. Вызвать Init(), Calculate(), Release() из разных потоков?
  5. Каков вообще диапазон аргумента val? Весь int? А точно? А 0 тоже? А MIN_INT и MAX_INT?
  6. А тут бросаются какие-то исключения?
  7. А тут пишутся какие-то логи? А это как-то конфигурируется?

ну и т.д.

Вы скажете, что эти вещи должны быть описаны в документации? Да, должны быть. Но, во-первых, это не всегда так. А во-вторых, документация — это набор букв, которые не парсятся компилятором, не выполняются на рантайме, никак и никем автоматически не верифицируются. Там можно быть правда. А может быт результат стучания по печатной машинке стаи обезьян. Или погода на Марсе. Разработчики не любят писать документацию и ещё меньше любят её обновлять. Смиритесь с этим. Ну или прочитайте, наконец, код библиотеки.

Предназначение библиотеки

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

Тесты

Тут сразу целый набор нюансов. Если в составе библиотеки есть тесты — это о многом говорит, их можно почитать, позапускать, это существенно добавит понимания, как эту библиотеку можно\нужно использовать. Например, я не раз встречал в тестах строки «TODO:…», «possible bug», закомментированные куски тестов с пометкой «раскомментировать после реализации функционала» и т.д. Даже самый элементарный тест может вдруг обнаружить, к примеру, что автор ожидает на входе функции температуру в Кельвинах, хотя вы были на 100% уверены, что она должна быть в Цельсиях.

Если тестов нет — это тоже о многом говорит (в первую очередь о том, что лучше бы поискать другую библиотеку). Возможно, их следует написать самостоятельно. А возможно, библиотека так написано, что их очень трудно написать — тогда и с использованием библиотеки могут быть проблемы.

Квалификация создателя библиотеки


Тут есть ровно два варианта. С большой долей вероятности создатель библиотеки имел более высокую квалификацию чем вы в области задач, решаемых библиотекой. Ну, вряд ли бы иначе он взялся писать библиотеку. Это вполне себе существенный повод почитать его код — возможно, вы чему-то научитесь, может быть код показывает какие-нибудь «подводные камни» решаемой проблемы, которые вам было бы полезно знать или предлагает даже лучшие пути решения, чем вы рассчитывали. В любом случае, почитать код хорошего специалиста — всегда полезно.

Второй (реже попадающийся) случай, это когда создатель библиотеки имеет квалификацию ниже, чем вы. Во-первых, хорошо бы это понять (а как это сделать без чтения кода?). Во-вторых, тут ведь как с цепью — качество вашего продукта будет не выше качества самой плохой его компоненты, и вот тут вы осознанно хотите создать себе проблему на ровном месте?

Халатность

Вы не знаете, насколько сильно тот человек, который писал библиотеку, хотел сделать её качественной. Возможно он потратил лишнюю сотню часов на «полировку» кода, а может быть эта библиотека была последним его продуктом на прошлом месте работы, написанной в период «последних двух недель» перед уходом от ненавистного работодателя. Вы ведь представляете, насколько разным может быть качество кода в первом и втором случае?

Злой умысел


Все мы знаем историю с недавней закладкой АНБ в генераторе случайных чисел. Ну и о слухах (или не слухах) о 10 млн $ за это дело тоже в курсе. Люди весьма скептичны и подозрительны в повседневной жизни, но вот в плане доверия к ПО (да ещё если вдруг и бесплатному!) становятся на совсем противоположные позиции.

Скажи мне, кто твой друг, и я скажу тебе, кто ты

То же самое справедливо и для отношений продукта с его библиотеками. Если в библиотеке есть баг — он будет и в вашем продукте. Утечка памяти в библиотеке? Нет, теперь это утечка памяти в вашем продукте. Блокировка? Проблемы производительности? Неопределённое поведение? Получите, распишитесь.

Вывод

Абстракция — это не когда вы не понимаете внутреннего устройства чего-то, это когда вы уверены в нём настолько, что можете себе позволить о нём не задумываться.

ссылка на оригинал статьи http://habrahabr.ru/post/207336/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *