Осторожней с разработчиками ПО

Подразумевается, что разработчики программного обеспечения – это высококвалифицированные специалисты, получившие хорошее образование и накопившие опыт. Кто-то же отбирает их и назначает на должности! Однако почему-то они дают неправильные ответы на некоторые очень важные вопросы, которые должны быть усвоены ими ещё на стадии образования.

Внимание автора привлекли маленькие такие картиночки на полях редактора исходного кода в интегрированной среде разработки Visual Studio компании Microsoft, когда в нём открыт файл интерфейса. Это такие синенькие квадратики с вертикальной стрелочкой. Если навести на них курсор мыши, то появится всплывающая подсказка: «Этот метод унаследован». Вот тут-то автора скрутило, ведь это совершенно неправильное утверждение! Методы интерфейсов можно только определять в классе, следующем интерфейсу, но никак не наследовать от него. Казалось бы, крупнейший в мире производитель средств разработки должен знать лучше.

Пришлось начать разбираться, что происходит, и оказалось, что не понимают смысла следования интерфейсу почти все работники сферы ИТ, кто имеют заметное присутствие в Интернет: в блогах, соцсетях и т.п. Это включает популярный сайт W3 Schools, по которому учатся многие начинающие разработчики. Он утверждает: «Интерфейс — это полностью абстрактный класс». Какая дичайшая чушь! Или этот сайт изначально занимается подрывной деятельностью против человечества, или неграмотный автор заблуждается, но этого никто не заметил. Оба варианта одинаково ужасны.

Вопрос, чем отличается абстрактный класс от интерфейса, каждый год задают на собеседованиях миллионам кандидатов на должность разработчика ПО. По-видимому, большинство отвечает на него неправильно, и так же по-видимому это устраивает большинство нанимателей. Это тихий ужас, потому что в индустрии ИТ, оказывается, работают десятки миллионов некомпетентных сотрудников.

Абстрактный класс — это выкройка или чертёж. Люди не носят выкройки: они носят одежду, скроенную по выкройкам. Люди не живут и не ездят в чертежах: они живут в домах и ездят в автомобилях и поездах, построенных по чертежам. Точно так же, абстрактный класс является шаблоном для создания реальных объектов, порождённых от него.

Интерфейс — это лишь каталог. Люди не пользуются каталогами. Они пользуются товарами, которые заказывают из них. Точно так же, интерфейс используется, чтобы узнать, какие функции содержатся в классе, который следует интерфейсу.

Создать экземпляр интерфейса невозможно. Можно только создать экземпляр класса, следующего интерфейсу. Точно так же, можно обращаться к уже существующим экземплярам классов при помощи интерфейса. Заказать можно лишь объект конкретного класса, у которого есть указанные в интерфейсе методы. Поэтому интерфейс иногда называют договором: он определяет, что с этим объектом можно делать.

Каковы последствия незнания или недопонимания этих понятий? Это, конечно же, неправильный программный код, содержащийся в ПО, которым всё человечество пользуется. Одним из ярчайших примеров является возвращаемое значение, объявленное интерфейсом, а не конкретным классом, когда функция знает, что она возвращает. Да, встречаются ситуации, когда это точно неизвестно, и тогда выхода нет. Но если это известно, то возвращать интерфейс нет смысла. Другое дело — параметры функции. Тут интерфейсы полезны, потому что позволяют абстрагироваться от конкретного класса и написать более гибкий код. Общее правило простое: знаешь, с чем имеешь дело? Используй конкретный класс. Не знаешь? Используй интерфейс. В чём разница? Ничто не бывает бесплатным, особенно хорошее и удобное. Производительность может быть существенно ниже при использовании интерфейса. Это все мы наблюдаем повсеместно, о чём автор уже упоминал в предыдущих статьях цикла.

Как так получилось? Или знающих профессионалов просто нет, или они намеренно врут, или почему-то молчат. Первое сомнительно, второе маловероятно, третье весьма возможно. Враньё чревато разоблачением. Знающим невыгодно поправлять незнающих. Зачем плодить себе конкурентов? И вот так мощность целых электростанций тратится сначала на написание, а затем на выполнение медленного программного кода, тогда как цены на энергоресурсы высоки и продолжают расти, а ради обладания ими летят ракеты и взрываются бомбы. Оказывается, разработчики ПО тоже к этому причастны.

Почему-то так сложилось, что разработчики ПО окутаны некой дымкой загадочности и гениальности, но это только при первом знакомстве. Достаточно познакомиться с ними поближе, и внезапно некоторые из них оказываются далеко не такими загадочными и совсем не такими гениальными, как кажется со стороны. Постепенно приходит понимание, что это было вызвано лишь их богатым словарным запасом, состоящим из узкоспециального жаргона, сокращений, оборотов речи и прочей подобной мишуры и шелухи. На поверку под ними оказываются личности со странностями недалёкого ума. Да, они специалисты, но и пьяный токарь четвёртого разряда с маленькой фабрики, выпускающей втулки для садовых тележек, тоже специалист. Объединяет их то, что оба часто гонят брак, а отличает то, что токарь не сыпет заумными фразами вроде «поиск по бинарному дереву быстрее прямого перебора» или «машина состояний поддерживает асинхронное исполнение».

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

Кто-то скажет, что так я договорюсь до лозунгов «красных кхмеров», но суть именно такая: нельзя позволять разработчикам ПО вариться в собственном соку, в собственном котле. Это порождает целый ряд проблем, вызванных изоляцией, главная из которых — это непонимание потребностей пользователей, перерастающее в нежелание их понимать, а затем в презрение и, наконец, в ненависть к пользователям, которую они проявляют везде в профильных соцсетях. Именно изолировав себя от окружающих, разработчики создали атмосферу, в которой им сходит с рук воинствующая некомпетентность: их нишевый жаргон никто не понимает, и они используют его, чтобы выговориться из любых неприятных ситуаций. Способность разработчика обманывать заказчика и заговаривать зубы пользователям в результате оказывается одним из самых ценных его качеств. Это нездоровая ситуация, и из неё надо как-то выбираться, пока они всех нас не прикончили ошибками, вкрадывающимися всё больше во всё более критические системы.

К сожалению в нашей цивилизации отсутствует промежуточное звено между разработчиками и остальным населением, не обладающим специальной подготовкой. Нет арбитра, который может сказать: вот этот разработчик хороший, результаты его труда удовлетворительные, и его следует наградить, а вот этот никуда не годится, его продукты откровенный мусор, и его следует отправить на перековку. Вместо этого пользователи вынуждены лишь довольствоваться тем, что от щедрот своих выкатят разработчики, и жаловаться таким же пользователям, как они сами, работающим в службах поддержки. Это ещё хорошо, когда такие есть, хотя большинство из них являются рабами и цепными псами разработчиков. Когда же поддержку осуществляют они сами, то остаётся только уповать на какую-нибудь сверхъестественную силу.

Непонимание потребностей пользователей может иметь самые разные проявления. Чаще всего оно порождается нежеланием оторвать зад от кресла и сделать хотя бы несколько шагов, чтобы прочувствовать, что с продуктом что-то не так. Внезапно может оказаться, что забыли проверить ввод каких-нибудь данных, не убедились в совместимости, перепутали форматы, и т.д. Примеров миллионы, и с ними сталкиваются сотни раз на дню, но достучаться до разработчика и добиться их исправления крайне трудно. В чём дело? Да в простом: будучи некомпетентными, разработчики прежде всего боятся разоблачения и стремятся замолчать ошибки и недочёты, чтобы не оказаться в беде, впав в немилость руководства.

У токаря с фабрики за брак вычитают из зарплаты. А кто-нибудь когда-нибудь слышал, чтобы вычли у разработчика за ошибки? Автору не приходилось. Какие бы «баги» не сажали подкованные и красноречивые «чайники», им это всегда сходило с рук и лишь давало возможность сказать ещё одну бравурную речь о том, как они напряжённо трудятся. Вот так человечество вырастило касту избалованных шарлатанов с антисоциальными взглядами и привычками, считающую себя избранной и выше любой критики, пока токари с фабрики изо всех сил старались выпускать качественную продукцию.