Тег «советы»

Правила хобби-проектов

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

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

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

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

Задокументировать архитектуру в ARCHITECTURE.md

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

Например, кусок из ARCHITECTURE.md Комлинка:

### Accounts

Контекст, отдельный от всего остального. Не должно быть зависимостей во вне (например, на Feeds).
Этот контекст занимается _пользователями_: регистрация через почту, через гитхаб, подтверждение аккаунтов, инвайты.

### Feeds
Контекст, который занимается _постами_ и комментариями к ним.

### Events
Контекст, который занимается _событиями_: например, конкретная встреча нодскула.

## Веб
### Вьюхи

Для каждой сущности должно в итоге быть несколько шаблонов:

1. Full. Entity with all related things.
   E.g. Post: includes Comments, includes Author, includes Group, etc.
2. Widget. When element is tightly related on one-to-one basis
   E.g. on Event page there would be Place widget.
3. List item. When we present a list of homogenous entities.
   E.g. On main page, we see a list of posts. On post page we see a list of comments.
4. Line. When we mention entity in passing.

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

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

В каком случае правило помогает: когда возвращаешься через месяц-полгода к проекту, становится сильно проще восстановить структуру в голове. Зная структуру, становится проще локализовывать проблемы.

Записать в README.md как запустить проект с нуля

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

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

Покрыть тестами то, что может сломаться

Чтобы не бояться менять то, что можно менять. Не надо целиться на стопроцентное покрытие тестами — но имеет смысл потестировать суть и самые важные флоу. Так что это не про юнит-тесты, а про интеграционные тесты и user acceptance тесты.

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

Деплоить одной простой командой

Хуже всего, когда пишут в твиттере, мол, сайт не работает, ты уже пофиксил — а как деплоить-то и забыл. Rsync? А какие флаги нужны? А на каком сервере оно сейчас лежит? (pun intended)

Хотя нет, ещё хуже — это когда процесс деплоймента звучит как «так, делаешь ssh на сервер, ищешь директорию, делаешь git pull, мёржишь конфликты, потом запускаешь вот такую команду…» У тебя и так много боли, не надо добавлять её ещё и деплойментом.

В каком случае правило помогает: Каждый. Чёртов. Раз.

Задокументировать создание серверов

Даже если в моменте кажется «да там дроплет создал, хуё-моё, постгрес накатил и скачал архивчик, делов-то», лучше описать процесс, пока можешь. Рано или поздно с сервером что-то случится, и, по законам Мёрфи, в этот момент уже будет поздно вспоминать.

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

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

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

Вести роадмап вне головы и ввести цели

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

Роадмап на пару шагов вперёд помогает удерживать big picture в фокусе. Цели проекта помогут оценить, правильно ли идёт дело.

В каком случае помогает: Когда хобби-проект начинает расти.

1

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

Пятая симфония Бетховена

Кросспост из моего телеграм-канала #longtailed.

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

Как слушать «классическую» музыку

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

Раньше музыку слушали по-другому. До появления звукозаписи люди не могли включить музыку по дороге на работу или в метро, и «индивидуального» прослушивания музыки тоже практически не было: «высокую» музыку ходили слушать в концертные залы, и это во многом был Концертный Экспириенс. Также люди играли дома самостоятельно (насколько помню, с появлением же звукозаписи заметно упали продажи нот, на которых зарабатывали многие композиторы). И, на примере симфоний, это непрерывный период слушания, в котором отвлекаться особо не на что. Совет: Попробуйте выделить спокойные сорок минут дома, когда вы никуда не едете и не спешите, включите музыку и постарайтесь не переключаться на дела.

Стоит осознать разницу современной музыки и «классической». Практически вся современная музыка написана в одной форме — песня, в то время как в «классической» музыке форм дофига. Форма задаёт ожидания слушателей: вы ожидаете, что в песне будет текст/припев/куплет/проигрыш/припев; так и с другими формами. Форма была важна и для композиторов немного в другом ключе — они зачастую (например, Бетховен) и вовсе не давали названий своим творениями и они назывались «по форме», то бишь, сейчас это было бы что-то вроде: Наутилус Помпилиус — Песня в си-минор №30, и всё. Совет: Попробуйте понять, какой форме следует автор (и на какие приличия он, может быть, плюёт!)

С другой стороны, мы сейчас выделяем много жанров современной музыки, а всю «старую» музыку кидаем в одну коробку — а там тоже всё очень неоднородно. ADVICE: попробуйте послушать разные формы, разных композиторов, разного времени (как искать что нравится — тема для отдельного разговора!).

Современная музыка (опять же, это связано с звукозаписью) очень сильно привязана к личности автора — практически всегда он же и исполнитель, и есть «каноничная» версия. Ситуации, где песню исполняет кто-то другой, довольно редки, а в случае с «классической» же музыкой одну и ту же симфонию исполняют десятки оркестров под руководством самых разных режиссёров, и, как и с каверами, каждый вносит что-то своё. Совет: Если вам понравилось что-то, то стоит а) запомнить, кто играет и кто дирижирует, б) сравнить с другими исполнениями!

