Хабрахабр

[Из песочницы] Разработка кода не глядя

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

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

Сейчас разрабатываю приложение для распознавания показаний медицинских приборов. Я выпускник магистратуры Института Математики, механики и компьютерных наук.

Хотелось не только пользоваться чужими поделками, но и научиться делать приложения самому. В конце школы мною было принято решение поступать учиться на программиста, уж очень мне нравилось, да и до сих пор нравится, возиться с компьютером.

С точки зрения незрячего пользователя я уверенно управлялся с компьютером с использованием обоих скрин-ридеров, о которых речь пойдёт ниже. К тому моменту я уже был достаточно опытным пользователем Windows. С точки зрения зрячего пользователя я знал что и где можно подкрутить в системе, чтобы она снова работала, и даже имел с этого первый доход.

Под Windows самыми популярными являются Jaws от Freedom Scientific и опенсорсный NVDA.. Для озвучивания текста с экрана компьютера используются специальные приложения (читатели экрана). Система Windows даже на тот момент была уже устроена так, что пользоваться ей полноценно можно было только используя оба скрин-ридера.

Конечно, когда дело доходило до ковыряний в bios или переустановки системы, приходилось привлекать помощь зрячих людей.

При разработке же круг проблем выглядит немного иначе.

Написание кода

Но за рамками Pascal, на котором у нас, как правило, преподают основы программирования без автодополнения совсем никак. Код, конечно, можно писать в блокноте на Windows, благо он очень хорошо озвучивается как Jaws так и NVDA.

Все задания я выполнял только на своём компьютере, так как мучить админов в лабораториях установкой NVDA мне не хотелось, а о цене на Jaws я просто молчу.

Фокус скрин-ридера, это такая абстрактная точка, которая указывает область GUI, которая сейчас озвучивается скрин-ридером, сама хорошо помещалась в поле текстового редактора, и при удачной компиляции и запуске перемещалась в консоль. Среда Pascal ABC озвучивалась в достаточной мере для той теории, которую нам преподавали. При неудачной же начинались чудеса с использованием различных хитростей скрин-ридера, которыми в этой статье перегружать читателя я не буду.

Единственное что могу сказать, из того, что я когда-либо пробовал использовать для разработки на Windows из серьёзных IDE, нормально озвучивается только Visual Studio начиная с 2015-ой версии. Как раз под конец изучения этой темы у меня ноутбук разделился на крышку и остальную часть, и на этом вся моя разработка на Windows прекратилась. А все удобные возможности, вроде автодополнений, доступны только с использованием платного Jaws.

Верный ноут повержен, нужен новый боевой конь. Итак.

Знаю, дорого, но во первых это были те года, когда за одного Мак-Кинли давали примерно 30 Ярославлей, а во-вторых, для незрячих машины удобней просто нет. Следующей машиной у меня стал MacBook.

Сколько бы я ни мечтал начать говнокодить на Python, никак не получается. С тех пор и по сей день разработку я провожу в Xcode, он великолепно озвучивается при помощи VoiceOver, правда сильно ограничен в выборе языка разработки: C, C++, Objective-C и Swift. Т.Е. В 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, но есть вещи, которые лучше всего сделать через терминал.

Терминал

Конечно, не удобно, когда VO проговаривает весь выводимый текст, но используя возможности VO можно прослушивать вывод по словам, строкам и даже по символам. Терминал на Mac озвучивается, я имею в виду стандартный. Помимо этого, озвучиваемый терминал даёт возможности незрячему программисту использовать пакетные менеджеры типа Home brew или cocoapods. А значит можно пользоваться терминалом, и даже одним из консольных текстовых редакторов, nano озвучивается просто блестяще.

Заключение

Есть достаточное количество различных программ экранного доступа для разных платформ: Jaws, NVDA и экранный диктор для Windows, orca в GNOME для Linux, VoiceOver на Mac, и редакторов кода, которые озвучиваются, таких как: Visual Studio на windows и Xcode на Mac. Имея проблемы со зрением, можно стать или оставаться разработчиком. Тем более всё чаще попадаются сообщения о том, что в какой-нибудь редактор добавляют доступность, и я уверен, что со временем и VSCode и прочими Идеями можно будет пользоваться незрячим разработчикам.

Так что, конечно, берегите зрение всеми возможными способами, но если всё же случилось, из профессии вам уходить не придётся, просто необходимо приспособится к программам экранного доступа, и воспользоваться моим подходом или изобрести свой.

Думаю написать о том, как я GUI разрабатываю, но я открыт для ваших предложений. Если есть интерес, пишите в комментариях, какие области разработки в слепую вас интересуют, и я в будущих статьях их освещу.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть