Всегда считал, что поиск истины возможен только с помощью аргументов/контраргументов, от приведения которых вы упорно уклоняетесь. Но у вас, конечно же, может быть своё, индивидуальное мнение на этот счет. ;)
1. Какие ваши контраргументы по поводу отсутствия у вас сужения контекста должен я обдумать, если вы вообще не привели? :)
Процитируйте их, если я неправ.
2. С каких пор утверждение «исключительно мое» должно опровергаться не кол-вом, а авторитетностью источников? Вы что-то новое в русском языке сейчас изобретаете. :)))
3. В своем глазу бревна не видите. Ваше утверждение про быдлокод в 15-25 строк вообще без каких-либо аргументов. И откуда эти 15-25 строк взяты (с потолка что-ли?) — тоже не аргументировано.
Маленькое уточнение: сказанное справедливо для open source проектов — закрытые коммерческие, увы, умирают (если язык хороший, то медленно и мучительно). Пример — Visual FoxPro от Microsoft.
Ни в обсуждаемой статье, ни в комментарии tangro, и в вашем возражении ему (см. вашу ссылку выше) — нигде не было привязки к конкретному языку программирования. Следовательно, контекст обсуждения — языки программирования в целом. И в этом контексте ваше правило «4-5 строк в методе» является в корне неверным. Отсюда и последовавшая критика в ваш адрес.
я честно говоря устал вести этот спор и не вижу в нём продуктивности.
Это ваша вина.
Видите ли, здесь очень мало телепатов, которые могут догадаться, что когда вы в качестве контраргумента привели очень частный случай (ваш опыт в рамках конкретного языка), то дальнейшее обсуждение должно ограничиться рамками именно вашего частного случая, а не оставаться в рамках изначальной статьи.
Вы сейчас о чем? Я вообще-то говорил о проигрыше в дополнительных накладных расходах при дроблении методов под правило «4-5 строк в методе», а не о проигрыше в качестве тестирования.
И тут уже надо смотреть в каждом конкретном случае — в итоге мы больше выигрываем или теряем? Не факт, что всегда мы будем в выигрыше.
И вообще, оптимальное кол-во строк в функции/процедуре/методе определяется балансом очень многих факторов, не только тестирования (например, язык программирования, задача, длительность сопровождения, изменяемость кода, повторная используемость, трудоемкость и качество тестирования и т.д. и т.п.) и поэтому даже внутри одного проекта может сильно отличаться. Поэтому правила типа «N строк на метод и баста!» отношу к оторванным от жизни догмам из серии «Мне это помогло — значит и тебе поможет».
Но зато и тестов для коротких методов надо гораздо больше написать.
Кроме того, не забывайте, что даже если все короткие методы будут согласно тестам идеально работать, ошибки в вызывающем их модуле все равно возможны: не так состыковали, не все комбинации параметров предусмотрели и т.д. и т.п. Эти возможные ошибки тоже ведь надо покрыть тестом кода верхнего уровня, не так ли? В итоге получается, что выиграша по тестам может быть и не быть, а в отдельных случаях будет даже проигрыш.
Будь я тогда рядом с вами, я бы предложил провести следующий эксперимент с вашим проектом: замерить время поиска и исправления какой-либо ошибки в нормально откомментированном коде и в том же коде, но без комментариев. Людьми, который этот код либо в глаза не видели, либо уже полностью забыли. А потом мы бы сделали выводы, сколько времени впустую вы тратите только из-за того, что вам кажется, что комментариев быть не должно.
Вы, наверное, только на маленьких проектах работаете?
В больших проектах отсутствие комментариев — это мрак. Да, можно, конечно, покопавшись в коде, в конце концов разобраться что к чему, но, поверьте, в больших проектов и без этого есть чем голову занять и на что время тратить и лишние траты ресурсов (времени, мозгов, нервов и т.д.) там совсем ни к чему.
Исключение: короткие имена переменных очень удобны для счетчиков циклов (да и то если цикл короткий и не предполагает разрастания на 1-2 экрана). Сам привык к этому еще со времен PL/I (если кто помнит — i,j,k,etc.): коротко плюс сразу видно, где нормальная переменная (долгоживущая), а где временная финтифлюшка, нужная только для данного цикла.
Это с вашей личной (тоже, кстати, субъективной) точки зрения нет ничего хорошего и плохого. Раз вы признаете изначальную субъективность оценок «хорошо/плохо», то это значит, что кто-то имеет точно такое же право навесить ярлык «хорошо» на любой понравившийся ему предмет/действие/явление, как и вы — право этот ярлык содрать и на этом основании заявлять, что нет ничего хорошего. ;)
Вы увидите, что нарушитель это не только хакер с шпионским ПО.
Я с этим где-то спорил?
И от некоторых угроз токен весьма эффективная защита.
Я с этим где-то спорил?
Это что — такая уловка? Вместо приведения контраргументов сказать пару очевидных фраз (спасибо, кэп!), которые оппонент никогда даже не ставил под сомнение, и думать, что этим все доказано?
Напоминаю проигнорированный вами вопрос:
Так в чем я неправ, говоря «Токен в руках бестолкового клиента — не защита»?
Как видите, мое утверждение не противоречит ни одному из приведенных сейчас вами псевдоаргументов.
Вообще-то в русском языке ваше поведение называется «спорить». См. gramota.ru:
Спорить — возражать кому-л., доказывать что-л.
Во-вторых, вы так и не ответили на уточняющие вопросы по вашей точке зрения. Следует ли из этого, что вам нечем ее обосновать и она является таким же продуктом вашей фантазии, как и ваши домыслы, приписываемые Volosatik'у (см. ниже)?
Это, конечно, очень ценно — сообщить всем свои эмоции по поводу моей внимательности. :)))
Но даже эта жизненно «необходимая» для обсуждения :) информация — не повод увиливать от цитат, подтверждающих ваши домыслы в чужой адрес.
Ответьте прямо: подтверждаются ваши утверждения-домыслы хоть чем-то или нет?
Вы по существу вопроса можете что-то сказать?
Если вы не в курсе, то в обсуждениях разбор утверждений/аргументов/контраргументов оппонента — это и есть разговор по существу. И если его избегать — это уже не обсуждение получится, а балаган какой-то: каждый сочиняет всё, что хочет, а других не слушает.
Так вы же сами говорили «ответственность», «должен отвечать». Какая же это ответственность, если в случае провала ответственные за проваленный участок работ (=виновные в провале) продолжают сидеть на попе так же ровно, как и в случае успеха?
Если вас коробит слово «виноват», то спокойно можете заменить его на «отвечает за провал» — смысл моих слов не изменится.
Если программа «нафиг никому не нужна» — то какая разница, насколько качественный в ней код и насколько хорошо она оптимизирована?
Для покупателя программы — никакой.
А вот для руководителя проекта, который обязан оценивать труд в т.ч. и программистов, — разница огромнейшая. Если ему это без разницы — гнать надо в шею таких руководителей!
Вы перечитайте эту ветку. Дискуссия началась с тезиса, что даже если программа «не выстрелила», то главное — что программист код хороший написал…
Еще раз перечитал. Ничего нового не обнаружил.
Ваша ошибка в том, вы пытаетесь свалить на программиста ответственность за неудачи на всех участках работ. А программист — всего лишь один из многих и отвечает только за свой участок работ.
P.S. А вообще, к сожалению, большинство программистов наслаждаются процессом, а не результатом…
Это вина не программистов, а их руководителя, который не может выстроить нормальную систему мотивации своих подчиненных. Это я вам как руководитель программистов говорю.
то есть вы предпочитаете ситуацию, когда банк преспокойно может воровать деньги клиентов списывая это на них же самих?
Подскажите, как банк умудрится своровать деньги клиентов, списывая это на них же самих? ЭЦП уже отменили? Или банковские айтишники шутя умеют вычислять закрытый ключ ЭЦП по имеющемуся у них открытому? С огромным любопытством выслушаю технологию. И, думаю, не я один — весь мир прильнет к экранам мониторов. ;)
токен, как средство формирования эцп, имеет массу полезных свойств.
Вы не меняйте тему. Мы сейчас не о достоинствах токена спорим.
Кроме того, перечисленные вами достоинства свойственны не только токенам, но и обычным программным средствам с хранением ключей на флешке/CD/жестком диске.
Ага, особенно в ситуации, когда клиенты могут преспокойненько «воровать» сами у себя (см. выше), и государство пока не имеет эффективных механизмов, ограничивающих этот процесс. В таких случаях государству надо быть полным идиотом, чтобы принять «правила игры», вводящие безусловную ответственность банков за игры клиентов в фиктивные кражи.
1. Какие ваши контраргументы по поводу отсутствия у вас сужения контекста должен я обдумать, если вы вообще не привели? :)
Процитируйте их, если я неправ.
2. С каких пор утверждение «исключительно мое» должно опровергаться не кол-вом, а авторитетностью источников? Вы что-то новое в русском языке сейчас изобретаете. :)))
3. В своем глазу бревна не видите. Ваше утверждение про быдлокод в 15-25 строк вообще без каких-либо аргументов. И откуда эти 15-25 строк взяты (с потолка что-ли?) — тоже не аргументировано.
Какое же это «исключительно мое», раз я уже 3-ий по счету, кто с вами по этому поводу спорит? ;)
А вот это действительно исключительно ваше мнение. ;)
Это ваша вина.
Видите ли, здесь очень мало телепатов, которые могут догадаться, что когда вы в качестве контраргумента привели очень частный случай (ваш опыт в рамках конкретного языка), то дальнейшее обсуждение должно ограничиться рамками именно вашего частного случая, а не оставаться в рамках изначальной статьи.
И тут уже надо смотреть в каждом конкретном случае — в итоге мы больше выигрываем или теряем? Не факт, что всегда мы будем в выигрыше.
И вообще, оптимальное кол-во строк в функции/процедуре/методе определяется балансом очень многих факторов, не только тестирования (например, язык программирования, задача, длительность сопровождения, изменяемость кода, повторная используемость, трудоемкость и качество тестирования и т.д. и т.п.) и поэтому даже внутри одного проекта может сильно отличаться. Поэтому правила типа «N строк на метод и баста!» отношу к оторванным от жизни догмам из серии «Мне это помогло — значит и тебе поможет».
Кроме того, не забывайте, что даже если все короткие методы будут согласно тестам идеально работать, ошибки в вызывающем их модуле все равно возможны: не так состыковали, не все комбинации параметров предусмотрели и т.д. и т.п. Эти возможные ошибки тоже ведь надо покрыть тестом кода верхнего уровня, не так ли? В итоге получается, что выиграша по тестам может быть и не быть, а в отдельных случаях будет даже проигрыш.
Будь я тогда рядом с вами, я бы предложил провести следующий эксперимент с вашим проектом: замерить время поиска и исправления какой-либо ошибки в нормально откомментированном коде и в том же коде, но без комментариев. Людьми, который этот код либо в глаза не видели, либо уже полностью забыли. А потом мы бы сделали выводы, сколько времени впустую вы тратите только из-за того, что вам кажется, что комментариев быть не должно.
В больших проектах отсутствие комментариев — это мрак. Да, можно, конечно, покопавшись в коде, в конце концов разобраться что к чему, но, поверьте, в больших проектов и без этого есть чем голову занять и на что время тратить и лишние траты ресурсов (времени, мозгов, нервов и т.д.) там совсем ни к чему.
Я с этим где-то спорил?
Это что — такая уловка? Вместо приведения контраргументов сказать пару очевидных фраз (спасибо, кэп!), которые оппонент никогда даже не ставил под сомнение, и думать, что этим все доказано?
Напоминаю проигнорированный вами вопрос:
Так в чем я неправ, говоря «Токен в руках бестолкового клиента — не защита»?
Как видите, мое утверждение не противоречит ни одному из приведенных сейчас вами псевдоаргументов.
Во-вторых, вы так и не ответили на уточняющие вопросы по вашей точке зрения. Следует ли из этого, что вам нечем ее обосновать и она является таким же продуктом вашей фантазии, как и ваши домыслы, приписываемые Volosatik'у (см. ниже)?
Но даже эта жизненно «необходимая» для обсуждения :) информация — не повод увиливать от цитат, подтверждающих ваши домыслы в чужой адрес.
Ответьте прямо: подтверждаются ваши утверждения-домыслы хоть чем-то или нет?
Если вы не в курсе, то в обсуждениях разбор утверждений/аргументов/контраргументов оппонента — это и есть разговор по существу. И если его избегать — это уже не обсуждение получится, а балаган какой-то: каждый сочиняет всё, что хочет, а других не слушает.
Если вас коробит слово «виноват», то спокойно можете заменить его на «отвечает за провал» — смысл моих слов не изменится.
Для покупателя программы — никакой.
А вот для руководителя проекта, который обязан оценивать труд в т.ч. и программистов, — разница огромнейшая. Если ему это без разницы — гнать надо в шею таких руководителей!
Еще раз перечитал. Ничего нового не обнаружил.
Ваша ошибка в том, вы пытаетесь свалить на программиста ответственность за неудачи на всех участках работ. А программист — всего лишь один из многих и отвечает только за свой участок работ.
Это вина не программистов, а их руководителя, который не может выстроить нормальную систему мотивации своих подчиненных. Это я вам как руководитель программистов говорю.
Вы не меняйте тему. Мы сейчас не о достоинствах токена спорим.
Кроме того, перечисленные вами достоинства свойственны не только токенам, но и обычным программным средствам с хранением ключей на флешке/CD/жестком диске.
Во-вторых, каким образом из приведенной вами моей цитаты следует, что злоумышленник всесилен? Может покажете всем полет вашей логической мысли? ;)