Читаем всей семьей, новый технолоджи радар вышел.

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

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

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

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

Вот вам ценная информация, если когда-то надумаете участвовать в стажировке.

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

P.S. Немного забавно читать, когда стек у стажеров больше чем у меня.

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

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

Пока это лучшее

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

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

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

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

Вот что подумалось, с помощью ast разбирать класс на функции, делать автоматом генерировать промт

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

[описание морфемы]

[чеклист для морфемы]

[код функции]

🤔🤔🤔

Попробуем-с на досуге