Комментарии 7
Статья как раз в тему после — «Твой код никого не интересует»
НЛО прилетело и опубликовало эту надпись здесь
В защиту автора, скажу, что в оригинале стоит слово «architecture». Я же перевел как «код» имея ввиду более абстрактное понятие, чем конкретные символы, выражения.
P.S: А так да, что-то подобное было и в моей практике. Я определял на каком ЯП этот человек программировал раньше и из какой он страны. Заказчики дивились моей прозорливости =))
P.S: А так да, что-то подобное было и в моей практике. Я определял на каком ЯП этот человек программировал раньше и из какой он страны. Заказчики дивились моей прозорливости =))
Интересно было бы почитать про орг. меры, направленные на соблюдение всех этих «кодинг гайдлайнов», требований к коммитам и т.п в группе разработчиков размером под 10 человек и более. Очень не хватает реального практического опыта, а не теоретизирования на тему.
По моему горькому опыту примерно лишь половина разработчиков из команды понимает зачем всё это нужно, остальные в разной степени считают это необязательными пожеланиями и относятся соответственно. При попытках объяснить натыкаешься на позицию «вот понапридумывали всякого барахла, главное чтобы код работал!». Может и правда всё это лишняя шелуха?
По моему горькому опыту примерно лишь половина разработчиков из команды понимает зачем всё это нужно, остальные в разной степени считают это необязательными пожеланиями и относятся соответственно. При попытках объяснить натыкаешься на позицию «вот понапридумывали всякого барахла, главное чтобы код работал!». Может и правда всё это лишняя шелуха?
Я вот никак не могу согласиться, что сборка и развёртывание находится выше контроля версий. Придание программе работоспособности — это более базовая вещь, чем контроль версий.
У них, вероятно, контроль версий триггерит сборку проекта. Да, понятно, это прикольное и распространённое решение. Но если убрать контроль версий, то развёртывание всё равно можно делать — от F5 в двухпанельнике до rsync. А при сборке запускаются специфические утилиты — компиляторы/трансляторы/линкеры/т.д. Эти утилиты можно и без контроля версий запускать. Контроль версий в этом случае не может лежать ниже сборки. Контроль версий добавляет удобства разработке а не утоляет базовые потребности.
Сама идея применить пирамиду Маслоу — прикольная, но выходные данные какие-то нелогичные. Я бы контроль версий объединил с разделом «поддержание».
У них, вероятно, контроль версий триггерит сборку проекта. Да, понятно, это прикольное и распространённое решение. Но если убрать контроль версий, то развёртывание всё равно можно делать — от F5 в двухпанельнике до rsync. А при сборке запускаются специфические утилиты — компиляторы/трансляторы/линкеры/т.д. Эти утилиты можно и без контроля версий запускать. Контроль версий в этом случае не может лежать ниже сборки. Контроль версий добавляет удобства разработке а не утоляет базовые потребности.
Сама идея применить пирамиду Маслоу — прикольная, но выходные данные какие-то нелогичные. Я бы контроль версий объединил с разделом «поддержание».
Согласен, инфраструктура разработки — широкое понятие, и система контроля версий — только её часть.
И согласен с тем, что контроль версий не является самым важным и критичным. Потому что, если программа не работает, то следующая версия и контроль версий могут вообще не понадобиться, по причине отказа заказчика выбравшего другой продукт вместо вашего.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пирамида Маслоу в аспекте разработки ПО