Вражеский нейлон

На снимке - здание Вычислительного Центра Сибирского Отделения Академии Наук СССР в Новосибирском Академгородке, где произошли описанные здесь события.
На снимке — здание Вычислительного Центра Сибирского Отделения Академии Наук СССР в Новосибирском Академгородке, где произошли описанные здесь события.

История сия произошла в начале семидесятых годов прошлого века. Она наверняка тянет на сюжет крутого боевика, поскольку в ней присутствуют и засыпанный сибирскими снегами Вычислительный Центр и специальная бригада сотрудников КГБ во главе с майором и роскошная блондинка, которая разделась донага ради раскрытия большой тайны. Будут в этой истории допрос и обыск а также арест невиновного. А арестованным невиновным окажется сам автор.
Если интересно и есть время — читайте дальше.

Часть первая: Арест начинающего программиста

В начале семидесятых годов прошлого века я был студентом Новосибирского Государственного Университета и начинал учиться программированию в Вычислительном Центре Сибирского Отделения Академии Наук СССР (ВЦ СОАН, или просто ВЦ)  в Новосибирском Академгородке.

Так выглядел пульт управления машиной БЭСМ-6.
Так выглядел пульт управления машиной БЭСМ-6.

Вычислительный Центр был в то время в Академгородке главным аттракционом для приезжавших в него многочисленных делегаций из разных уголков СССР и из-за рубежа. Зарубежные страны тогда делили на братские (принадлежавшие к социалистическому лагерю), капиталистические и развивающиеся. Обмен делегациями в те времена был очень развит. Для жителей капиталистических стран это был практически единственный способ посетить СССР. А для жителей СССР и соцстран это была форма поощрения за хорошую работу и признание статуса человека. 

Делегации привозили к ВЦ на новеньких автобусах с надписью “Интурист” к главному входу. Под строгим наблюдением экскурсоводов и специальной сотрудницы ВЦ их вели в так называемый Машинный Зал. Там они проходили по широкому проходу вдоль поставленных по его бокам шкафов с тихо гудящим оборудованием. Многие шкафы были покрыты панелями с сотнями загадочно мигавших лампочек.

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

Дав время проникнуться этой атмосферой и осмотреть шкафы с оборудованием, членов делегации уводили в другое помещение и показывали нарисованные графопостроителем графики и чертежи. А под конец их проводили мимо печатающих устройств, изрыгающих из себя рулоны бумаги с цифрами и загадочными текстами и объясняли, что вот она — новая наука, не осциллографы и пробирки, а цифры!

После этого слегка обалдевших членов делегации садили в автобус и везли кормить в ресторан.

О чём экскурсантам не рассказывали, так это о том, что вычислительные машины после их посещения часто ломаются. Среди сотрудников ВЦ утвердилось мнение, что именно делегации в немалой степени виноваты в частых отказах ЭВМ (Электронных Вычислительных Машин, термин «компьютер» тогда ещё не применялся). Мол, ЭВМ-ам нужен чистый воздух, а посетители заносят с собой в Машинный Зал бытовую пыль.

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

Фотография из (почти) того времени: Космонавт Герман Титов в гостях у сибирских учёных
Фотография из (почти) того времени: Космонавт Герман Титов в гостях у сибирских учёных

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

Так выглядела перфокарта
Так выглядела перфокарта

А спустя отведенное время (несколько часов) — можно было забрать в том же окошке распечатку (рулон бумаги с напечатанными на нем результатами).
 
От студенческого общежития, где мы жили, до ВЦ было около километра. Вначале я, как и другие студенты, бегал несколько раз в день от общежития до ВЦ и назад, чтобы исправить найденные ЭВМ ошибки, перебить содержимое нескольких карточек и снова отдать колоду в окошечко.

Заметив моё усердие, мне выделили место за “студенческим столом” в одной из комнат Лаборатории Машинной Графики ВЦ. Это место выглядело как правый дальний угол стола, где мне можно было складывать мои распечатки и прочие материалы, а при наличие в комнате свободного стула даже и писать за столом.

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

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

Однажды я сказал старшему коллеге:
Странные какие-то эти паяльщики. Чего они в коридоре сидят? Своей комнаты у них нет?. — Его ответ меня немного напугал. Он сказал:
Ты бы лучше помалкивал. Неужели ты сам не догадался? Эти крепкие ребята — из КГБ. И иностранные делегации к нам больше не возят. Ты не обратил внимания?.

Как видите, пока автор вас не обманывает. Уже сотрудники КГБ а нашей истории появились. Перейдем теперь к аресту.

Хотя Вычислительный Центр принадлежал Академии Наук, был он в то время организацией со строгим режимом. Существовало несколько видов штемпельков со специальными знаками, чернильные следы от которых на внутреннем пропуске позволяли пройти в  определённые части (зоны) большого здания ВЦ.

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

Но вот как раз этот пункт режимных правил я нарушал. Дело в том, что в то время я завёл знакомство с несколькими молоденькими лаборантками отдела вычислительной техники, работавшими посменно, в том числе и в ночные смены. Эти знакомства позволяли мне пропускать свои колоды на ЭВМ не только без очереди, но и почти сразу забирать распечатки с результатами. Тем самым я мог полнее утолить мою жажду программировать. Но передо мной встала дилемма — с одной стороны, вечерами я могу много раз запустить мои программы, но с другой стороны — для этого я должен нарушать установленный режим работы ВЦ.

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

Пройдя по всем коридорам и проверив все двери, проверяющие удалялись в свою дежурку и оставались там до утра.
Избежать этой проверки было очень просто — в условное время надо было закрыть комнату на ключ, выключить свет и дождаться толчка в дверь. Спустя определённое время путь был свободен.

“Паяльщики» сидели за столом вечерами и ночами, но мои многочисленные проходы, похоже, у них особого интереса до поры до времени не вызывали.

Но однажды ситуация изменилась. Когда я в очередной раз, дождавшись окончания обхода Ночным Дежурным, прошмыгивал по коридору мимо очередного «паяльщика», он как-то очень пристально и недобро проводил меня своим взглядом.

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

Он попросил меня предьявить мой пропуск, внимательно его изучил, и изрек: «Что же Вы Режим нарушаете? Следуйте за мной».

Он завёл меня в свою служебную комнату и сказал, обратившись уже на ты: «Посиди тут у меня. Под арестом». После этого он вышел в коридор, закрыл дверь, провернул ключ в скважине и тяжёлыми шагами удалился.

Часа через полтора (что я за это время передумал, рассказывать не буду) он вернулся, и возвращая пропуск, укоризненно сказал: «Я сам всего не знаю. Но что-то тут… «, он сделал неопределённый жест рукой. «Сам понимаешь, кто такие в коридоре сидят. А  они зря сидеть не будут!», сказал он убежденно.

«Не попадайся больше!». С этим его напутствием в ушах я выбежал из здания ВЦ и припустил по заваленной снегом тропинке к моему студенческому общежитию.

А спустя какое-то время стол с «паяльщиками» исчез. Упомянутый коллега на эту тему пошутил так: «Наверное они всё припаяли, что надо было. Теперь машины будут как часы работать».

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

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

Как видите, я выполняю данные в начале рассказа обещания. Вот вам и арест и сибирские снега. Но моё личное участие в этой истории на этом закончилось.

Как? Наверняка возмутятся некоторые читатели. А где обещанная роскошная блондинка, её раздевание и страшная тайна?
Потерпите, уважаемый читатель, об этом — в следующей части.

Часть вторая: Рассказ понятого

Что было на самом деле, я случайно узнал примерно лет через двадцать. В город, где я тогда жил, приехал в командировку мой дальний знакомый, бывший инженер-электронщик из ВЦ. Он зашёл ко мне в гости. За стопочкой мы стали вспоминать прошлое и я рассказал ему о моём полуторачасовом аресте. И вот тогда он рассказал о таких гранях этой истории, о которых я и не подозревал. Вот что он рассказал:

Я тогда работал инженером-электронщиком. Как молодому сотруднику, смены мне доставались часто ночные.

Фотография из того времени: школьникам показывают, как работает графопостроитель.
Фотография из того времени: школьникам показывают, как работает графопостроитель.

В начале семидесятых годов мы провели в Машинном Зале ремонт, поставили устройства так, чтобы они производили большее  впечатление на иностранные делегации, которые нам тогда стали привозить чуть не каждый день.
И всё бы хорошо, но после этого стали наши ЭВМ ломаться чаще обычного. Особенно, если делегации из капиталистических стран к нам привозили. Сначала мы на эту тему острили, а потом корреляция стала недвусмысленной.

Приезжает делегация из Болгарии или Монголии — ЭВМ работают, а из Франции или США — ломаются, оперативную память после их ухода надо частично заменять.

Этим вопросом заинтересовались в местном отделении КГБ. Их вывод был прост: Капиталисты пытаются нам вредить. В  некоторых их делегациях есть люди с какими-то миниатюрными приборчиками. Эти приборчики и выжигают память наших ЭВМ.
Было решено поймать вредителей за руку.

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

Да вот беда — делегации из капиталистических иных стран, как и сотрудники проходили мимо их стола, а секретный прибор на них не реагировал. А вот память на наших ЭВМ выгорала.

Хоть плачь: поближе к обеду привозят делегацию, её проводят через Машинный Зал увозят от нас в ресторан обедать. А мы вместо обеда начинаем усиленно перепаивать блоки памяти.

Делать нечего. На высоком уровне было принято решение: иностранные делегации пока на ВЦ не возить.

И количество дневных поломок сократилось почти до нуля. Но… остались поломки вечерние. Нечасто, раз или два в неделю, почти точно в десять часов вечера память ЭВМ выгорала!

Как выяснилось, крепкие “паяльщики” действительно сидели за столом не зря. Оказывается, они не только изображали инженеров-электронщиков и наблюдали за стрелкой важного прибора. Кроме этого, они вели точный дневник с записью всех проходящих мимо их стола.

И этот дневник показал следующее — перед каждой вечерней поломкой в Машинный Зал входила красивая молодая блондинка. Пробыв там несколько минут, она выходила из Зала в сопровождении менее красивой брюнетки. А примерно через десять — пятнадцать минут (иногда к этому времени брюнетка уже одна возвращалась в Зал), инженеры делали в своём журнале запись о поломке ЭВМ. 
При этом передвижения самой брюнетки, её присутствие или отсутствие на поломки никак не влияли.

И вот, Дорогой Читатель, я приступаю к описанию развязки этой запутанной истории.

Как-то вечером к зданию ВЦ подъехала чёрная Волга. Из Волги вышли два человека — мужчина и женщина. Предупреждённый Ночной Дежурный проводил их к столу “паяльщика” и мужчина сел за стол рядом с ним. Женщину отвели в одну из соседних комнат.

В ожидаемое время в коридоре показалась роскошная блондинка и стала приближаться к дверям Машинного Зала. Когда она приблизилась к столу “паяльщиков”, приехавший на чёрной Волге мужчина неожиданно встал, и профессионально улыбнувшись, спросил:
— Вы — Сидорова Елизавета Петровна?
— А как Вы догадались? — кокетливо начала было блондинка. Но что-то ей подсказало, что это не время и не место для кокетства. И, сменив на полуслове интонацию и как-то погрустнев, она ответила просто: “Да”.

Майор Комитета Государственной Безопасности Волков, представился мужчина.
Прошу Вас пройти со мной.
—  А вы, лейтенант, — обратился он к «паяльщику», — пригласите понятых.

И майор завёл бедную Лизу в комнату, где их дожидалась женщина, как выяснилось — тоже офицер КГБ.

В качестве понятых были приглашены мой знакомый, рассказавший мне конец этой истории, начальница ночной смены перфораторщиц Зина Павловна, а также начальник смены, который сыграет решающую роль в разгадке этой тайны, и которого мы назовём Шурик.
Звали его по другому, но он был настолько похож на персонажа известной кинокомедии Гайдая “Операция Ы и другие приключения Шурика”, что по другому его мало кто звал.
Шурик был романтик и дотошный знаток ЭВМ. Он знал каждый их узел, сильно горевал  и просто физически заболевал, если эти узлы по непонятной ему причине выходили из строя. Несмотря на свой рассеянный и несолидный вид, он быстро дорос до поста начальника смены. В планируемую операцию он был посвящён в числе немногих. У него были свои гипотезы о том, как мог бы быть сделан прибор, от излучения которого столь дорогие ему ЭВМ ломаются. Ему страшно натерпелось на этот прибор взглянуть.

Заведя Лизу в комнату и дождавшись прихода понятых, майор предложил Лизе добровольно отдать прибор, который своим излучением ломает советские ЭВМ.

Лиза перепугалась. Тушь из её накрашенных ресниц потекла на прекрасное лицо. Но она собралась с мыслями и ответила, что не знает ни о каком приборе.

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

Он кивнул головой своей сотруднице. Та подошла к Лизе, быстро и профессионально всю её ощупала.
— Ничего нет, отрапортовала сотрудница.
— Тогда придётся осмотреть все внимательнее. Пусть она разденется. — приказал майор.

Да вы что, с ума сошли? — вскипела Зина Павловна, которая почувствовала себя защитницей прав всех обиженных женщин. Не при мужиках же!

Майора КГБ это не смутило. Он спокойно ответил Зине Павловне, что раздевание будет производиться в присутствии сотрудницы КГБ и её, как понятой, и за шкафом, стоящим в комнате.

Женщины зашли за шкаф. И уже через десяток-другой секунд сотрудница подала майору Лизин халатик и платьишко, которое та носила под ним.

Майор внимательно рассмотрел оба незатейливых предмета женской одежды.
Сначала он положил каждый из них на стол, разгладил и рассмотрел внимательно каждый квадратный дециметр с обоих сторон. Потом он внимательно прошелся взглядом вдоль каждого шва. А после этого поднял каждый предмет одежды перед собой и проверил их на просвет.
Но… ничего не нашел!

Раздосадованный, майор понюхал сначала халат, а потом платьишко. Но ничего кроме запаха молодого женского тела, как видно, не унюхал.

Зина Павловна вышла в это время из-за шкафа и с неодобрением наблюдала за действиями майора.
— Вы ещё на вкус попробуйте, осуждающе сказала она майору.
— Надо будет – попробуем — огрызнулся майор.
— Что там ещё на ней осталось? Строго спросил майор сотрудницу.
— Рубашка нижняя, бюстгальтер и трусы — по-военному чётко отрапортовала та.
— Давайте их сюда — приказал майор.

Ну вы вообще… Начала было Зина Павловна, но осеклась встретившись со строгим взглядом майора.

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

И опять ничего!

— Осмотрите её очень внимательно, — приказал майор сотруднице. — Волосы, подмышки интимные места. Сами знаете…

Через некоторое время сотрудница доложила, что ничего не найдено.
— Пусть одевается, не сдавался майор. Повезём её на Рентген.

Понятые мужского пола всё это время стояли у дверей и безмолвно наблюдали происходящее. Однако, когда майор собрался отдавать одежду сотруднице для передачи Лизе, Шурик встрепенулся, и внезапно спросил:
— А комбинация… нейлоновая?
— А бес её знает, ответил майор . — Точно — импортная. Тут вот чекушечка маленькая. Мэйд ин Франсе, написано. Хорошо пошито. Точно не подделка грузинская. Нет, точно импортная, — сделал окончательное заключение майор .
— Дайте её… мне. — попросил Шурик.
— Да девушка застыла ведь уже, холодрыга тут у вас, а она — голая, — начало было Зина Павловна, но опять осеклась под строгим взглядом майора.

Майор не не очень уверенным шагом подошел к  Шурику и передал ему женскую нижнюю рубашку.

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

— Нет, — с досадой сказал он. — Так ничего не понятно.

И неожиданно для всех, держа на вытянутой руке перед собой рубашку, он чуть не побежал в дальний угол комнаты к письменному столу.

Он пробежал при этом мимо майора, сотрудницы, а также мимо бедной Лизы, которая голая стояла за шкафом и от неожиданности только взвизгнула, прикрыв руками свои прелести.

Но Шурик даже не заметил ни конфузного положения Лизы, ни её прелестей. Его взгляд был прикован к листу бумаги, лежащему на столе. Подбежал к столу, Шурик быстро оторвал от листа уголок и расчленил его на множество мелких кусочков. Разложи в кусочки на столе, Шурик взял в руки рубашку и потёр её части друг о друга над кусочками. Некоторые кусочки бумаги подлетели вверх и пристали к рубашке.

“Я так и знал! Это она!”  Гордо произнёс Шурик, театрально повернувшись с рубашкой в руке к остальным, находившимся в комнате.

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

Но не до того было Шурику. Как бы споря сам с собой, он, задумчиво глядя в потолок, изрёк: “Но всё же надо провести натурный эксперимент!” И, неся перед собой на вытянутой женскую рубашку, Шурик двинулся в Машинный Зал.

Ничего пока не понимающему майору не оставалось ничего другого, как вместе с понятым двинуться за ним. Правда перед этим он приказал своей подчинённой — “Оставайтесь с ней здесь. Она может одеться”.

Войдя в Машинный Зал, Шурик громко сказал: “Сейчас будем проводить следственный эксперимент. Думаю, АВОСТы попрут”.

— Авосты — это кто? — Спросил майор, попытавшись вернуть инициативу в свои руки.
— АВОСТы — этот АВарийные ОСТановки, когда программы останавливаются, если в ЭВМ что-то ломается. —  доступно объяснил ему Шурик.

— Начинаю эксперимент! — Опять громко обьявил Шурик.

После этого он, к несказанному удивлению работников ночной смены, приложил Лизину рубашку к своей одежде, прижав её сбоку руками, как бы наполовину надев её. После этого он продефилировал в таком виде по проходу несколько раз взад и вперёд.
Проделав это, он громко объявил: “Всё. Ждём минут пять-десять”. И впился глазами в мигающие лампочки на панели.

Майор подошёл к нему и тоже впился.

Сначала всё шло как обычно. Лампочки как бы нехотя и хаотично мигали там и сям. Но прошла минута, и загоревшись, некоторые лампочки уже не гасли. Их становилось всё больше и больше.

“А вот и АВОСТы пошли”, — сообщил из угла комнаты зала чей-то голос.

Лампочки больше не гасли, а строили затейливые, сливающиеся вместе узоры.
“Много опять паять придётся, но зато причину знаем!” — С нескрываемым довольством в голосе сказал Шурик. Ох уж эта…

“…Лиза», — подсказали ему. “Молодец эта Лиза!” — неожиданно воодушевлённо произнёс Шурик.

— Так, что, не везти её на Рентген? — спросил ничего не понявший и сбитый с толку майор.

— Ну конечно нет, — горячо начал объяснять ему Шурик.

Понимаете, у нас оперативная память на катушечках магнитных. Катя, покажи товарищу катушечку.

Проворная сотрудница смены Катя быстро достала из стола малюсенькую катушечку, обмотанную тонюсенькими проводками. “Вот”. — Она подала катушечку Шурику.

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

Знамо дело, — подтвердил своё понимание майор, неожиданно перейдя на простонародный язык.
Буржуйский же, нейлон этот.

И, чтобы вернуть утраченную инициативу в свои руки, громко объявил «паяльщику», который тоже к этому времени переместился в Машинный Зал: “Операция завершена успешно!”

И распрямив плечи, орлом осмотрел окружающих.

«Паяльщик» быстро приблизился к нему и на ухо напомнил:
— Товарищ генерал велел сразу по окончании позвонить и доложить.
По всем правилам майору надо было бы уйти в другую, безлюдную комнату и доложить оттуда. Но его так распирало чувство гордости за столь удачно проведённую операцию, что он решил не следовать инструкции.

— Где тут у вас телефон? — громко спросил он, хотя и сам прекрасно видел его на одном из соседних столов.
— Вот — показали ему.

Подойдя молодеческим строевым шагом к столу, расправив плечи, с довольной улыбкой майор набрал известный ему номер.

Телефон был громкий, и все присутствующие в зале услышали суровый, усталый бас генерала:
— Слушаю.
— Товарищ Генерал, докладывает майор Волков, — заорал в трубку майор.
— Докладываю. Операция «Электрон» завершена успешно!

Генерал был, видимо, опытен и мудр. По крайней мере, таковым был его голос.
Не разделяя майорского энтузиазма, генерал сухо и конкретно спросил:
— Врага нашли?

Немного растерявшись, но быстро взяв себя в руки, майор бодро оттрубил:
— Нашли, товарищ Генерал!
— И кто это? — по прежнему без эмоций, но уже с лёгкой теплинкой в голос спросил заслуженный Генерал.

Оглядев окружающих, как школьник у доски в надежде на подсказку, майор начал
— Нейлон… но после небольшой заминки твердо и бодро закончил:
— Нейлон оказался вражеский, товарищ Генерал!

***
Как ты наверняка понял, дорогой читатель, обещанная в начале повествования страшная тайна состояла в том, что наши отечественные магнитные катушечки оказались чувствительны к электростатическому излучению, которое вырабатывалось от трения иностранной комбинации о прекрасное Лизино тело, а также от трения других нейлоновых предметов одежды о тела членов делегаций из капиталистических стран. 
Советская легкая промышленность, как и промышленность ряда социалистических стран, выпускала тогда нейлоновые рубашки, блузки, плащи и т.д. Пара таких рубашек была и у меня. Через непродолжительное время после надевания тело под ними покрывалось потом, поскольку нейлон был толстый и “не дышал”. Видимо именно поэтому он и не влиял на работу отечественных катушечек.
Огородиться от действия “вражеского” нейлона оказалось несложно. Шкафы с катушечками убрали вглубь зала, хорошенько заэкранировали и заземлили. А сотрудникам на всякий случай запретили носить на работе нейлоновые предметы одежды.

С колечками памяти мне пришлось пересечься ещё как минимум два раза.

После окончания НГУ я поступил работать на ВЦ и в своём карьерном росте в середине восьмидесятых дорос там до поста Учёного Секретаря Отделения Информатики ВЦ. Среди прочей рутинной работы мне пришлось несколько раз заниматься патентном на некую гениальную установку, позволяющую наматывать проволочку на магнитные колечки. Автором патента был один из инженеров ВЦ. Патент был зарегистрирован в ряде зарубежных стран. За поддержку патента ВЦ выплачивал ощутимую сумму из своего более чем скромного валютного бюджета.
Увы, время для патента было упущено. Поддерживали его несколько лет и платили за это валютой зря.

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

Теория была интересная, позволявшая в узких пределах корректировать содержание памяти, если катушечки работали ненадёжно. Но… время катушечек прошло.
Мне с большим трудом удалось убедить руководителя проекта, что тема неактуальна уже лет двадцать по всему миру. В конце концов он согласился с моими доводами и я сделал интерактивный курс по конечным автоматам. Но это — тема другого рассказа.

Владельцам современных смартфонов с сотнями гигабайт оперативной памяти наверняка трудно себе представить, что они носят в кармане компьютеры с памятью в сотни миллионов раз большей, чем располагали ЭВМ семидесятых годов прошлого века, бывшие гордостью всей огромной страны. Для хранения каждого бита информации тогда использовалась одно маленькое магнитное колечко с намотанной на неё проволочкой.
Своё колечко для каждого бита! Вдумайтесь: если бы оперативная память среднего смартфона начала двадцатых годов двадцать первого века была сделана из тогдашних колечек, их было бы столько много, что если бы их загрузить в большие грузовики, колонна грузовиков была бы длинной с экватор нашей матушки Земли.

***

Эта история взята из открытой книги, которую я начал писать и публиковать: Мемуары кочевого программиста: Байки, Были, Думы.


ссылка на оригинал статьи https://habr.com/ru/post/663838/

Подход к удалёнке в AirBnB

image

Сегодня мы объявляем, что сотрудники Airbnb могут жить и работать где угодно.

Наш подход к работе в Airbnb имеет 5 ключевых особенностей:

  1. Вы можете работать дома или в офисе — как вам удобнее
  2. Вы можете переехать в любую точку страны, например, из Сан-Франциско в Нэшвилл, и ваша зарплата не изменится.
  3. У вас есть возможность жить и работать в 170 странах до 90 дней в году в каждом месте.
  4. Мы будем регулярно встречаться для командных собраний. Большинство сотрудников будут контачиться лично каждый квартал примерно в течение недели (некоторые чаще)
  5. Чтобы осуществить это, мы будем работать в соответствии с многолетней дорожной картой с выпуском двух основных продуктов в год, что позволит нам работать четко скоординированным образом.

Почему мы выбрали такой подход

Мир стал более гибким. Наш бизнес не оправился бы так быстро после пандемии, если бы не миллионы людей, которые работали на удаленке и снимали квартиру через Airbnb.



У нас также был самый продуктивный двухлетний период в истории нашей компании — и все это при удаленной работе.


Два десятилетия назад стартапы Кремниевой Долины популяризировали опенспейсы и on-site perks.

Современные стартапы используют гибкость и удаленную работу. Я думаю, что через 10 лет это станет основным способом работы компаний.

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

Но есть и нюансы.

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

Правильное решение должно сочетать в себе эффективность Zoom и значимую человеческую связь, которая возникает, когда люди собираются вместе.

Наш подход пытается объединить лучшее из обоих миров.


Следите за новостями Мировоззрение Y Combinator в телеграм-канале.

Полезные материалы


ссылка на оригинал статьи https://habr.com/ru/post/663840/

Полный Гайд по Shopify

Всем привет! В этой статье я постарался посмотреть на Shopify со стороны разработчика и обычного пользователя, рассказал свой опыт и наблюдения при работе на разных темах. Если вы еще не знакомы с Шопифаем, то я также постараюсь донести основную информацию, которую вам нужно знать чтобы работать с темами и разрабатывать магазины на Шопифай. Еще можно писать плагины для Шопифай магазинов, но я этим не занимался, поэтому в данной статье будет информация про разработку тем.

Что такое Шопифай?

Шопифай это платформа на которой вы можете открыть магазин, если вам есть что продавать, а если вы разработчик вы можете разрабатывать темы или плагины. В Шопифае главная ценность это тема, ведь тема и является магазином, по сути. Поэтому выбор темы — очень важный шаг при открытии магазина.

Популярность Шопифая в России

Шопифай в России не очень популярен, это, скорее всего, обусловлено высокими ценами за тарифы + в связи с текущей ситуацией Шопифай приостановил работу в России (на разработку тем это не повлияло). Чтобы открыть свой магазин на Шопифай, вам нужно выбрать соответствующий тариф. Изначально при открытии магазина вам дадут 14 дней пробного периода. За это время вы можете понять нравится вам платформа или нет. После пробного периода вам будет предложено оплатить тариф и продолжить заполнение магазина.

Для разработчиков тарифов нет, главное указать, что вы используете магазин в качестве разработки. Для простоты работы рекомендую создать партнерский аккаунт. Партнерский аккаунт позволит вам видеть доступ ко всем магазинам, который есть у вашего аккаунта. Удобно когда вы кому-то помогаете с магазином или создаете магазин для заказчика на фрилансе.

Как видите у меня только один магазин и у него стоит тип Development. Это означает, что он используется для разработки. Еще как партнер вы сможете тестировать функции, которые еще не вышли. Как я и сделал, под Development написано Shopify Markets preview, я активировал эту функцию чтобы потестить. Когда вы тестируете какие-то не вышедшие функции у вас есть ограничения. На этот магазин тоже наложили ограничение, вот такая желтая плашка внизу страницы, которая везде меня преследует и напоминает о себе.

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

Отсутствие русского интерфейса

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

Зато в Шопифай есть русский язык для магазина. Главное не путать язык аккаунта с языком магазина.

Мультиязычность магазина

Вы можете перевести свой магазин на все популярные языки (не все темы поддерживают мультиязычность). Выберите тему на которой хотите поменять язык, после этого нажмите на кнопку Actions -> Edit languages. Вы попадете на страницу на которой вы сможете поменять язык темы или поменять написание какого-либо слова или предложения.
Важный момент: не все темы поддерживают несколько языков, прежде чем купить какую-либо тему, узнайте поддержку мультиязычности (если она вам нужна). К слову о темах, все темы от Shopify поддерживают мультиязычность.

Как выбрать тему?

Если вы решили купить тему где-либо, кроме официальных платных тем Шопифая, то будьте аккуратны, часто они продаются с ошибками кода, с отсутствием заявленных функций, ошибками в словах и прочими неприятными моментами. Из плюсов могу отметить поддержку после покупки, но и то не все саппорты отвечают быстро или выполняют работу качественно. В общем покупка, как их называют в Шопифае «third party themes», рискованный шаг. А если вы разработчик, можете спокойно выбирать тему Dawn и на ней тренироваться. Я поработал на нескольких платных темах и могу сказать, что Dawn — лучшая тема в которой я работал на данный момент.

Первые шаги в Шопифай

Первым делом заведите аккаунт в Shopify, если у вас его еще нет. Следующим шагом перейдите в админ панель вашего магазина, для этого после ссылки на ваш магазин поставьте слэш и введите admin. Выглядит вот так:

https://yourstoreurl.myshopify.com/admin

После того как вы попали в админ панель, опубликуйте тему, скорее всего, там будет тема Dawn:

Еще неплохой практикой будет пройти специальные гайды от Шопифая. Они проведут вас по всему, что нужно сделать чтобы ваш магазин заработал и его увидел весь мир, начиная от добавления продуктов и до настройки платежных систем. Находятся в правом верхнем углу, прямо возле вашего профиля:

Основные настройки магазина

Прежде чем продавать товары в вашем магазине, нужно его настроить. Настройки находятся в левом нижнем углу.

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

Перейдите в пункт Checkout и подробно изучите его, ведь в нем находится информация касательно оформления заказа в вашем магазине. Почему это так важно? Когда вы покупаете тему или используете бесплатную тему, данный пункт не является очевидным и скорее всего вы зададитесь вопросом: «Почему у меня нет иконки человечка в хэдере Ведь во многих темах иконка человечка (личный кабинет) завязан на этой настройке. Самый первый пункт в этой настройке как раз предлагает вам выбрать один из трех пунктов касательно личного кабинета пользователя в вашем магазине:

  1. Don’t use accounts
    Покупателю не нужно создавать аккаунт, чтобы купить товар в вашем магазине.

  2. Accounts are optional
    Покупатель может создать аккаунт, чтобы купить товар в вашем магазине, но это не обязательно.

  3. Accounts are required
    Для того чтобы купить у вас товар, покупателю нужно будет создать аккаунт.

Когда я только начинал изучать Shopify меня подловила эта настройка и я потратил какое-то количество времени, прежде чем понял, что она связана с иконкой на сайте. Рекомендую ознакомиться со следующими настройками тоже. А мы переходим дальше.

Все что ниже этой строки предназначено для разработчиков

Но если вы заинтересованы, то приятного чтения

После того как вы настроили свой магазин, хорошо бы иметь связанную тему с гитхаб репозиторием.

Как связать Шопифай тему с Гитхаб репозиторием?

После того как вы настроили магазин (или пропустили этот пункт) самое время разобраться с подключением темой через Гитхаб. Это удобная фишка, которая позволяет вам следить за изменениями в файлах вашей темы, а еще самое крутое это то, что когда вы делаете какое-либо изменение в кастомайзере, она автоматически пушится в ваш репозиторий на гитхабе. Все что нужно сделать это при публикации темы выбрать пункт Connect from GitHub:

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

Поздравляю! Вы освоили навык подключения темы из гитхаб репозитория. Следующий шаг — научиться быстро работать с кодом темы, ведь в стандартном редакторе кода нет эммета и прочих приколюх к которым мы все так привыкли. Теперь давайте посмотрим на редактор кода.

Для того чтобы перейти в редактор кода выберете нужную вам тему, нажмите на Actions -> Edit code. Перед вами откроется вот такая страница:

Слева находятся папки с файлами. Каждая папка хранит определенный тип файлов.

Папки и файлы в Shopify

Папка Layout предназначена для файла темы, который называется theme.liquid. Этот файл нужен для того чтобы подключать css, javascript, дополнительный функционал к сайту. Также он хранит футер и хэдер магазина. Еще в этой папке может лежать файл password.liquid. Я в него никогда не заходил, поэтому не скажу вам ничего про него.

Следующая папка Templates. Она нужна для создания шаблонов страниц, таких как: продуктов, 404, корзины, коллекций, блога, поиска, личного кабинета пользователя. Вы можете создать разные шаблоны одного медиа контента. Например, вы можете создать несколько шаблонов страницы продуктов. Для того чтобы применить шаблон, перейдите на страницу продукта и в правом сайдбаре во вкладке Theme template выберите созданный вами шаблон.

Дальше идет папка Sections. Она нужна для создания секций. Секции — главный компонент при создании магазина, ведь в них содержится весь контент сайта.

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

{% render 'snippet-name' %}

Папка Assets хранит в себе все стили и скрипты.

Папка Config нужна для конфигурации магазина. Особой нужды что-то менять в нем нет, он создается автоматически в зависимости от ваших изменений в теме.

Папка Locales хранит переводы магазина на разные языки. По стандарту выбран Английский язык. В теме Dawn есть переводы магазина на другие языки, в вашей теме может и не быть, проверяйте! Вы можете переводить магазин как и в файле, так и на специальной странице про которую я говорил в начале статьи.

Вот так выглядит перевод магазина в файле
Вот так выглядит перевод магазина в файле

Как вы уже, скорее всего, заметили, тема редактора кода — светлая. Я долгое время работал на ней и только потом открыл для себя лайфхак. Делюсь с вами.

Как поменять светлую тему в Shopify?

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

После этого окно расширится и в правом нижнем углу вы увидите две кнопки: Light и Dark. Нажимаем на Dark и мы получаем заветную тёмную тему.

Единственный минус, что периодически при открытии большого количества файлов Шопифай редактор кода ломается и нужно перезагружать страницу, а при перезагрузки тёмная тема слетает и придется снова её включать.

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

Возможно вы задались вопросом: «А можно ли кастомизировать Shopify темы или писать темы с нуля при помощи редактора кода?» Допустим используя VS Code. И я отвечу, что да, можно.

Что такое Shopify CLI?

Shopify CLI — интерфейс командной строки, который позволяет вам разрабатывать Шопифай темы и плагины. Он быстро генерирует Node.js, Ruby on Rails и приложения PHP, расширения приложений, Shopify Scripts (бета) и темы Shopify. Вы также можете использовать его для автоматизации многих общих задач разработки. Вы сможете одной командой добавить несколько продуктов в ваш магазин, придется только опубликовать их и загрузить изображения.

Как установить Shopify CLI?

Прежде чем перейти к установке Shopify CLI, сделайте следующее:

  1. Установите Ruby

  2. Установите Git

  3. Создайте партнерский аккаунт (если его еще нет).

Установка на macOS (Homebrew)

brew tap shopify/shopify brew install shopify-cli

Установка на Windows (RubyGems.org)

gem install shopify-cli

Проверка версии Shopify CLI

shopify version

Если у вас все успешно установилось, вам покажет текущую версию Shopify CLI на вашем компьютере:

Вы также можете писать команды в Терминале Visual Studio Code, разницы нет.

Аутентификация

Используйте команду shopify login чтобы подключиться к магазину с которым вы хотите работать. Например:

shopify login --store myers.myshopify.com

--store обязательный элемент в данной команде, без него вы не подключитесь к магазину.

Прежде чем мы перейдем к VS Code я расскажу об одном моменте. Если вы являетесь владельцем партнерского аккаунта и захотите подключиться к магазину с этой почты, то Шопифай CLI выдаст ошибку в которой говорится о недостаточных правах.

Поэтому я добавил свою вторую почту в команду в партнерском аккаунте. Теперь при подключении в магазин у меня появилась организация. Значит все сделано верно.

Получение файлов магазина в локальную папку на ПК

Давайте откроем пустую папку и попробуем стянуть файлы из Шопифай в нашу папку. Для этого используем команду:

shopify theme pull

У вас спросят с какой темы скачать файлы. Выбираем нужную тему.

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

Поздравляю! Теперь вы научились стягивать файлы темы в локальную папку. Еще чуть-чуть и станете Shopify экспертами. Теперь давайте попробуем выполнить пару полезных комманд. Первая из них:

shopify theme serve

Эта команда создает веб-сервер и вы сможете работать с локальной темой без влияния на опубликованную тему. Запускаем команду и ждем. После успешного выполнения команды вы увидите следующее:

Теперь по адресу http://127.0.0.1:9292 мы сможем посмотреть на наш магазин.

Работает!
Работает!

Чтобы остановить просмотр темы, нажмите в терминале CTRL + C.

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

shopify theme push

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

Список команд

shopify whoami — узнать в каком магазине вы находитесь

shopify version — посмотреть текущую версию Shopify CLI на вашем компьютере

shopify theme list — посмотреть список тем в вашем магазине

shopify switch --store storeurl.myshopify.com — переключение между магазинами, которые находятся в вашей партнерской организации

shopify populate customers l draftorders l products — добавление покупателей, черновых заказов, продуктов

shopify logout — выход из магазина

Это не весь список доступных команд, для просмотра всех команд, введите в терминале shopify --help.

Расширения VS Code для работы с Шопифай темами

В процессе работы у вас может появиться мысль, что чего-то хватает. VS Code не понимает, что за файлы открыты, не подсказывает и вообще ничего не делает. Есть несколько плагинов, которые возможно упростят вашу работу. Лично я разницы не заметил, либо уже забыл как было до этого. Чтобы посмотреть какие доступны плагины введите Shopify или liquid в поиске расширений.

Минусы работы в VS Code с Shopify

  1. Невозможность перехода по включенным файлам, как в редакторе Шопифай (даже с кучей расширений);

Теперь сравним этот же фрагмент с редактором кода Shopify

  1. При пуше темы слетают кастомные секции. Если вы долго с ней работаете и вам нужно проверять как она выглядит, может занять какое-то количество времени чтобы добавить в секцию контент. Скорее всего, секция не включена в стандартные секции темы и поэтому ее нужно будет постоянно добавлять после пуша. Можно конечно её добавить в список секций и тогда проблема должна быть решена.

Заключение

Шопифай на территории России не очень популярен, поэтому если вы хотите работать Shopify разработчиком в России, вам будет сложно найти заказы на русских фриланс площадках. Но Shopify очень популярен по всему миру. Поэтому знания Английского + знания Shopify платформы откроют большие границы. Но так как сейчас западные фриланс площадки закрылись, вы можете устроиться Shopify разработчиком в компанию, получать бесценный опыт работы и оттачивать навыки.

В Shopify есть огромный потенциал как для бизнеса, так и для разработчика. Как минимум Hydrogen. Это React-based фреймворк на котором можно делать динамические магазины.


ссылка на оригинал статьи https://habr.com/ru/post/663844/

Как развиваться программисту, не меняя работу

Можно ли расти профессионально, не меняя работу. Думаю, я не одна, кто задавался этим вопросом.

Всем привет! Меня зовут Настя и я frontend разработчик. Начинала в небольшой веб-студии, где приходилось создавать интерфейсы с поддержкой Internet Explorer 8. Но не будем о грустном) Последние 5 лет я работаю в международной IT компании с главным офисом в Дании. Когда я сюда устраивалась, все было новое — процессы, стек технологий, общение с иностранными коллегами. Но за несколько лет узнала все это настолько хорошо, что работа превратилась в рутину. Проекты плюс-минус однотипные, новые технологии вводятся с запозданием. Но как специалиста меня ценят. Я могу сама выбирать график работы, и это не про “плавающее начало дня с 9 до 11”, а то количество часов/дней, которые я готова уделять проектам. Например, сейчас я работаю только 3 дня в неделю. Регулярные командировки за границу (в доковидное время), коллеги — классные ребята и отличные специалисты, оплата по рынку и регулярно растет, баланс работы и личной жизни соблюден.

Есть мнение, что, чтобы расти профессионально, нужно менять работу каждые 2-3 года. Так и у рекрутера не будет сомнений, что у предыдущей компании не было с вами проблем, и стек технологий снова станет новым и интересным. Но можно ли расти профессионально, не меняя работу? Тем более сейчас, когда в условиях нестабильности количество открытых вакансий резко сократилось. А при одной только мысли о том, что снова придется проходить собеседования и доказывать, что ты не верблюд, по спине пробегает холодок. Я нашла для себя несколько вариантов, как можно поддерживать форму и увеличивать свою ценность в качестве программиста, но при этом оставаться в той же любимой компании.

Pet проекты

Думаю, этот вариант очевиден. Считается, что для расширения кругозора необходимо изучать парадигмы и сферы разработки, отличные от тех, с которыми вы привыкли работать. Мне доводилось немного работать с PHP, когда в веб-студии мы натягивали верстку на CMS системы. А также пришлось поближе познакомиться с С# и базами данных, когда в другой компании я занималась полной техподдержкой сайта. Что мне это дало? Я поняла, что backend это не мое. Что ж, отрицательный результат — тоже результат, я вернулась во frontend.

Но меня никогда не хватало на то, чтобы писать код по вечерам после работы. Тестовые задания то приходится заставлять себя делать, не то что целые проекты вести. А вот Go-программисту Владу Гукасову это удается. Он разработал сервис автоматизации рекламных компаний, который начинался как pet проект, чтобы автоматизировать работу коллег. Во время работы над ним он изучил PHP-фрейворк Laravel, поработал с асинхронными запросами, погрузился в оптимизацию нагрузок с помощью горизонтального масштабирования. Всего этого как раз не хватало в его резюме. А теперь этот сервис также является источником небольшого, но дополнительного дохода.

Когда идей нет, но есть силы и желание, можно поучаствовать в open-source проектах или помочь некоммерческим организациям.

Open Source. Помощь проектам с открытым исходным кодом. Что можно делать? Исправить баг, или самостоятельно добавить фичу. Участие в open-source разработке прививает хорошие навыки, такие как соблюдение стандартов и написание тестов, ведь ваш код увидят тысячи других разработчиков. PHP-разработчик Андрей Нестер уже писал о том, как волнительно для него было делать первый pull request. И хоть опыт был не совсем удачный, он продолжил и периодически отправлял pull request’ы в любимые проекты Yii2, Design Patterns, Django. Взамен получил гораздо больше — знакомство с интересными людьми и новый неповторимый опыт разработки.

Если вы не готовы разбираться и оптимизировать чужой код, то помогайте с документацией, отвечайте на вопросы в Stack Overflow, выступите с докладом или сами организуйте митап по технологии, как например это позволяет сделать NodeSchool. И хотя под «опенсорс» чаще всего понимают программное обеспечение, есть книги, списки и курсы, которые разрабатываются как опенсорс-проекты. В общем, со всеми подробностями вам в помощь целое руководство по участию в опенсорс-проектах.

НКО. Некоммерческим организациям также время от времени требуется помощь: отредактировать страницу на сайте, починить базу данных, настроить оплату или нарисовать логотип, для этого привлекаются онлайн-волонтеры. Подобные задания можно найти на специальных площадках.

IT-волонтер
Пасека
ProCharity
Todogood

Ко мне обращался специалист по профориентации подростков, и я участвовала в зум звонке, на котором рассказывала о плюсах и минусах работы программиста. Было интересно попробовать проанализировать профессию с точки зрения человеческих качеств. Что тебе должно нравится, чтобы ты выбрал эту работу? Если не программирование, то где еще можно применить свои навыки? Самым запоминающимся вопросом на этом звонке был “Правда ли, что у программистов скучная жизнь?”. А я то думала все представляют программиста в шезлонге у моря, лениво клацающим по клавиатуре, или на вечеринке, отмечающим очередной успешный релиз. 

Блог

Каждый из нас прошел свой путь и имеет уникальный опыт, которым стоит поделиться. Я считаю, что не стоит переживать, если нет опыта в написании текстов — все придет с практикой. Все же помнят свою первую программу? Вот и тут тоже самое. Блог помогает закреплять полученные знания и учит формулировать свои мысли, а еще дает отличный толчок к карьере. 

Статьи. Мне сложно даются тексты, предложения не льются рекой, их из себя приходится доставать клещами. Поэтому я начала с постов в Instagram* (признан экстремистским и запрещен в России), так как думала, что к полноценной статье не готова и материала мало. К тому же в контактах у меня в основном друзья, и шквала критики я не рассчитывала там получить. И да, не одним Твиттером живет IT сообщество, в Instagram* тоже есть полезный контент. В качестве картинок я использовала личные фотографии, а тексты были не о конкретных технологиях, а про IT в целом — объяснения каких-то терминов и принципов работы, типа “почему не стоит деплоить в пятницу”. У меня было всего 170 человек в подписчиках, но этого вполне хватило, чтобы получить несколько предложений по работе и сотрудничеству, как только в аккаунте появился контент по профильной теме. 

Ну а если вы читаете этот текст, значит я наконец написала что-то больше чем пост в Instagram. Кстати, статью можно разместить не только на Хабре, но и на одной из следующих площадок.

Medium
Tproger
Hakernoon

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

Видео. Я уже давно сотрудничаю с порталом видеоуроков LoftBlog. Когда-то откликнулась на объявление о поиске ведущей на канал, и раз в неделю мы стали записывали новости из мира IT. Первая съемка растянулась часов на 5, которые затем превратились в 5ти минутный ролик, а все потому что забывался текст, не хотели выговариваться слова. А еще было так страшно, что лицо в итоге не выражало никаких эмоций. В общем первые ролики были «ну такие», и я получала комментарии, что говорю как робот. Но мы продолжали и со временем стало лучше. Хотя новости в итоге закрыли, но я осталась работать на канале в рамках других проектов. Например, вы можете увидеть меня в серии роликов “Азбука Программиста”, где я рассказываю про IT термины. Считаю, что это отличная практика перед выступлением на конференции или проведением онлайн-занятий. У видеоуроков все те же плюсы, что и у статей — учат формулировать мысли, закрепляют знания, но также учат правильно говорить — без мычания и слов-паразитов, работать с мимикой и жестами. 

