Как разработчику справиться с проектом в одиночку. Советы из опыта

Привет! Меня зовут Юлия Дон, я работаю .NET-разработчиком более трех лет, и недавно мне выпала возможность стать единственным девелопером на проекте. Опыт получился интересный, и я решила поделиться им с вами.

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

Иллюстрация Алины Самолюк

Начало карьеры

Моя карьера в ІТ начиналась с небольшого стартапа, который перерос в серьезный коммерческий проект. В нашей команде было четыре разработчика. Мы создали систему видеонаблюдения, которая распознавала людей на видеопотоке и подсчитывала количество вошедших/вышедших из помещения. Этот продукт использовался во многих торговых центрах для сбора статистики посещаемости.

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

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

Мы занимались этим проектом несколько лет и, когда на определенном этапе поняли, что в продукт добавить больше нечего, отправились работать в большие украинские ІТ-компании.

Я устроилась в Customertimes на крупный проект по разработке ПО для документооборота и торговли сырьем на бирже. Для меня это была совершенно новая сфера, о которой я раньше знала поверхностно. Именно это делало для меня проект невероятно увлекательным. Нас было пятеро разработчиков на проекте: я — Middle и четыре Senior.

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

Я один на один с проектом

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

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

Этот путь оказался непростым. У меня на тот момент не было опыта веб-разработки, я занималась только десктоп-приложениями и бэкенд-разработкой. Поэтому поначалу мне приходилось сражаться с JavaScript (какое-то время он побеждал, но со Stack Overflow и документацией в союзниках я потихоньку стала получать преимущество).

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

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

Кроме того, на проекте использовалась база данных MongoDB, которая местами существенно отличается от привычной мне MS SQL. Запросы пишутся иначе, и при каждой малейшей правке в базе необходимо было обращаться к документации. Так как разработчика БД на проекте не было, правки в базе, в том числе на проде, были на мне.

Очевидный, но очень важный совет: всегда перед изменениями в базе делайте бэкап. Это сэкономило мне много нервов, поскольку я допускала ошибки, которые при отсутствии бэкапа стали бы критичными. Была ситуация, когда при обычном апдейте строка удалилась из базы. Это случилось на проде... К счастью, был бэкап!

Мне также пришлось разобраться с инструментами AWS и TeamCity. Раньше я решала несколько незначительных задач по CI/CD, но на тот момент работала с коллегами, которые были готовы помочь и подсказать то, что непонятно. В этом же случае мы остались с деплоем один на один. Однако благодаря использованию TeamCity с особыми сложностями я не столкнулась. Все, что мне нужно было сделать, оказалось простым в изучении.

Ответственность за весь проект

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

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

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

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

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

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

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

Самостоятельное решение проблем

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

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

Понимание всего проекта

За время работы над проектом в одиночку я начала лучше понимать, какие именно компоненты отвечают за определенный функционал и как они взаимодействуют между собой. Это помогает быстро исправлять баги, легко дополнять проект небольшими фичами и реалистично давать оценку большинству задач. Первые мои оценки были «примерно пару недель, но, сколько точно — я не знаю». Чем больше я понимала, как устроен разный функционал, тем легче мне было прикинуть объем задачи, исходя из ее описания.

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

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

Отсутствие код-ревью

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

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

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

Отсутствие митингов

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

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

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

Гибкий график

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

Несколько советов

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

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

Сохранять доступы к инструментам, которые используются для разработки и деплоя (например, сервер, TeamCity, БД) и особенности развертывания приложения локально. При ознакомлении с проектом мне приходилось обращаться к заказчику, чтобы он уточнял креды у предыдущих разработчиков. Затем в ходе работы появились частности, известные только мне. Не стоит надеяться, что вы все удержите в голове. Лучше перестраховаться и записать их. Это существенно упростит передачу дел при расширении команды или при уходе с проекта.

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

Выводы

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

