Очевидно, вы читаете код чаще, чем пишете. Здесь нет ничего нового. Этот факт часто упоминается, когда обсуждается необходимость чистого кода. Или когда оцениваются достоинства разных языков программирования.
Я думаю, что этого двойного различия недостаточно. Вы пишете код. Хорошо. Но при чтении кода существует два вида чтения. Начнем с примера:
val string = "Hello World"
string should startWith ("Hello")
Даже если вы не читали мои статьи о ScalaTest, вы можете понять, что делает эта строка кода. В этом смысле чтение этой строки кода чрезвычайно просто. Я называю это «скимминг»
Но что, если эта строка кода не делает то, что вы ожидали? Тогда вам нужно действительно понять код. Тогда вы хотите понять, что происходит. В приведенном выше примере с Scala вы можете рассмотреть следующие варианты: является ли startWith («Hello») параметром, которому следует? Или «Hello» — аргумент, передаваемый результату, который вы получаете после передачи startWith to should? Что в любом случае? Метод? Объект? Функция? Экземпляр с методом apply?
Как вы видите, то, что было действительно легко снять, теперь становится довольно сложным для понимания.
То же самое может быть в случае библиотек. Рассмотрим Hibernate. Если вы настроили Hibernate, операции CRUD над сущностью действительно легко написать и понять. Но как только вы получите одно из страшных Hibernate-исключений ( LazyInitializationException , NonUniqueObjectException ,…), вы захотите по-настоящему понять, что происходит. И в этот момент многие люди понимают, что они понятия не имеют, что на самом деле происходит, когда они вызывают session.update или просто средство получения Hibernate Proxy.
Очевидно, вы хотите, чтобы все три вида обработки кода были как можно более простыми, а написание может быть наименее важным, потому что мы читаем больше кода, чем пишем. Но насколько важна способность скользить против понимания?
Со всем, что вы используете в приложении, вы будете делать много скимминга. Вот почему DSL, подобные приведенному выше примеру ScalaTest, являются таким замечательным инструментом.
Я подозреваю, что если вы делаете сложные вещи с библиотекой или языком, понимание всегда будет трудным. Но в некоторых случаях это становится очень сложно, потому что используются нестандартные приемы. В Java типичным примером хитрости является отражение и манипулирование байтовым кодом. Многие из более мощных библиотек используют его, чтобы обойти ограничения «нормальной» Java. В результате получается код, который легко просмотреть, но для многих просто невозможно понять. Примерами являются Mockito или Hibernate.
Поэтому при оценке библиотеки или ее написании вы можете подумать, сколько магии она использует.
Другой способ ограничить проблему с «пониманием» кода — сделать его ненужным. Я думаю, что Hibernate является примером, где это не удалось. У вас есть множество мест, где вы должны точно понять, что делает Hibernate, чтобы правильно его использовать.
Сама Java — пример, где это работает довольно хорошо. Во многих, многих проектах никто не должен понимать, как работает JVM. Это просто работает. Только в редких случаях вам нужно погрузиться в детали сборщика мусора или модели памяти.
Ключевым моментом здесь является чистая не вытекающая абстракция . Если у вас есть это, не имеет значения, какую магию вы используете, чтобы это произошло. Но если ваша абстракция протекает, части магии, которую вы используете внутри, будут вытекать с риском превращения вашего проекта в нечто, действующее так, как будто оно околдовано.
С http://blog.schauderhaft.de/2011/11/27/the-three-ways-to-work-with-code/