Подкасты. Еще один способ поделиться своими знаниями: как делать надо или не надо, обсудить последние новости. Что-то среднее по сложности между статьей и видеоуроком, так как не нужно следить за качеством картинки и мимикой, но четкая речь и хороший звук обязательны. Также в рамках сотрудничества с LoftBlog, мне доверили записывать интервью с IT специалистами про их карьерный путь, ошибки и советы начинающим. Мы записывались в студии подкастов, и в основном эти ролики доступны на YouTube, но одно интервью (с Data инженером Артемом Гогиным) можно послушать на SoundCloud или в Apple Podcasts

Онлайн-школы

Преподавая, учишься сам. Есть несколько форматов, в которых можно сотрудничать с онлайн школами.

Наставничество. Я прошла несколько интенсивов при одной онлайн школе и в итоге решила попробовать себя там же в качестве наставника на курсе по базовому HTML и CSS. В мои обязанности входила проверка домашних заданий. Студенты поэтапно создавали веб страницу и я проверяла правильность использования тегов, помогала с расположением элементов и их стилизацией. Мне нравилось работать со студентами. Они пишут код так, как вы бы сами никогда не догадались. Например, используют position:relative и свойства top и left, там, где можно было обойтись одним margin. И нужно было приводить их к правильному решению, объяснять, почему мы делаем так, а не иначе. Но на наставничество уходило много времени, несколько часов ежедневно. Баланс работы и личной жизни явно перестал сходиться, и от наставничества пришлось отказаться.

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

Иногда студенты задают вопросы, на которые у меня нет готового ответа. Если вопрос из серии “а что будет, если”, то пробуем этот вариант по ходу занятия и смотрим что же получится. Один раз спросили про горячие клавиши в Safari, а я работала только с Chrome. Попытка погуглить во время занятия с треском провалилась, пауза затягивалась, но тут пришли на помощь с ответом другие студенты. В общем, учишься быстро реагировать на нестандартные ситуации и держать лицо в любом случае. Считаю, что это отличная возможность глубже погрузиться в предметную область и структурировать информацию у себя в голове.

Школы, предлагающие вакансии
LoftSchool
Школа программистов
Международная онлайн школа программирования для детей “IT Future Online” 
Детская онлайн-школа программирования “Hello World

Хакатоны

Это соревнования, в котором команды за определенное время (обычно 36-48 часов) создают прототип продукта для решения определенной проблемы. Мне хакатоны всегда казались чем-то для ребят олимпиадников, рожденными, чтобы программировать. Я же никогда сверхспособностями к написанию кода не обладала. Но еще в доковидное время мне повезло наткнуться на рекламу хакатона “Цифровой прорыв”. Там не упоминались страшные незнакомые названия технологий, как это было обычно, да и звали не только разработчиков, но и дизайнеров, менеджеров. Уговорила себя подать заявку, пообещав, бросить эту затею, если что-то пойдет не так.

У меня не было команды. Все, кому я предлагала пойти, отказались. Но перед хакатоном был сформирован общий чат участников, где как раз такие одиночки и объединялись в команды. Я так поняла это обычная практика.

Пойти на хакатон было одним из лучших моих решений. Нам нужно было решить проблему из сферы здравоохранения: придумать систему, чтобы люди не бросали прием препаратов при первых признаках улучшения. В итоге было решено создать приложение взаимопомощи, с менторами и менти, напоминающими друг другу о необходимости принять лекарство. На мне был интерфейс для врача, который делает назначения. Для работы я использовала тот же стек, что и обычно, и этого вполне хватило. Мы с командой выиграли региональный этап и получили грант на разработку проекта в размере 200 000 рублей. Какое-то время работа над приложением продолжалась, но pet проекты требуют много времени, и, насколько я знаю, он лег на полку.

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

Участие в хакатонах открывает много возможностей — можно найти работу или инвестора для своего проекта, ну и просто познакомиться с хорошими людьми со схожими интересами. Так что новичкам не стоит бояться участвовать, просто ищите хакатоны с пометкой “Beginner Friendly”.

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

Список ресурсов, где искать хакатоны
Хакатоны.рф
Russian Hackers
DEVPOST
Международная лига студенческих хакатонов MLH

Конференции

Я обожаю конференции за их особую атмосферу. И это не новые технологии, а какой-то дух сообщества — много разных разработчиков, все улыбаются, общаются и соревнуются за очередной блокнот или кружку. Скучаю по этому, видеоформат совсем не то. Как-то моя компания выступала в качестве партнера конференции DUMP и мне доверили представлять ее со стендом. Мы с коллегами рассказывали о компании и приглашали на собеседования. Там же разыгрывали мерч и я разрабатывала задания по frontendу, которые нужно было решить, чтобы поучаствовать в лотерее. 

Участие в конференции — отличный способ обзавестись деловыми знакомствами и заодно внести вклад в развитие профессионального сообщества. Правда, публичные выступления на сцене перед толпой даже у опытных специалистов, вызывают страх и волнение, что уж говорить о новичках. Но ведь именно там, где страшно, обычно ждут новые возможности. Пока такое выступление только в моем списке планов, но я уверена, что все получится. 

Что делать, если не хочется становиться спикером? Можно вступить в программный комитет. В задачу программного комитета входит подготовка конференции — подбор и тренировка докладчиков, работа с комьюнити. На сайте любой конференции есть контакты организаторов, куда и нужно писать о своем желании и опыте. Если будут вакантные места, вам обязательно ответят.  

Где искать предстоящие конференции?
IT-Events
call4paper

Собеседования

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

И все-таки зачем? Собеседования отлично подсвечивают слабые стороны, будь то soft или hard скилы, и показывают направления, где есть возможность для роста. Я была по обе стороны баррикад: и проходила собеседование и проводила их сама. Прохождение собеседований — отдельный навык. Здесь важны не только знания, но и то, как ты себя ведешь и не ляпнешь ли чего лишнего. Помню, как на одном собеседовании кандидат уровня junior, практически только после курсов, начал ругать технологии, которые используются у нас на проектах, с намеком на то, что он бы сделал лучше. Не надо так. Если вас не устраивает стек, можно просто поинтересоваться, что повлияло на такой выбор и как происходит процесс введения новых инструментов. 

Итоги

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

Я всегда была практиком в том плане, что знала, как сделать, чтобы заработало. Но почему оно работает именно так, а не иначе, меня не очень интересовало. С появлением наставничества и преподавания этот пробел в моих знаниях закрылся. Но я бы не решилась вести занятия, если перед этим у меня не было опыта записи видеоуроков. Так одно по цепочке ведет к другому.

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


ссылка на оригинал статьи https://habr.com/ru/company/loftschool/blog/663842/

Есть ли жизнь без тестов?

Это история про то, как нам удалось написать довольно сложную business-critical систему, и добиться, чтобы она была стабильной даже без юнит-тестов (WAT?!).

Представьте: ERP-система в области логистики. Сложная бизнес-логика, составление расписаний, электронный учет рабочего времени, планирование и управление ресурсами со статистическими подсказками на основе сотен миллионов записей геораспределенных исходных данных, мониторинг прогресса >1000 одновременно работающих водителей в реальном времени, интеграция с 7 другими системами (в том числе финансовыми), и т.д., в общем большая и сложная система.

Систему начали с нуля, писали на ASP.Net Web API, Entity Framework и AngularJs (Реакта и Vue тогда еще не было, дело было в далёком 2013), небольшой, но высокопрофессиональной командой, по Scrum, написали за 4 месяца первую базовую продакшн-версию с минимальным функционалом, впоследствии функционал постепенно наращивали, система развивается и по сей день. Через год после начала разработки, система уже была внедрена по всей компании и являлась business-critical, т.е. остановка системы даже на несколько часов могла повлечь довольно существенные убытки для компании.

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

Почему без юнит-тестов?

Бесспорно, юнит-тесты — очень хорошая штука. Прошу понять меня правильно, я ни в коем случае в этой статье не пытаюсь сказать что они не нужны или их не надо писать. Нужны. И надо.

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

Сколько раз я видел эти классические слова: «это не тесты у вас не работают, это вы просто их писать не умеете». Но ведь так можно любую неподходящую технологию оправдать… Нет, я думаю, не всё так просто. Вот с паттернами к примеру. Любой более-менее опытный программист знает: паттерны это не панацея, универсальных решений не бывает, всегда нужно смотреть по ситуации, что конкретно использовать и как именно.

Вот и тесты такие же на мой взгляд — да, есть случаи, когда автоматические тесты подходят идеально: например, если реализуешь какой-нибудь протокол, или пишешь компилятор, или библиотеку со строго заданным API и прочее. В таких случаях есть четкие требования и они описаны на низком уровне — и тесты работают замечательно. А по TDD такие проекты делать и вовсе сплошное удовольствие.

Но есть и бизнес-приложения. Требования вроде и есть, но они описаны на очень высоком уровне, и мапить их в тесты мягко сказать непросто. Вроде, потому что заказчик в начале проекта сам не до конца понимает, что конкретно ему нужно. Это выясняется в деталях только в процессе, на Sprint Demo или на дэйли. Если разработка действительно agile, то требования часто меняются, а знаете что такое изменение требований на высоком уровне, в разрезе тестов? А вот что: удаляем несколько десятков тестов и пишем заново. И это продолжается весь проект. Каждый второй спринт. Примерно так…

И да, с учетом того, что кода тестов при хорошем покрытии значительно больше, чем кода самого решения… Получается, в общем, довольно неэффективно.

Если не юнит-тесты, то что?