Самое базовое, наверно: в отличие от современной музыки НЕТ СЛОВ НЕПОНЯТНО ЧТО СЛУШАТЬ ЧТО ХОТЕЛ СКАЗАТЬ АВТОР (а когда они есть, то всё равно непонятно). Базовые вещи не поменялись, музыка — выражение ощущений, мыслей и образов, просто раньше оперировали другими инструментами (pun intended), поэтому выражалось менее грубо. Совет: Не стоит взвинчивать себя поисками Смысла, это скорее игра в распознавание структур, а смыслы сами себя найдут (я ещё не встречал людей, у которых третье движение в Пятой симфонии не ассоциировалось с военными/маршами). Как в известной картинке про шторы, автор хочет, чтобы вы послушали перекличку духовых и всё.

Пятая симфония

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

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

А в качестве конкретной записи хочется порекомендовать Джона Элиота Гардинера с Революционно-романтическим оркестром. Про эту запись есть два интересных момента, если сравнивать с другими: во-первых, она быстрее, чем «обычно», это очень заметно. А во-вторых, это оркестр «аутентистов», они стараются воспроизводить музыку, «как она тогда звучала», например, струны у них не из металла, а из жил/кишок (и, опять же, сравните разницу в звуке с Лондонским оркестром, здесь он приземлённый и более агрессивный).

В записи все девять симфоний, так что если понравится, то в ней есть ещё много очень хорошего (седьмая, например!)

Это был кросспост из моего телеграм-канала #longtailed.

21 идея для разработчика

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

  1. Задача программиста не «писать код», задача программиста — решать бизнес-задачи, и «поиграться с новым фреймворком» зачастую не решает бизнес-задачу.
  2. Мы работаем с людьми, и только иногда пишем код, поэтому отношения между людьми — важная часть работы.
  3. Разработчики тоже люди, и подвержены всем тем же когнитивным ошибкам, что и все остальные. Стоит почитать про когнитивные ошибки, FAE, и книгу Канемана в отдельности.
  4. Постоянно сменяющиеся фреймворки появляются потому, что у нас нет идеального решения проблем, которые стоят перед фронтенд-разработчиками. Каждый следующий успешный фреймворк — шаг в интересном направлении в сторону идеала, стоит относиться к ним с точки зрения «что интересного этот фреймворк/библиотека привносит в мою работу».
  5. Разработчики не просто «пишут код», они участвуют в бизнес-процессах. Если в компании принят Аджайл, то нужно относиться к этому если не серьёзно, то как минимум с уважением.
  6. Код-ревью — важная часть процесса разработки. Нельзя быть хорошим разработчиком, но относиться к код-ревью халатно.
  7. Как программисты, мы несём ответственность за то, что деплоим. В том числе, и моральную. Не стоит делать неэтичные вещи.
  8. Пользователи — живые люди. Наши продукты и ошибки могут напрямую влиять на их жизнь, стоит осознавать последствия наших действий.
  9. Люди отличаются друг от друга, люди думают по-разному: что нам кажется сложным, бизнесу может казаться тривиальным — это создаёт конфликт, который приходится разрешать.
  10. Нужно нести ответственность за свои дедлайны, и если не укладываешься — идти передоговариваться.
  11. У задач есть два вида сложности: внутренняя и внешняя сложность. От первого вида сложности не избавиться, он есть в задаче изначально; второй привносим мы, городя неуместные архитектуры и изобретая велосипеды. Надо следить за тем, чтобы внешняя сложность не была больше внутренней.
  12. Когда при написании кода или проектировании архитектуры разработчик выбирает простое решение вместо правильного, он создаёт технический долг. По долгам придётся платить.
  13. Код других людей почти всегда кажется непонятным или криво написанным, не всегда причина в том, что код действительно криво написан. Иногда эти другие люди — это мы полгода назад.
  14. Иногда задача решается без изменения кода вовсе.
  15. Смелость менять то, что нужно менять, безразличие к тому, что изменить невозможно, и мудрость отличить одно от другого.
  16. Случается так, что тривиальное для разработчика бизнесу чрезвычайно полезно и ценно — это хорошая ситуация, не стоит от неё бежать.
  17. Редкая компания заинтересована в твоём росте: если бы её не устраивал твой текущий уровень, тебя бы не взяли.
  18. Конференции, митапы и прочее полезны в первую очередь людьми, которые пришли, и во вторую — докладами.
  19. Собеседование — это игра на двоих, не только компания смотрит на тебя, но и ты — на компанию.
  20. Мы приходим в профессию, потому что нам это интересно, но платят нам за пользу, которую мы приносим. Стоит почитать про cost center и profit center, и понимать, где ты находишься сейчас.
  21. Когда работаешь фрилансером, заказчик нанимает тебя ради скиллов, которых у него нет — он не может указать тебе на плохой код, а ошибки, которые ему видны, описывает своим языком.

Написать мысли насчёт, кхм, списка мыслей можно на [email protected] или в твиттере: я там @marinintim.