Федя и Самат
Начинать новое дело — страшно. Нет, очень страшно. Конечно существуют люди вроде Сержа Фаге, которые запускают по несколько бизнесов в год, но меня любой запуск пугает настолько, что в середине дня позвоночник иногда прошивает холодом, а если проснулся в 3 утра — можно смело идти за ноутбуком и начинать рабочий день: всё равно не заснуть. Надеюсь, с опытом это пройдет :-)
В любом случае, вдвоём страшно чуть меньше. Мы с Саматом запускаем совместную услугу — настройку ин-хаус разработки. Это не аутсорс, который перепродаёт часы программистов, и не консалтинг, который говорит «как надо» и уходит в сторону, когда получается «как вышло».
Мы — это другой уровень. Приходим в компанию и выстраиваем вашу собственную разработку: тренируем команду, нанимаем новых ребят, лечим кодовую базу и процессы, помогаем принимать продуктовые решения. Нанять нас — это как нанять крутейшего техдира (вернее двух), но без опционов и обязательства до конца жизни платить зарплату. Всё это мы уже делали много раз в разных компаниях, а сейчас поняли, что можем это смасштабировать.
Совсем скоро мы в реальном времени начнём рассказывать, как именно мы помогаем одному из наших клиентов: расскажем, как крупный сервис доставки с 4000 заказов в день решает наболевшие у всех проблемы, вроде накопленного техдолга и перегруженной команды разработки.
Если хотите, чтобы мы помогли вашей компании — напишите Самату на @samatg. Если вы — разработчик и хотите работать в одной из наших команд, напишите мне на fedor@borshev.com.
Начинать новое дело — страшно. Нет, очень страшно. Конечно существуют люди вроде Сержа Фаге, которые запускают по несколько бизнесов в год, но меня любой запуск пугает настолько, что в середине дня позвоночник иногда прошивает холодом, а если проснулся в 3 утра — можно смело идти за ноутбуком и начинать рабочий день: всё равно не заснуть. Надеюсь, с опытом это пройдет :-)
В любом случае, вдвоём страшно чуть меньше. Мы с Саматом запускаем совместную услугу — настройку ин-хаус разработки. Это не аутсорс, который перепродаёт часы программистов, и не консалтинг, который говорит «как надо» и уходит в сторону, когда получается «как вышло».
Мы — это другой уровень. Приходим в компанию и выстраиваем вашу собственную разработку: тренируем команду, нанимаем новых ребят, лечим кодовую базу и процессы, помогаем принимать продуктовые решения. Нанять нас — это как нанять крутейшего техдира (вернее двух), но без опционов и обязательства до конца жизни платить зарплату. Всё это мы уже делали много раз в разных компаниях, а сейчас поняли, что можем это смасштабировать.
Совсем скоро мы в реальном времени начнём рассказывать, как именно мы помогаем одному из наших клиентов: расскажем, как крупный сервис доставки с 4000 заказов в день решает наболевшие у всех проблемы, вроде накопленного техдолга и перегруженной команды разработки.
Если хотите, чтобы мы помогли вашей компании — напишите Самату на @samatg. Если вы — разработчик и хотите работать в одной из наших команд, напишите мне на fedor@borshev.com.
#вопрос почему ты решил уйти из агентства в продуктовую разработку?
В продуктовой компании (а тем более в стартапе) гораздо больше чувство причастности — на момент перехода я гнался за тем, чтобы не быть маленьким винтиком в чужой системе (или в 10 системах, в случае агентства). Я хотел полностью нести ответственность за всё, что происходит — начиная от определения стратегии, заканчивая постановкой и выполнением задач.
Хотелось доказать себе, что я могу не только делать, что говорят клиенты, но и самостоятельно участвовать в процессе зарабатывания денег. Мне очень повезло с ГдеМатериалом — я пришёл в только образовавшуюся команду без собственных наработок, поэтому выстроил все процессы буквально из ничего.
Ну а ещё — я фанат качественного кода, а в агентствах обычно с этим туго.
Сейчас я выхожу на следующий за внутренней разработкой уровень — мы с Саматом Галимовым начинаем серийно масштабировать внутреннюю разработку, то есть делать так же быстро, как в агентстве, но так же качественно, как ин-хаус.
В продуктовой компании (а тем более в стартапе) гораздо больше чувство причастности — на момент перехода я гнался за тем, чтобы не быть маленьким винтиком в чужой системе (или в 10 системах, в случае агентства). Я хотел полностью нести ответственность за всё, что происходит — начиная от определения стратегии, заканчивая постановкой и выполнением задач.
Хотелось доказать себе, что я могу не только делать, что говорят клиенты, но и самостоятельно участвовать в процессе зарабатывания денег. Мне очень повезло с ГдеМатериалом — я пришёл в только образовавшуюся команду без собственных наработок, поэтому выстроил все процессы буквально из ничего.
Ну а ещё — я фанат качественного кода, а в агентствах обычно с этим туго.
Сейчас я выхожу на следующий за внутренней разработкой уровень — мы с Саматом Галимовым начинаем серийно масштабировать внутреннюю разработку, то есть делать так же быстро, как в агентстве, но так же качественно, как ин-хаус.
А давайте потусим в Питере в субботу?
В эту субботу в 14:00 собираемся в творческом пространстве Код 505 на Старом Невском.
Будет AMA — вы задаёте вопросы, а я отвечаю. Как Живые Советы, только в Питере. Чтобы прийти, нужно зарегистрироваться и придумать вопрос. Доступно всего 30 мест.
Регистрируйтесь и подписывайтесь на канал встречи с оперативными новостями.
В эту субботу в 14:00 собираемся в творческом пространстве Код 505 на Старом Невском.
Будет AMA — вы задаёте вопросы, а я отвечаю. Как Живые Советы, только в Питере. Чтобы прийти, нужно зарегистрироваться и придумать вопрос. Доступно всего 30 мест.
Регистрируйтесь и подписывайтесь на канал встречи с оперативными новостями.
Ну и чтобы два раза не вставать — я ищу фронтендера на свой проект. Обязательно знать vue.js и не бояться код-ревью, желательно знать Quasar Framework, иметь Android-телефон и писать тесты (если нет — научим). Работа проектная, занятость парт-тайм, оплата — по неделям.
Присылайте ссылку на гитхаб, пожелания об условиях работы и пару слов о себе на fedor@borshev.com с пометкой «Фронтендер-андроидер»
Присылайте ссылку на гитхаб, пожелания об условиях работы и пару слов о себе на fedor@borshev.com с пометкой «Фронтендер-андроидер»
Что делать, если проебал дедлайн?
Что глупого можно сделать, когда опаздываешь на встречу? Предупредить об опоздании за пять минут до начала. А еще глупее? Пообещать прийти через 10 минут, а прийти через 20 — опоздаешь дважды.
Когда я опаздываю, я волнуюсь. А когда я взволнован, я неверно воспринимаю реальность — переоцениваю силы и называю заниженные сроки. В новые сроки невозможно уложиться, и все повторяется по кругу — доверие разваливается вместе с проектом.
Если проебал задачу — не торопись называть новый дедлайн. Тот срок, который вертится на языке — результат целого пучка когнитивных искажений. Если ты ошибся в спокойной обстановке, то почему думаешь, что не ошибаешься сейчас, когда быстрое мышление заполняет разум стыдом и неуверенностью?
Ошибиться со сроком — не страшно. Страшно — ошибиться второй раз: тебе перестанут доверять.
Подумай, из-за чего произошла накладка. Не давай обещаний, пока четко не осознаешь настоящую причину, почему проебал срок в первый раз:
Я неверно оценил свои силы → Я долго разбирался с новым плагином для Ангуляра
Изменились условия задачи → Я не учел, что потребуется переверстывать шапку
Я неверно понял задачу → Я не обсудил задачу с постановщиком
Подумай, что еще упустил при планировании. Выспись: новый срок назовешь завтра, не страшно. А если менеджер прижимает к стенке и требует дату прямо сейчас — умножай срок, который хотел назвать, на три.
Что глупого можно сделать, когда опаздываешь на встречу? Предупредить об опоздании за пять минут до начала. А еще глупее? Пообещать прийти через 10 минут, а прийти через 20 — опоздаешь дважды.
Когда я опаздываю, я волнуюсь. А когда я взволнован, я неверно воспринимаю реальность — переоцениваю силы и называю заниженные сроки. В новые сроки невозможно уложиться, и все повторяется по кругу — доверие разваливается вместе с проектом.
Если проебал задачу — не торопись называть новый дедлайн. Тот срок, который вертится на языке — результат целого пучка когнитивных искажений. Если ты ошибся в спокойной обстановке, то почему думаешь, что не ошибаешься сейчас, когда быстрое мышление заполняет разум стыдом и неуверенностью?
Ошибиться со сроком — не страшно. Страшно — ошибиться второй раз: тебе перестанут доверять.
Подумай, из-за чего произошла накладка. Не давай обещаний, пока четко не осознаешь настоящую причину, почему проебал срок в первый раз:
Я неверно оценил свои силы → Я долго разбирался с новым плагином для Ангуляра
Изменились условия задачи → Я не учел, что потребуется переверстывать шапку
Я неверно понял задачу → Я не обсудил задачу с постановщиком
Подумай, что еще упустил при планировании. Выспись: новый срок назовешь завтра, не страшно. А если менеджер прижимает к стенке и требует дату прямо сейчас — умножай срок, который хотел назвать, на три.
Самое главное правило сдачи работы
Самое главное правило сдачи любой творческой работы — никогда не оставляй заказчика одного. Не кидай ссылку на макеты, не отправляй демо-доступ, не высылай текст в Гугль-доке.
Если тебя нет рядом — любой вопрос автоматически получает ответ не в твою пользу. Почему мы сделали вход по имейлу вместо входа по паролю? Почему я нажимаю на пятую кнопку на третьей странице, а она не работает? Что имел ввиду дизайнер?
В личном разговоре всё это можно сгладить, объяснить, убедить — в итоге будет понятный компромисс и синхронное с заказчиком продвижение к результату. А когда тебя рядом нет — итогом будут только правочки.
Не хочешь слить в трубу результаты работы — презентуй её лично.
Самое главное правило сдачи любой творческой работы — никогда не оставляй заказчика одного. Не кидай ссылку на макеты, не отправляй демо-доступ, не высылай текст в Гугль-доке.
Если тебя нет рядом — любой вопрос автоматически получает ответ не в твою пользу. Почему мы сделали вход по имейлу вместо входа по паролю? Почему я нажимаю на пятую кнопку на третьей странице, а она не работает? Что имел ввиду дизайнер?
В личном разговоре всё это можно сгладить, объяснить, убедить — в итоге будет понятный компромисс и синхронное с заказчиком продвижение к результату. А когда тебя рядом нет — итогом будут только правочки.
Не хочешь слить в трубу результаты работы — презентуй её лично.
Спасибо всем, кто пришёл вчера на AMA в Питере!
Вы задавали интересные и сложные вопросы, давали полезные дополнения. Получилось супер!
Думаю, можно будет повторить через месяц или два.
Вы задавали интересные и сложные вопросы, давали полезные дополнения. Получилось супер!
Думаю, можно будет повторить через месяц или два.
Вопрос: какой софт используешь для Pomodoro? Синхронизируешь ли с календарём и другими приложениями?
Я использую Tomato One.
Со времён поста про Помодоро у меня стало меньше концентрированной работы — я гораздо больше разговариваю с людьми, чем пишу код, так что количество помидорок немного уменьшилось. Синхронизацию с календарём я потерял года три назад — просто не вижу в ней смысла: время прекрасно учитывает RescueTime, с которого я скоро смигрирую на встроенный в Catalina учёт времени.
Есть вопрос? Напишите мне на fedor@borshev.com
Я использую Tomato One.
Со времён поста про Помодоро у меня стало меньше концентрированной работы — я гораздо больше разговариваю с людьми, чем пишу код, так что количество помидорок немного уменьшилось. Синхронизацию с календарём я потерял года три назад — просто не вижу в ней смысла: время прекрасно учитывает RescueTime, с которого я скоро смигрирую на встроенный в Catalina учёт времени.
Есть вопрос? Напишите мне на fedor@borshev.com
Я начал новый цикл советов — простым языком рассказываю, чем аккуратный объектно-ориентированный код отличается от неаккуратного.
В первом совете из цикла рассказал о зацеплении — показателе того, насколько один класс зависит от другого.
Как думаете, насколько получилось понятно для ребят, неискушённых в программировании?
В первом совете из цикла рассказал о зацеплении — показателе того, насколько один класс зависит от другого.
Как думаете, насколько получилось понятно для ребят, неискушённых в программировании?
Запись вебинара об удалённой работе
Готова запись моего вебинара об удалённой работе, который проходил в прошлое воскресенье. Вышло туго — видео сильно дёргается. Я долго сомневался, выкладывать ли запись вообще, но потом поспрашивал у тех, кто смотрел вебинар — говорят, что мешает не сильно.
Так что вот вам ссылка для покупки. В честь первого дня продаж — скидка, запись стоит всего 2000 рублей.
Из записи вы узнаете, как строить распределённые команды — нанимать людей, делать их счастливыми, управлять происходящим. Если работаете в офисе — тоже пригодится: совсем не обязательно сидеть дома, чтобы быть поддерживать дела в порядке.
Готова запись моего вебинара об удалённой работе, который проходил в прошлое воскресенье. Вышло туго — видео сильно дёргается. Я долго сомневался, выкладывать ли запись вообще, но потом поспрашивал у тех, кто смотрел вебинар — говорят, что мешает не сильно.
Так что вот вам ссылка для покупки. В честь первого дня продаж — скидка, запись стоит всего 2000 рублей.
Из записи вы узнаете, как строить распределённые команды — нанимать людей, делать их счастливыми, управлять происходящим. Если работаете в офисе — тоже пригодится: совсем не обязательно сидеть дома, чтобы быть поддерживать дела в порядке.
YouTube
Тизер вебинара «Счастье и процессы в удалённой работе»
Полная запись — http://pmdaily.ru/courses/remote-happiness/. Видео получилось дёрганым, но это всё равно лучше, чем ничего.
free-for.dev
Давно хотел вам посоветовать крутейший источник знаний об окружающем мире — free-for.dev. Это каталог сервисов, которые предоставляют бесплатные тарифы для программистов. Ценность этого каталога — не в халяве (хотя наверное это кому-то тоже важно), а в его таксономии. Просто читаете, какие сервисы существуют, и узнаёте много нового о современном контексте разработки.
К примеру именно из free-for.dev я когда-то давно узнал, что в мире существуют такой класс сервисов, как APM, или что можно просто скормить все логи в papertrail, а не поднимать свой ELK-стек.
Каждый раз, когда собираетесь притащить что-нибудь новое в свою инфраструктуру — посмотрите на free-for.dev, наверняка это уже есть в виде облачного сервиса за $10 в месяц.
Давно хотел вам посоветовать крутейший источник знаний об окружающем мире — free-for.dev. Это каталог сервисов, которые предоставляют бесплатные тарифы для программистов. Ценность этого каталога — не в халяве (хотя наверное это кому-то тоже важно), а в его таксономии. Просто читаете, какие сервисы существуют, и узнаёте много нового о современном контексте разработки.
К примеру именно из free-for.dev я когда-то давно узнал, что в мире существуют такой класс сервисов, как APM, или что можно просто скормить все логи в papertrail, а не поднимать свой ELK-стек.
Каждый раз, когда собираетесь притащить что-нибудь новое в свою инфраструктуру — посмотрите на free-for.dev, наверняка это уже есть в виде облачного сервиса за $10 в месяц.
#вакансия #работамечты #питер
Мы с Саматом ищем рубистов в iGooods. Вы придёте в самую сложную и интересную фазу проекта — мы забрали код от аутсорсеров, и теперь приводим его в порядок: покрываем тестами API, разбиваем лишние связи, строим нормальный CI/CD. Из последних достижений — выдернули user-facing фронтенд из монолита и запустили SPA на React/TSX, унесли тестовые стенды на DigitalOcean, внедрили Rails::Engine и прямо сейчас внедряем паттерн Repository, чтобы избавиться от толстых моделей.
Проект — автоматизация службы доставки из магазинов: задания для сборщиков товаров и курьеров, управление персоналом (сколько и куда выводить людей), интеграции с разными сервисами, начиная от разбора списка товаров от сотен офлайн-магазинов и заканчивая собственной системой аналитики на ClickHouse. По технологиям — Rails 4 (скоро поправим), DRY-стек, тесты пишем на RSpec. Код и CI на Гитлабе, задачи в Джире. Лежит всё на железках в Селектеле, но мы активно виртуализуемся и контейнеризуемся.
Вы будете седьмым бекендером в команде, которая под нашим руководством приведёт в порядок кодовую базу без отрыва от выкатывания полезных фич. Это — отличный опыт и красивая строчка в резюме.
Работа из офиса на Технологическом институте, один день в неделю — дома. Зарплата — от 150k для мидлов и 250к+ для синьоров. Если вы — джуниор и покажете проект с тестами на гитхабе, возьмём вас на 80k и прокачаем до мидла.
За рекомендацию мидла, который пройдёт испытательный срок, бонус 80 000 рублей.
Вопросы и отклики пишите руководителю бекенда Жене Зубаирову @MindCufk.
Мы с Саматом ищем рубистов в iGooods. Вы придёте в самую сложную и интересную фазу проекта — мы забрали код от аутсорсеров, и теперь приводим его в порядок: покрываем тестами API, разбиваем лишние связи, строим нормальный CI/CD. Из последних достижений — выдернули user-facing фронтенд из монолита и запустили SPA на React/TSX, унесли тестовые стенды на DigitalOcean, внедрили Rails::Engine и прямо сейчас внедряем паттерн Repository, чтобы избавиться от толстых моделей.
Проект — автоматизация службы доставки из магазинов: задания для сборщиков товаров и курьеров, управление персоналом (сколько и куда выводить людей), интеграции с разными сервисами, начиная от разбора списка товаров от сотен офлайн-магазинов и заканчивая собственной системой аналитики на ClickHouse. По технологиям — Rails 4 (скоро поправим), DRY-стек, тесты пишем на RSpec. Код и CI на Гитлабе, задачи в Джире. Лежит всё на железках в Селектеле, но мы активно виртуализуемся и контейнеризуемся.
Вы будете седьмым бекендером в команде, которая под нашим руководством приведёт в порядок кодовую базу без отрыва от выкатывания полезных фич. Это — отличный опыт и красивая строчка в резюме.
Работа из офиса на Технологическом институте, один день в неделю — дома. Зарплата — от 150k для мидлов и 250к+ для синьоров. Если вы — джуниор и покажете проект с тестами на гитхабе, возьмём вас на 80k и прокачаем до мидла.
За рекомендацию мидла, который пройдёт испытательный срок, бонус 80 000 рублей.
Вопросы и отклики пишите руководителю бекенда Жене Зубаирову @MindCufk.
Вопрос: почему ты работаешь стоя? Весь день вообще не садишься?
Когда-то я начал работать стоя в попытках разобраться с больной спиной. Со спиной в итоге разобрался при помощи доктора, но привычка работать стоя осталась. То есть если отвечать одним словом — работаю стоя потому, что мне это нравится.
За день я присаживаюсь много раз. Во-первых, я никогда не работаю дома больше, чем полдня. Во-вторых, в кафе и офисах клиентов часто не бывает мест для работы стоя. В третьих, работать за ноутбуком стоя не так уж и удобно — у меня 13", и чтобы разглядеть код, с моим ростом приходится наклонятся.
Другие вопросы — #вопрос. Задать свой — fedor@borshev.com
Когда-то я начал работать стоя в попытках разобраться с больной спиной. Со спиной в итоге разобрался при помощи доктора, но привычка работать стоя осталась. То есть если отвечать одним словом — работаю стоя потому, что мне это нравится.
За день я присаживаюсь много раз. Во-первых, я никогда не работаю дома больше, чем полдня. Во-вторых, в кафе и офисах клиентов часто не бывает мест для работы стоя. В третьих, работать за ноутбуком стоя не так уж и удобно — у меня 13", и чтобы разглядеть код, с моим ростом приходится наклонятся.
Другие вопросы — #вопрос. Задать свой — fedor@borshev.com
Срочно в номер: завтра ваш сертификат letsencrypt может превратится в тыкву
В Letsencrypt нашли баг, который при определённых условиях позволял перевыписать сертификат даже, если это запрещено владельцем домена.
Баг выглядит как не очень страшный, но есть большая проблема — letsnecrypt отзывает часть сертификатов, которые мог затронуть этот баг, причём отзывает их срочно, прямо завтра.
Это ощутимо задело ГдеМатериал — половину сертификатов пришлось перевыписывать.
Почитайте почту и проверьте свои сервисы вот тут.
В Letsencrypt нашли баг, который при определённых условиях позволял перевыписать сертификат даже, если это запрещено владельцем домена.
Баг выглядит как не очень страшный, но есть большая проблема — letsnecrypt отзывает часть сертификатов, которые мог затронуть этот баг, причём отзывает их срочно, прямо завтра.
Это ощутимо задело ГдеМатериал — половину сертификатов пришлось перевыписывать.
Почитайте почту и проверьте свои сервисы вот тут.
От 0 до 150 000 строк кода не жертувя качеством
Ребята из MoscowPython выложили видео моего доклада о том, как мы в ГдеМатериале поддерживаем качество кода.
В записи пошло не так всё, что только возможно — на доклад я приехал из соседнего города, поспав всего пару часов, мы не рассчитали положение петличного микрофона, презентация запустилась странным образом (буду делать не только PDF, но и PPTX), и я не нашёл на сцене воды, что с моим непривычным горлом привело к тому, что я чувствовал себя чукчей посреди аравийской пустыни.
Несмотря на все проблемы, получилось круто, так что смотрите, но не смейтесь :-)
Ребята из MoscowPython выложили видео моего доклада о том, как мы в ГдеМатериале поддерживаем качество кода.
В записи пошло не так всё, что только возможно — на доклад я приехал из соседнего города, поспав всего пару часов, мы не рассчитали положение петличного микрофона, презентация запустилась странным образом (буду делать не только PDF, но и PPTX), и я не нашёл на сцене воды, что с моим непривычным горлом привело к тому, что я чувствовал себя чукчей посреди аравийской пустыни.
Несмотря на все проблемы, получилось круто, так что смотрите, но не смейтесь :-)
YouTube
Django в стартапе: от 0 до 150 000 строк кода, не жертвуя качеством
Фёдор Борщёв (ГдеМатериал) @ Moscow Python № 72
"Речь пойдет о том, как мы поддерживаем здоровье кодовой базы в проекте с безумными требованиями к скорости и постоянно меняющимися задачами. Мы поговорим про TDD, SOLID и KISS там, где люди меньше всего к…
"Речь пойдет о том, как мы поддерживаем здоровье кодовой базы в проекте с безумными требованиями к скорости и постоянно меняющимися задачами. Мы поговорим про TDD, SOLID и KISS там, где люди меньше всего к…
Второй совет про аккуратный код: связность
Вышел второй совет об аккуратном коде, где я простым языком рассказываю о принципе единой ответственности (S из SOLID).
Опять прошу от вас обратной связи — понятно ли это для людей, которые не сильно разбираются в программировании?
Вышел второй совет об аккуратном коде, где я простым языком рассказываю о принципе единой ответственности (S из SOLID).
Опять прошу от вас обратной связи — понятно ли это для людей, которые не сильно разбираются в программировании?
#вопрос: объектно-ориентированный стиль или функциональный?
На похожий вопрос я уже отвечал в посте про монорепозитории. Если вкратце — выбор технологий зависит не от того, какая технология «лучше», а от того, насколько она применима к задачам, которые решает команда. Вы же не станете забивать гвозди копёром, просто потому, что вам нравится дёргать за рычаги и слушать звук дизеля?
Однако в выборе парадигмы программирования зарыта ещё одна интересная проблема — это уровень счастья людей, которые потом будут ей пользоваться. К примеру лично я получаю гораздо больше удовольствия, когда пишу функциональный код, нежели чем структурный.
Уверен, что я такой не один, поэтому жёстко приходить в команду с тем, что «мы теперь пишем только ООП» я бы не стал. Если бы я, как CTO, был уверен, что у нас вся команда хочет писать в функциональном стиле, функциональный стиль подходит ко всем нашим core-библиотекам, и мы сможем нанимать неограниченное количество новых людей, которые будут это поддерживать — я бы, наверное, согласился.
Задайте свой вопрос на fedor@borshev.com
На похожий вопрос я уже отвечал в посте про монорепозитории. Если вкратце — выбор технологий зависит не от того, какая технология «лучше», а от того, насколько она применима к задачам, которые решает команда. Вы же не станете забивать гвозди копёром, просто потому, что вам нравится дёргать за рычаги и слушать звук дизеля?
Однако в выборе парадигмы программирования зарыта ещё одна интересная проблема — это уровень счастья людей, которые потом будут ей пользоваться. К примеру лично я получаю гораздо больше удовольствия, когда пишу функциональный код, нежели чем структурный.
Уверен, что я такой не один, поэтому жёстко приходить в команду с тем, что «мы теперь пишем только ООП» я бы не стал. Если бы я, как CTO, был уверен, что у нас вся команда хочет писать в функциональном стиле, функциональный стиль подходит ко всем нашим core-библиотекам, и мы сможем нанимать неограниченное количество новых людей, которые будут это поддерживать — я бы, наверное, согласился.
Задайте свой вопрос на fedor@borshev.com
Коридорное тестирование
Коридорное тестирование — это когда берёшь систему (или её прототип), выходишь в коридор и просишь первого встречного решить с их помощью задачу. Скажем, делаешь новую навигацию для интернет-магазина и просишь пару случайных пользователей найти глубокозапрятаный пылесос определённой марки.
Есть ребята, которые под коридорным тестированием понимают «взять макеты и побегать с ними по коридору». То есть не тестируют прототипы, а просто показывают макеты разным людям и спрашивают «что думаешь?».
Кроме очевидной глупости — увеличения энтропии на проекте, эти ребята ещё и тратят силы всей команды. Даже для того, чтобы просто забить болт на самое некомпетентное мнение, нужно проделать несколько операций: это мнение нужно записать, донести до дизайнера, послушать его аргументы против, решить что с ними делать. А если принести громкое мнение авторитетного человека, составленное по всем правилам обратной связи, да ещё и таких мнений несколько — проект можно вообще парализовать: ведь нет никакой связи между тем, что человек говорит громко и авторитетно и тем, что он несёт не полную чушь.
Берегите свой проект от излишней обратной связи — показывайте промежуточные результаты только людям, которым доверяете.
См. также «Одна задача — один ответственный»
Коридорное тестирование — это когда берёшь систему (или её прототип), выходишь в коридор и просишь первого встречного решить с их помощью задачу. Скажем, делаешь новую навигацию для интернет-магазина и просишь пару случайных пользователей найти глубокозапрятаный пылесос определённой марки.
Есть ребята, которые под коридорным тестированием понимают «взять макеты и побегать с ними по коридору». То есть не тестируют прототипы, а просто показывают макеты разным людям и спрашивают «что думаешь?».
Кроме очевидной глупости — увеличения энтропии на проекте, эти ребята ещё и тратят силы всей команды. Даже для того, чтобы просто забить болт на самое некомпетентное мнение, нужно проделать несколько операций: это мнение нужно записать, донести до дизайнера, послушать его аргументы против, решить что с ними делать. А если принести громкое мнение авторитетного человека, составленное по всем правилам обратной связи, да ещё и таких мнений несколько — проект можно вообще парализовать: ведь нет никакой связи между тем, что человек говорит громко и авторитетно и тем, что он несёт не полную чушь.
Берегите свой проект от излишней обратной связи — показывайте промежуточные результаты только людям, которым доверяете.
См. также «Одна задача — один ответственный»