...иногда стоит вместо того, чтобы договариваться о том, как использовать 10 существующих терминов плюнуть на все и принять один, даже если он будет 11-ым (и особенно, если он будет временным).
Однако в большинстве случает прежде чем вызывать к жизни тот или иной новый термин следует 20 раз подумать... по многим причинам.
И еще:
Языком ИТ традиционно является английский, а, увы, не русский. Русских вариантов многих нужных терминов как-то так и не родилось...
Есть один нюанс, который глобально ничего не меняет, но заслуживает отдельного упоминания: "нужных терминов" не вообще "не родилось", а скорее "родилось, но не выросло" (не укоренилось в массовом сознании), поскольку, вообще-то существуют ГОСТ-ы, то есть ГОсударственные СТандарты.
В период существования СССР было принято множество стандартов в различных областях, которые были обязательными для исполнения. Я не рискну утверждать, что стандартизовано было все (поскольку понимаю, что подобное утверждение невозможно доказать, зато очень просто опровергнуть), но, однозначно, очень многое: определения, форматы документов, последовательности выполнения процессов и так далее. После распада СССР был принят закон "О техническом регулировании" (№ 184-ФЗ от 27 декабря 2002 г.), заменивший обязательную стандартизацию - добровольной. Обязательными к исполнению остались лишь Технические Условия (ТУ за разными номерами), регламентирующие безопасность продукции, безопасность производства и так далее (Глаголев В.А. Разработка технической документации. - СПб.: Питер, 2008). Сегодня можно выполнять или не выполнять стандарты советские (ГОСТ), российские (ГОСТ Р), зарубежные (государственные и негосударственные), международные (например, ISO) и внутренние корпоративные.
Сам термин "стандарт" происходит из английского языка и обозначает "узаконенную меру" или "образец" (Брокгауз Ф. и Ефрон И. "Иллюстрированный энциклопедический словарь" - М.: Эксмо, 2008), но стандартизация, по своей сути, известна еще со времен Древнего Египта, где размер кирпичей для строительства должен был быть всегда один и тот же, и кирпичи проверялись на сей предмет специальными чиновниками.
Стандарт - это всегда палка о двух концах: с одного конца он дает определенность, с другого - вменяет некоторые, иногда весьма неудобные, обязанности. На полезность стандартов и понимание того, что можно/нужно стандартизировать, а что - нет, существует множество взглядов, в частности, есть такие мнения:
Кое-кто утверждает, что разработка ПО стала настолько специализированной и фрагментированной, что не поддается стандартизованному образованию. Она действительно фрагментирована – для стандартизованного обучения, но не для стандартизованного образования.
[...]
Одним из признаков зрелой профессии является наличие кодекса этики или стандартов профессионального поведения. (Макконнелл С. Профессиональная разработка программного обеспечения. - СПб.: Символ-Плюс, 2006).
И некоторые компании вводят стандарты одежды. Не столь строгие, чтобы требовать определённой униформы, но все же серьёзно ограничивающие свободу выбора. Когда это происходит впервые, вред поистине огромен. Люди не могут говорить и думать ни о чем другом. Всякая полезная работа прекращается. Наиболее ценные сотрудники начинают понимать, что их действительные достижения никто не ценит, что их вклад в общее дело не так важен, как стрижки и галстуки. В конечном итоге они уходят. Компания же плетётся дальше, пытаясь доказать, что найм подходящих людей, как выяснилось, не так уж важен.
[...]
...следует отметить, что великий триумф стандартов в современном мире – это практически всегда успех стандартных интерфейсов. Стандарт на резьбу, на пальчиковую батарейку или кассету с плёнкой содержит много сведений о конечном продукте – о том, как он взаимодействует с другими частями, но ни слова о процессе создания этого продукта. Батарейка имеет тип АА, если отвечает стандарту соответствующего интерфейса (по форме, размеру, отказоустойчивости, электрическим характеристикам и т. д.), независимо от того, создана ли она под водой, роботами или обученными обезьянами. Из успеха стандартов на интерфейсы можно лишь с некоторой натяжкой делать вывод, что процессы тоже следует стандартизировать (Демарко Т., Листер Т. Человеческий фактор: успешные проекты и команды, 2-е издание. - СПб.: Символ-Плюс, 2008).
Когда Unix-сообщество соединилось с культурой Internet-инженеров, в него также проникло мышление, сформированное процессом RFC-стандартизации IETF (Internet Engineering Task Force - Инженерная группа по решению конкретной задачи в Internet). Согласно традиции IETF, стандарты должны возникать из опыта с работающим прототипом, но как только они становятся стандартами, код, который им не соответствует, считается нерабочим и безжалостно уничтожается.
[...]
Одним из самых печально известных примеров абсурдной стандартизации были сетевые протоколы Открытого взаимодействия систем (Open Systems Interconnect, OSI), которые недолго конкурировали с TCP/IP в 1980-х годах - семиуровневая модель на расстоянии выглядела изящной, но оказалась чрезмерно сложной и нереализуемой на практике.
[...]
Стандарт RS232 для последовательных соединений был настолько недоопределенным, что иногда казалось, будто не существует двух одинаковых последовательных кабелей (Реймонд Эрик С. Искусство программирования для Unix. - М.: Издательский дом "Вильямс", 2005).
Что касается лично меня, то я считаю, что наличие стандартов, которые необязательны для выполнения - это как "летняя зима" или "круглый квадрат", либо это обязательно для выполнения, либо это не стандарт. Может быть добровольность в этом деле и правильна, но все же ощущается какая-то едва уловимая абсурдность во всем этом. Она привела к тому, что:
- Крупные компании часто пытаются стандартизировать то, что может быть и не стоило бы.
- При наличии ГОСТ часто изобретаются велосипеды - далеко не каждый специалист знает существующие стандарты в своей области, и никто не знает их все (советские, российские, международные...).
Этапы жизненного цикла, виды документации, виды программных продуктов и так далее, и тому подобное - на все это существовали ГОСТ-ы еще с 70-ых, а сегодня даже студентов как-то уже не очень легко учить по стандартам (по отечественным действующим), поскольку те значения терминов, которые в них даны, часто не совпадает с общепринятыми ныне (чаще всего "привозными"). Например, согласно ГОСТ 19781-90 "Обеспечение систем обработки информации программное":
- Программа, которая написана для ЭВМ одной архитектуры, но может исполняться в системах обработки информации с другими архитектурами без доработки или при условии ее доработки, трудоемкость которой незначительна по сравнению с разработкой новой программы, называется отнюдь не "переносимой", а "мобильной".
- "Макроопределение" - программа, под управлением которой макрогенератор порождает макрорасширения макрокоманд (ПРОГРАММА, а не сама строка с определением).
- Ситуация, в которую попадают две или несколько асинхронных процедур, характеризующаяся невозможностью дальнейшего выполнения из-за взаимных зависимостей... думаете "дэдлок"? Ну, в общем-то, да - "deadlock", но согласно ГОСТ по-русски это называется "тупиковая ситуация".
- Порция данных, состоящая из последовательности литер - вовсе даже не "строка", а "литерная цепочка" или просто "цепочка".
Зачем я, собственно, все это пишу? В каком-то смысле плАчу "за прошлогодний снег" - я часто отмечаю, что язык ИТ - не русский, а английский, но только недавно осознал, что у нас собственная советская культура в части ИТ была, был наработан гигантский объем ныне устаревающего опыта, и русский язык на самом-то деле МОГ БЫТЬ языком ИТ.
Вы можете столкнуться с ГОСТ-ами:
- В вузе при оформлении диплома - мы с зав. кафедрами принципиально требовали от студентов на факультете Программирования оформления пояснительных записок согласно требованиям ГОСТ, составляющих, в частности, Единую систему программной документации (ЕСПД), один раз за пять лет можно и окунуться в оформление с головой, опыт нелишний.
- При разборках со старыми документами.
- При работе в государственных учреждениях или компаниях, выполняющих заказы для таковых.
- Если сами захотите действовать согласно ГОСТ.
- Рекомендую: если прежде чем изобретать 11-ый термин для чего-либо захотите убедиться, что вам не подходят существующие 10. Знаете/помните, чем деталь отличается от узла, сборочной единицы, комплекта и комплекса? ГОСТ-ы знают. В чем различие между аппаратно-программным комплексом (АПК) и автоматизированной системой (АС)? Ответ в ГОСТ-ах (одним из отличий является то, что в состав АПК не входит персонал, в отличие от АС).
Комментариев нет:
Отправить комментарий