Я думаю, что большинство читателей не имеют проблемы со зрением, но задумываются, что случится, если зрение откажет. Здесь должна быть картинка, но я её не вижу, поэтому интересующихся, как кодить, не глядя на экран, прошу под кат.
Так получилось, что с детства я обладаю сильно пониженной остротой зрения. Выглядит это так, как будто я вижу общую картину без какого-либо фокуса с большим количеством шумов.
Я выпускник магистратуры Института Математики, механики и компьютерных наук. Сейчас разрабатываю приложение для распознавания показаний медицинских приборов.
В конце школы мною было принято решение поступать учиться на программиста, уж очень мне нравилось, да и до сих пор нравится, возиться с компьютером. Хотелось не только пользоваться чужими поделками, но и научиться делать приложения самому.
К тому моменту я уже был достаточно опытным пользователем Windows. С точки зрения незрячего пользователя я уверенно управлялся с компьютером с использованием обоих скрин-ридеров, о которых речь пойдёт ниже. С точки зрения зрячего пользователя я знал что и где можно подкрутить в системе, чтобы она снова работала, и даже имел с этого первый доход.
Для озвучивания текста с экрана компьютера используются специальные приложения (читатели экрана). Под Windows самыми популярными являются Jaws от Freedom Scientific и опенсорсный NVDA.. Система Windows даже на тот момент была уже устроена так, что пользоваться ей полноценно можно было только используя оба скрин-ридера.
Конечно, когда дело доходило до ковыряний в bios или переустановки системы, приходилось привлекать помощь зрячих людей.
При разработке же круг проблем выглядит немного иначе.
Написание кода
Код, конечно, можно писать в блокноте на Windows, благо он очень хорошо озвучивается как Jaws так и NVDA. Но за рамками Pascal, на котором у нас, как правило, преподают основы программирования без автодополнения совсем никак.
Все задания я выполнял только на своём компьютере, так как мучить админов в лабораториях установкой NVDA мне не хотелось, а о цене на Jaws я просто молчу.
Среда Pascal ABC озвучивалась в достаточной мере для той теории, которую нам преподавали. Фокус скрин-ридера, это такая абстрактная точка, которая указывает область GUI, которая сейчас озвучивается скрин-ридером, сама хорошо помещалась в поле текстового редактора, и при удачной компиляции и запуске перемещалась в консоль. При неудачной же начинались чудеса с использованием различных хитростей скрин-ридера, которыми в этой статье перегружать читателя я не буду.
Как раз под конец изучения этой темы у меня ноутбук разделился на крышку и остальную часть, и на этом вся моя разработка на Windows прекратилась. Единственное что могу сказать, из того, что я когда-либо пробовал использовать для разработки на Windows из серьёзных IDE, нормально озвучивается только Visual Studio начиная с 2015-ой версии. А все удобные возможности, вроде автодополнений, доступны только с использованием платного Jaws.
Итак. Верный ноут повержен, нужен новый боевой конь.
Следующей машиной у меня стал MacBook. Знаю, дорого, но во первых это были те года, когда за одного Мак-Кинли давали примерно 30 Ярославлей, а во-вторых, для незрячих машины удобней просто нет.
С тех пор и по сей день разработку я провожу в Xcode, он великолепно озвучивается при помощи VoiceOver, правда сильно ограничен в выборе языка разработки: C, C++, Objective-C и Swift. Сколько бы я ни мечтал начать говнокодить на Python, никак не получается. В Visual Studio для Mac Python пока не завезли, а VSCode, сколько бы не пели разработчики, озвучивается так, что лучше бы не озвучивался. Т.Е. Если приложение не озвучивается, скрин-ридер либо озвучивает пустые поля или кнопки, либо совсем молчит, в VSCode интерфейс выглядит, как мешанина элементов, непонятных, несвязанных совсем между собой, половина не нажимается, половина вызывает какие-то новые рамки чуть ли не в другом конце окна.
Процесс разработки
Начало разработки совсем не отличается от того, что делают все: создание проекта, создание репозитория, если требуется, тем более Xcode GIT репозиторий создаёт сам.
Как я уже сказал выше, Xcode ограничен в выборе языка, поэтому как правило я использую или C++ или Swift.
Xcode сам создаёт файл Main и сам описывает функцию Main.
Как и все, я добавляю файлы по необходимости, но тем, без чего к сожалению, не получается обойтись в разработке сложных проектов, это автодополнения, начиная от сниппетов различных частей кода, вроде описания классов, или циклов, которые просто ускоряют разработку, и заканчивая методами классов или функциями с длинными заковыристыми названиями, которые просто очень сложно удержать в голове без доступа к визуальной памяти.
Отладка
Написанный код необходимо отладить. Хорошо, когда после написания проект собрался, программа запустилась и сразу правильно отработала, но когда такое было?
Во-первых, синтаксические, семантические и пунктуационные ошибки. Навигатор ошибок в Xcode доступен, и при том при выделении конкретной ошибки он перемещает курсор редактирования к нужной строке, но плохо, что он либо не показывает номер символа, где он эту ошибку увидел, либо не проговаривает его VO, и с этим смирится только остаётся.
Отдельно хочу сказать за скобки, насколько я знаю, зрячие тоже страдают от лишних открытых или закрытых скобок, но если зрячий человек может попытаться визуально их определить, если он всё таки чему-то учился и не кашу, а код пишет, он путаницу скобок разберёт. Без глаз — это плохо, частично выручает то, что сниппеты как правило включают нужное количество скобок, да и заботливая IDE закрывает сама скобки, если пользователь их открывает, но и тут ошибки возможны.
Единственный способ, это с начала вырезать тело функции, запустить, если собралось, вернуть тело, и так с каждым блоком кода, пока скобка не будет выявлена.
Проект собрался, программа запустилась, а в консоли внизу вместо ожидаемого и желанного "program ended with exit code: 0" появилось [LLDB], дебагером низкого уровня я пользоваться не умею, поэтому эту надпись я воспринимаю так, что что-то в логике программы пошло не так.
Сообщения отладчика редко бывают понятными. Поэтому можно утыкать всю программу брэйк-поинтами, но, не будучи зрячим, очень трудно понять, на какой точке ты остановился, или в каком месте программа падает. Поэтому лично я расставляю выводы вроде "test #", в разных частях Main, если приложение ничего не выводит, если выводит, расставляю выводы там, где приложение падает, к примеру начиная с входа в подозрительную функцию, и смотрю, до какого вывода программа доходит, после чего остаётся только выловить ошибку между достигнутым выводом и не достигнутым.
Выполняя тестовое задание для одной компании, я освоил панель Variable View, это такая панель в области дебагера, в которой отображаются живые переменные в том случае, если установлена точка останова, благодаря ей я разобрал сериализованный json на словарь, со вложенным массивом словарей.
Контроль версий
Xcode сам может работать с GIT, но есть вещи, которые лучше всего сделать через терминал.
Терминал
Терминал на Mac озвучивается, я имею в виду стандартный. Конечно, не удобно, когда VO проговаривает весь выводимый текст, но используя возможности VO можно прослушивать вывод по словам, строкам и даже по символам. А значит можно пользоваться терминалом, и даже одним из консольных текстовых редакторов, nano озвучивается просто блестяще. Помимо этого, озвучиваемый терминал даёт возможности незрячему программисту использовать пакетные менеджеры типа Home brew или cocoapods.
Заключение
Имея проблемы со зрением, можно стать или оставаться разработчиком. Есть достаточное количество различных программ экранного доступа для разных платформ: Jaws, NVDA и экранный диктор для Windows, orca в GNOME для Linux, VoiceOver на Mac, и редакторов кода, которые озвучиваются, таких как: Visual Studio на windows и Xcode на Mac. Тем более всё чаще попадаются сообщения о том, что в какой-нибудь редактор добавляют доступность, и я уверен, что со временем и VSCode и прочими Идеями можно будет пользоваться незрячим разработчикам.
Так что, конечно, берегите зрение всеми возможными способами, но если всё же случилось, из профессии вам уходить не придётся, просто необходимо приспособится к программам экранного доступа, и воспользоваться моим подходом или изобрести свой.
Если есть интерес, пишите в комментариях, какие области разработки в слепую вас интересуют, и я в будущих статьях их освещу. Думаю написать о том, как я GUI разрабатываю, но я открыт для ваших предложений.
