Если не сложно, киньте ссылкой на любые материалы где описывается разработка и внедрение сабжа.
Насколько я понимаю, это включает в себя стандарты кодинга (форматирование, стили, etc.), общие приемы проектирования, органичные ограничения для повышения эффективности процесса разработки, командный review кода и т.п.
Понимаю что тема весьма глобальна, но надо хотя бы с чего-то начать.
Здравствуйте, Yuri_Ch, Вы писали:
Y_C>Если не сложно, киньте ссылкой на любые материалы где описывается разработка и внедрение сабжа. Y_C>Насколько я понимаю, это включает в себя стандарты кодинга (форматирование, стили, etc.), общие приемы проектирования, органичные ограничения для повышения эффективности процесса разработки, командный review кода и т.п. Y_C>Понимаю что тема весьма глобальна, но надо хотя бы с чего-то начать.
Здравствуйте, Yuri_Ch, Вы писали:
Y_C>Если не сложно, киньте ссылкой на любые материалы где описывается разработка и внедрение сабжа. Y_C>Насколько я понимаю, это включает в себя стандарты кодинга (форматирование, стили, etc.), общие приемы проектирования, органичные ограничения для повышения эффективности процесса разработки, командный review кода и т.п. Y_C>Понимаю что тема весьма глобальна, но надо хотя бы с чего-то начать.
Здравствуйте, Yuri_Ch, Вы писали:
Y_C>Здравствуйте, Kisloid, Вы писали:
K>>Мы пользуемся этим.
Y_C>+1 В общем-то, мы с этой книги и начали Интересуют также публикации на тему.
Что касается стандартов кодирования, то материалов дофига.
Проблема не в них. Проблема в том, как в конкретной группе найти то,
что будет работать именно в этой группе.
С одной стороны тупо спустить сверху "идеальный" стандарт не получится.
А с другой стороны всех "счастливых" сделать тоже нереально.
Кому-то придется наступать себе на горло
Возьми любую дискуссию по поводу goto или пробелы vs. табуляторы
и ты получишь примерное представление о чем я говорю...
Собственно это верно и для всех остальных документов, которые определяют процессы.
Здравствуйте, bkat, Вы писали:
B>Что касается стандартов кодирования, то материалов дофига.
сдается мне, что это не самое главное.
B>Собственно это верно и для всех остальных документов, которые определяют процессы.
imho главное таки определить процессы. остальное подтянется чисто эволюционно.
я чаще встречал отсутствие (и большие проблемы) тестирования, чем проблемы с код-стандартом.
...тут недавно "эмоционально" беседовали по поводу коде-ревью. фишка не в том, что бы был заполнен документ про то, что он был проведен. фишка в том, что бы автор кода был уверен(!), что код проверят. imho
Здравствуйте, bastrakov, Вы писали:
B>Здравствуйте, bkat, Вы писали:
B>>Что касается стандартов кодирования, то материалов дофига.
B>сдается мне, что это не самое главное.
Так и есть. Это всего лишь один из многих документов,
которые потребуются. Стандарт кодирования сам по себе бесполезен,
если нет процедур для code review.
Стандарт кодирования — это то, что имеет довольно низкий приоритет.
B>>Собственно это верно и для всех остальных документов, которые определяют процессы.
B>imho главное таки определить процессы. остальное подтянется чисто эволюционно. B>я чаще встречал отсутствие (и большие проблемы) тестирования, чем проблемы с код-стандартом.
Именно так. Проблема в том, как их (процессы) определить
Штудирование чужих доков — вещь в общем познавательная,
но процессы от этого понятнее не становятся.
В общем сложная и неподъемная это тема для обсуждений в форуме...
Здравствуйте, bkat, Вы писали:
B>Что касается стандартов кодирования, то материалов дофига. B>Проблема не в них. Проблема в том, как в конкретной группе найти то, B>что будет работать именно в этой группе. B>С одной стороны тупо спустить сверху "идеальный" стандарт не получится. B>А с другой стороны всех "счастливых" сделать тоже нереально. B>Кому-то придется наступать себе на горло B>Возьми любую дискуссию по поводу goto или пробелы vs. табуляторы B>и ты получишь примерное представление о чем я говорю...
B>Собственно это верно и для всех остальных документов, которые определяют процессы.
Во-во, поэтому и представляют интересс success-story в подобных начинаниях.
Стандарт не спускается сверху, да и я честно говоря тоже далеко не сверху — предположительно он будет обкатан в небольшой группе, где по возможности будут установлены необходимые и отсеяны лишние формальности. А остальные — хочется думать, что втянутся, когда будет достигнут положительный результат.
Здравствуйте, bkat, Вы писали:
B>Так и есть. Это всего лишь один из многих документов, B>которые потребуются. Стандарт кодирования сам по себе бесполезен, B>если нет процедур для code review. B>Стандарт кодирования — это то, что имеет довольно низкий приоритет.
В первом посте я именно об этом и говорит. Вариантов стандартов полно на любой вкус, у меня уже драфт набросан, причем он будет обсуждаться и дополняться каждым участником эксперимента — это чтобы по минимуму "наступать на горло". А вот как внедрять пока не совсем понятно. Понятно, что по частям — тогда с чего начать.
Y_C>Стандарт не спускается сверху, да и я честно говоря тоже далеко не сверху — предположительно он будет обкатан в небольшой группе, где по возможности будут установлены необходимые и отсеяны лишние формальности. А остальные — хочется думать, что втянутся, когда будет достигнут положительный результат.
Не слишком ли много формализма для обычных договорённостей?
Обычно проблемы возникают по другим причинам.
Об этом выше писали bkat и bastrakov.
Обычно под процессами понимается:
планирование, управление требованиями, управление версиями, управление конфигурациями, тестирование и контроль качества, и ещё ворох задач.
Требование соответствия стандартам кодирования на этом фоне выглядит, как одно из сотни обыкновенных правил.
Здравствуйте, Yuri_Ch, Вы писали:
Y_C>Если не сложно, киньте ссылкой на любые материалы где описывается разработка и внедрение сабжа.
... Y_C>Понимаю что тема весьма глобальна, но надо хотя бы с чего-то начать.
я в первый раз не стал писать, думал, что вы уже читаете указанные документы-ресурсы.
(на самом деле в интернете об этом написаны горы. ...правда из этих гор надо нарыть зерно золота. )
прочитав последние посты, я понял, что вы где-то не в той стороне, про которую вам "показывают пальцем".
попробую. будет непонятно — спрашивайте. буду врать — побьют-поправят.
1) выберит любую методологию. цикл или водопад. можно просто для начала нарисовать на бумаге линию (водопад). можно замкнутую линию (цикл). это время.
2) расставте точки на линии. тут начало кодирования, тут сдача проекта. тут окончание сбора требований. тут начало тестирования. специально пишу вразброс! сами расставляйте, что у вас и где. если тестирование начнется до окончания сбора требований, то я не виноват. логика должна присутствовать.
3) к каждой точке привяжите документы и процессы. здесь мы должны увидеть требования. здесь мы должны подтвержить, что тех-документ готов полностью. здесь тестировщики должны сказать, что и как они будут тестировать...
4) повесте лист на стену, и ставте точки ежедневно, где вы сейчас, и что у вас должно быть.
5) почитайте все же теорию.
необходимые документы, в том числе и стандарт кодирования, подтянутся к нормально поставленому процессу сами. например, неупомянутые вами, тесткейсы, волшебным образом вдруг станут необходимы. потому что сборка, в нормальном процессе, это не аврал всей команды, а ежедневный автоматицеский эвент.
нафига это все надо? доло в том, что если на листе написано одно, а в жизни у вас другое — надо что-то делать. любая методология не делает проекты успешными. это просто сигнализация. если она молчит, значит у вас все хорошо.
p.s. насчет стандарта кодирования... видел несколько раз. пережил несколько попыток введения такого документа. проблема в том, что человек, который пишет такой документ, всех хочет заставить писать код понятный для себя лично. я просто счастлив, что нет стандарта диаграммы классов, или структуры дб.
хотя периодически встречаю людей, которые убеждают всех, что именно они знают, как точно должно выглядеть то и другое. но если бы мы все создавали базы и классы, как мы их понимаем _в_начале_работы_ , то мы все перевешались бы через 1-2 года работы на этом же проекте. гибче надо быть. и в вопросе введения формальных процессов в том числе.
Здравствуйте, bastrakov, Вы писали:
B>необходимые документы, в том числе и стандарт кодирования, подтянутся к нормально поставленому процессу сами. например, неупомянутые вами, тесткейсы, волшебным образом вдруг станут необходимы. потому что сборка, в нормальном процессе, это не аврал всей команды, а ежедневный автоматицеский эвент.
сорри профессионалам.
здесь я имел ввиду юнит-тесты. которые делаются автоматически при автосборке.
и без успешного прохождения которых сборка считается невалидной.
Здравствуйте, bastrakov, Вы писали:
B>сорри профессионалам. B>здесь я имел ввиду юнит-тесты. которые делаются автоматически при автосборке. B>и без успешного прохождения которых сборка считается невалидной.
Я их не упомянул, потому что они уже есть Есть система сборки, есть юнит-тесты, есть поставленный процесс тестирования, есть более-менее удобоваримая постановка ТЗ.
В любом случае спасибо, есть над чем подумать.
для повышения эффективности процесса разработки, командный review кода и т.п.
