Рубрика «управление разработкой»

Рассказывает Светлана Каюшина, руководитель отдела документирования и локализации.

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

Читать полностью »

В сфере разработки программного обеспечения, нередко встречаются тезисы наподобие «Nobody cares about your code» (перевод — «Твой код никого не интересует»), «Код всего лишь инструмент» и ситуации полного непонимания со стороны бизнеса, почему это мы должны выделять время и деньги на какой-то там «рефакторинг» кода который уже работает.

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

image

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

What do you get when you cross an IT department, a faulty Sprint review, determination, and pizza? Greatness, that's what.

Sprint Review: Shitty to Great - 1
Читать полностью »

От переводчика: этот текст — перевод записи в личном блоге Михаэля Стапельберга (Michael Stapelberg) видного open source-разработчика (профиль GitHub), который внес значительный вклад в развитие Debian.


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

Debian был частью моей жизни на протяжении 10 лет.

Несколько недель назад, на посвященной Debian встрече, проходившей в Цюрихе, я встретился с несколькими своими старыми друзьями, которых не видел много лет. Когда я уже ехал домой на велосипеде, меня осенило, что все обсуждаемые нами темы так или иначе сводились к тому, что мы обсуждали с ними в прошлый раз. Мы дискутировали о достоинствах systemd, который вновь привлек внимание участников open source сообщества, затронули тему процессов в Debian. Кульминацией стало обсуждение демократии как таковой и соответствующие теоретические и практические ошибки. Но, на самом деле, это уже чисто швейцарская тема.

Это не обзор прошедшего митапа, я просто хочу объяснить, что побудило меня задуматься о своем текущем отношении к Debian, и подходит ли он мне.

Итак, я принял решение, которое должен был принять давно: я сворачиваю свое участие в развитии Debian.
Читать полностью »

Тестирование синтетических данных

Начнём со сладкого и приведём примеры из практики тестирования.

Представьте себе готовый к запуску интернет-магазин. Ничего не предвещает беды. Маркетологи разработали стратегию продвижения, были написаны статьи в профильные интернет-ресурсы, оплачена реклама. Руководство ожидало до 300 покупок еженедельно. Проходит первая неделя, менеджеры фиксируют 53 оплаты. Руководство магазина в ярости...Читать полностью »

image

Как обычно происходит код-ревью? Вы отправляете пул-реквест, получаете обратную связь, вносите исправления, отправляете фиксы на повторный ревью, затем получаете одобрение, и происходит мерж. Звучит просто, но на деле процесс ревью бывает очень трудоемким.

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

Получается, что чем объемнее пул-реквест, тем меньше пользы будет от его проверки.
Читать полностью »

Всем привет!

Меня зовут Алик Курдюков, я CTO компании United Traders. Немного обо мне можно узнать у меня в профиле. В последнее время мы увеличиваем темпы набора IT людей в компанию и сталкиваемся с проблемой: нас многие знают как «Fin» компанию, но очень мало кто знает как «Tech». Поэтому теперь у нас есть блог на Хабре.

В этом посте я хочу рассказать о том, как мы устроены со стороны разработки. И с удовольствием буду отвечать на вопросы в комментариях.

Читать полностью »

Привет! Мы продолжаем Backend United, серию митапов для разработчиков серверной части. Третья встреча называется «Холодец», и посвящена она будет микросервисной архитектуре. Вместе с коллегами из Booking.com, Dodo Pizza и Авито поговорим о монолитах, распилах и обратной стороне сервис-ориентированной архитектуры.

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

Backend United 3: Холодец - 1

Читать полностью »

Хочу поговорить о таком важном качестве, как ответственность за ошибки, как свои так и команды.

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

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

Почему нужно рассказывать о таких случаях, если вы разработчик?

Казалось бы, ошибка, на проде, нужно исправить и в следующем релизе спокойно это вылить, зачем беспокоить руководителя?

А вы приносите плохие новости руководству? - 1

Читать полностью »