Зачем разработчику издеваться над собственным кодом
Проблема решена: 317 кликов исправили ошибку
В 1992 году я считал себя лучшим программистом в мире. В свое оправдание могу сказать лишь, что тогда я только закончил колледж (это было еще до появления Интернета) и жил в Боулдере, штат Колорадо, подрабатывая в мелких компаниях – я почитал за большую удачу возможность просто услышать о других программистах, не говоря уже о том, чтобы повстречаться с ними.
В итоге я познакомился с человеком по имени Билл О’Нил, который нанял меня в качестве программиста, работающего по контракту. Он создал компанию с довольно неоригинальным названием Computer Research & Technologies, и мы стали работать над различными задачами вместе.
Мы занимались разработкой CRUD-приложений [Create, Read, Update, Delete – вариант приложения с базовыми функциями создания, просмотра, обновления и удаления записей в базе данных – прим. перев.] для бизнеса на Visual Basic и FoxPro под Windows 3.1 (и иногда под DOS, так как предчувствовали, что новомодный графический интерфейс останется с нами надолго).
Билл был первым профессиональным программистом, с которым я когда-либо работал. Да что тут говорить, он был первым программистом вообще, с которым я когда-либо работал. Он выдавал мне техзадание, по нему я писал программу на Visual Basic и затем отдавал ее на проверку Биллу. После этого он спокойно объяснял мне, что мой код никуда не годится.
Пара примеров:
- Порядок табуляции: Неправильный.
- Вводим число вместо текста: Ошибка.
- Вводим дату из прошлого: Ошибка.
- Вводим слишком много символов: Ошибка.
- Выравнивание элементов интерфейса: Не работает.
- Работает ли программа с необычными символами в именах, как, например, в «О’Нил»? Нет.
Меня удивило то, что проблема была не в самом коде. Иногда он делал мне замечания по поводу того, как я пишу и структурирую свой код. Я боялся отдавать ему свою работу на проверку. И постепенно на горьком опыте я познал, что самое сложное при написании кода – это исключить тысячи возможных ситуаций, в которых приложение может работать неправильно: большинство из них зависит именно от пользователя.
Таким был мой первый опыт работы с «системой наставничества», и благодаря Биллу я научился относиться с глубоким уважением к искусству разработки ПО. Не знаю, чем Билл занимается сейчас, но, где бы он ни был, я снимаю перед ним шляпу. Мне не всегда нравилось то, чем я занимался, но, научившись самодисциплине в процессе тестирования (и «взламывания») своего кода, я, безусловно, вырос как разработчик.
Конечно, всегда хочется переложить свою ответственность на плечи мифического тестировщика. Если вам когда-нибудь посчастливится поработать с одним из них, то вам нужно опасаться профессиональных тестировщиков. Они вселяют ужас. Просмотрите список того, что «обязательно нужно протестить», и вы тут же вспомните все самое худшее, что с вами было.
Мне кажется, отправной точкой в карьере разработчика является тот момент, когда ты понимаешь, что твой главный враг – это ты сам, и победить можно, лишь смирившись с этим. Действуйте так, будто вы и есть ваш злейший враг. Крушите свой интерфейс. Крушите свой код. Издевайтесь над своей программой.
Это значит, что разработчики должны иметь хорошее представление, по крайней мере, о самых распространенных ошибках, которые обычно допускают программисты. Вы – тестировщик №0. Это ваша обязанность.
Для начала рассмотрим типичные заблуждения разработчиков об именах, предложенные Патриком МакКензи:
- У каждого человека есть только одно каноническое полное имя.
- У каждого человека есть только одно полное имя, которое он использует.
- В данный момент у каждого человека есть только одно каноническое полное имя.
- В данный момент у каждого человека есть только одно полное имя, которое он использует.
- У каждого человека ровно N имен, независимо от значения N.
- Имя человека можно записать определенным количеством символов.
- Имена людей не меняются.
- Имена людей меняются, но только в ограниченном числе случаев.
- Имена людей записаны в кодировке ASCII.
- Имена людей записаны только в одной кодировке.
Это лишь первые 10 заблуждений. В списке есть еще 30. Помимо этого, еще много записано в комментариях, если вам этого не достаточно. Может быть, вам понравятся заблуждения разработчиков о времени?
- В сутках 24 часа.
- В месяце либо 30 дней, либо 31 день.
- В году 365 дней.
- В феврале всегда 28 дней.
- Любой 24-часовой период всегда начинается и заканчивается в один и тот же день (или неделю, или месяц).
- Неделя всегда начинается и заканчивается в один и тот же месяц.
- Неделя (или месяц) всегда начинаются и заканчиваются в один и тот же год.
- Компьютер, на котором запущена программа, всегда будет находиться в часовом поясе GMT.
- Хорошо, допустим, что это не так. Но, по крайней мере, часовой пояс, в котором должна работать программа, никогда не сменится.
- Когда программа будет введена в коммерческую эксплуатацию, то часовой пояс точно не будет меняться.
- Системное время всегда будет соответствовать точному местному времени.
- Системное время всегда будет соответствовать времени, которое не сильно отличается от местного.
- Если системное время отображается неправильно, то оно будет отличаться от фактического на определенное количество секунд.
- Часы на сервере и клиентской машине показывают одно время.
- Часы на сервере и клиентской машине показывают примерно одно и то же время.
Разве есть еще? Конечно, есть! Есть даже целый дополнительный список того, что МакКензи забыл включить в тот громадный общий список.
Катастрофическая ошибка: Пользователь пытался использовать программу по назначению. Возможные действия: 1) уничтожить компьютер; 2) заплакать
Думаю, схема ясна. Это и есть программирование. Мы ведь делаем все это ради развлечения, не забыли?
Но, как говорят по ТВ: «Стойте, есть еще кое-что!» Серьезно, ребята, куда вы уходите? Вернитесь. Есть еще масса других заблуждений, о которых вы должны знать:
Заблуждения разработчиков о географии
1. Географические объекты имеют лишь одно официальное название
В некоторых местах используется несколько языков и, соответственно, несколько названий, которые могут отличаться друг от друга. Пример – Женева (нем. Geng, фр. Genève, итал. Ginevra).
2. Географические объекты в каждом языке имеют лишь одно официальное название
Возможно, это верно для сверхцентрализованных государств, никогда не меняющих своего мнения. Мой дом находится на холме, у которого есть два названия. Каждое из них зависит от карты, на которую они нанесены. На топографических картах (используемых военными) он носит название «Антлисберг» (Äntlisberg), в то время как на карте города он значится как «Энтлисберг» (Entlisberg): оба названия официальные.
В названиях улиц Тайбэя на латинском языке использовались разные типы транслитерации в зависимости от квартала, поэтому официальные названия улиц в этом городе могут меняться.
3. Названия географических объектов соответствуют правилам записи символов в алфавите данной страны
Географические объекты обычно носят очень странные названия, так как зачастую были придуманы до того, как появился язык и были закреплены его правила: поэтому данное утверждение неверно. К примеру, по правилам немецкого языка последовательность букв «ue» является эквивалентом «ü». Это верно потому, что звук «üe» в немецком языке больше не используется. Название одного из холмов Цюриха пишется как «Üetliberg» (Утлиберг) (и произносится соответствующим образом).
4. Названия географических объектов можно записать с помощью стандартного набора символов алфавита данной страны
Один из островов архипелага Кергелен (принадлежащих Франции) записывается как «Île de Croÿ» (Иль-де-Крои). Большинство французов не знают, как ввести символ «ÿ».
5. Названия географических объектов можно записать с помощью расширенного набора символов алфавита данной страны
Это было бы справедливо, если бы улицы не называли в честь иностранцев с необычными вариантами написания имен. В Париже есть улица Белы Бартока (Béla Bartók). Во французском алфавите нет символа «ó».
6. У географических объектов есть лишь один официальный адрес
В Женеве есть дамба, расположенная на реке Рона и, соответственно, на границе двух государств. Поэтому в Швейцарии и Франции она носит разные названия.
7. В каждом государстве есть своя столица
Не в Швейцарии. Правительство страны располагается в Берне, но официально этот город столицей не является.
8. Здания не могут перемещаться
В Цюрихе здание весом 6200 тонн передвинули на 60 метров для того, чтобы построить железную дорогу.
9. В почтовом адресе всегда указывается название улицы
Во многих удаленных точках Европы одного названия небольшого поселения достаточно для записи почтового адреса.
10. Код языка всегда совпадает с кодом соответствующей ему страны
Код Японии записывается как «jp», а код японского языка – «ja».
Заблуждения разработчиков об адресах
1. Все адреса начинаются или, по крайней мере, содержат порядковый номер здания
Пример: Великобритания, WC2E 9DD, Лондон, Королевский театр Ковент-Гарден.
2. Если у здания есть порядковый номер, то он будет записан только цифрами
Примеры: EC2A 4BX1A, Лондон, Бонхилл-Стрит, 4-5 и TS4 2HT, Мидлсбро, Эгмонт-Роуд, 1А.
3. Нет зданий с порядковым номером 0
Пример: TS4 2HT, Мидлсбро, Эгмонт-Роуд, 0.
4. По крайней мере, нет зданий с отрицательным порядковым номером
Гай Чисхолм приводит такой пример: RG14 7QS, Ньюбери, Майнус-Уан (Minusone) Прайори-Роуд.
5. У здания не может быть одновременно и имени, и необычного номера
Пример: HU5 2RD, Халл, Принцесс-Роуд, 4-6, Идас Корт.
6. Если у здания есть название, то у него не будет порядкового номера (и наоборот)
Пример: Великобритания, EC1N 8QX, Лондон, Саффрон-Стрит, 60-66, Зиккурат-билдинг, квартира 1.4.
7. На одной улице один порядковый номер может быть только у одного здания
Разница между SA18 3QJ, Амманфорд, Тайкроус, Амманфорд-Роуд, 50 и SA18 3YF, Амманфорд, Лландиби, Амманфорд-Роуд, 50 составляет около 4 миль (Google Maps).
8. Если в одной из строк адреса есть число, то оно обозначает порядковый номер здания
Великобритания, EC1N 8FH, Лондон, Сафрон-Хилл, 44, Дом Да Винчи, квартира 18.
Кроме этого, могут упоминаться номера в отеле, а также номера этажей и блоков и организации, содержащие числа в своем названии.
Адриен Пирар ссылается на адрес в Японии, содержащий 15 цифр в 6 отдельных числах (если считать индекс одним числом, то 5).
Адрес записывается в формате: 980-0804 (индекс), Мияги-Кен (префектура) Сендай-Ши (город) Аоба-Ку (район) Кокубунчо (субрайон) 4-10-20 (номер подрайона, номер квартала, номер здания) Сендай (название здания) 401 (номер квартиры).
9. Тогда первая строчка в адресе всегда начинается с порядкового номера здания
[речь идет о формате записи адреса в англоязычных странах – прим. перев.]
Одно из исключений: WC1V 7BN, Лондон, Хай-Холборн, 311-318, 3 этаж.
10. У здания может быть лишь один порядковый номер
Бентон Лам в качестве исключения предлагает следующий пример из Специального административного района Гонконга. В нем указывается как номер дороги (14), так и номер группы строений (3): HKSAR, Айленд-Ист, Тайку-Ван-Роуд, 14, Ситиплаза, 3, 15/F.
11. Число строений на улице есть разница между наибольшим и наименьшим значением порядкового номера зданий
Тибор Шульц говорит о том, что номера зданий могут быть пропущены, например, когда на улице с одной стороны расположены здания с четными номерами, а с другой – с нечетными; несколько зданий могут иметь один номер (как в случае с недавно построенным зданием) или одно здание может иметь сразу несколько номеров.
Кирилл Чепелов и Сами Лехтинен утверждают, что в Антибе, Франция, и сельских районах Финляндии некоторые здания нумеруются в зависимости от того, на каком расстоянии от начала дороги они находятся. Например, Лонг-Роуд, 65, означает, что здание находится в 750 метрах от места, где начинается данная дорога.
12. Если номера зданий на правой стороне дороги четные, то на другой стороне они должны быть нечетными
Кирилл Чепелов рассказывает, что на Бульваре Теофиля Сюэра, Монтрёй, Сен-Сен-Дени, Франция, по обе стороны дороги располагаются только четные номера зданий, также как и в некоторых других городах и департаментах.
13. В названии здания не может упоминаться число
Бен Тилли сообщает об адресе: США, 02109, Бостон, Массачусетс, Тен-Пост-Офис-Сквер – и он, судя по всему, отличается от адреса: США, 02109, Бостон, Массачусетс, Пост-Офис-Сквер, 10.
14. По крайней мере, можно опускать нули, идущие впереди
Шон Крэмптон сообщает о доме, расположенном по адресу Пало-Альто, Альма-Стрит, 101, где комнаты под номерами 1 и 001 находятся на разных этажах.
15. Если на улице есть здание A, то на ней не должно быть здания Альфа
Дуглас Перро рассказывает, что жил в блоке одного из больших общежитий, в котором были блоки от A до Z, а также блоки Альфа, Бета, Гамма, Дельта и Тета. Почта и службы доставки постоянно путали блоки A и Альфа. В то время он жил по адресу: 33613, Тампа, Флорида, 14100 N 46-Стрит, Альфа, 39.
16. В название улицы не могут входить числа
IP13 6SU, Вудбридж, Севен-Гарденс-Боро, 8 (сообщил Рафаэль Манкин).
17. Хорошо, но числа в названиях улиц записываются словами, не цифрами
Ян Йонгбум говорит о том, что в Нидерландах улицы могут содержать числа, записанные цифрами, например, Плейн 1944 в Неймегене.
18. Если названия улицы и здания содержат числа, между ними должен быть разделитель
Еще один пример от Яна Йонгбума: Гондель, 2695 в Лелистаде означает «район Гондель, улица 26, дом 95».
Теперь я не стану винить вас, если вы решите бросить программирование. Но мне кажется, нам нужно сделать друг для друга то же, что 20 лет назад Билл сделал для меня – научить менее опытных разработчиков тому, что хороший программист знает, что он должен пропустить свой код через самые жесткие тесты.
Иначе я вам гарантирую, что это сделают другие. А когда это произойдет, то либо конкуренты вас обгонят, либо из-за вас у службы поддержки будет гораздо больше работы. Даже не знаю, что хуже.
P.S. Больше материалов по теме стартапов в наших блогах на Geektimes и Megamozg.