На удивление, способов обеспечения качества ПО, помимо автоматических и ручных тестов, немало! Жалко и обидно, что они настолько недооценены, и о них мало кто говорит. Вот посмотришь хабр: тесты, тесты, тесты. Качество софта = всегда только тесты. И все, как будто нет альтернатив. Но ведь это не так: альтернативы есть, и в ряде случаев они подходят гораздо лучше.

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

Другим «источником вдохновения» стал Брет Виктор, автор множества потрясающих концептов, и в том числе идеи Seeing spaces, и особенно той ее части (начиная примерно с 3:53 на видео), где речь идет о способах расследования и предотвращения багов. Идея в том, что для того, чтобы понять, что происходит внутри системы, нужно как бы «развернуть» эту систему, заглянуть внутрь, визуализировать ее во всех возможных плоскостях, увидеть как она работает изнутри. Если хорошо понимать, как работает система — то многих ошибок можно избежать. Здесь кстати снова пересечение с космической темой: это получается этакий локальный «Центр Управления Полетами» для данной системы.


(картинка взята отсюда: vimeo.com/97903574)

В свое время идея Брета меня совершенно захватила и наверное неделю я пытался придумать способ «развернуть» нашу конкретную систему, пока наконец-то не слепил из подручных средств утилитку-монитор, визуализирующий как минимум некоторые процессы происходящие внутри и позволяющий как бы заглянуть «под капот» системы. Эта утилитка впоследствии сэкономила мне много часов, позволила избежать кучи ошибок на ранней стадии, а в нескольких случаях — понять детально, что происходит на продакшене.

Безусловно, в современном вебдеве это решается с помощью логов, трейсинга (OpenTelemetry) и мониторинга, но многие успешные компании в добавление к этим вещам имеют свои собственные, специализированные утилиты, заточенные под визуализацию этого конкретно решения.

Кроме этих вещей, были недели поисков в гугле, десятки прочитанных статей, множество опробованных подходов и утилит, и конечно многие часы работы над кодом. Забегая вперед, одним из главных открытий для меня стал метод «fault tree analysis», но были и другие очень важные вещи. Всё это в совокупности позволило получить надежную и стабильную систему без юнит-тестов и тестировщиков.

«Космический» подход

Как пишут код, в котором не должно ошибок вообще? Ответ разочаровывающий: пишут его нудно и долго. Страшная бюрократия, документации больше чем кода и т.д. Никакого Scrum’а. И все же есть-таки чему поучиться и что позаимствовать у космического ПО!

  1. Формальная верификация. Использовать ее на бизнес-проектах конечно не получится (слишком дорого), но понимать — полезно. Понимать проблемы, с которыми формальная верификация сталкивается, понимать почему же так сложно доказать что цикл завершается, и понимать почему формальная верификация — не панацея, даже если есть возможность ее применить. Есть классный David Crocker’s Verification Blog, где можно с этой темой ознакомиться, рекомендую. Когда-то давно я читал этот блог как худлит, на ночь, прямо с самой первой записи и дочитал «до наших дней» (причем это единственный блог вообще который я прочитал полностью в своей жизни). Да, часть информации специфична для C/C++, но все равно очень много полезного по теории формальной верификации и статическому анализу.
  2. Программирование по контракту. Контрактное программирование тоже хорошая штука, но снова очень не дешевая и далеко не панацея. Например, в упомянутом выше блоге Дэвида, есть интереснейшая статья о случае с взрывом ракеты Ariane 5 при взлете, где он небезосновательно утверждает, что runtime-проверки могут спасти, но только если: а) программа может сделать что-то полезное, если проверки не прошли; б) это что-то полезное было как следует протестировано. В общем, знать про контрактное программирование очень полезно, но для повсеместного применения в бизнес-решениях оно конечно дороговато.
  3. Статический анализ. Сейчас много мощных средств для статического анализа кода программ. Почему бы их не использовать? Например, эксперт Gerard Holzmann из лаборатории надежного ПО NASA в документе The Power of Ten — Rules for Developing Safety Critical Code пишет, что никаких оправданий просто не может быть чтобы не использовать. Потому что это очень дешево: запустил анализатор и все. А ведь статический анализатор очень хорош для отслеживания некоторых категорий технических багов, которые сложно заметить на глаз.
  4. Простой код. Простой код проще поддается статическому анализу, и в нем меньше вероятность сделать ошибку. Опять же согласно документу из предыдущего пункта, методы и функции желательно умещать в один лист печатного текста ака 60 строк кода: иначе психологически не воспринимается, как логическая единица. И желательно избегать рекурсии: рекурсивный алгоритм обычно сложнее понять, чем тот же алгоритм развернутый в цикл (и опять же статические анализаторы лучше с циклами работают чем с рекурсией).

Давайте рассмотрим последние два пункта немного подробнее.

Статический анализ

Статический анализ выглядит привлекательно: позволяет отловить кучу проблем и дешево.

Кстати, самый простой тип статического анализа — это intellisense, то, что мы каждый день используем в IDE (ну и компиляция кода, как частный случай). Очень важно, чтобы ваш проект полностью покрывался интеллисенсом. Например, если не использовать Entity Framework, а писать magic strings stored procedures, то вероятность сделать ошибку при очередном рефакторинге резко возрастает.

Кроме стандартного intellisense, есть конечно же линтеры, такие как Stylecop или более современные и продвинутые, типа SonarQube.

А если хочется написать что-то совсем кастомное, заточенное под конкретный проект (и мне кажется, это очень даже полезно делать), то в C# есть ещё даже более крутая штука: Live Code Analyzers!

Live Code Analyzers

Начиная с Visual Studio 2015, с появлением Roslyn, были добавлены Live Code Analyzers — статические анализаторы кода, которые запускаются в IDE по мере создания кода. Иными словами, простая и доступная возможность создать кастомный intellisense.

В Live Code Analyzer есть доступ ко всему, с чем работает компилятор: лексическая свертка, AST, результаты семантического разбора. Можно комплексно анализировать код и обнаруживать довольно сложные ошибки.

В этой статье не хочется погружаться слишком глубоко в Code Analyzers, но давайте рассмотрим хотя бы вот такой простой пример — обнаружить все методы в solution больше 100 строк:

