Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять? (понятно, что можно разбивать работу на микрошаги и просто увеличить колличество коммитов, но они-то так не делают?)
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять?
Перестать менять свою производительность количеством коммитов
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять? (понятно, что можно разбивать работу на микрошаги и просто увеличить колличество коммитов, но они-то так не делают?)
Комить не раз в день, а каждое исправление, каждую фичу, каждое обособленное изменение исходников.
Их 4К комитов — это не безудержная работа, а просто высокая гранулярность комитов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, alpha21264, Вы писали:
A>>Ты из советского поколения или из постсоветского? В зависимости от этого я буду по-разному объяснять.
bnk>Ну пионером я полгода побыть успел. Жалко вот что галстук не сохранился. Так что не совсем уверен — советское или уже пост-советское
Это пост-советское. Ничего плохого в этом нет, просто эффективность ты будешь понимать так, как это американцы понимают.
Советские понимали по-другому.
A>>1) Сколько ошибок остаётся на плате после работы программы. (Время было гораздо менее важным критерием) A>>2) Сколько пожеланий пользователя (Тикетов) осталось незакрытыми. A>>А уж как это выражается в коде, да чёрт его знает.
A>>Идеальная программа должна быть написана в течении вечера, быть абсолютно надёжной и работать вечно.
bnk>Это да. Но показатели производительности/объема, которые я имел в виду, в основном же для чего нужны — для прогнозирования, не? bnk>То есть, чтобы оценить, сколько займет / во что обойдется та или иная работа / проект, в данных условиях, с данными людьми. bnk>Это как фундаментальные законы — не отвечают на вопрос "зачем", зато отвечают на вопрос "как".
Ну да. Только в программировании все эти метрики врут. Не попадают даже в порядок.
Об этом написано во всех книжках по менеджменту, начиная с самой первой "Мифический человеко-месяц".
В реальной жизни все оценки просто берутся по худшему и умножаются в десять раз.
Вообще, если в программу нужно вносить тысячи изменений, значит с программой что-то не так.
bnk>Например, как оценить, сколько времени займет разработка CMS, зная что в команде 5 индусов из Мумбая? bnk>Можно по аналогии с предыдущими проектами. Как сравнить проекты? По объему коду-числу коммитов. Также производительность людей. bnk>Я в этом ключе о полезности показателей говорил.
Всего пять индусов, или в команде ещё кто-то есть?
В очередной книжке "Peopleware" написано, что если их из проекта исключить, то проект пойдёт быстрее.
Дело в том, что все эти "распределённые команды" нужны не для повышения эффективности.
Как раз эффективность труда современный капитализм спустил в унитаз. Это делается для "управляемости".
Управляемость — это чтобы индусы не вздумали сами продавать свой продукт.
Именно для этого делаются команды, которые размазаны по всему миру,
в которых разработчики принадлежат разным культурам и говорят на разных языках.
Расплачиваются эффективностью. Я это уже говорил.
Вообще, рекомендую познакомиться с ТРИЗ (Теория Решения Изобретательских Задач).
Сначала это научит тебя правильно ставить вопросы. А потом... ууу!!! Потом будет ментальный взрыв.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять? (понятно, что можно разбивать работу на микрошаги и просто увеличить колличество коммитов, но они-то так не делают?)
4000 коммитов в год — это в среднем 15 коммитов в день. Т.е., это либо отдельный коммит на каждые измененные несколько строчек, либо чувак принимает патчи от команды из десятка программистов, просматривает их, и коммитит под своим аккаунтом.
Здравствуйте, IQuerist, Вы писали:
IQ>Подскажите плиз годный материал по теме. Какой должна быть стратегия, чтобы частые комиты не мешали, а помогали?
Да стратегия очень простая. Комитить надо некое минимальное, но осмысленное изменение. Например, исправил ты баг — комить. Реализовал мелкую фичу — комить. И надо стараться не смешивать коммиты от разных фич. Например, если ты решил переформатировать код, то лучше делать это не в процессе реализации фичи или исправления бага, а отдельным комитом. Решил сделать рефакторинг — опять таки комить его отдельно от изменений меняющих функциональность.
Ну, и комитить стоит сначала локально, а потом уже стопку комитов слать на сервер.
Если выполняется большая работа, стоит завести для нее ветку.
Кроме того мы стараемся использовать ребэйз, тчобы не было много параллельных веток. Это не всегда прокатывает, но если прокатывает — это лучший выбор. Потом проще разбираться с историей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Просьба цитировать только то, что надо для понимания ответа (обычно это одна фраза). Наличие строчки "VD>Здравствуйте, IQuerist, Вы писали:" уже говорит о наплевательском отношении к цитированию.
IQ>Соотнося это с реальной жизнью — академический рефакторинг это запланированные изменения кода, которые вряд ли когда то будут произведены
Ну, вот представляешь? Некоторые таки делают рефакторинги отдельно от прочих изменений. А рефакторинг в процессе правки — это грубейшее нарушение техпроцесса кодирования. В этом случае никак невозможно проверить качественность рефакторинга, так как поведение программы меняется.
Если ты уже начал менять код и вдруг понял, что для дальнейшей работы нужен рефакторинг, то можно закомитить текущее положение дел с комментом "Some feature. WIP", сделать рефакторинг и продолжить работу над фичей. Как вариант — сделать сташ, произвести рефакторинг и, затем, сделать ансташ. Ну, или доделать фичу и потом уже сделать рефакторинг.
IQ>Имхо в академическом определении есть подмена (возможно издержки перевода) — когда вы пилите код вы можете увидеть очевидную необходимость рефакторинга и его цель, т.к. вы "в контексте". Когда вы код не пилите, контекста нет... остаются лишь "благие намерения".
Ни кто не обещал, что будет просто. Потому то кухарки и не занимаются программирование. И как я уже сказал, всегда есть исключения, когда проще нарушить правило, чем возиться с мерджами измененного кода. Но эталоном является то что я описал. И в принципе у высококлассных программистов это получается.
Вот, например, коммиты в нашем проекте — Nitra: https://github.com/rsdn/nitra/commits/master
Большинство коммитов атомарные. Только на второй странице можно встретить объединенный коммит.
IQ>Теоретическую мотивацию разделения рефакторинга и прочих изменений я конечно понимаю, но в реальности это имхо очень похоже на эскапизм, впрочем имхо в современной разработке очень много эскапизма...
В реальности нужно учиться работать мелкими изменениями и стараться это делать. Со временем все начнет получаться. Иногда это кажется перебором, так как несколько усложняет жизнь. Но потом, когда приходится искать проблемы в прошлых коммитах, это очень упрощает жизнь.
Ну, и надо понимать, что это только не большая часть общего набора мер по поддержанию в хорошем качестве кода большого проекта. Чтобы код не превратился в говно нужно делать много чего. Структурировать. Повышать уровень кода. Организовывать работу людей так, чтобы они не сталкивались в одном месте кода (чтобы не было кучи разруливаний при мерджах). Организовывать тестирование. И т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IQuerist, Вы писали:
IQ>Со многим согласен, но насчет "никак невозможно проверить качественность рефакторинга, так как поведение программы меняется" имхо это больше иллюзия чем работающая практика...
100% работающая практика. Просто надо сразу помнить об этом и видя, что нужен рефакторинг не начинать его делать в незакомиченном коде. Лучше разорвать коммит по фиче на два и вставить между ними коммит с рефакторингом.
IQ> Да ладно, программируют уже даже индусы...
1. Среди индусов есть неплохие программисты.
2. Индокод он и есть индокод. И не важно написал его индус или русский с руками из жопы.
Даже в коде хороших программистов другому разобраться не просто (нет тучи деталей, которые надо знать). А уж в индокоде разобраться вообще не реально. Такой код проще переписать.
IQ>Имхо специалисты не нарушают правил, т.к. они понимают, когда правила работают, а когда не работают.
Тут не причем "работают/не работают". Тут вопрос в том, что люди не святые и нельзя все просчитать на 100%. Плюс иногда правильный путь создает слишком много проблем и проще забить на правильность, чем тратить море сил на не очень важные вещи.
IQ>Если не сложно, могли бы вы привести самый очевидный кейс, типичной проблемы решение которой сильно бы облегчилось наличием именно мелких комитов, а не просто наличием истории изменений. Не такая — найти виноватого и выдать ему люлей, а что ни будь связанное с бизнесом или процессом.
1. Это облегчает изучение кода другими членами команды.
2. Поиск изменений сделанных в прошлом. Например, с целью выявления ошибок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я часто вожусь с одной проблемой несколько дней. Ранее я тупо не комитил эту работу. Потом, пообщавшись с другими программистами, и просто осознав необходимость отдельного документирования отдельных действий начал коммитить более гранулярно. Но все же я просто иногда забываю закомитить какие-то изменения или начинаю делать 2-3 дела одновременно. Понимаю, что это плохо, но безалаберность, присущая исследовательским натурам вроде меня, не дает делать как следует.
Я иногда в таких случаях накопившееся за несколько дней провожу несколькими, логически независимыми коммитами. Т.е., со стороны это выглядит так: сначало несколько дней ничего, а потом несколько коммитов подряд, с интервалами в 10-15 минут.
VD> Их 4К комитов — это ... просто высокая гранулярность комитов.
Откуда такая уверенность?
Посмотрел твой профиль на Github — сначала у тебя было 100 коммитов в год, потом этот показатель вырос под полторы тысячи, что вполне наглядно отражает рост опыта.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Посмотрел твой профиль на Github — сначала у тебя было 100 коммитов в год, потом этот показатель вырос под полторы тысячи, что вполне наглядно отражает рост опыта.
Уважаемый у меня этого опыта уже 20 лет. И за год он уже давно не растет в разы (если вообще растет). А количество коммитов определяется исключительно тем как я комитил и над чем работал.
Я часто вожусь с одной проблемой несколько дней. Ранее я тупо не комитил эту работу. Потом, пообщавшись с другими программистами, и просто осознав необходимость отдельного документирования отдельных действий начал коммитить более гранулярно. Но все же я просто иногда забываю закомитить какие-то изменения или начинаю делать 2-3 дела одновременно. Понимаю, что это плохо, но безалаберность, присущая исследовательским натурам вроде меня, не дает делать как следует.
Ну, и у меня много задач/работ. Не все они связаны с программированием. И не все они комитятся.
Еще надо учитывать тот фактор, что какое-то время я работал в команде или просто помогал кому-то. Все это время, естественно, комитов от меня было меньше. Зато увеличивалось число комитов у других участников проектов.
В общем, поверь на слово. Ничего лично во мне не поменялось.
ЗЫ
Кстати, как посмотреть на этот показатель?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alpha21264, Вы писали:
ЭФ>>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять?
A>Перестать менять свою производительность количеством коммитов
А какие есть еще показатели производительности?
Я вот тоже раньше думал, что количество коммитов, или там число строк кода — лажа.
Однако когда глядя на историю, я все же изменил свое мнение. IMHO, достаточно вменяемые показатели.
То есть, оценивать объем работ и производительность по ним можно, но к сожалению с задержкой в месяцы-годы.
Здравствуйте, bnk, Вы писали:
bnk>alpha21264, Вы писали:
A>>Перестать менять свою производительность количеством коммитов
bnk>А какие есть еще показатели производительности?
bnk>Я вот тоже раньше думал, что количество коммитов, или там число строк кода — лажа. bnk>Однако когда глядя на историю, я все же изменил свое мнение. IMHO, достаточно вменяемые показатели. bnk>То есть, оценивать объем работ и производительность по ним можно, но к сожалению с задержкой в месяцы-годы.
Ты из советского поколения или из постсоветского? В зависимости от этого я буду по-разному объяснять.
Во-первых, показатели — то когда ты естественным интеллектом не можешь оценить некую ситуацию.
В идеальном случае лучше всё-таки развивать интеллект, а не придумывать показатели.
Показатели врут. А ещё больше врут люди, которые подкручивают показатели.
Во-вторых, если уж очень хочется придумывать показатели, то они должны показывать не объёмы кода, а его полезность.
Вот например я работал в одной западной конторе, которая... ну в общем, работает на Интел.
Наша программа разводила печатные платы (в основном интеловские материнки).
Так у нас было два показателя:
1) Сколько ошибок остаётся на плате после работы программы. (Время было гораздо менее важным критерием)
2) Сколько пожеланий пользователя (Тикетов) осталось незакрытыми.
А уж как это выражается в коде, да чёрт его знает.
Идеальная программа должна быть написана в течении вечера, быть абсолютно надёжной и работать вечно.
Здравствуйте, alpha21264, Вы писали:
A>Ты из советского поколения или из постсоветского? В зависимости от этого я буду по-разному объяснять.
Ну пионером я полгода побыть успел. Жалко вот что галстук не сохранился. Так что не совсем уверен — советское или уже пост-советское
A>Во-первых, показатели — то когда ты естественным интеллектом не можешь оценить некую ситуацию. A>В идеальном случае лучше всё-таки развивать интеллект, а не придумывать показатели. A>Показатели врут. А ещё больше врут люди, которые подкручивают показатели.
A>Во-вторых, если уж очень хочется придумывать показатели, то они должны показывать не объёмы кода, а его полезность. A>Вот например я работал в одной западной конторе, которая... ну в общем, работает на Интел. A>Наша программа разводила печатные платы (в основном интеловские материнки). A>Так у нас было два показателя: A>1) Сколько ошибок остаётся на плате после работы программы. (Время было гораздо менее важным критерием) A>2) Сколько пожеланий пользователя (Тикетов) осталось незакрытыми. A>А уж как это выражается в коде, да чёрт его знает.
A>Идеальная программа должна быть написана в течении вечера, быть абсолютно надёжной и работать вечно.
Это да. Но показатели производительности/объема, которые я имел в виду, в основном же для чего нужны — для прогнозирования, не?
То есть, чтобы оценить, сколько займет / во что обойдется та или иная работа / проект, в данных условиях, с данными людьми.
Это как фундаментальные законы — не отвечают на вопрос "зачем", зато отвечают на вопрос "как".
Например, как оценить, сколько времени займет разработка CMS, зная что в команде 5 индусов из Мумбая?
Можно по аналогии с предыдущими проектами. Как сравнить проекты? По объему коду-числу коммитов. Также производительность людей.
Я в этом ключе о полезности показателей говорил.
Здравствуйте, bnk, Вы писали:
bnk>Это да. Но показатели производительности/объема, которые я имел в виду, в основном же для чего нужны — для прогнозирования, не? bnk>То есть, чтобы оценить, сколько займет / во что обойдется та или иная работа / проект, в данных условиях, с данными людьми. bnk>Это как фундаментальные законы — не отвечают на вопрос "зачем", зато отвечают на вопрос "как".
Можно у людей спросить, сколько времени у них займет проект. Это работает. Только обычно надо их оценку умножать на некоторый коэффициент, и для конкретного человека или группы людей надо нащупать этот коэффициент эмперически.
Здравствуйте, bnk, Вы писали:
bnk> ЭФ>>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять? bnk> A>Перестать менять свою производительность количеством коммитов bnk> А какие есть еще показатели производительности?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять? (понятно, что можно разбивать работу на микрошаги и просто увеличить колличество коммитов, но они-то так не делают?)
Думаю, тебе надо начать коммитить каждую строчку, сразу всех обгонишь по эффективности.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, VladD2, Вы писали:
VD>Уважаемый у меня этого опыта уже 20 лет. И за год он уже давно не растет в разы (если вообще растет). А количество коммитов определяется исключительно тем как я комитил и над чем работал.
VD>Я часто вожусь с одной проблемой несколько дней. Ранее я тупо не комитил эту работу. Потом, пообщавшись с другими программистами, и просто осознав необходимость отдельного документирования отдельных действий начал коммитить более гранулярно.
Подскажите плиз годный материал по теме. Какой должна быть стратегия, чтобы частые комиты не мешали, а помогали?
ЭФ>а у парней с микрософта
Им сторонние разработчики часто присылают патчи, которые они коммитят под своими аккаунтами.
Кроме того, у парней из корпораций могут быть всякие нелепые KPI вида "Количество изменений в системе за год"
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, IQuerist, Вы писали:
IQ>>Подскажите плиз годный материал по теме. Какой должна быть стратегия, чтобы частые комиты не мешали, а помогали?
VD>Да стратегия очень простая. Комитить надо некое минимальное, но осмысленное изменение. Например, исправил ты баг — комить. Реализовал мелкую фичу — комить. И надо стараться не смешивать коммиты от разных фич. Например, если ты решил переформатировать код, то лучше делать это не в процессе реализации фичи или исправления бага, а отдельным комитом. Решил сделать рефакторинг — опять таки комить его отдельно от изменений меняющих функциональность.
Это понятно, в части (кстати эта часть больше половины или меньше) случаев все довольно очевидно... Но, например, при хорошей такой загрузке рефакторинг имхо часто происходит в рамках реализации фичи или исправления бага иначе его просто годами откладывают на потом. Баги нередко тоже исправляются "гроздьями". Напрашивается забавное название для стратегии — атомизация изменений.
Здравствуйте, IQuerist, Вы писали:
IQ>Это понятно, в части (кстати эта часть больше половины или меньше) случаев все довольно очевидно... Но, например, при хорошей такой загрузке рефакторинг имхо часто происходит в рамках реализации фичи
По определению рефакторинг: "процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы". То есть совмещение рефакторинга или форматирования кода с другими изменениями противоречит этому изменения. Так что рефакторино можно и нужно делать отдельно от других изменений.
IQ>или исправления бага иначе его просто годами откладывают на потом. Баги нередко тоже исправляются "гроздьями". Напрашивается забавное название для стратегии — атомизация изменений.
Понятно, что бардачно жить проще. У меня смого не всегда получается придерживать правильной стратегии. Но надо стараться. Иногда можно сделать кумулятивный коммит. Но надо понимать, что это плохо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, IQuerist, Вы писали:
IQ>>Это понятно, в части (кстати эта часть больше половины или меньше) случаев все довольно очевидно... Но, например, при хорошей такой загрузке рефакторинг имхо часто происходит в рамках реализации фичи
VD>По определению рефакторинг: "процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы".
Соотнося это с реальной жизнью — академический рефакторинг это запланированные изменения кода, которые вряд ли когда то будут произведены
VD>То есть совмещение рефакторинга или форматирования кода с другими изменениями противоречит этому изменения. Так что рефакторино можно и нужно делать отдельно от других изменений.
Имхо в академическом определении есть подмена (возможно издержки перевода) — когда вы пилите код вы можете увидеть очевидную необходимость рефакторинга и его цель, т.к. вы "в контексте". Когда вы код не пилите, контекста нет... остаются лишь "благие намерения".
Теоретическую мотивацию разделения рефакторинга и прочих изменений я конечно понимаю, но в реальности это имхо очень похоже на эскапизм, впрочем имхо в современной разработке очень много эскапизма...
Re[10]: Как повысить свою продуктивность в 10 раз?
Здравствуйте, VladD2, Вы писали:
VD>Ну, вот представляешь? Некоторые таки делают рефакторинги отдельно от прочих изменений. А рефакторинг в процессе правки — это грубейшее нарушение техпроцесса кодирования. В этом случае никак невозможно проверить качественность рефакторинга, так как поведение программы меняется.
Со многим согласен, но насчет "никак невозможно проверить качественность рефакторинга, так как поведение программы меняется" имхо это больше иллюзия чем работающая практика...
VD>Если ты уже начал менять код и вдруг понял, что для дальнейшей работы нужен рефакторинг, то можно закомитить текущее положение дел с комментом "Some feature. WIP", сделать рефакторинг и продолжить работу над фичей. Как вариант — сделать сташ, произвести рефакторинг и, затем, сделать ансташ. Ну, или доделать фичу и потом уже сделать рефакторинг.
Вот это интересно, надо будет обдумать.
VD>Ни кто не обещал, что будет просто. Потому то кухарки и не занимаются программирование.
Да ладно, программируют уже даже индусы...
VD>И как я уже сказал, всегда есть исключения, когда проще нарушить правило, чем возиться с мерджами измененного кода. Но эталоном является то что я описал. И в принципе у высококлассных программистов это получается.
Имхо специалисты не нарушают правил, т.к. они понимают, когда правила работают, а когда не работают.
VD>В реальности нужно учиться работать мелкими изменениями и стараться это делать. Со временем все начнет получаться. Иногда это кажется перебором, так как несколько усложняет жизнь. Но потом, когда приходится искать проблемы в прошлых коммитах, это очень упрощает жизнь.
Если не сложно, могли бы вы привести самый очевидный кейс, типичной проблемы решение которой сильно бы облегчилось наличием именно мелких комитов, а не просто наличием истории изменений. Не такая — найти виноватого и выдать ему люлей, а что ни будь связанное с бизнесом или процессом.
VD>Ну, и надо понимать, что это только не большая часть общего набора мер по поддержанию в хорошем качестве кода большого проекта. Чтобы код не превратился в говно нужно делать много чего. Структурировать. Повышать уровень кода. Организовывать работу людей так, чтобы они не сталкивались в одном месте кода (чтобы не было кучи разруливаний при мерджах). Организовывать тестирование. И т.п.
