Написание слова тэг

Слово "тэг" пишется как суперпозиция 70% "э" и 30% "е". В физическом смысле используется пульсовая модуляция, иногда оно "тег", иногда "тэг", ну и корни обычно "теггировать".

Неспровоцированная мудрость про архитектуру

Чем дальше, тем больше я убеждаюсь, что в реальности, в любом проекте (кроме целей проекта) важны только три вещи:

* имена
* связи
* инструменты

Всё остальное - шелуха и исправимо. Почему именно они?

Имя в IT - это всё. Весь IT построен на удачных "названиях", которые придумали странным штукам. Как только какое-то название оказывается _особо_ удачным (байт? сервер?), с этого момента жизнь не мыслима без них. Но между "стало основой языка для поколений" и "неудачное название, закапываем" большая серая полоса, и чем она чернее, тем хуже проект будет развиваться.

Название в IT - это не бирочка на баночке. Это набор прилагающихся к слову глаголов, прилагательных и связей с другими понятиями.

Если бы кто-то придумал назвать сетевой порт "коммьюнити", то у нас были бы не приложения, слушающие на портах, а взаимодействие с коммьюнити, которые бы были в множестве и мысль о том, что один бинарь может претендовать на то, чтобы заменять собой всё комьюнити, была бы глупой (как сейчас звучит глупой идея о приложении, которое слушает все порты IP-адреса). Соответственно, в момент создания названия закладывается всё то, что может и не может быть с объектом, для которого дают названия. Если у вас the shelf rolls into the tombstone offer, то ваш проект - труп. Потому что никто не понимает что такое tombstone offer, и как в него можно roll, и почему это делает shelf. Если у вас taps fill pools until sinks opened by sensors, браво, чтобы это ни было, если 'fills' описывает происходящее более-менее похоже, то ваша терминология - успешна.

(тут случайно всплыл пример терминологии "на грани" - у людей есть front-end, есть back-end, а посредине ... middle-end? Далеко они не уплывут со средним концом...)

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

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

Такие связи образуются всё время, причём против воли создателей, потому что человек вносит реакцию на среду локально, а связи - объект глобальный, и не всегда можно предсказать наличие влияния. Существует набор формализмов, охватывающих некоторые виды связей, но будет очень наивно думать, что все связи выявляются сразу. Периодическое их причёсывание - основа здравого развития проекта.

Инструменты важны по двум причинам: во-первых, молоток со встроенным микрометром не оставляет опций для выкапывания ям (даже если яма очень нужна); другими словами, инструмент ограничивает возможности. Но он же ещё задаёт онтологическое пространство для обсуждений изменений. Терминология инструмента всегда используется в проекте, т.е. инструменты - это первый источник слов для названий. Я бы сказал, что влияние инструментов на принимаемые высокоуровневые решения значительно большее, чем просто "технологический стек" (кто придумал слово "стек"? оно изумительно).

Все эти три сущности, на самом деле ответы на вопросы: "что?", "как?", "чем?", и моё неспровоцированное авторитетное мнение, что эти три вопроса - самые главные в любой архитектуре.