Прилетел из Ростова-на-Дону в Москву.

Теперь про то, что делать с проектом, когда он готов.

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

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

Ответ во втором критерии — решении задачи. Потому что может оказаться, что проект решает смежную задачу, и вам будет необходимо немного скорректировать траекторию развития проекта.

Например, когда я сделал Pycon, мой преподаватель в Яндекс.Лицее проявил инициативу, и мы провели первое настоящее альфа-тестирование.

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

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

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

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

В Москве есть терминалы для пополнения транспортной карты «Тройка». Раньше были жёлтые прямоугольнички, и когда ты прикладывал к ним карту, то высвечивалась надпись типа

КОШЕЛЁК
ОСТАТОК 12 ЕДИНИЦ
ДЕЙСТВУЕТ ПО 17.03.2024

Даю немосквичам подумать, что такое «единицы» и много ли это — 12 единиц.

.
.
.

Короче, оказывается, единицы — это рубли. 12 рублей.

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

Это была присказка, а основная мысль вот какая. Когда люди долго что-то разрабатывают, они неизбежно навешивают абстрактные ярлыки на всякие образы, просто чтобы было короче. Например, я пилил проект, в котором были классы World, Agent, Handler и Manager — а вот что это значит, было закопано где-то в середине документации. И это ошибка — с объяснения того, что чем называется, надо было вообще начать, потому что иначе сторонний разработчик копается в коде и не понимает, что происходит. Поэтому если вы знаете слово, которое в команде разработки повторяется достаточно часто — проверьте, насколько оно интуитивно воспринимается со стороны и объясните его другим, если нужно.

А Мосметро надо переименовать единицы в рубли — не казино ведь.

Недавно опять налажал с гитом.

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

Потратил час на прочтение документации по гиту по этим командам. Моя жизнь стала в сто раз лучше. Планирую прочитать весь официальный Git Book.

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

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

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

В моём случае вся акселерация состояла из пяти звонков длительностью 15 минут по четвергам. Я просто рассказывал, что сделал, и (что важно) отправлял скриншот карточки в Трелло того, что я должен сделать за неделю. И это просто магия какая-то, потому что моя производительность повысилась в разы! Казалось бы.

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

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

Конечно, вам нужно делать задачи в порядке важности, который вы определили на первом тестировании. Но у меня так не получилось — я делал карточки из списка «классные фичи», а список «ОЧЕНЬ ВАЖНО!!!» остался почти тем же. Потому что сложные и важные задачи обычно делать сложнее. :—)

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

Обожаю Пайчарм за внимание к супермелочам.

Например, если вынести методы класса наружу (как обычные функции), то он автоматически заменит одну пустую строку между методами на две согласно PEP8. И наоборот.

HTML и CSS — это, чуваки, жуткий депрекейтед.

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

А нам (точнее, вам, фронтендерам :—) придётся с ним мучаться. Ты пишешь vertical-align — и, скорее всего, ничего не произойдёт, потому что ой знаете это свойство работает только для элементов типа Жопа. Вертикал-элайн должен делать то, что подразумевается — двигать блок наверх, и ниипёт. Язык должен стать более декларативным. float не должен ломать половину других свойств при применении. width: 1px вообще не должен существовать.

Возможно, будущее за гибкими конструкторами сайтов типа Редимага — но это как просто положить кусок говна в красивую обёртку от конфеты. Человечество заслуживает чего-то принципиально нового и удобного.

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

А всё остальное надо к чертям выкинуть и переписать.

Косяк в приложении Додо. Там база устроена так, что «сырники с малиновым вареньем» — это на самом деле просто сырники, а выбрать сгущёнку или варенье ты должен уже внизу (последний пункт заказа на скрине).

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

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

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

Я же тут поднимаюсь до мидла, да? Вот мой прогресс за месяц:

1. Кажется, я наконец-то научился работать в команде. Так получилось, что раньше я всегда работал один, а если над моим кодом работал кто-то ещё, это превращалось для меня в мучения.

Я очень сильно привязываюсь к коду, который пишу сам с нуля. Если я написал микросервис, дал наружу сигнатуры API, то не надо было писать мне «а почему ты здесь написал вот так, если можно было вот так: ...». Объяснение, почему я сделал так, как сделал, отнимало у меня невероятно много нервов. Самое страшное было, когда кто-то коммитил в мой код. Ты что, охуел трогать мой священный микросервис?

Конечно, это неправильно, и я это понимал, но ничего с собой сделать не мог.

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

1.1. Научился работать с гитом в команде. Раньше у меня было две (в лучшем случае) ветки, и не было непредсказуемых ситуаций. Теперь веток миллиард, гитфлоу, надо уметь чинить свои косяки некостыльно, и мне пришлось побольше почитать про гит и разобраться в штуках, которые я не знал.

2. Научился работать восемь часов в день.

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

3. Ну и, конечно, технические штуки, которые я объединяю в один пункт. Научился работать с REST-либами, немного тестирования, прокачался в CI, в Докере, просто начал делать полезные штуки типа лейблов для мёрдж-реквестов. Тут особо ничего и не скажешь — научился и научился. Хотя это вообще самое главное.

<Здесь был пост, а потом я один раз случайно перетёр его содержимое. Нужно пойти в архив и восстановить.>

А ещё в конце концов ты можешь оказаться неправ — у меня было много раз, что я говорил (или уже собирался говорить) «Не, это невозможно», а потом ещё немного сидел и оказывалось, что возможно.

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

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

У меня они такие:

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

Я думаю, это хорошо.