Время от времени люди говорят мне, что я что-то делаю не по стандарту, и потому неправ. Дескать, «твоя реализация протокола не соответствует RFC» или «почему ты пишешь void main ( ) , когда по стандарту должно быть int main ( ) »? Меня давно подмывало написать пост на эту тему, и вот, после очередного такого упрека , я собрался с духом.
Начну немного издалека. Вот вы наверняка читаете этот пост через веб-браузер. Браузер при этом использует какие-то библиотеки, те взаимодействуют, например, с оконной системой, а она в свою очередь как-то взаимодействует с операционной системой. Чтобы отрендерить эту страничку вам пришлось выполнить довольно много кода, существенная часть которого наверняка была написана на Си. Как думаете, написан ли этот сишный код полностью по стандарту (C99, C11 и тп), полностью ли он свободен он конструкций с неопределенной семантикой, и так далее? Довольно сомнительно. А важно ли это? Ведь вас, как пользователей, это совершенно не беспокоит. Скорее всего, вы о таких вещах никогда раньше даже и не задумывались. Какая разница, по стандарту написан код или не по стандарту, если страничка загружается и выглядит более-менее сносно?
Рассмотрим пример из жизни. В интересах следствия сюжет и имена действующих лиц были намеренно изменены. Приходит заказчик и просит написать FTP -сервер. Программист честно открываете RFC, пишет все строго по нему и отдает сервер команде тестировщиков. Тестировщики берут пару десятков наиболее популярных FTP-клиентов, включая всякие там приложения под Android, бэкап-утилиты и так далее, и начинают ходить ими в сервер. Спустя какое-то время выясняется, что в некоторых клиентах при работе с сервером возникают ошибки, при этом с ProFTPd те же клиенты работают нормально. Программист внимательно смотрит в tcpdump и реджектит багрепорты один за другим с пояснением, что все эти ваши клиенты в определенных аспектах нарушают RFC. Затем программист, его руководство, тестировщики и заказчик долго между собой ругаются, но в конечном счете сервер приходится переписать так, чтобы с ним могли работать все клиенты. Даже если сервер будет работать не по RFC. Потому что никому не нужен сервер, если 30% пользователей не могут с ним работать.
Другой пример, также из жизни. Программист написал некоторый RESTful сервис и опубликовал в корпоративной Wiki описание его API. Очень скоро в этот сервис начали ходить клиенты. Проходит время, сервис развивается и в какой-то момент у программиста возникает желание произвести рефакторинг. Он рефакторит несколько концов и выкатывает сервис в тестовое окружение. В этот момент выясняется, что часть клиентов поломалась. Расследование показывает, что многие клиенты работают не совсем по спецификации. Может ли программист, воспользовавшись этим предлогом, оставить все как есть? Совершенно очевидно, что не может! Должна быть обратная совместимость . Код придется либо откатить, либо исправить так, чтобы он работал с существующими клиентами. Даже если это означает работать не по спецификации.
Примеры с клиентами и серверами на мой взгляд просто наиболее наглядны, но то же самое справедливо в отношении языков программирования, форматов файлов и так далее. Важно понимать, что программирование — это в первую очередь решение конкретных задач , и только потом все остальное. Программа должна приносить деньги, независимо от того, фрилансер вы или же работаете на дядю. От того, что вы тратите ценные время и силы на запоминание стандартов, а также проверку кода на предмет соответствия этим стандартам, ваша основная цель не становится ближе. Скорее наоборот. Вы делаете лишние усилия, от которых нет пользы абсолютно никому .
Следует также отметить, что по определению любая спецификация неточна . Если бы она была точна, мы могли бы написать для нее компилятор. Но тогда это была бы уже не спецификация, а самый настоящий код, даже если бы это был код на естественном языке. Следовательно, в спецификации всегда есть возможность двоякого трактования, неопределенности, а также противоречия и ошибки, из-за которых в точности следовать спецификации просто невозможно. Я уже не говорю о том, что, как и любая документация, спеки могут устаревать , вводя тем самым людей в заблуждение. Истина только в коде!
Бесспорно, по возможности спецификаций следует придерживаться , иначе ваш код не станет работать с очередной версией стороннего приложения или даже попросту не соберется после обновления компилятора. Но я не вижу ни одной достаточно веской причины упорно приводить абсолютно все и вся в точное соответствие стандартам. Да-да, у меня для вас плохие новости. Мир не идеален и в нем полно говнокода, если вы до сих пор этого не поняли.
Главное — чтобы работало. Аджайл-аджайл и в продакшн!
Материалы по теме: Линус Торвальдс выступил с критикой дизайна файловых систем ; раздел «Две силы в Microsoft» статьи Джоэла Спольски Как Microsoft проиграла битву за API ; пост про оптимизации, безопасность и «нормальные языки» в блоге alexanius’а.
