Это редакция бюллетеня PHP SitePoint от 30 мая 2017 года. Подпишитесь здесь !
Laracasts недавно опубликовал очень интересное видео без Laravel о том, что называется визуальным долгом . Это всего 3 минуты, поэтому, пожалуйста, найдите время, чтобы посмотреть его, прежде чем читать дальше.
Выполнено? Хорошо, спойлеры ниже.
В видео Джефф начинает с небольшого подробного кода, основанного на событиях, с некоторыми слушателями, методами огня, интерфейсом, на котором базируются различные классы, и несколькими подсказками типа и возврата повсюду.
Просматривая код, он утверждает, что он полон визуального долга . Затем Джефф объясняет, что хотя PHP предлагает подсказки типа и возврата, они не нужны, и быстро удаляет их из всех сигнатур методов, чтобы уменьшить объем кода. «У нас было очень хорошо без них очень долго», — утверждает он.
Затем он тянется за интерфейсами и удаляет их тоже. Он утверждает, что люди тянутся к ним слишком часто, слишком рано, и добавляют ненужный вес к их коду.
В том, что похоже на окончательный вариант, он удаляет ключевое слово «final» из класса, утверждая, что глупо защищать разработчика от себя, но затем неожиданно он также обрезает даже ключевое слово publicpublic
Конечный результат? Примерно на 25% меньше кода в этом простом примере. Но долг ушел?
Если вы в какой-то степени следовали за мной , вы знаете, что я очень противный и многословный. Таким образом, я был взволнован, когда в PHP появились правильные подсказки типов.
Количество ошибок, с которыми я столкнулся, и количество времени, которое я потратил, работая над кодом других людей, потому что они не давали понять, какой тип значения ожидается, так как ввод или вывод метода огромен, и просто наличие Возможность получить хорошую, автоматическую статическую проверку и правильные подробные советы по автозаполнению IDE во время работы стоила для меня перехода на новейшую версию PHP.
Работая в командах, больший контроль над кодом означает меньшее количество техногенных ошибок, и я за это. Время драгоценно, и тратить его на предсказуемые ошибки совершенно греховно. Я не могу согласиться с Джеффом в удалении их из его кода. Мы хорошо обходились без них долгое время, но у нас все было хорошо без многих вещей, которые теперь делают нашу жизнь намного лучше. Для меня они не представляют визуальный долг — я чувствую себя в долгу без них , потому что я знаю, что могу извлечь из них выгоду таким образом, чтобы предотвратить технический долг.
Я согласен с ним в удалении интерфейса. В случае с видео это не дало ощутимых преимуществ, хотя это могло быть связано с самим примером кода. В качестве примера он выбрал Events, и его класс Event, как описано в видео, на самом деле был вполне приличным интерфейсом.
В целом, я думаю, что интерфейсы в порядке, если вы создаете что-то, что должно быть разработано как расширение или замену чего-либо, или когда используемый вами пакет использует интерфейс, чтобы убедиться, что подпись совпадает, но в остальном они добавляют немного веса кода. Я помню мой старый Zend Framework 1 день, когда на 20 уровнях вглубь структуры каталогов фреймворка были основные интерфейсы без тела — только класс и пустые скобки. Код бюрократии, одним словом.
Удаление final Запрещать людям расширять класс (который в любом случае легко обойти) кажется бессмысленным, и если это подразумевается в качестве превентивной меры в команде, чтобы держать коллег под контролем, это так же эффективно, как памятка. Некоторые страстно не согласятся , но я говорю с final Я не обязательно вижу его присутствие как визуальный долг или его отсутствие как возможность технического долга — я просто не вижу его полезности.
Наконец, есть удаление public
public function fire( ... ) { ... }
к этому:
function fire ( ... ) { ... }
Не могу сказать, что согласен с этим. Хотя он удаляет некоторые символы из файла, я считаю, что он приносит больше вреда, чем пользы. Во-первых, как человек с легкой формой ОКР, я был бы невероятно обеспокоен тем фактом, что другие методы были protectedprivatepublic
function fire ( ... ) { ... }
protected function log ( ... ) { ... }
Во-вторых, почти во всех примерах везде используется ключевое слово publicначинают изучать PHP, что это значит, и научить их использовать один общий подход. Представляете, где бы мы были, если бы всех учили использовать пробелы с первого дня? В-третьих, хотя public То, что оставляет это устранение видимого визуального долга , — это технический долг .
Вывод
В целом, я бы сказал, что я стремлюсь к здравому смыслу (без необходимости в final или к интерфейсам, когда они явно не нужны) и к ошибкам на стороне многословия : статический тип намекает даже на сольные проекты и многословность на визуальную свободу в команды, потому что многословие делает вещи понятнее для всех и уменьшает недопонимание.
В заключение, у меня нет непреклонных предпочтений в этом случае. Мое мнение здесь представляет собой смесь «да» и «нет» на каждый из его аргументов, но я полностью согласен с его последним мнением: ставить под сомнение все — даже человека, который говорит вам, чтобы ставить под сомнение все .
Проклятие знания сильное, а аргумент от власти еще сильнее. Не позволяйте себе погрузиться в волну восприятия опыта только потому, что доска для серфинга чувствует себя в безопасности. Там могут быть акулы в виде как визуального, так и технического долга, и хороший код всегда является балансом обоих.
Как вы относитесь к визуальным свободам, представленным в видео? Какие из них вам мешают, а какие вы бы усыновили?