А часто ли вы работаете на многих проектах одновременно?

Доброе утро, коллеги.

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

Насколько эта ситуация типичная у нас в компаниях, где ведутся мобильные проекты или это мне так повезло?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Працював бекенд розробником в конторі зі спеціалізацією на мобільній розробці і там була ситуація точнісінько як ви описуєте. І це стосувалось усіх розробників, менеджерів і навіть тестерів. Здається це норма для студій. По іншому може бути, якщо компанія розробляє виключно один або декілька додатків, тобто у продуктовіх компаніях.

В цілому ведення декількох проектів сурова дійсність: навіть в google розробники зазвичай працюють на 2-3 проектах. В spotify теж шерять девелоперів між мікрокомандами. Але здається у них більш збаланосваний підхід до зміни контексту ніж в вебстудіях. Є тести та автоматизація, гадаю і планування краще — що нівелює фактор стресу в порівнянні з вашим прикладом.

У меня такое было, правда это был веб, работал на 4 проектах — вначале было тяжело но потом втянулся и понял что я так более продуктивно работаю, и повысил колво продуктивной работы в 8 часах с 3 до 7 часов — можно было и до 8 поднять но митинги сделали свое дело.

Работаю на двух проектах... Тяжело переключаться, держать все в головe, устанавливать приоритеты, распределять приоритеты, координировать работу.... Только одно преимущество — сидеть без дела еще тяжелей :))

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

Такая ситуация типична для веб-студий.
Задачи «на сегодня», «до 16:00», «а вот ещё правки пришли, сделай плиз».
Открываешь утром почту, а там 3-5 тасков все с разных проектов. И это ещё хорошо если 3-5 и они мелкие.

В больших аутсорс-компаниях такого нет, там один проект на месяцы, а то и годы, а одну задачу 2 недели пилить — норма, могут и месяц :)

Со стороны это выглядит
Как бардак

обычное дело. А еще кроме работы свои проекты — опенорсы, стартапы и пр.

пишу для 3х проектов, джава, питон и пхп+жс. Напрягает, если нормально зарубиться в питон то потом что бы переключиться в пхп+жс нада часа два. Точно так и в джаву. В питоне имплементирую решение разных систем линейных уравненений (моделирование событий) и для тестирование сайтов, в пхп+жс — презентация данных и управление скриптами питона, на джава другой проект связанный с NLP. Думаю какой то их них бросить потому что пока они были на уровне «покажи квори резалт, запусти скрипт с такими параметрами или прочитай файл» — то это еще нормально. Когда перешли на уровень — «тут 10 листов описания апи УИМА и три главы в книге посвященных решению систем линейных уравнений методом ХХХ» то вижу что я не способен так долго и так много концентрироваться.

Я постоянно работаю на разных проектах. С недавнего времени еще и с несколькими клиентами. Было время, что даже на разных языках писал (Salesforce занимался и WPF desktop приложением).
Мне так больше нравится. Мне скучно становится, когда я долго одим и тем же занимаюсь. Я только рад, что у меня «зоопарк».

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

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

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

Вторая рекомендация — вести сырое логирование дел. Просто папку, где создавать текстовые файлы типа yy.mm.dd_описание_задачи.txt где в свободной форме быстро написать что было задано, кем, когда и с какой аргументацией. Очень помогает, когда тебе потом кидают предъявы что мол не успел к дедлайну или нихера не делал. Поверь, манагеры имеют свойство забывать формировать таски, особенно «мелкие». Но по сути эти «мелочи» составляют те самые «вторые 90% проекта», без которых он загнётся.

ЗЫ. Нужна оптимизация.

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

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

public String getDocumentType(String document) throws Exception, Kakashki{
return com.supermegacorporation.otdelgovnokoda.ivanoff.DocumentFactory.newInstance().createDocument( document ).getTipKlasifakatora + 07 + _itdoaijmmmr + “spravka”;
}

У нас на проекті заборонено писати коментарі в коді. Так само як і заборонено писати гавнокод — у всіх все ок:-)
Існує лише кілька випадків, коли коментарі доречні. Наприклад, @TODO, попередження про потенційний timeout, пояснення сенсу роботи великої і складної регулярки і т.д.
Але коли ти пишеш код, пояснюючи логіку — це на 99% гарантія того, що код уже попахує.

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

Предлагаю пойти дальше: не вижу говнокода, не слышу говнокода, не говорю о говнокоде. И тем более о говноюзере — он сам говно!

Якщо обирати між аргументами Роберта Мартіна і аргументами Олексія Пєнія, то я схиляюся до першого варіанту.

100% людей считают свой код понятным. В том числе им самим через время. 99.(9)% из них не правы, и делятся на 2 типа:
— те, кто пишет комменты в код, чем делает его понятным, в том числе помогает разобраться в намерениях если там найдут баги. Знаешь, когда код не делает что задумано — очень полезно знать, а что собственно задумано.
— те, кто пишет комменты да DOU (а вдруг кому непонятна истина), но не в код (гениальность автора несомненна).
— те, кто действительно пишет абсолютно понятный код.