Я брала на себя роли веб-разработчика, разработчика баз данных, тестировщика и DevOps. Но со временем могут возникнуть риски торможения в развитии своих навыков. Очень динамический рост происходит вначале в силу незнакомого проекта и, как в моем случае, незнакомых технологий. Но при построении архитектуры приложения отсутствует критический взгляд других разработчиков. Даже если ты Senior с опытом разработки 10+ лет, твой опыт все равно не покрывает весь спектр существующих технологий, которые можно было бы применить в рамках разработки нового функционала.

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

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

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

👍НравитсяПонравилось1
В избранноеВ избранном6
Подписаться на тему «разработка»
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube

51 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Якщо чесно, то суперечливий досвід.
Не знаю, як зараз все працює в .NET, але в списку порад (а їх 4) є трохи дивна — «Не боятися» і незрозуміла — «Вести документацію». І не було найважливішого поради — «Писати тести». Коли у вас є тести і гарне покриття коду, вам не потрібно боятися, не потрібно писати документацію (тести і є документація) і 99 шансів зі 100, що таких проблем, як втрата даних через помилки в запитах не буде.

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

Як добре, що я свого часу пішов з .NET

А що тут не так? Якщо для тебе це новий проект і нова технологія, то тут треба багато чого вкурить. Не бачу кожної проблеми в тому, що фікс першої кнопки зайняв так багато часу.

Просто з посту не зовсім зрозуміло, про яку кнопку і який баг йдеться. Але якщо це звичайна кнопка на HTML сторінці, то що там можна тиждень виправляти? Ну якщо ти звичайно не вчорашній випускник 2-місячних курсів.

Абзазом вище:

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

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

Вона зовсім нічого не знала про ці технології на той момент...

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

спасибо! да, в моем случае, к счастью, риски были не критичны)

(ведь сама с собой я могла поговорить в любое время).

это да, если второй я соглашается в деталях)

если не соглашается, тоже хорошо) может что-то полезное предложить)

вспоминаю свой проект по УЗИ, когда возникло желание его довести до коробочного продукта. Но в процессе у второго Я постоянно возникали идеи по расширению функционала)

Очень давно тоже остался один на проекте. Напарника и тестировщицу временно перебросили чтобы закрыть аутсурсинговый проект. Тестировщицу так назад и не вернули, и потом пару лет тестировать было некому и баги нас преследовали. Тимлид уехал в Сиэтл на оншор — на пол года. И вот на мне первый мануал, супорт клиентов и абгрейд движка + разработка мак версии, без самого мака. Ходил тестил у менеджера, напишу пару операторов, скомпилирую и иду к нему проверять. Бывало раз 10-15 в час зайду. Вот интересно что Топка меня ниразу не послал (хотя вежливо намекал что я задолбал), и всегда говорил — спасибо — я естественно отвечал: «тебе спасибо». В итоге человек уехал в Питер :), через неделю истязаний. Перешёл в одну крайне известную всем питерскую контору. Мак пришлось стрелять на потестить лично у директора. Купить его — хрен бы там в 2007 за маком надо было ехать в США, с тех времён и мак понты — т.е. у тебя мак — ты был в Америке. Вот это путишествие как раз и было дорого по настоящему. Это был один из самых наряженных моментов в карьере.

Тестировщицу так назад и не вернули, и потом пару лет тестировать было некому и баги нас преследовали.

то есть самим тестировать не позволяла профессиональная гордость?

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

Ну естественно — на моей машине все работает, погнали все на прод :)

при чем тут тестировщик? Нужен взрослый человек просто в комманду.

Зачем тогда QA вообще нужны ? Денег просят. Одно дело когда не проверяя ничего самостоятельно сразу «кидают» все в тестирование, иногда правда и для того — чтобы показать что на тебе катаются. Если сказать прямо — «не разрешай это с собой делать» — могут и послать на хутор. (Конкретно обламав, потому как до того тебе джуниры разве что в рот не заглядвали :) ) Другое дело что всех нюансов все равно не учтешь, вариантов много юзабилити например не учли или ещё чего что кажется не принципиальным — но по факту неприятный баг.

Зачем тогда QA вообще нужны ?

ну не для того, чтобы за девелоперами подтирать и проверять что на проде тоже работает. Exploratory testing, сложные случаи, организация процесса. И не всегда они нужны, в зависимости от рисков и сложности системы. Зачастую даже вредны.

