Будьте хорошим гражданином. Сделайте ваши процессы наглядными
Иногда быть хорошим разработчиком означает меньше заниматься магией
Реализация по умолчанию - это хорошо, но слишком много всего - плохо
Как часто вам приходилось разрабатывать довольно сложные операции с участием разных движущихся частей? Вы собираете все аккуратно, проверяете на наличие ошибок, все работает ...
Затем вы понимаете, что после вашей следующей встречи, на которой они добавили кучу функций в текущую сборку, вам придется заставить этот процесс работать во многих местах вашей кодовой базы. И вы понимаете, что для этого вам придется повторить какой-то код.
Хорошие новости
Вам не нужно повторять код. Это нормально делать время от времени, но если вы обнаружите, что делаете это часто, вам в конечном итоге придется реорганизовать этот код, и вам придется делать это снова и снова. Никто не хочет тратить все это время зря, и большинству из нас не нравится такая скука.
Приведем пример, ладно?
Допустим, вы разработали этот слишком общий шаблон ...
Вашему контроллеру представления нужны некоторые данные. Возможно, он получает данные от контроллера модели, поэтому вашему контроллеру представления требуется свойство типа контроллера модели.
Вашему контроллеру представления также нужен источник данных, и вы используете массив вашего типа модели. Массив используется для заполнения таблицы или представления коллекции, поэтому различные методы для этого collectionView должны использовать массив.
Возможно, в этом конкретном сценарии рассматриваемый tableView является одним из нескольких, и вы просто хотите отделить и скрыть код, потому что этот контроллер представления выходит из-под контроля с количеством представлений таблиц и коллекций, которые у него есть.
Шаблон протокол / делегат часто подходит для такого сценария. Но допустим, вы выполнили кучу реализаций в делегате и не хотите повторять это.
Нет проблем, просто предоставьте реализацию по умолчанию, верно? Почему бы даже не запускать все автоматически в реализации? Тогда это просто происходит, и никому не о чем беспокоиться. Отлично, правда?
Плохие новости
Когда вы предоставляете реализацию по умолчанию, вы сразу теряете доступ к визуализации кода, который заставляет все работать. Он лежит где-то в отдаленной папке, и никто не может его быстро увидеть.
Уродливые новости
Когда ваша реализация по умолчанию скрыта, другие разработчики этого не понимают. Они могут подумать, что вы какой-то волшебник, и побояться подойти к вам, чтобы узнать, как вы сделали то, что сделали (как они узнают, что вы не превратите их в лягушку?).
Затем они могут повторить вашу реализацию в следующем контроллере представления, который они делают, который выполняет тот же процесс, не осознавая, что им просто нужно было принять ваш протокол. Хуже того, может быть, они приняли ваш протокол, и теперь все происходит дважды. Ура, вы думали, что делаете хорошее дело, но вы просто помогли внести ошибку в кодовую базу…
Это не ваша вина, Мартин, или Стив, или как его зовут, должны были проверять доску Trello, систему отслеживания ошибок или все, что вы используете для документации. Но, тем не менее, вы могли бы помочь предотвратить это, если бы еще немного подумали.
Решение
Короче говоря, не предоставляйте слишком много реализаций по умолчанию и документируйте то, что важно для всех, кто ее использует.
Оставьте некоторую видимость вашей реализации. Может возникнуть соблазн заставить все это волшебным образом работать (кто не хочет, чтобы его считали волшебником, верно?), Но оставьте одну или две собственности в покое, чтобы, по крайней мере, другие разработчики могли сразу проверить, что происходит (при условии, что вы задокументировали Это…).
Вот упрощенный пример
У нас есть индикатор активности, который мы хотим видеть на любом из наших контроллеров представления, которые получают данные от сетевого вызова.
Я вижу здесь пару проблем с точки зрения удобства использования.
Во-первых, если кто-то другой запустил этот ViewController и принял NetworkUI, но затем не смог продолжить реализацию по какой-либо причине, мы могли бы продолжить и попытаться реализовать наш собственный индикатор активности. Это связано с тем, что он полностью реализуется после того, как ViewController принимает протокол, но не оставляет никакой видимости в ViewController. Создайте этот протокол, затем адаптируйте к нему View Controller, и вы поймете, что я имею в виду.
Другая проблема заключается в том, что мне нужно позвонить setupActivityIndicator, чтобы заставить его работать, но я не знаю этого, потому что здесь нет документации. Как мы можем это улучшить?
Было бы еще хуже, если бы мы сделали что-то вроде автоматического вращения индикатора активности. Это было бы круто, но оставило бы нам массу проблем.
Если вы воспользуетесь этой реализацией, а затем перейдите к своему классу ViewController и сделайте его подклассом NetworkUIController, вы поймете, что я имею в виду.
Во-первых, давайте сделаем его более заметным
Давайте удалим нашу реализацию свойства activityIndicator. Это заставит нас (или следующего разработчика) создать это свойство либо вручную, либо щелкнув по кнопке «Исправить». Надеюсь, что в этот момент они заинтересуются и изучат вашу документацию. Ой, подождите, у нас их нет.
Давайте задокументируем это
Документация настолько важна и проста, почему бы просто не выработать привычку делать это? Я не говорю о добавлении ненужной документации, но в таком случае я бы хотя бы добавил ///comment для вызова метода setupActivityIndicator, прежде чем пытаться получить доступ к этому свойству. Я не обязательно документирую этот метод, поскольку он до боли ясен в том, что он делает, и его не видно, пока вы его не вызовете (в этот момент, будем надеяться, что вы знаете, что он делает).
Если вы не знали, комментарий, начинающийся с трех косых черт (///), оставляет документацию для любого разработчика, который щелкает с помощью опций свойство, метод, класс и т. Д. Вы также можете задокументировать отдельные параметры функции так же, как Apple делает со своими.
Для получения дополнительной информации:
Заворачивать
При создании реализаций по умолчанию, оставляя видимость и документацию, мы с самого начала даем нашим будущим «я» и другим разработчикам, использующим нашу кодовую базу, боевой шанс. Надеюсь, вы подумаете о том, чтобы сделать немного меньше волшебства, когда будете создавать свое следующее приложение.