// да, только 2 типа.

Хороший совет я прочитал много лет назад в одной старой книге по ФОРТРАНу:

«Создавайте комментариев больше, чем это кажется необходимым»

С тех пор я всегда следую этому совету.

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

Шесть ошибок. В двух строчках. Пиши тесты.

У меня клавиатура не локализовала и я не экзамен по гармотности пистма сдаю. По сути есть что добавить?

У меня клавиатура под отмазки не локализована, только под код и комменты.

Тесты устаревают точно так же.

С той лишь разницей что устаревший тест определить проще — он упал после внесенных изменений. И тогда уже дело за командо решить устарел он или нет. Комментарии же устаревают тихо.

— те, кто пишет комменты в код, чем делает его понятным, в том числе помогает разобраться в намерениях если там найдут баги. Знаешь, когда код не делает что задумано — очень полезно знать, а что собственно задумано.
окей, прокомментируй пожалуйста это dou.ua/...rums/topic/19629/#1053971
— те, кто пишет комменты да DOU (а вдруг кому непонятна истина), но не в код (гениальность автора несомненна).
добавь комментарий, который пойдет в плюс, кодя взял из рандомного репозиторий майкрософта, стрим и миметайп ридонли поля класса, устанавливаются через конструктор, другой логики в классе нет

public HttpContent GetContent()
{
var data = new StreamContent(this._stream);
data.Headers.ContentType = new MediaTypeHeaderValue(this._mimeType);
return data;
}

В данном случае (другой логики в классе нет) полезным будет комментарий перед классом на тему «зачем этот класс вообще существует».

ну вот его название и интерфейс: internal class BinaryRequestContent : IRequestContent
задача все та же добавить комментарий, который пойдет в плюс, а не от самого капитана

это проект докер, чтобы понятнее было что это за класс и зачем

github.com/...t/BinaryRequestContent.cs

Комментарий нужен в IRequestContent.cs, приблизительно такого содержания:

/* DocketClient.MakeAsyncRequest does not care what kind of data it sends
in POST requests but needs proper Content-Type header which RequestContent
should provide, either from context or by examining the data to be sent. */

Чтобы следующий человек посмотрел, сказал wtf? и прибил всю иерархию.
Почему GET запросы получают явный Content-Type, а для POST нужны прокладки-адаптеры? Если там во всех *двух* случаях использования тип заранее статически известен?

var data = new RequestContent("application/x-tar", stream);
var data = new RequestContent("application/json", this.client.serializer.serialize(...));

Почему это вообще класс, а не функция ah, wait a minute, ООП-шники.

Факт явного несоответствия комментария и кода был бы очень полезен. Было бы сразу видно, что планировалось одно, по факту немного другое, и надо бы немного подчистить.

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

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

Ну это как раз имеем. Гораздо интереснее «сделайте как вооон-там», при том что это самое «вооон-там» является частью дорогого программного пакета, а вы требуете in no time и бесплатно.

Я не обещал рассказать. Только сделать хорошо. За деньги. Деньги вперёд.
И вот когда в руках предоплата, телепатия начинает работать.

А говорил, что клавиатура под отмазки не локализована. Не последовательно ;)

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

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

вот скопирую тебе специально из достаточно известной книжки пример, что делает этот код?
// вывод сумм чисел 1..n для всех n от 1 до num
current = 1;
previous = 0;
sum = 1;
for ( int i = 0; i < num; i++ ) {
System.out.println( «Sum = » + sum );
sum = current + previous;
previous = current;
current = sum;
}

Код делает...
// вывод сумм чисел 1..n для всех n от 1 до num

Я угадал? Но прикинь такого кода 3000 строк и без комментов. И не аргументируй книгой — книга сама по себе огромный масив комментов :)

не угадал, но ты сделал бы баг основываясь на том что комментарий не лжет

Я больше скажу, я бы сделал тест основываясь на том, что комментарий не лжёт. И послал бы автора переделывать.
И да, если бы код оказался в моей зоне ответственности, я бы переделал код под документацию, а не документацию под код. Потому что у меня все основания считать, что задумка была такая, как в ТЗ. А коммент — копипаста из него.

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

а если код есть а документации нет или найти в ней что-то уже не получается или это побочный функционал, или все по сторям из беклога?

И да, если бы код оказался в моей зоне ответственности, я бы переделал код под документацию, а не документацию под код. 
и весь код бы в проекте прочел и переделал?) такое заливаешь, это нереально успеть

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

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

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

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

PS. Деминг — автор японского экономического чуда, если вдруг не в курсе.

Пока гром не грянет, читать код не нужно
а как писать новый тогда?) обычно программисты заняты чтением кода 60-80% времени, остальное время пишут новый на основе прочитанного, если исключить активности не связанные с программированием

Это неправильные пчёлы, они делают неправильный код. Такой, на чтение которого надо похоронить 60-80% времени, плюс ещё на отдых от этого маразма.

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

Особенно когда прервали на минутку, а оказалось на пару месяцев.

Підписатись на коментарі