самим тестировать

Программист может сам протестировать примерно с тем же качеством, что тестировщик может сам написать.

Програмісту, який не зміг вигадати все те, що зміг тестувальник, немає місця на ринку.

немає місця на ринку.

Ох эти мечты и влажные фантазии :)

Кстати, а тестировщику, который не может имплементировать всё то, что может протестировать, место на рынке есть?)

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

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

Программист может сам протестировать примерно с тем же качеством, что тестировщик может сам написать.

В смысле, проверить то, что работает не только на машине разработчика, но и на проде?

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

Другое дело, что система, и особенно постановка тестирования ее может быть сложной, но это в 80% случаев проблема процесса.

За то, чтобы всё работало, отвечает QA. За то, чтобы всё работало в срок — отвечает девелопер.

Воно завжди все працює. Правда, інколи недовго, а інколи не так, як треба. Але працює все завжди.

На одной из прошлых работ в течение большей части времени из 4-х лет, что я там работал, был единственным Андроид-разработчиком. Бывали периоды, тянул одновременно 2-3 проекта. Надо сказать, очень доходчиво понимаешь, почему важна архитектура, паттерны, солиды. Когда через несколько месяцев уже в собственноручно написанном коде начинаешь в офисе ночевать, чтобы причину бага найти, потом очень ответственно к чистоте кода подходишь в следующем проекте. Это не прочувствовать, когда тебе пытается привить чистоту кода через код ревью тимлид с «синдромом вахтёра», который необоснованно, по твоему мнению, придирается к мелочам. Когда на своей шкуре понимаешь, к каким последствиям через полгода наслоения этих «мелочей» приводят.

а можно адресок ? проверим на устойчивость к скрапингу)

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

к сожалению, общемировая практика признаёт скрапинг как вполне себе легальную деятельность, соответственно не вижу ничего неэтичного)

полезная статья! спасибо!

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

Зачем так бэкапить? Почему для этой цели не использовать систему контроля версий, хоть гит, хоть svn?

Проект был реализован по принципу DB first, и бэкап так или иначе было необходимо создавать, так как миграций для восстановления конкретной версии там не было. А вот где его хранить, локально или на гите, это уже частность.

Версионинг БД и пихать в репу

Почему для этой цели не использовать систему контроля версий, хоть гит, хоть svn?

ну, технически не проблема дамп БД закидывать в гит. Но стоит ли оно того?

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

Да, погорячился. Спасибо.

Також на початку карєри був єдиним фулстек/веб розробником в команді десктоп розробників. Це були часи нестандартних браузерів, Internet Explorer 6, XHTML, верстання table-ами, зачатків jQuery, third party Web User Controls i відсутності StackOverflow, а ще моєї дурості, що карєру треба будувати в одній компанії.
За 3 роки я написав купу граблі, за які зараз соромно, пройшов шлях «Dunning—Kruger effect» від «Піку дурості» до «Ями Страждань», звалився в депресію, відстав від трендів, через відсутність менторів, не вивчив нічого корисного, так і не освоїв FrontEnd розробку.
Короче нікому не рекомендую такого досвіду.

*мем з Гарольдом, що приховує біль*

Я став єдиним девелопером на проекті через три місяці від початку роботи. Першої роботи джуніор програмістом без попереднього досвіду.
Це була просто сатана. Але були і плюси — вчишся дуже швидко :)

Я представляю, какой это был вызов) но, мне кажется, такой опыт лишним не бывает

Схожа історія :)
Рятували друзі-досвідчені розраби, які погоджувались іноді ввечері приділяти годинку твоїм проблемам
Вчишся, справді, з космічною швидкістю

Коли працюєш один іноді не вистачає свого «доктора Ватсона». ))
Комусь допомагає гумова качечка але людина все ж була б краще

аби вигляд мала розумний ))

Уточки это круто, но на определенном этапе хочется что бы она все-таки умела говорить и была ИТ специалистом:)

самое время затолкать в уточку нейронную сеть)

Подписаться на комментарии