private void CheckMethodsAreShortEnoughToComprehend(SyntaxNodeAnalysisContext context) {     var methodDeclaration = (MethodDeclarationSyntax)context.Node;      // собственно проверка     if (methodDeclaration.Body == null || methodDeclaration.Body.GetText().Lines.Count <= 100)         return;      // если проверку не прошли, кидаем ошибку     var diagnostic = Diagnostic.Create(ShortMethodsRule, methodDeclaration.Identifier.GetLocation(), methodDeclaration.Identifier.Value);     context.ReportDiagnostic(diagnostic);  } 
Полный код класса анализатора

[DiagnosticAnalyzer(LanguageNames.CSharp)] public class MyAnalyserAnalyzer : DiagnosticAnalyzer {     private static DiagnosticDescriptor ShortMethodsRule = new DiagnosticDescriptor(         "MyAnalyser.ShortMethodsRule",         "Method is too long.",         "Method '{0}' is more than 100 lines long.",         "Database",         DiagnosticSeverity.Warning,         isEnabledByDefault: true,         description: "Long methods are hard to read and comprehend. Statistics shows, that long methods have much more mistakes. Please refactor.");      public override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics     {         get         {             return ImmutableArray.Create(ShortMethodsRule);         }     }      public override void Initialize(AnalysisContext context)     {         // для каждой ноды "method declaration" в solution будет запущен наш метод проверки         context.RegisterSyntaxNodeAction(CheckMethodsAreShortEnoughToComprehend, SyntaxKind.MethodDeclaration);     }      private void CheckMethodsAreShortEnoughToComprehend(SyntaxNodeAnalysisContext context)     {         var methodDeclaration = (MethodDeclarationSyntax)context.Node;          // собственно проверка         if (methodDeclaration.Body == null || methodDeclaration.Body.GetText().Lines.Count <= 100)             return;          // если проверку не прошли, кидаем ошибку         var diagnostic = Diagnostic.Create(ShortMethodsRule, methodDeclaration.Identifier.GetLocation(), methodDeclaration.Identifier.Value);         context.ReportDiagnostic(diagnostic);      }  } 

Как видите, все довольно просто. Некоторое количество обвязки, но сама проверка — буквально одна строка. Впрочем, более полезные проверки потребуют, конечно, намного больше кода.

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

Например, мне удалось создать анализатор, который ругается, если поместить запрос к БД за пределы методов Web API контроллера (чтобы работа с БД не размазывалась по всему решению, поскольку очень часто проблемы с производительностью возникают после того, как кто-нибудь использует метод, дергающий базу данных в цикле).

Но вот сделать более сложный анализатор, который бы следил, чтобы внутри endpoint’а типа PUT /user/{id}, невозможно было бы случайно изменить пользователей с другим ID (чтобы предотвратить случайный data corruption), уже не вышло.

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

Простой код

Простой код — это самый надежный способ борьбы с логическими ошибками. Простой, понятный, лаконичный код — это прекрасно! Но непросто.

Блоггеры и докладчики меня поймут: вот пишешь статью, или готовишь доклад, и хочется привести пример, который был бы одновременно и простым, и полезным. И вот на то чтобы изобрести такой пример, несколько дней может уйти (и еще не факт что придумаешь в итоге)! Найти те заветные 20 строчек кода, которые хорошо бы демонстрировали идею, делали бы что-то действительно полезное, и были бы простыми и понятными при этом — на практике оказывается очень нелегко.

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

Есть по этому поводу знаменитая цитата от Blaise Pascal (перевод с французского):

Это письмо получилось таким длинным потому, что у меня не было времени написать его короче.

И в этой цитате, безусловно, — очень много правды!

Вот какие подходы и методы лично я использую (весьма успешно) для создания простого кода:

  1. Инкрементный рефакторинг. Этот подход позволяет избежать излишнего усложнения кода еще на стадии разработки проекта.
  2. Простые оптимизации. Подход к решению проблем с производительностью, чтобы сохранить качество кода.
  3. Fault tree analysis. Это способ для определения наиболее критичного кода, который можно себе позволить сделать совершенным, и это окупится.
  4. Maintainability Index. Вычисление метрик кода позволяет легко найти участки кода плохого качества.

Давайте рассмотрим их подробно.

1. Инкрементный рефакторинг

Термин мой собственный, выдуманный. Может быть это как-то по-другому официально называется. Но для меня — это просто то, как я пишу код, уже много лет, и весьма успешно.

Если грубо, идея заключается в том, чтобы не создавать детальную архитектуру кода проекта заранее. Накидали план в общих чертах, — и поехали. Как только какой-то класс или метод разрастается слишком сильно — ага, пора рефакторить. Видим, что слишком много контроллеров — ага, пора делать новый микросервис. И так далее. Таким образом, проект растёт инкрементно и «натурально», именно в тех местах, в которых действительно нужно.

Замечание: архитектура — понятие многогранное, здесь и далее я говорю именно про архитектуру кода — т.е. про то, как правильно структурировать проект, разбить на компоненты, сущности, файлы, классы и т.д.

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

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

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

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

  1. Thresold. Нужен способ понять, когда пора остановиться и проревизить архитектуру.
  2. Рефакторинг. Рефакторинг бывает разный. Некоторые понимают под рефакторингом «переписать половину проекта нафиг». Такое бывает, если всё совсем запустили и накопилась целая гора технического долга — т.е. когда thresold или отсутствовал, или был выбран неудачно. Зато при правильно выбранном thresold’е рефакторинг происходит почти безболезненно, настолько, что его можно даже делать в проекте без тестов.

Я использую простой thresold, состоящий из двух условий:

  1. Копипастить код можно (о ужас!), но не более одного раза (т.е. максимум 2 «копии»). Если копипастишь в третий раз — пора писать абстракцию.
  2. Если файл достиг 200 строк, пора рефакторить — разбивать его на несколько файлов, и заодно ревизить общую архитектуру.

При таком подходе архитектура строится соответственно росту проекта, и архитектурно продумываются именно те части проекта, которые растут и следовательно являются самыми важными и востребованными.

Правильная архитектура автоматически ведет к более простому коду.

2. Простые оптимизации

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

У нас был в случай, когда человек, не очень хорошо разбиравшийся в MS SQL, «соптимизировал» систему путем перевода почти всех запросов к БД с Entity Framework на stored procedures. Потом пришлось переводить обратно, потому что поддерживать T-SQL код, не покрытый интеллисенсом, довольно сложно (повторюсь, речь о бизнес-проекте, требования меняются постоянно, а с ними вместе и модель базы данных). Да, и к слову, перевод на stored procedures оказался бессмысленным — проблем это не решило. Решение было в добавлении индексов и предпросчёта.

К чему веду: очень легко переусердствовать с оптимизациями. Код при этом очень сильно усложняется, и соответственно сложнее становится избежать багов. Везде нужен компромисс, также и с оптимизациями.

Например, если выяснилось, что Entity Framework генерирует неоптимальный запрос, или не умеет генерировать запрос который вам нужен, это не повод переходить на хранимые процедуры. Покрутите проблему в голове, почитайте умные статьи, решение всегда найдётся. В частности, сложные T-SQL запросы это в любом случае зло — так что и не нужно пытаться их генерировать. Вместо этого, например, вытащите данные по отдельности простыми запросами и склейте их в памяти.

Вообще, 90% проблем с производительностью БД на средних объемах данных и не супер высокой нагрузке решаются пятью простыми способами:

  1. Индексы
  2. Простые запросы и склейка данных в памяти
  3. Кэш
  4. Предпросчёт
  5. Пейджинг

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

Мораль: Когда чините производительность, не увлекайтесь, а то сломаете себе носcodebase.

3. Fault tree analysis

Fault tree analysis — это по сути, просто метод для поиска возможных отказов, но его действенность, сложно переоценить.

Итак, для начала, уточняем у заказчика: какие части системы не должны отказывать ну ни при каких условиях, какие страницы наиболее критичны?

И дальше начинаем с этих страниц, и думаем: что может привести к тому, что страница не будет работать? И как это можно решить?

Например, примерно так я анализировал одну из критических страниц нашего сервиса — страницу со списком заданий и водителей, которая отображалась на InfoTV:

  1. Если нет связи с сервером — страница просто не загрузится.
    • Решение: Можно использовать server workers, и в случае отказа сети, хотя бы показывать старый снапшот данных. Конечно, при этом желательно вывести уведомление, что данные старые, и показать дату, когда они последний раз были синхронизированы с сервера.

  2. Если ошибка в Javascript, то страница не сможет отобразить список заданий или же не сработает периодическое обновление страницы и она «застынет»
    • Решение: максимально покрыть фронтенд-код интеллисенсом, вынести в отдельный файл главный код, который отображает список и обновляет страницу, упростить его, некритичные функции обернуть в try-catch, чтобы ошибка в этих функциях не повлияла на отображение списка

  3. Если API возвращает ошибку или данные в неожиданном формате
    • Решение: продолжать показывать старые данные, как если бы система была оффлайн. Выводить соответствующее сообщение об ошибке.
    • Кроме того, можно улучшить стабильность бэкенда. Для этого нужно проанализировать, в каком случае может возникнуть ошибка на бэкенде?
      1. Если допущена ошибка в коде и возникло исключение
      2. Если сервер упал
      3. Если нет связи с БД
      4. Если БД перегружена и запрос вылетел с таймаутом
      5. Если на сервере БД вышел из строя жесткий диск

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

На самом деле, пример упрощён: анализ критичных областей должен быть очень детальным. Нужно буквально смотреть на каждую строчку кода, и смотреть, при каких обстоятельствах она может упасть. Учитывать всё: потерю связи, пожар а дата-центре и т.д.

Что хочу сказать про fault tree analysis: несмотря на то, что более менее все архитекторы знают про reliability, про то, как его улучшать, но оценку проблем как правило проводят очень ситуативно, бессистемно, часто пытаясь применить обобщенное решение (что работает довольно плохо). Например, я работал в двух больших Unicorn-ах, и даже там подход к reliability всё ещё бессистемный, и только в Big Tech этим уже занимаются серьёзно.

Fault tree analysis позволяет сконцентрироваться на действительно критичных участках и провести полный, системный анализ возможных отказов на этих участках. Если вы так ещё не делаете — попробуйте, это действительно круто работает!

4. Maintainability Index

Предположим, что мы проанализировали возможные отказы, улучшили код, и всё стало хорошо! Но ведь код имеет свойство постоянно меняться, практически жить своей жизнью. Изменения могут быть небольшими, но постоянными, и на code review, когда ты видишь только diff, бывает нелегко оценить суммарную получившуюся сложность всего метода в целом.

И вот здесь, для поддержания кода в хорошем состоянии, очень хорошо подойдёт вычисление метрик кода, таких как Cyclomatic Complexity — это отлично умеет делать Visual Studio для C#, да и для других языков полно утилит, которые умеют это делать.

В Visual Studio основные метрики суммируются в характеристике под названием Maintainability Index (от 0 — совершенно невозможно этот код поддерживать, до 100 — очень легко поддерживать), а полный набор отображаемых метрик выглядит примерно так:

Строится дерево по всему решению, дерево можно развертывать и искать конкретные классы и методы, где все плохо. Это, даже без fault tree analysis, — первые кандидаты на рефакторинг, особенно если они относятся к важным частям системы.

Интересный факт: когда мы впервые вычислили метрики кода нашего решения, самое худшее качество кода было в самом главном, самом критическом методе всей системы (который если упадёт — то всё, это «full stop»). И я уверен, что такой феномен — совсем не редкость.

В итоге, мы потратили наверное целый человеко-спринт 🙂 на то, чтобы этот метод переписать и максимально упростить.

Заключение и выводы

Это довольно старая история, но всё ещё очень актульная. С тех пор, например, я основал свой стартап, ему уже 5 лет, десятки клиентов (B2B), десятки тысяч пользователей, и ни одного теста. Несмотря на кучу pivot-ов и глобальных рефакторингов, очень стабильная система, и я в состоянии поддерживать и развивать её в одиночку.

Конечно, с тестами было бы ещё лучше, ещё надежнее, — в идеале, все возможные способы улучшения надежности ПО должны использоваться в комбинации друг с другом.

Но в этой статье я хотел обратить внимание на то, что все эти «второстепенные» способы, на самом деле дают удивительно хороший результат, и могут использоваться даже без тестов. О них мало кто пишет, мало кто считает их серьезным подспорьем для улучшения надежности ПО. А зря, на самом деле, они отлично работают!


ссылка на оригинал статьи https://habr.com/ru/post/279943/