Первое — это сам проект. Критерии крутого проекта:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, когда я сделал 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, в Докере, просто начал делать полезные штуки типа лейблов для мёрдж-реквестов. Тут особо ничего и не скажешь — научился и научился. Хотя это вообще самое главное.

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