March 6th, 2010

Об интернете, математике и образовании вообще...

А началось все с вопроса yelisdm "А ты помнишь, как считается дискриминант? Только не заглядывая в гугл?" и присланного им же демотиватора.

Честно скажу, как считать дискриминант, я не помнил. Более того, я даже не помнил, что это такое. Посмотрев на демотиватор, я конечно вспомнил, что это что-то, связанное с уравнениями, но что именно, вспомнить уже не получилось.

Однако стало интересно - а смогу ли я все же найти решение квадратного уравнения "с нуля"?

Итак, есть уравнение ax2 + bx + с = 0. И как же его решать?

Collapse )

На то, чтобы заново "изобрести" решение на основании тех фактов и правил, которые еще не забылись, ушло около часа времени. И вот тут я подхожу к основной мысли, ради которой я и затеял этот пост.

Существует способ найти решение гораздо быстрее. Открыв гугл и набрав там "квадратное уравнение". На первой же ссылке, ведущей в википедию, будет описано, как это уравнение решить.

В результате способность "заново" открыть способ решения квадратного уравнения (или любой другой уже решенной математической задачи) становится практически никому не нужной (и даже вредной, если кто-то всерьез этой возможностью пользуется), ибо, как показала практика, "вспомнить" давно забытое не так и просто. Потому что гораздо быстрее спросить у гугла. И предпочтение нужно будет отдать тому, кто вместо того, чтобы в течении часа "изобретать" решение, решит просто найти его.

Разумеется, когда речь идет о "переднем крае" науки, то там уже игра идет по другим правилам, и на первое место выйдет именно способность делать подобные вещи, описанные выше.

Но для подавляющего большинства будет гораздо эффективнее просто найти ответ на просторах интернета.

Получается, что игнорировать такое явление, как интернет, становится очень неэффективно. А система обучения этот факт полностью на данный момент игнорирует, оставаясь такой же, какой она была 20 лет назад. Обучая людей тому, что им в современном мире никогда не понадобится и не показывая того, как то же самое можно получить гораздо более эффективным способом. Как если бы после появления микрокалькуляторов продолжали обучать пользоваться логарифмическими таблицами и линейками.

Делайте выводы :)

35. Золотое правило дизайна API

(В оригинале - The Golden Rule of API Design)

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

Разработчики API решают эту проблему по-разному, но самый простой способ – блокировка API. Так, на Java вы можете сделать большинство ваших классов final. В C# таким ключевым словом будет sealed. Независимо от языка вы можете захотеть, чтобы API предоставлялось через singleton или через статические фабричные методы с целью защитить себя от переопределения поведения и использования вашего кода, которое может вас ограничить в будущем. Это все звучит логично, но реально ли это все сделать?

В течении последнего десятилетия мы постепенно осознали всю важность модульного тестирования, но это знание еще не полностью распространилось в отрасли. Подтверждение этому вокруг нас. Возьмите любой непротестированный класс, использующий какой-нибудь сторонний API, и попытайтесь написать для него юнит-тест. Практически наверняка вы столкнетесь с проблемами. Вы обнаружите, что код, использующий API, буквально приклеен к этому API. Окажется практически невозможным отделить API так, чтобы отследить, как код взаимодействует с ним и перехватить возвращаемые значения для проверки.

Со временем состояние может улучшиться, но только если мы в процессе проектирования API начнем смотреть на тестирование как на реальный пример его использования. И речь здесь не о тестировании только нашего кода. Здесь начинается Золотое Правило Проектирования API: «Недостаточно написать тесты для разрабатываемого вами API, нужно написать тесты для кода, использующего ваш API». Когда вы это проделаете, вы на себе испытаете все те проблемы, с которыми столкнутся те, кто будет использовать ваш API и писать тесты для своего кода.

Не существует простого способа сделать API удобным для тестирования кода тех, кто этот API будет использовать. Static, final и sealed по сути неплохие конструкции и могут использоваться при необходимости. Однако кроме этого нужно иметь в виду процедуру тестирования и пройти через нее самому. Испытав это на себе, вы сможете учитывать ее тонкости при проектировании.

Автор оригинала - Michael Feathers

Перевод мой, при использовании ссылка на мой живой журнал обязательна!