То, что отличает мышление людей от того, как думают компьютеры, - это то, как мы используем концепции. Чтение новостей - это не просто то, что говорят мне, что выпитое вино может быть не так полезно для нашего здоровья, как мы думали ранее (Красное вино вредно для вас, говорят эксперты). Поскольку я думаю, что с помощью концепций я могу проверить обоснованность утверждения (в исследовательской статье говорится, что при контроле на благосостояние польза от вина для здоровья исчезает), я знаю, что эта информация может повлиять на моего брата, который любит выпить случайно, и я также знаю, что мне, вероятно, следует сказать ему, чтобы он пил меньше. Другими словами, концепции - это не просто модели или процессы. Они помогают нам решить, какая информация имеет отношение к делу, какую еще информацию нам может понадобиться найти и как нам следует реагировать. Наша система концепций помогает нам выполнять множество функций.
Я поднял этот вопрос потому, что, не понимая концепций и того, что они делают, мы не замечаем того факта, что код и его документация повреждены. Я имею в виду, что код и документация - это головоломка, которую должен разгадать пользователь. Подобно тому, кто потерял конечность и учится жить нормальной, но неудобной жизнью, мы научились приспосабливаться и жить с этим. Позвольте мне попытаться объяснить.
На высоком уровне концепции существуют, чтобы делать одно: помогать вам решать проблемы. Концепции делают это с помощью:
- Сообщая вам, какая информация важна
- Сообщает вам, когда его использовать
- Помощь в оценке или прогнозировании ситуаций
- Предлагая варианты действий
- Принимая решения
Представьте, что вам нравится новый проект с открытым исходным кодом, и вы решили внести в него свой вклад. Что вы делаете? Вы просматриваете файловую систему, читаете строки кода и, если вам повезет, вы найдете документацию, которая укажет вам правильное направление. Но в конце концов, читатель должен пройтись по папкам, по файлам и понять, как это работает. Нам нигде не рассказывают, как все работает. Документация страдает той же проблемой. Человек не сможет научиться понимать фреймворк или API, если не поймет более концептуальные аспекты базы кода. Если вы перейдете на справочную страницу API для разработчиков Apple и попытаетесь научиться кодировать приложения таким образом, вы потеряетесь. Сама документация предоставляет только определенный тип информации: в основном описания классов, функции, синтаксис и примеры. Информации, связывающей все это воедино, практически нет. Концептуальной работы не ведется.
Нет концептуальной информации = запутавшийся программист.
Вот пример того, кто проделал концептуальную работу. Flexbox. Если вы не читали, вот один комментарий.
Спасибо за это - внезапно все другие руководства по flexbox обрели смысл. Хотя мне совершенно комфортно работать с HTML и CSS (даже с тонкостями и причудами позиционирования CSS), что-то в flexbox всегда казалось неуловимым. Ваш учебник взял то, что просто не «щелкнуло для меня (что бы это ни было), и заставило его щелкнуть ».
Как строятся концепции?
Информация, как правило, должна выполнять две функции, чтобы превратиться в рабочую концепцию. Первое, что вам нужно, - это понимание на высоком уровне того, для чего используется эта концепция. Например, прежде чем вы сможете правильно использовать функцию, вам нужно знать, что она может делать в более широком контексте. NSLayoutConstraint - это отдельная функция от Apple UIKit API (библиотеки пользовательского интерфейса Apple iOS). Функция используется для определения отношения объектов к экрану и другим объектам. Это помогает разместить приложения на экранах разного размера, не выглядя странно. Этот тип информации о том, что функция делает, связывает информацию с проблемами и целями. Теперь я знаю, что когда я хочу убедиться, что мое приложение масштабируется для экранов разного размера, я должен использовать NSLayoutConstraint (сообщает, когда его использовать, а также предлагает курс действий). Это также помогает мне понять, о чем я должен думать, когда возникают проблемы с масштабированием. Это целевое знание.
Второй тип информации - это механические знания. Документация в основном помогает предоставить этот тип знаний. Механические знания - это изучение всех правил и поведения вещей, которые позволяют вам использовать эту концепцию. Имея только то, что я объяснил выше о NSLayoutConstraint, вы можете только знать, что функция делает и когда ее использовать. Вы понятия не имеете, как им пользоваться. Знания в области механики - это научиться правильно мыслить. Вам нужно знать входы и выходы, синтаксис и его поведение. Большая часть этих знаний организована с помощью моделей. Чтобы использовать NSLayoutConstraint, вы должны понимать трейлинг, интервалы, приоритеты и другие атрибуты. Все это помогает вам предсказать, в какой код будет компилироваться и как на самом деле делать то, что мы узнаем.
Чтобы перейти от проблемы к решению, вам нужна как высокоуровневая целевая информация, так и низкоуровневая информация о механике. Концепция, которая имеет как цель, так и информацию о механике, называется «Полное решение проблем» или для краткости PS Complete. Хотя хорошо написанный код и документация значительно упрощают его расшифровку, есть много возможностей для улучшения.
Это не означает, что придумать хороший способ организации и передачи концепций легко. Модель, которую я только что дал, позволяет вам понять, какой тип работы необходимо выполнить; он не говорит нам, что мы можем и должны делать.
Цели разработки
Но прежде чем мы перейдем к описанию того, как мы можем изменить способ организации нашего кода и документации, мы должны поговорить о некоторых из целей, которые должны иметь код и документация.
- Легко выучить и понять
Эта цель суммирует мои основные критические замечания в адрес организации кода и документации. Мы хотим, чтобы код и документация, которые мы пишем, было легче изучать и понимать. Это выходит за рамки простого добавления в комментарии и RME. Мы хотим, чтобы люди, от специалистов по сопровождению кода до новых пользователей, могли войти и легко узнать, как все работает.
Для этого нам понадобятся:
Информация о целях ( Архитектурный дизайн и описание проблемы)
Это высокоуровневая информация, которая описывает, где находится код и что он делает. Причины и преимущества описаны ранее.
Доступность для поиска и обнаружения
Сохранение организации документации в том виде, в каком она есть (список классов или функции). Люди не могут найти нужную функцию (или могут даже не знать, что она вообще существует). В общем, решение узнать, как что-то сделать, - это поиск вашей проблемы в гугле. Если никто не задал этот вопрос, вы можете задать его Stack Overflow. И если ничего из этого не работает, как в случае с новыми и нишевыми базами кода, тогда вы сами.
Большим преимуществом концептуального представления документации является то, что люди могут легче искать функциональные возможности, в которых они нуждаются. - Помогает при разработке и написании кода.
Одним из преимуществ концептуально прочного дизайна кода является то, что кодирование становится намного проще. Несмотря на то, что множество кода скомпоновано вместе, в какой-то момент его следует концептуализировать. Решения о том, как кто-то должен думать об объекте или о том, как что-то ведет себя, должны быть четко изложены. Внесенные позже архитектурные изменения требуют больших затрат и тратят много времени.
Подумайте о некоторых из лучших API-интерфейсов, которые вы использовали. Большинство из них очень просты. Или хотя бы концептуально просто. Все в них интуитивно понятно, а код читается очень просто. - Второстепенные цели
Очевидно, что мы хотим сэкономить как можно больше времени и энергии при написании кода для внесения значимых изменений. Время, потраченное на то, чтобы что-то понять или изучить, - это безвозвратная потеря.
Теперь, когда у нас есть довольно хорошее представление о том, как должен работать код, мы можем перейти к тому, как мы можем организовать наш код и документацию, чтобы помочь нам в этом.
Это часть 1 из текущей серии статей, посвященных концепциям разработки и написания кода и документации.
В части 2. Я опишу различные инструменты, которые мы можем использовать для достижения наших целей.
P.S. Пожалуйста, оставляйте отзывы как о содержании, так и о самом написании! Я также с удовольствием отвечу на любые ваши вопросы. Это было давно и много значит. Заранее спасибо!
