Здравствуйте, blackhearted, Вы писали:
I>>А еще мануал вытесняет живое общение. B>а как же распределённые команды? B>ждать в Саратове, пока проснётся НЙ?
Есть варианты :
1 сделать билд в один шаг, т.е. удалённый разраб скачивает код, запускает сборку хоткеем в IDE и работает
2 обложить костылями (говнанты,гономавены) и тд. Вот типичный расклад в этом случае http://rsdn.ru/forum/humour/2651979.1.aspx
Здравствуйте, Ikemefula, Вы писали:
I>Есть варианты : I>1 сделать билд в один шаг, т.е. удалённый разраб скачивает код, запускает сборку хоткеем в IDE и работает I>2 обложить костылями (говнанты,гономавены) и тд. Вот типичный расклад в этом случае http://rsdn.ru/forum/humour/2651979.1.aspx
Непонятно, почему ты эту ситуацию пытаешься связать с "костылями" в виде Ant, Maven. По-моему, ничего общего в проблематике.
Сама по себе ситуация подобного рода типична, вопрос в том, как её лечить. С нашим текущим подходом в этом случае было бы следующее: по результатам такого взлёта девелопер должен был бы 1) оформить подробный лог такого взлёта, 2) создать тикет с ним, 3) ссылку на тикет запихнуть во внутреннее Wiki в соответствующую секцию (если нет, создать). Вероятнее всего, в этом случае старший девелопер сказал бы "раз так, опиши это не в виде лога, а в виде HOWTO, в вики в настройке рабочей среды" и по крайней мере проблема была бы документирована и известен шаг решения; а ещё вероятно исправление — не сразу, но постепенно, по мере нахождения сил на это.
I>3 написать мануал, после пары месяцев все сведётся к п.2 с той разницей, что мануал будет устаревшим и времени будет уходить больше чем в п.2
Непонятно, что ты имеешь в виду под мануалом, но всё-таки рабочая обстановка должна создаваться полностью автоматизированно, а все другие варианты — только промежуточные перед этим.
Здравствуйте, neFormal, Вы писали:
F>Или так: код, который не совершает следующих грехов:
F>Гордыня — код понятен даже джуниору (если он понял задачу) F>Зависть — код не дублирует уже существующий код F>Чревоугодие — код не пожирает все возможные ресурсы себе в угоду F>Блуд — код не содержит бессмысленных конструкций просто ради кода F>Гнев — в коде заложено удобство использования, а не ненависть к тем, кто будет поддерживать F>Алчность — код не тащит весь доступный функционал в каждый(или единственный) модуль F>Уныние — код написан не на выброс
Чет я не понял формулы. Слева грехи а справа их описание или же справа описано как не совершать эти грехи ?
Здравствуйте, fin_81, Вы писали:
I>>Бред, с таким подходом эти самые стандарты и принципы никогда не появятся.
_>Общепринятых принципов нет, потому что они решают проблему только в пределах одного проекта. В другом проекте эти "принципы" не помогут, чаще портят. Одним нужна скорость в килостроках в минуту, другим — математическая доказанность. У одних код — это заодно и документация, у других код — это интерпретация формул в строгого доказательства какой-то теоремы. Для большинства код это средство для создания продукта. И качество кода — это один из параметров для получения какого-то профита в виде денег или в виде общественного признания, и редко как способ показать как качественно (по разумению кодера) пишется код.
То есть, правильно я тебя понял, говорить про качетсво нельзя в принципе ? Ни принципов, ни стандартов.
Здравствуйте, Ikemefula, Вы писали:
F>>Гордыня — код понятен даже джуниору (если он понял задачу) F>>Зависть — код не дублирует уже существующий код F>>Чревоугодие — код не пожирает все возможные ресурсы себе в угоду F>>Блуд — код не содержит бессмысленных конструкций просто ради кода F>>Гнев — в коде заложено удобство использования, а не ненависть к тем, кто будет поддерживать F>>Алчность — код не тащит весь доступный функционал в каждый(или единственный) модуль F>>Уныние — код написан не на выброс
I>Чет я не понял формулы. Слева грехи а справа их описание или же справа описано как не совершать эти грехи ?
справа их описание..
лично для тебя: Гордыня — не усложнять без надобности Зависть — не дублировать существующий код/функционал Чревоугодие — следить за расходом ресурсов Блуд — не словоблудствовать, писать достаточно кратко Гнев — думать о том, кто это будет использовать/поддерживать, а не ненавидеть его заранее Алчность — не тащить весь доступный функционал в каждый(или единственный) модуль, сокращать зависимости Уныние — не писать на выброс
Здравствуйте, neFormal, Вы писали:
I>>Чет я не понял формулы. Слева грехи а справа их описание или же справа описано как не совершать эти грехи ?
F>справа их описание.. F>лично для тебя: F>Гордыня — не усложнять без надобности F>Зависть — не дублировать существующий код/функционал F>Чревоугодие — следить за расходом ресурсов F>Блуд — не словоблудствовать, писать достаточно кратко F>Гнев — думать о том, кто это будет использовать/поддерживать, а не ненавидеть его заранее F>Алчность — не тащить весь доступный функционал в каждый(или единственный) модуль, сокращать зависимости F>Уныние — не писать на выброс
Мнэээ... то есть надо не совершать ни один из этих грехов, а именно:
* усложнять без надобности
* дублировать код и функционал
* игнорировать траты ресурсов
* писать развесисто и бессмысленно
* игнорировать, ненавидеть и презирать пользователя
* развешивать зависимости
* писать так, чтобы нельзя было развивать
Здравствуйте, netch80, Вы писали:
N>Непонятно, почему ты эту ситуацию пытаешься связать с "костылями" в виде Ant, Maven. По-моему, ничего общего в проблематике. N>Сама по себе ситуация подобного рода типична, вопрос в том, как её лечить. С нашим текущим подходом в этом случае было бы следующее: по результатам такого взлёта девелопер должен был бы 1) оформить подробный лог такого взлёта, 2) создать тикет с ним, 3) ссылку на тикет запихнуть во внутреннее Wiki в соответствующую секцию (если нет, создать). Вероятнее всего, в этом случае старший девелопер сказал бы "раз так, опиши это не в виде лога, а в виде HOWTO, в вики в настройке рабочей среды" и по крайней мере проблема была бы документирована и известен шаг решения; а ещё вероятно исправление — не сразу, но постепенно, по мере нахождения сил на это.
I>>3 написать мануал, после пары месяцев все сведётся к п.2 с той разницей, что мануал будет устаревшим и времени будет уходить больше чем в п.2
N>Непонятно, что ты имеешь в виду под мануалом, но всё-таки рабочая обстановка должна создаваться полностью автоматизированно, а все другие варианты — только промежуточные перед этим.
Если рабочая обстановка автоматизирована, то не ясно, зачем нужно описывать HOWTO , секции в WIKI и документировать проблемы
Здравствуйте, netch80, Вы писали:
N>Мнэээ... то есть надо не совершать ни один из этих грехов, а именно: N>* усложнять без надобности N>* дублировать код и функционал N>* игнорировать траты ресурсов N>* писать развесисто и бессмысленно N>* игнорировать, ненавидеть и презирать пользователя N>* развешивать зависимости N>* писать так, чтобы нельзя было развивать
N>Я правильно понял?
да, всё верно
N>Или всё-таки надо совершать все эти грехи?
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Ikemefula, Вы писали:
F>>>Гордыня — код понятен даже джуниору (если он понял задачу) F>>>Зависть — код не дублирует уже существующий код F>>>Чревоугодие — код не пожирает все возможные ресурсы себе в угоду F>>>Блуд — код не содержит бессмысленных конструкций просто ради кода F>>>Гнев — в коде заложено удобство использования, а не ненависть к тем, кто будет поддерживать F>>>Алчность — код не тащит весь доступный функционал в каждый(или единственный) модуль F>>>Уныние — код написан не на выброс
I>>Чет я не понял формулы. Слева грехи а справа их описание или же справа описано как не совершать эти грехи ?
F>справа их описание..
Если справа описание, то не ясно, как грехом может считаться например код который не пожирает все возможные ресурсы себе в угоду
F>лично для тебя:
Я поправил:
F>Гордыня — усложнять без надобности F>Зависть — дублировать существующий код/функционал F>Чревоугодие — распылять все доступные ресурсы ресурсов F>Блуд — словоблудствовать, писать невнятно, пространно F>Гнев — заранее ненавидеть того кто будет использовать код F>Алчность — тащить весь доступный функционал в каждый модуль, плодить зависимости F>Уныние — код на выброс
— Не вари козлёнка в молоке матери его…
— Подожди-ка… А, я понял! Это значит: «Не ешь мясное вместе с молочным?»
— Да ты пиши, что я тебе говорю: «Не вари козлёнка в молоке…»
— Ага, теперь я догадался! Надо иметь отдельную посуду для мяса и молока.
— Послушай, что ты несёшь? Я же тебе ясно сказал: «Не вари козлёнка…»
— Всё, ну, теперь я, наконец, всё понял! После мясного, прежде чем есть молочное, надо подождать шесть часов…
— Да делайте, что хотите!!
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, fin_81, Вы писали:
_>> Качество кода можно объективно судить только на основе какого то стандарта. Если нет стандарта, то все оценки субъективны. N>Тут мыщьх сослался на стандарт, в котором все показатели оцениваются экспертами. То есть в принципе это субъективно. Но практика показывает, что таки эксперты со стажем могут иметь существенные различия в отдельных частностях, но в общем очень неплохо сходятся. Иначе бы вообще не было общего подхода
Субъективизм кончается там, где невозможно написать по другому: синтаксис языка, статический анализ кода, "предупреждения компилятора как ошибки". Если возможно, почему нельзя написать так как хочется, зачем мне думать про мифическое качество кода? Качество кода — это из разряда преждевременной оптимизации. А вот _стандарты_ качества — это уже предметный разговор. А есть ли стандарты качества кода?
_>> Полный субъективизм, который сложно распространить на другие проекты. N>Таки практика показывает, что адекватно распространяется.
"Адекватно" — это субъективный термин. Участвовал в трех разных проектах во всех проектах разный стиль кодирования, проекты приносили "адекватный" доход предприятию (и мне) и имели "адекватный" по качеству код, который по началу вводил в ступор своей "непонятной безобразностью". Месяц-полтора и код уже вполне "адекватный" по качеству.
Самый качественный код который писал это самая первая моя строка — рисование круга по центру экрана на бейсике zx-spectrum. Это был шедевр, потому что я боялся того, что компьютер взорвется если я нарисую круг, который вылезет за границы экрана. Я читал два дня документацию на импортном языке, чтобы узнать разрешение экрана, координаты центра и радиус круга который влезет на экран. Это и есть Качество кода, когда у тебя есть время для изучения проблемы, ты можешь предварительно промоделировать все граничные условия не на продакшн коде. Не всегда есть время для этого, суровый рынок не терпит трусов, которые боятся писать некачественный код.
I>>>Основной эффект такого разделения это затруднение рефакторинга. Т.е. устранить дублирование не получится. _>>Тут много вопросов: сперва надо узнат почему так разделили, может это специально сделано, чтоб любители рефакторить не поломали/испортили чужой код, в котором он не разбирается.
N>Вот это некорректно. Чтобы "любители рефакторить" ничего не поломали, придуманы тесты. Это касается и посторонних, и автора текущего кода: во всём одновременно разбираться таки невозможно. А если есть способ проверить корректность результата после своего изменения, то нет проблемы в чужом вмешательстве, если этот чужой зачем-то развивает код, а не просто ерунду творит.
Тесты придуманы не для "любителей рефакторить", тесты придуманы для того чтобы контролировать качество продукта, для того чтобы контролировать способность удовлетворять требованиям пользователя. Тесты плоско-параллельны к качеству кода который как бы улучшается в результате переделывания. Если меняется чужой участок кода путем рефакторинга, то думаю понимание кода не улучшается. И разделение на задачи, решения и прочие модули — это способ разделения/распараллеливания сложной задачи, где важное значение имеет невмешательство в чужой код. Тут уже проблемы не качества кода, а адекватности архитектуры и процесса совместной разработки. Стандарты качества кода — это скорее всего следствия процесса разработки. Пока единства процессов разработки не заметно, каждый день придумывают всякие агилы, тдд и рупы и тп. И каждый пытается доказать что его процесс самый "адекватный и качественный".
Здравствуйте, Ikemefula, Вы писали:
I>То есть, правильно я тебя понял, говорить про качетсво нельзя в принципе ? Ни принципов, ни стандартов.
Раз нет единых стандартов качества кода, то про абсолют качества говорить сложно. Все зависит от обстоятельств.
У нужны ли стандарты качества кода? Какие проблемы они решают кроме субъективно-эстетических?
Здравствуйте, fin_81, Вы писали:
I>>То есть, правильно я тебя понял, говорить про качетсво нельзя в принципе ? Ни принципов, ни стандартов. _>Раз нет единых стандартов качества кода, то про абсолют качества говорить сложно. Все зависит от обстоятельств.
Интересно, а как же появились стандарты да еще в те времена когда не было стандартов и говорить про какие то абсолюты было сложно ?
_>У нужны ли стандарты качества кода? Какие проблемы они решают кроме субъективно-эстетических?
Например финансовые. Если ты наговнокодил, в следующей версии к N часам на фичи надо добавить M (M ~ N) часов на исправление твоего говнокода, что бы фичи стали хотя бы теоретически реализуемыми.
Здравствуйте, fin_81, Вы писали:
_>Тесты плоско-параллельны к качеству кода который как бы улучшается в результате переделывания. Если меняется чужой участок кода путем рефакторинга, то думаю понимание кода не улучшается.
Ну и ахинея.
1 Тесты позволяют улучшить качество кода за счет того, что детектят регрессию.
2 Рефакторинг часто нужен для того, что бы понять код который приходится править.
>И разделение на задачи, решения и прочие модули — это способ разделения/распараллеливания сложной задачи, где важное значение имеет невмешательство в чужой код.
Такое ощущение что вы там у себя заборами огораживаетесь, что бы невмешиваться в чужой код
Все ровно наоборот — нужно _добиваться_ того, что бы в чужой код можно было влезть как в свой собственный, который ты знаешь как пять пальцев и который тебе нравится как та еда, что тебе мама готовила и в котором тебе комфортно, как у себя дома.
Именно эту цель преследуют всякие техники вроде парнопрограммирования, ревью кода, рефакторинг и тд и тд и тд — сделать чужой код своим.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, fin_81, Вы писали:
I>>>То есть, правильно я тебя понял, говорить про качетсво нельзя в принципе ? Ни принципов, ни стандартов. _>>Раз нет единых стандартов качества кода, то про абсолют качества говорить сложно. Все зависит от обстоятельств.
I>Интересно, а как же появились стандарты да еще в те времена когда не было стандартов и говорить про какие то абсолюты было сложно ?
Не знаю как они появились. Наверно вследствие идеологических (религиозных) войн, путем насильственного насаждения. Поэтому эта тема в религиозных войнах.
_>>У нужны ли стандарты качества кода? Какие проблемы они решают кроме субъективно-эстетических?
I>Например финансовые. Если ты наговнокодил, в следующей версии к N часам на фичи надо добавить M (M ~ N) часов на исправление твоего говнокода, что бы фичи стали хотя бы теоретически реализуемыми.
А как мне определить что мой код "результат переработки еды", какой пункт стандарта мне скажет что я вместо плюса использовал минус. Предварительные тесты могут сказать, а "мифический стандарт качества кода" думаю не в состоянии предупредить об этом. Качество продукта и качество кода это слабо связанные показатели, особенно когда про качество кода сложно что-то предметно сказать.
Здравствуйте, fin_81, Вы писали:
_>>>У нужны ли стандарты качества кода? Какие проблемы они решают кроме субъективно-эстетических?
I>>Например финансовые. Если ты наговнокодил, в следующей версии к N часам на фичи надо добавить M (M ~ N) часов на исправление твоего говнокода, что бы фичи стали хотя бы теоретически реализуемыми.
_>А как мне определить что мой код "результат переработки еды", какой пункт стандарта мне скажет что я вместо плюса использовал минус.
Здесь нет никаких чудес. Если ты продублировал блок кода раз 10 то это однозначно говнокод. Если ты научишься бороться с дублированием, можно поговорить и про другие вещи, как то читаемость, порог вхождения и тд и тд.
>Предварительные тесты могут сказать, а "мифический стандарт качества кода" думаю не в состоянии предупредить об этом. Качество продукта и качество кода это слабо связанные показатели, особенно когда про качество кода сложно что-то предметно сказать.
С качеством кода связана целая куча метрик. Например если ты продублировал код 10 раз, то у этого блока показатель "количество идентичных участков" есть необходимое и достаточное условие говнокода.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, fin_81, Вы писали:
_>>Тесты плоско-параллельны к качеству кода который как бы улучшается в результате переделывания. Если меняется чужой участок кода путем рефакторинга, то думаю понимание кода не улучшается.
I>Ну и ахинея. I>1 Тесты позволяют улучшить качество кода за счет того, что детектят регрессию.
Тесты улучшают качество продукта, а красивый код тут поскольку-постольку. I>2 Рефакторинг часто нужен для того, что бы понять код который приходится править.
То есть рефакторинг нужен для математического тыка.
>>И разделение на задачи, решения и прочие модули — это способ разделения/распараллеливания сложной задачи, где важное значение имеет невмешательство в чужой код.
I>Такое ощущение что вы там у себя заборами огораживаетесь, что бы невмешиваться в чужой код
Опыт работы с многопоточными приложениями подсказывает, что надо как можно реже трогать совместно используемые данные. А если все таки нужен доступ к таким данным лучше использовать какие то примитивы синхронизации: согласование документаций модулей, оповещение использующих эти данные и тд и тп.
I>Все ровно наоборот — нужно _добиваться_ того, что бы в чужой код можно было влезть как в свой собственный, который ты знаешь как пять пальцев и который тебе нравится как та еда, что тебе мама готовила и в котором тебе комфортно, как у себя дома.
А синхронизация мыслей между программистами и телепатическое оповещение причастных тоже прилагается. Или все таки надо сперва помитинговать и потом согласованно совершить мировую революцию. Я не настолько эгоист чтоб нагло править чужой код, лучше уж совместно двигаться к единой цели. И код здесь не причем. Тут важен процесс разработки.
I>Именно эту цель преследуют всякие техники вроде парнопрограммирования, ревью кода, рефакторинг и тд и тд и тд — сделать чужой код своим.
То есть качество кода не причем, главное процесс разработки. А там в процессе и найдем среднее арифметические для показателя качества кода. С этим согласен.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, fin_81, Вы писали:
_>>>>У нужны ли стандарты качества кода? Какие проблемы они решают кроме субъективно-эстетических?
I>>>Например финансовые. Если ты наговнокодил, в следующей версии к N часам на фичи надо добавить M (M ~ N) часов на исправление твоего говнокода, что бы фичи стали хотя бы теоретически реализуемыми.
_>>А как мне определить что мой код "результат переработки еды", какой пункт стандарта мне скажет что я вместо плюса использовал минус.
I>Здесь нет никаких чудес. Если ты продублировал блок кода раз 10 то это однозначно говнокод. Если ты научишься бороться с дублированием, можно поговорить и про другие вещи, как то читаемость, порог вхождения и тд и тд.
Убрал эти копипасты, получил дополнительную вложенность. Что хуже копипаста, или дополнительная вложенность. Что лучше нормальная форма с тормозными join'ами или все в одной таблице. Зависит от обстоятельств. Пока не узнаешь эти обстоятельства судить о мифическом качестве кода судить трудно.
>>Предварительные тесты могут сказать, а "мифический стандарт качества кода" думаю не в состоянии предупредить об этом. Качество продукта и качество кода это слабо связанные показатели, особенно когда про качество кода сложно что-то предметно сказать.
I>С качеством кода связана целая куча метрик. Например если ты продублировал код 10 раз, то у этого блока показатель "количество идентичных участков" есть необходимое и достаточное условие говнокода.
Мне вот интересно кто смотрит эти метрики, тем более по этим метрикам может вынести вердикт о качестве кода. Надо несколько месяцев/лет следить за этими метриками чтобы сказать что-то дельное о качестве кода. А это слишком поздно.
Ни принципов, ни стандартов.
