Про эффективность инновационных методов
21 век же! технологии проникают в образование.
вот и решили в нашем местном министерстве провести школьный этап олимпиады по предметам в онлайн-режиме. тут и организация нужная нашлась с подходящим софтом. деньги на такое дело в бюджете находятся легко и в достатке - это ж ай-ти, мать его ити!
контракт заключили, провели - красота!
чё раньше так не делали? сплошные плюсы же:
- разгрузили учителей. им не надо готовить задания, организовывать проведение;
- учебный процесс не прерывается. дети участвуют из дома в любое удобное время;
- никакого скопления детей - просто супер, с эпидемиологической точки зрения;
- никто не попал под машину и даже не поскользнулся по пути на олимпиаду.
и самое главное - благодаря беспристрастной проверке результатов компьютерной программой, учителям не удалось "завалить" ни одного талантливого ученика, и на городской уровень по физике вышло целых 200 человек, а не 50, как обычно. отчёт по итогам школьного этапа шикарен: процесс оптимизирован, да ещё и с использованием инновационных методов, да ещё и результат зашкаливает - а это значит и премия, и деньги на дальнейшую оптимизацию.
технологию обкатывали пока только на школьном этапе, поэтому городской этап прошёл по-старинке: очно.
собрали этих 200 юных эйнштейнов, да ньютонов с резерфордами в одну из школ. едва нашли, куда усадить.
раздали бланки с заданиями.
примерно половина встали и вышли, как только прочитали задания. в следующие 10 минут ушли ещё примерно три четверти оставшихся. работы на проверку сдали около тридцати человек.
теперь, внимание, вопрос: откатят ли в следующем году школьный этап "как было", или распространят инновацию на городской?
Как гуманитарий программу оптимизировал
На досуге я иногда пишу скрипты для GTA (только для одиночной игры, если что) на Sanny Builder Script и JavaScript и балуюсь программками на Python (а недавно по совету одного приятеля замахнулся на C# и Windows Forms). Надо оговориться, что вся моя скриптерско-программистская деятельность сугубо любительская и далека от профессионализма, поэтому я не претендую ни на истину в последней инстанции, ни на звание знатока. Тем не менее в моём скромном опыте бывают и успехи, в том числе поучительные. Вот об одном таком примере я и хочу рассказать.
Как-то раз, изучая tkinter для «Питона», я «заболел» грандиозной, но пока заброшенной идеей создать свой файловый проводник. Я умудрился даже сформировать его основу, которая, честно говоря, нравится мне и по сей день. Для программы задумывались списки файлов (избранное, копирование, перемещение, удаление и переименование), были заготовлены соответствующие вкладки, предусмотрены три строки с информацией и подсказками, работала настройка цветов элементов интерфейса, сохранение и загрузка цветовых схем (вдохновляясь разнообразием, которое давали некоторые старые программы, я заготовил энное количество таких схем), был довольно удобный механизм перемещения по файловой системе с помощью мыши и клавиатуры…
Но особой гордостью во время разработки стали иконки элементов, ведь, в отличие от некоторых режимов стандартного «Проводника» Windows, в моём великом детище пустые папки и папки с чем-нибудь имели разные значки, позволяя быстрее понять, есть ли смысл заглядывать внутрь.
Но было одно «но». Поначалу всё работало отлично, во время тестирования я не сталкивался ни с какими проблемами, однако, лазая по системным каталогам, я наткнулся на страшную папку, внутри которой оказалось больше 20 тысяч других папок. На открытие этого монстра моей бедной программе пришлось потратить около 23 секунд, что даже при обновлении окна, согласитесь, никуда не годится, ибо та же самая папка в «Проводнике» Windows открывалась почти мгновенно. И тут начались мучительные поиски причины тормозов…
Вооружившись таймером (внутри кода, естественно), я перебрал массу вариантов, что могло быть не так, но тщетно. Как вдруг помог метод тыка: с мыслью «а почему бы и нет» я просто — как мне тогда казалось — поменял местами несколько строк, запустил программу, уже не питая особых надежд на успех, нашёл злополучную папку — а она неожиданно открылась за восемь секунд! Вернувшись к коду, я осознал, что́ вызвало такой ощутимый прирост.
Этот момент умелые программисты наверняка оценивают сразу, уже на автомате, но я-то не программист, поэтому нещадно тупил. Итак, дело, по-видимому, оказалось в… порядке условий. Код, рисующий значки элементов, работал по следующему алгоритму: если элемент — диск, то рисуем иконку диска, если файл — то файла, если папка — то пустой или непустой папки. Из-за удачного предыдущего опыта (до обнаружения страшной директории) и сосредоточенности на других деталях программы я упустил из виду это место, а после чудесного прорыва сделал для себя такой вывод: чтобы программа не проверяла лишние условия, тратя на это драгоценные, как выяснилось, миллисекунды, условия в цепочке if else следует располагать в порядке убывания вероятности истинного результата. А что вероятнее встретится в файловой системе: диск, папка или файл? Разумеется, последние два объекта — наиболее частотные, диски же можно пересчитать по пальцам. Расставив условия сообразно этим вероятностям, я получил почти трёхкратный прирост скорости программы.
С того момента прошло немало времени, местами программа ощутимо поменялась, рисование значка диска было вынесено в отдельное место, и вообще я теперь уже сам путаюсь в собственных нагромождениях кода. Но кусочек с порядком условий стал выглядеть так:
Так как я нисколько не специалист, я не берусь судить, насколько верны выводы, сделанные мной на основе такого личного опыта. Во всяком случае, перед публикацией этой заметки я снова закопался в уже порядком подзабытый код и всё с тем же таймером опять сравнил эти два порядка условий — результат остался прежним. Если моё понимание верно, на что я надеюсь, этот пример может послужить хорошим уроком (в первую очередь мне самому), как расстановка банальных if’ов способна радикальным образом влиять на скорость выполнения программы.
Всем спасибо за прочтение и рабочего кода!
Оптимизация тогда и сейчас...
Я и действительность
Я незаменим!
За что именно платят программистам
Я работаю техлидом на крупную группу европейских медицинских компаний. Конкретно наша занимается элайнерами - это очень популярный в последние годы на западе метод коррекции прикуса путем последовательного ношения наборов индивидуально изготовленных прозрачных брекетов (точность изготовления очень высокая). Все взаимодействие с клиентами ведется в Европе (сейчас компания работает больше чем в 10 странах ЕС), но при этом план лечения, визуализация и сами элайнеры делаются в лаборатории в США. Ну и как это обычно бывает, для продаж, работы дантистов, пациентов и собственно лаборатории есть набор сервисов, написанных в разное время, которые с собой изначально ну никак не взаимодействовали. Работа над тем, чтобы весь этот зоопарк сервисов купленных в разное время компаний заставить работать вместе, кипит уже очень давно.
И есть у нас такой кейс - иногда план лечения составляется неправильно и его направляют на доработку. Пустяковая работа на 30 секунд - скопировать комментарий к изменению статуса, зайти на портал лаборатории, изменить статус там, добавить комментарий. Тем не менее, в определенный момент у моей команды случился пустой бэклог и мы взяли автоматизацию этого как маленькую фичу на один спринт. Работы там было на день по разработке и еще на пару дней по тестированию, основное время было потрачено на коммуникацию с командой лаборатории в Техасе (разница во времени дикая).
После релиза за неделю мы автоматически обработали 900(!) запросов. Это 7,5 часов - с учетом обеда рабочий день отдельного сотрудника. Это 4 рабочих дня в месяц уже сейчас, а компания очень активно развивается и это число наверняка как минимум удвоится за 2023 год.
И это маленькая фича. При релизе больших кусков функционала экономия может достигать нескольких тысяч человекочасов в месяц.
И вот за это компании платят нам деньги.