Однажды задолбался задавать на собеседованиях одни и те же вопросы без fun’а, родил функцию на Python. Веселился, придумывая. Кажется, решавшие задачку тоже получали свою порцию.

Собсно, вот код (Python 3.x):

import 'os'

func readFileId(names=[], mode):
    _ = ''
    id = -1
    for n in names:
        with os.open(n, 'w') as f:
            _ += f.read()
        f.close()
    print 'default: ' + id + ', actual: ' + _
    return id ? _ : id

Надо найти в нём ошибки. В зависимости от упоротости и перфекционизма количество ошибок от X до Z (подумал и решил таки не публиковать числа, лишняя подсказка получается). Кому и игнор PEP8 спать не мешает.

Суть упражнения (вполне типового, похожим джавистов на сертификациях кошмарят) в следующем:

• Проверка знания языка.
• Проверка внимательности.
• Проверка умения думать над кодом.
• Иногда показывает уровень чувства прекрасного.

Т.к. собираюсь написать более задорный вариант, этот «палю». Применять его больше не буду. Развлекайтесь.

PS. Тем, кто не согласен и у кого что-то не получается: пжлст, не пишите мне, что вы не поняли код, что это плохое упражнение и прочее. Значит, не для вас. Не беда.

В учебниках и разговорах постоянно про гибкую архитектуру. Гибкость то, гибкость сё. И толком не формализовали, особенно если взглянуть уровнем выше: какую объясняющую формулу (и понятную всем) дать, чтобы она работала для любого софта? Вот чтобы для разлапистых бекендов, для фронтового фреймворка, для мобильного приложения, для десктопной игрушки и т.д.

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

Внимайте:

Архитектура является тем более гибкой, чем больше в ней мест, в которые вы можете воткнуть костыль без переписывания остального кода. Костыль — ветвление, хардкод, жесть категории «if user == petrov { kill all }».

И никак иначе. Остальное не работает.

Фигня в том, что реальный мир, с которым соприкасается ваш софт, с его реальными людьми и прочими занятными явлениями является миром костылей. Мы вынуждены компенсировать чужие ошибки, например. Вынуждены учитывать, что в окружении сервиса любой элемент может упасть в любой момент времени. Мы должны учитывать пьяного дядю Васю на буровом тракторе в Кукуевке, испокон веков стоящей на трансгалактическом кабеле связи. Бухгалтеров. Детей с их разрушительными лапами. Распинаться так могу ещё долго.

И вот всё это хоть как надёжно друг с другом интегрируется только потому, что в каждом сервисе есть вёдра if’ов. Даже если вы по наивной прозрачности мозга выпустили в свет хрустальный сервис, уже через год в нём будет вот это вот всё. Окажется, что в стороннем API ошибка (или ошибки, если считать таковыми разработчиков API). Или к вам зайдёт очень грустная помощница очень главного директора с просьбой больше не делать с её директором то, что мы задумали делать со всеми. Или вам очень-очень надо оптимизироваться, ужимаясь в худенькую квоту серверов. Или клиент пишет «отправлять вам запросы могу ТОЛЬКО ТАК, всего вам хорошего, держитесь». Или бага в базе данных (тикет болтается с 2013 года), а вы это обнаружили за минуту до выкатки. Или от вас очень захотели работающего рендеринга сайта на IE под Mac OS образца 2007 года.

Так нафига страдать нервами по факту? Заранее, всё можно предусмотреть заранее. Не упарываться по фабрикам, возвращающим фабрики (привет джавистам). Не унифицировать всё до нечитаемой одной строчки. Не стремиться избавлять код от лишнего (что нередко не лишнее, но те части нужной реальности, что не попадают в вашу чистую модель). Не городить тонну абстракций. Пара лет эксплуатации и на активно живущем сервисе вас проклянут, пытаясь не убиться в попытках сберечь красоту (забьют болт и начнут запросто костылить, что будет гораздо уродливее на фоне ваших абстракций).

Архитектура (и код) должна отражать реальный мир. Реальную задачу и её прогнозируемые вариации. API отдаёт пять видов ошибок (не смогли разработчики в унификацию, потому в одном случае код есть, в другом нет, в третьем список ID хардкодом в тексте сообщения, в четвёртом списка нет аще, в пятом код ошибки в некоторых случаях является кодом удачной операции)? Делайте пять классов на каждый вид. Не, блин, унифицируйте, блин. Завтра они добавят шестую ошибку. Послезавтра заказчик попросит в третьем варианте ошибки дополнять своими данными. И всё, хана вашим красотам.

Чем чаще пробую этот подход на проектах, тем больше нравится. Да, при первом и втором взглядах возникает ощущение избыточности кода. Наивности. Излишней прямоты. Ахаха, вместо фабрики абстрактных ящиков копипаста десяти ящиков, отличающихся… ну… тут породой дерева, тут гвоздиком, тут наклеечкой, а здесь немножко круглый. А могла быть фабрика! Могла бы. И, возможно, будет. Только через год-другой эксплуатации в бою. А то и три. А лучше десять. И то при достаточном экономическом обосновании. Ведь, что смешно, нередко эти десять ящиков ещё и работают лучше фабрик.

Слава костылю! Костылику слава!