Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 115
Какая хорошая и нужная статья!
Вы сэкономили многим людям деньги на антидепрессантах.
Вы сэкономили многим людям деньги на антидепрессантах.
> в нашем коде меньше ошибок, чем нам кажется
Ну здесь можно сказать только одно — ха-ха-ха.
Разве что это является мантрой для самовнушения :)
Ну здесь можно сказать только одно — ха-ха-ха.
Разве что это является мантрой для самовнушения :)
Тсссс… не выдавайте никому эту тайну;)
Так оно и задумывалось
Так оно и задумывалось
Над «в любой программе есть ошибки» мы смеемся.
А в «в моей программе ошибок нет» либо слепо верим, либо так же слепо не верим.
А в «в моей программе ошибок нет» либо слепо верим, либо так же слепо не верим.
> Colwin
Вау, ты таки как простой смертный бываешь на Хабре.
> Над «в любой программе есть ошибки» мы смеемся.
> А в «в моей программе ошибок нет» либо слепо верим, либо так же слепо не верим.
Что происходит, когда твой код становится чужим, а чужой — твоим? (merge в одном функциональном scope; поддержка legacy; поддержка того, что изначально написал ты, а потом поддерживал какой-то другой человек; итп)
Вау, ты таки как простой смертный бываешь на Хабре.
> Над «в любой программе есть ошибки» мы смеемся.
> А в «в моей программе ошибок нет» либо слепо верим, либо так же слепо не верим.
Что происходит, когда твой код становится чужим, а чужой — твоим? (merge в одном функциональном scope; поддержка legacy; поддержка того, что изначально написал ты, а потом поддерживал какой-то другой человек; итп)
Сейчас объясню идею. Мы начинаем писать программу. Допустим я недавно писал «эскпертную» систему поиска соответствий в базе статистики. Наша база oracle, база к которой надо привяpаться общается через JSON простыни.
Пишу первый шаг привязки что-то типа.
Сразу хочется написать
Или даже
Вопрос зачем? Я так уверен что тут в 4 строчках ошибка? Не лучше ли сразу идти дальше.
Если я начну ловить ошибки которых нет, я сразу признаю, что ошибок больше чем я думаю. Логично?)
Пишу первый шаг привязки что-то типа.
$rec = $dbh->selectrow_arrayref('select from expert_base ...
$top_catalog = first {
$rec->{JSON_VALUE} eq $_->{id}
} @{$json->{sport}};Сразу хочется написать
warn $top_catalog;Или даже
warn Dumper($top_catalog);Вопрос зачем? Я так уверен что тут в 4 строчках ошибка? Не лучше ли сразу идти дальше.
Если я начну ловить ошибки которых нет, я сразу признаю, что ошибок больше чем я думаю. Логично?)
Лев Семёнович изумился бы, во что вылились его наработки %)
Логично лишь то, что вы признали бы в этом случае, что ошибки возможны. И это признание ни в коем разе не могло бы быть связано с указанной количественной характеристикой. Ошибки действительно возможны.
Однако же, неоспоримо, что на переключение между контекстами будет затрачено какое-то время, и по возможности его следует минимизировать, и ваш подход вполне имеет право на жизнь. Впрочем, наряду со множеством других.
Если я начну ловить ошибки которых нет, я сразу признаю, что ошибок больше чем я думаю. Логично?)
Логично лишь то, что вы признали бы в этом случае, что ошибки возможны. И это признание ни в коем разе не могло бы быть связано с указанной количественной характеристикой. Ошибки действительно возможны.
Однако же, неоспоримо, что на переключение между контекстами будет затрачено какое-то время, и по возможности его следует минимизировать, и ваш подход вполне имеет право на жизнь. Впрочем, наряду со множеством других.
Ну и что?
Я лично часто после логически законченного участка кода вставляю assert'ы.
Во-первых они повышают субъективную уверенность в коде, во-вторых — никак не влияют на производительность. И, в-третьих, не отнимают много времени.
Я лично часто после логически законченного участка кода вставляю assert'ы.
Во-первых они повышают субъективную уверенность в коде, во-вторых — никак не влияют на производительность. И, в-третьих, не отнимают много времени.
Когда-то я писал фрагментик кода, где нужно было обязательно отлавливать все ошибки и писать в лог. Работа была с деньгами пользователей и во избежание матов с их стороны, я очень тщательно обрабатывал все эксепшены, которые могли вылететь. В итоге я подловил даже такую ситуацию, когда эксепшн ну никак не мог вылететь, но я все равно обработал этот блок и написал что-то вроде log(«It's unbelievable!!!').
Как думаете, какая первая запись появилась в моем логе? ) В итоге оказалось там просто опечатка была, а по логике действительно не могло там ничего вылететь.
Как думаете, какая первая запись появилась в моем логе? ) В итоге оказалось там просто опечатка была, а по логике действительно не могло там ничего вылететь.
Далеко не у каждого программиста поиск нетривиальных решений задач приводит к депрессиям. У таких программистов отношение к проблеме иное — чем сложнее далось решение, оказавшееся в итоге гораздо эффективнее самого очевидного варианта, тем большее удовольствие от работы они получают.
Ваш подход хорош, когда создаваемый продукт «стандартен» и не требует поиска нетривиальных решений, которые, к слову, могут заключаться и в переходе на другие языки программирования.
Но даже на рынке стандартных тривиальных продуктов может сложиться так, что ваш конкурент соберёт команду таких программистов, которые окажутся «управляемыми перфекционистами». Т.е. у него получится за меньший срок сделать продукт качественнее, чем у вас. И что же тогда будете делать вы? Вам нужно предпринимать какие-то новые шаги в сторону лучшего продукта, но к вашей ноге прицеплена большая и тяжёлая гиря в виде текущего кода, созданного по принципу «TODO: will fix this someday».
А решение, на мой взгляд, очень простое. Нужно просто понимать, что ключ к продуктивности лежит как в оттачивании имеющихся навыков, так и в получении новых. Поэтому в какие-то моменты могут быть провалы в продуктивности, связанные с обучением. Их нужно воспринимать как часть нормального процесса, а для этого стоит просто переключиться на другую шкалу измерения продуктивности. Например, вместо строк кода/функциональных единиц выбрать количество освоенного материала за период времени.
И я бы не стал категорически отметать ни 20-миллисекундные оптимизации, ни выбор новых инструментов, ни критику со стороны. Потому что практика показывает, что там, где есть возможность оптимизировать 20мс, иногда можно найти оптимизацию в 2 секунды, если посмотреть на задачу под другим углом. А то, что поначалу казалось неконструктивом, оказывается очевидной правдой — просто на тот момент у тебя не было достаточного опыта и глубокого понимания проблемы, что заставляло тебя говорить абсолютную чепуху, на которую знающие люди реагировали резко, без лишних объяснений, но по существу.
Ваш подход хорош, когда создаваемый продукт «стандартен» и не требует поиска нетривиальных решений, которые, к слову, могут заключаться и в переходе на другие языки программирования.
Но даже на рынке стандартных тривиальных продуктов может сложиться так, что ваш конкурент соберёт команду таких программистов, которые окажутся «управляемыми перфекционистами». Т.е. у него получится за меньший срок сделать продукт качественнее, чем у вас. И что же тогда будете делать вы? Вам нужно предпринимать какие-то новые шаги в сторону лучшего продукта, но к вашей ноге прицеплена большая и тяжёлая гиря в виде текущего кода, созданного по принципу «TODO: will fix this someday».
А решение, на мой взгляд, очень простое. Нужно просто понимать, что ключ к продуктивности лежит как в оттачивании имеющихся навыков, так и в получении новых. Поэтому в какие-то моменты могут быть провалы в продуктивности, связанные с обучением. Их нужно воспринимать как часть нормального процесса, а для этого стоит просто переключиться на другую шкалу измерения продуктивности. Например, вместо строк кода/функциональных единиц выбрать количество освоенного материала за период времени.
И я бы не стал категорически отметать ни 20-миллисекундные оптимизации, ни выбор новых инструментов, ни критику со стороны. Потому что практика показывает, что там, где есть возможность оптимизировать 20мс, иногда можно найти оптимизацию в 2 секунды, если посмотреть на задачу под другим углом. А то, что поначалу казалось неконструктивом, оказывается очевидной правдой — просто на тот момент у тебя не было достаточного опыта и глубокого понимания проблемы, что заставляло тебя говорить абсолютную чепуху, на которую знающие люди реагировали резко, без лишних объяснений, но по существу.
Эмм… вы читали дисклаймер?
Нет? Тогда идите на… (с)
Нет? Тогда идите на… (с)
Читал. Продолжим?
Тогда концепция действительно не поменялась. Раз читали и не поняли.
Ваша позиция деструктивная критика. Логичная, но деструктивная.
Ваша позиция деструктивная критика. Логичная, но деструктивная.
Это была не критика, а контраргументация.
Ок.
> Далеко не у каждого программиста поиск нетривиальных решений задач приводит к депрессиям. У таких программистов отношение к проблеме иное — чем сложнее далось решение, оказавшееся в итоге гораздо эффективнее самого очевидного варианта, тем большее удовольствие от работы они получают.
Я сказал, что поиск нетривиальных решений приводит к депрессии? +1 к троллингу. я сказал что к депрессии приводит отсутствие решения. И не надо впадать в депрессию заранее. До того как мы подойдём к этому решению. Сперва к нему надо подойти. А там или решение появится или задача поменяется.
> Ваш подход хорош, когда создаваемый продукт «стандартен» и не требует поиска нетривиальных решений, которые, к слову, могут заключаться и в переходе на другие языки программирования.
Опять же где вы это увидели. Мой подход в разделении программирования и отладки. И психологичиском настрое писать прямо сейчас и не думать об ошибках и проблемах. Вам +1. А нет, вы смешали два понятия из разных частей статьи. Это контрагрументация или софистика? Еще +2.
Ок, давайте опять же отвечу, что если есть решение которое можно сесть и со скрипом запрограмировать на том, что есть, это лучше чем тратить время на ожидание и изучение волшебного решения. Хотя эта часть статьи спорна поэтому сниму с троллинга -1 балл.
> Но даже на рынке стандартных тривиальных продуктов может сложиться так, что ваш конкурент соберёт команду таких программистов, которые окажутся «управляемыми перфекционистами». Т.е. у него получится за меньший срок сделать продукт качественнее, чем у вас. И что же тогда будете делать вы? Вам нужно предпринимать какие-то новые шаги в сторону лучшего продукта, но к вашей ноге прицеплена большая и тяжёлая гиря в виде текущего кода, созданного по принципу «TODO: will fix this someday».
[irony]Если у конкурента есть такие замечательные и талантливые люди, то наиболее оптимально эту команду использовать для повторения чужих разработок. Это общеизвестный факт. Скорее эта команда выпустит коня на пяти ногах, пока пользуясь моей аналогией вы будете красиво отпиливать у него 6ую. За трллинг 0.
>А решение, на мой взгляд, очень простое. Нужно просто понимать, что ключ к продуктивности лежит как в оттачивании имеющихся навыков, так и в получении новых. Поэтому в какие-то моменты могут быть провалы в продуктивности, связанные с обучением. Их нужно воспринимать как часть нормального процесса, а для этого стоит просто переключиться на другую шкалу измерения продуктивности. Например, вместо строк кода/функциональных единиц выбрать количество освоенного материала за период времени.
Кэп? Я уже сказал, что часть статьи про лопату спорна. Наверно нужно дописать, что не надо этим заниматься, когда вариантов слишком много и не можешь ни на чем остановиться. Учиться нужно. Но если есть идея котору можно сделать прямо сейчас, но немного не хватает в текущем инструменте — имеет смысл попробовать сделать на нём.
>И я бы не стал категорически отметать ни 20-миллисекундные оптимизации, ни выбор новых инструментов, ни критику со стороны. Потому что практика показывает, что там, где есть возможность оптимизировать 20мс, иногда можно найти оптимизацию в 2 секунды, если посмотреть на задачу под другим углом.
А я бы стал. Оптимизировать скорее надо частые операции пусть даже и дешевые, а не редкие пусть даже дорогие. К тролингу не за что, а вот за матчасть -1.
А то, что поначалу казалось неконструктивом, оказывается очевидной правдой — просто на тот момент у тебя не было достаточного опыта и глубокого понимания проблемы, что заставляло тебя говорить абсолютную чепуху, на которую знающие люди реагировали резко, без лишних объяснений, но по существу.
Тоже спорный вывод. Вообще-то за мою работу меня обычно только хвалили. Ругали как раз за то, что не сделал или завалил сроки из-за излишнего перфекционизма. +3 К ролингу за поспешные выводы и за то что выпили со мной на брудершафт без моего ведома.
И вы продолжаете это называть контраргументацией? ;) И удивляться почему я последовал собственному совету и вас послал?)
> Далеко не у каждого программиста поиск нетривиальных решений задач приводит к депрессиям. У таких программистов отношение к проблеме иное — чем сложнее далось решение, оказавшееся в итоге гораздо эффективнее самого очевидного варианта, тем большее удовольствие от работы они получают.
Я сказал, что поиск нетривиальных решений приводит к депрессии? +1 к троллингу. я сказал что к депрессии приводит отсутствие решения. И не надо впадать в депрессию заранее. До того как мы подойдём к этому решению. Сперва к нему надо подойти. А там или решение появится или задача поменяется.
> Ваш подход хорош, когда создаваемый продукт «стандартен» и не требует поиска нетривиальных решений, которые, к слову, могут заключаться и в переходе на другие языки программирования.
Опять же где вы это увидели. Мой подход в разделении программирования и отладки. И психологичиском настрое писать прямо сейчас и не думать об ошибках и проблемах. Вам +1. А нет, вы смешали два понятия из разных частей статьи. Это контрагрументация или софистика? Еще +2.
Ок, давайте опять же отвечу, что если есть решение которое можно сесть и со скрипом запрограмировать на том, что есть, это лучше чем тратить время на ожидание и изучение волшебного решения. Хотя эта часть статьи спорна поэтому сниму с троллинга -1 балл.
> Но даже на рынке стандартных тривиальных продуктов может сложиться так, что ваш конкурент соберёт команду таких программистов, которые окажутся «управляемыми перфекционистами». Т.е. у него получится за меньший срок сделать продукт качественнее, чем у вас. И что же тогда будете делать вы? Вам нужно предпринимать какие-то новые шаги в сторону лучшего продукта, но к вашей ноге прицеплена большая и тяжёлая гиря в виде текущего кода, созданного по принципу «TODO: will fix this someday».
[irony]Если у конкурента есть такие замечательные и талантливые люди, то наиболее оптимально эту команду использовать для повторения чужих разработок. Это общеизвестный факт. Скорее эта команда выпустит коня на пяти ногах, пока пользуясь моей аналогией вы будете красиво отпиливать у него 6ую. За трллинг 0.
>А решение, на мой взгляд, очень простое. Нужно просто понимать, что ключ к продуктивности лежит как в оттачивании имеющихся навыков, так и в получении новых. Поэтому в какие-то моменты могут быть провалы в продуктивности, связанные с обучением. Их нужно воспринимать как часть нормального процесса, а для этого стоит просто переключиться на другую шкалу измерения продуктивности. Например, вместо строк кода/функциональных единиц выбрать количество освоенного материала за период времени.
Кэп? Я уже сказал, что часть статьи про лопату спорна. Наверно нужно дописать, что не надо этим заниматься, когда вариантов слишком много и не можешь ни на чем остановиться. Учиться нужно. Но если есть идея котору можно сделать прямо сейчас, но немного не хватает в текущем инструменте — имеет смысл попробовать сделать на нём.
>И я бы не стал категорически отметать ни 20-миллисекундные оптимизации, ни выбор новых инструментов, ни критику со стороны. Потому что практика показывает, что там, где есть возможность оптимизировать 20мс, иногда можно найти оптимизацию в 2 секунды, если посмотреть на задачу под другим углом.
А я бы стал. Оптимизировать скорее надо частые операции пусть даже и дешевые, а не редкие пусть даже дорогие. К тролингу не за что, а вот за матчасть -1.
А то, что поначалу казалось неконструктивом, оказывается очевидной правдой — просто на тот момент у тебя не было достаточного опыта и глубокого понимания проблемы, что заставляло тебя говорить абсолютную чепуху, на которую знающие люди реагировали резко, без лишних объяснений, но по существу.
Тоже спорный вывод. Вообще-то за мою работу меня обычно только хвалили. Ругали как раз за то, что не сделал или завалил сроки из-за излишнего перфекционизма. +3 К ролингу за поспешные выводы и за то что выпили со мной на брудершафт без моего ведома.
И вы продолжаете это называть контраргументацией? ;) И удивляться почему я последовал собственному совету и вас послал?)
> И вы продолжаете это называть контраргументацией? ;) И удивляться почему я последовал собственному совету и вас послал?)
Я удивляюсь почему у вас вообще такое отношение к человеку, который пытается построить диалог в обсуждении материала. Обвинить кого-то в троллинге и нехватке матчасти, попутно послав его подальше, может абсолютно любой. Это гораздо проще, чем попытаться понять о чём говорит другая сторона.
Я пытался донести до вас мысль, что описываемое в статье желание получить максимальную продуктивность в разработке, достигается неверным, с моей точки зрения, решением экономить на контроле за качеством кода. По моему опыту, переписывание кода с учетом найденных ошибок не всегда продуктивнее, чем контроль во время самой итерации.
И я намекнул вам (с рассчетом на развитие темы в дальнейшем обсуждении), что есть немало случаев, когда изучение новых инструментов позволяет сохранить контроль над ошибками на том же уровне, но при этом сильно увеличить вашу продуктивность. Просто за счет того, что новый инструментарий сам позаботится об этих вещах. Такая возможность достигается, например, за счёт перехода на инструменты с поддержкой автоматического выведения типов и сборкой мусора, или на инструменты с крутым сэндбоксингом без ограничения допустимых инструкций. Контроль вы не потеряли, качество кода не ухудшили, а продуктивность возросла. Следовательно, я имею возможность объективно высказаться, что ваш подход в игнорировании и «забивании» на некоторые ключевые принципы разработки качественного кода ни к чему хорошему в итоге не приведёт. Потому что всё что вы увидите, оглянувшись назад на свои работы, будет плохо пахнуть. Вы и сами это подтверждаете, когда в начале статьи пишете "Да, на старый код без слёз не взглянешь: всё можно сделать оптимальнее и, по крайней мере, читабельнее. Но код был написан быстро.".
И этому же вы пытаетесь научить других??
Вот моя позиция, которую вы, в следствие своего пренебрежения к чужому мнению, не заметили.
Я удивляюсь почему у вас вообще такое отношение к человеку, который пытается построить диалог в обсуждении материала. Обвинить кого-то в троллинге и нехватке матчасти, попутно послав его подальше, может абсолютно любой. Это гораздо проще, чем попытаться понять о чём говорит другая сторона.
Я пытался донести до вас мысль, что описываемое в статье желание получить максимальную продуктивность в разработке, достигается неверным, с моей точки зрения, решением экономить на контроле за качеством кода. По моему опыту, переписывание кода с учетом найденных ошибок не всегда продуктивнее, чем контроль во время самой итерации.
И я намекнул вам (с рассчетом на развитие темы в дальнейшем обсуждении), что есть немало случаев, когда изучение новых инструментов позволяет сохранить контроль над ошибками на том же уровне, но при этом сильно увеличить вашу продуктивность. Просто за счет того, что новый инструментарий сам позаботится об этих вещах. Такая возможность достигается, например, за счёт перехода на инструменты с поддержкой автоматического выведения типов и сборкой мусора, или на инструменты с крутым сэндбоксингом без ограничения допустимых инструкций. Контроль вы не потеряли, качество кода не ухудшили, а продуктивность возросла. Следовательно, я имею возможность объективно высказаться, что ваш подход в игнорировании и «забивании» на некоторые ключевые принципы разработки качественного кода ни к чему хорошему в итоге не приведёт. Потому что всё что вы увидите, оглянувшись назад на свои работы, будет плохо пахнуть. Вы и сами это подтверждаете, когда в начале статьи пишете "Да, на старый код без слёз не взглянешь: всё можно сделать оптимальнее и, по крайней мере, читабельнее. Но код был написан быстро.".
И этому же вы пытаетесь научить других??
Вот моя позиция, которую вы, в следствие своего пренебрежения к чужому мнению, не заметили.
вы опять выдергиваете фразы из контекста и вольно интерпретируете слова. Поэтому я позволяю принебрежение к вашему мнению.
Если хотите более уважительного отношения, относитесь более уважительно к чужим текстам
Если хотите более уважительного отношения, относитесь более уважительно к чужим текстам
Поздравляю, вы отличный тролль.
Жаль что я не последовал собственному совету и таки вступил с вами в дискуссию. В ней вы однозначно победили — извините у меня нет времени дальше дикутировать с человеком единственное желание которого показать, что я неправ, только потому что он лучше знает как надо.
Похожий случай был с моей крайней короткрометражкой. Я показал своему знакомому. Который кстати сам ничего не снимает. Он меня достал вопросом где изменение характера героини (да изменение характера очень фактор). Я ответил, что изначально планировалось, что я играю с настроением зрителя, а характер не трогаю. Нет изменения характера и всё. Не нужно оно там, мне нужно не сопродвижение, а сопереживани от зрителя.
Весь фильм на ассоциациях. На характерных ситуациях в которые зритель попадал. поэтому они его цепляют и держат, чтобы придти к финалу с тем настроением которое мне нужно. Да эксперимент.Не совсем удался — проблемы с организацией съемок. Но надо было попробовать.
Меня начали грузить какими-то новомодными сценарными концепциями. Я честно попытался объяснить, что вот тут хочу вызвать сочуствие, вот тут грусть, тут заинтересованность тут улыбку. И удержать восприятие зрителя.
Меня начали спрашивать, что по этому поводу сказал бы известный буржуйский сценарист. Откуда я знаю. Это моя работа, а не его. как сценарист — я сработал идеально. Как режиссер да — накосячил местами. Человек словил батхерд, и свалился в истерики «КАК ТАК МОЖНО?» пришлось ему сказать, что я о нем думаю — одним словом.
Ничего потом поговорили, побухали. Разобрались. Бывает ;)
Жаль что я не последовал собственному совету и таки вступил с вами в дискуссию. В ней вы однозначно победили — извините у меня нет времени дальше дикутировать с человеком единственное желание которого показать, что я неправ, только потому что он лучше знает как надо.
Похожий случай был с моей крайней короткрометражкой. Я показал своему знакомому. Который кстати сам ничего не снимает. Он меня достал вопросом где изменение характера героини (да изменение характера очень фактор). Я ответил, что изначально планировалось, что я играю с настроением зрителя, а характер не трогаю. Нет изменения характера и всё. Не нужно оно там, мне нужно не сопродвижение, а сопереживани от зрителя.
Весь фильм на ассоциациях. На характерных ситуациях в которые зритель попадал. поэтому они его цепляют и держат, чтобы придти к финалу с тем настроением которое мне нужно. Да эксперимент.Не совсем удался — проблемы с организацией съемок. Но надо было попробовать.
Меня начали грузить какими-то новомодными сценарными концепциями. Я честно попытался объяснить, что вот тут хочу вызвать сочуствие, вот тут грусть, тут заинтересованность тут улыбку. И удержать восприятие зрителя.
Меня начали спрашивать, что по этому поводу сказал бы известный буржуйский сценарист. Откуда я знаю. Это моя работа, а не его. как сценарист — я сработал идеально. Как режиссер да — накосячил местами. Человек словил батхерд, и свалился в истерики «КАК ТАК МОЖНО?» пришлось ему сказать, что я о нем думаю — одним словом.
Ничего потом поговорили, побухали. Разобрались. Бывает ;)
тем не менее спасибо, спор с вами помог более связно изложить некоторые мысли ;)
А конструктивной критикой, в таком случае, будет похвала? «Молодец, хорошо написал. Можно и нужно лучше, но всё равно молодчага» — такой себе подход для обучения человека, от которого многого-то и не ждут.
Нет. На самом деле статья сумбурная и местами спорная. Но в изначальном комментарии выше лейтмотив был такой «ты ничего не понимаешь и тебя просто ругали мало, но ничего я исправлю.»
Я пытался сейчас на работе программирую на pl/sql, js, perl,delphi сейчас ещё прибавится java и c под андроид. Ещё и не по работе есть прикольный стартап, до которого с лета руки не доходили.и еще съемки. В общем крыша хорошо едет. Вплоть до зависания. Подловил себя на излишнем контроле и лишних итерациях на отладке и поиске серебряной пули для стартапа. Вот и статья)
Правда уже понял, как стоит переписать.
Я пытался сейчас на работе программирую на pl/sql, js, perl,delphi сейчас ещё прибавится java и c под андроид. Ещё и не по работе есть прикольный стартап, до которого с лета руки не доходили.и еще съемки. В общем крыша хорошо едет. Вплоть до зависания. Подловил себя на излишнем контроле и лишних итерациях на отладке и поиске серебряной пули для стартапа. Вот и статья)
Правда уже понял, как стоит переписать.
А может вы просто слишком распыляетесь? Такие случаи, по-моему, описывали и до этого. Как вариант — можно уменьшить нагрузку, сконцентрировавшись на более узком кругу задач.
«ты ничего не понимаешь и тебя просто ругали мало, но ничего я исправлю.» — звучит нахально, но это работает. В такой манере можно делать код-ревью. Да, более опытный сотрудник будет совершать акт глумления над кодом менее опытного, тут уж ничего не поделать, в сфере IT сарказм является привилегией опытных. Но ведь это мотивирует догнать его по уровню знаний, перегнать, а потом, при удобном случае, ещё и пиздюлей навалять.
Иначе откуда брать знания? Книги все по рефакторингу не перечитать, за блогами всеми не уследить, все самые свежие 3rd-party-решения в книгах не описаны — а ведь именно это всё помогает работать наиболее продуктивно.
В статье фактически говорится «не нужен рефакторинг» — я сейчас работаю над проектом, где очень много функциональности реализовано, и всё работает, а вот масштабировать его крайне хреново, приходится много и с болью рефакторить. И до этого такие проекты попадались, и на разных работах, и явно не у меня одного.
«ты ничего не понимаешь и тебя просто ругали мало, но ничего я исправлю.» — звучит нахально, но это работает. В такой манере можно делать код-ревью. Да, более опытный сотрудник будет совершать акт глумления над кодом менее опытного, тут уж ничего не поделать, в сфере IT сарказм является привилегией опытных. Но ведь это мотивирует догнать его по уровню знаний, перегнать, а потом, при удобном случае, ещё и пиздюлей навалять.
Иначе откуда брать знания? Книги все по рефакторингу не перечитать, за блогами всеми не уследить, все самые свежие 3rd-party-решения в книгах не описаны — а ведь именно это всё помогает работать наиболее продуктивно.
В статье фактически говорится «не нужен рефакторинг» — я сейчас работаю над проектом, где очень много функциональности реализовано, и всё работает, а вот масштабировать его крайне хреново, приходится много и с болью рефакторить. И до этого такие проекты попадались, и на разных работах, и явно не у меня одного.
Да распыляюсь. Свёл все к двум проектам вне работы, программисткий один. На работе просто приходится писать на всём, что горит. Контора маленькая задач много. Разных.
Проблема в том, что это не более опытный сотрудник. В личку объясню почему. А меня ругать нельзя, я над-мотивированный и полезависимый. Поругаешь не по делу я сразу заявление на стол. Просто потому, что буду считать, что раз не справляюсь не вижу смысла дальше работать. Про код ревью,… у меня хороший код. В основном. Бывают исключения. На пред-предыдущей работе, написал дикий код под дикие требования. Собрался зарефакторить, а меня перевели на другой проект. Потом контора распалась на две. В той, в которой остался код, меня потом долго поминали, душевно. Хотя попросили бы объяснил, как просто всё переписать.
Я и не говорю, что не нужен рефакторинг. Лучше сказать пишите код, пока рефакторинг не понадобится. Потом уделите время рефакторингу.
Просто не надо заниматься рефакторингом пять раз на дню и не надо им заниматься пока он реально не нужен. А если занялись то ломитесь вперёд как лось. Полурефакторинг хуже, чем никакого.
Масштабирование по функционалу или производительности?
Проблема в том, что это не более опытный сотрудник. В личку объясню почему. А меня ругать нельзя, я над-мотивированный и полезависимый. Поругаешь не по делу я сразу заявление на стол. Просто потому, что буду считать, что раз не справляюсь не вижу смысла дальше работать. Про код ревью,… у меня хороший код. В основном. Бывают исключения. На пред-предыдущей работе, написал дикий код под дикие требования. Собрался зарефакторить, а меня перевели на другой проект. Потом контора распалась на две. В той, в которой остался код, меня потом долго поминали, душевно. Хотя попросили бы объяснил, как просто всё переписать.
Я и не говорю, что не нужен рефакторинг. Лучше сказать пишите код, пока рефакторинг не понадобится. Потом уделите время рефакторингу.
Просто не надо заниматься рефакторингом пять раз на дню и не надо им заниматься пока он реально не нужен. А если занялись то ломитесь вперёд как лось. Полурефакторинг хуже, чем никакого.
Масштабирование по функционалу или производительности?
«Поругаешь не по делу я сразу заявление на стол» — это очень трудная позиция для восприятия новых знаний, да и вообще очень трудная позиция(для окружающих). Я бы не хотел с вами работать :) Все мы считаем свой код хорошим, насколько это правда может сказать только более опытный и авторитетный коллега, не обязательно сотрудник.
Насчёт «полурефакторинга» не совсем ясно, его просто не бывает. Рефакторинг — процесс итеративный и постоянный, постепенное улучшение качества кода. То есть он != переписыванию всего с нуля и по-новой. И проводить его лучше сразу, ведь не даром существует знаменитая мантра red/green/refactor (и тут), откладывая его *до нужды* можно хорошенько запустить проект. Это как раз описанные выше случаи.
Конечно, многое зависит от культуры сообщества, в модных ruby-python-комьюнити это само собой разумеется и приветствуется. А масштабирование я имел в виду функциональности.
Насчёт «полурефакторинга» не совсем ясно, его просто не бывает. Рефакторинг — процесс итеративный и постоянный, постепенное улучшение качества кода. То есть он != переписыванию всего с нуля и по-новой. И проводить его лучше сразу, ведь не даром существует знаменитая мантра red/green/refactor (и тут), откладывая его *до нужды* можно хорошенько запустить проект. Это как раз описанные выше случаи.
Конечно, многое зависит от культуры сообщества, в модных ruby-python-комьюнити это само собой разумеется и приветствуется. А масштабирование я имел в виду функциональности.
А меня, действительно очень редко ругают. И я это тяжело переживаю (полезависмость — это зависимость от чужого мнения) и стараюсь до такого не доводить. Я сейчас шаманю с мелким проектом надеюсь через неделю две его выложить в исходниках и естественно этим похвастаться. Тогда можно будет и оценить.
Полурефакторинг — это улучшение одного двух модулей и на этом всё, запал кончился, запарка началась. Если вы считает, что такого не бывает мы с вами живем в разных странах. Оно конечно с одной стороны хорошо, с другой бесит неимоверно, когда в одном проекте разные соглашения.
Если нужен рефакторинг для наращивания функциональность, к сожалению им нужно заниматься плотно. Это единый процесс. Нужно решить откуда идти и в каком порядке. Как при этом сохранить текущую функциональность, чтоб не переписывать всё-всё-всё.
К счастью я попадал в ситуацию глобального штурмового рефакторинга один раз. С тех пор сильно не люблю PHP. Просто плохие воспоминания.
Полурефакторинг — это улучшение одного двух модулей и на этом всё, запал кончился, запарка началась. Если вы считает, что такого не бывает мы с вами живем в разных странах. Оно конечно с одной стороны хорошо, с другой бесит неимоверно, когда в одном проекте разные соглашения.
Если нужен рефакторинг для наращивания функциональность, к сожалению им нужно заниматься плотно. Это единый процесс. Нужно решить откуда идти и в каком порядке. Как при этом сохранить текущую функциональность, чтоб не переписывать всё-всё-всё.
К счастью я попадал в ситуацию глобального штурмового рефакторинга один раз. С тех пор сильно не люблю PHP. Просто плохие воспоминания.
хотя когда хвалят приятно, да)
-4, как минимум 4 человека не дочитало статью до конца (по крайней мере предпоследнюю главу) и сразу полезло в комментарии
> У таких программистов отношение к проблеме иное — чем сложнее далось решение, оказавшееся в итоге гораздо эффективнее самого очевидного варианта, тем большее удовольствие от работы они получают.
Согласен. На скорую руку можно писать, когда нужно быстро запустить проект, прям очень быстро. А вообще большинство программистов, опытных и увлеченных самим процессом программирования, относятся к коду как к искусству. И когда их заставляют писать быстро и лишь бы работало, частенько просто увольняются с такой работы :)
Согласен. На скорую руку можно писать, когда нужно быстро запустить проект, прям очень быстро. А вообще большинство программистов, опытных и увлеченных самим процессом программирования, относятся к коду как к искусству. И когда их заставляют писать быстро и лишь бы работало, частенько просто увольняются с такой работы :)
принципы годятся и на другие области, не только программирование:)
я не программист, было интересно примерять описанные подходы на свою работу.
я не программист, было интересно примерять описанные подходы на свою работу.
>в нашем коде меньше ошибок, чем нам кажется
ну да, ну да :)
ну да, ну да :)
есть аксиома тестерская, что в проге всегда есть ошибки, сколько б ее не тестировали и не исправляли:)
вопрос лишь в важности этих оставшихся ошибок.
вопрос лишь в важности этих оставшихся ошибок.
Вам не страшно открывать редактор? ;)
Мне страшно, сразу представляю сколько ошибок я сейчас наделаю. Поэтому предпочитаю говорить себе. что на этот раз ошибок наделаю меньше.
И чтобы вы думали — оно работает. Попробовал методику, если кратко, что написано выше:
— писать большой кусок не обращая на ошибки и не лазая в документацию
— перед компиляцией (писал на давно забытой дельфи) пробежать по коду
— не использовать дебаггер… сразу
Был удивлен — оно сработало.
Была пара мелких багов, быстро выловились. Забыта фича, мгновенно дописалась, как вспомнилась. В доках пришлось посмотреть одну функцию и у одной порядок параметров. Дебагер не ипользовал.
Самое странное, не было ни одной моей «любимой» ошибки — когда я путаю больше и меньше в условиях. Обычно я их пложу пачками.
Мне страшно, сразу представляю сколько ошибок я сейчас наделаю. Поэтому предпочитаю говорить себе. что на этот раз ошибок наделаю меньше.
И чтобы вы думали — оно работает. Попробовал методику, если кратко, что написано выше:
— писать большой кусок не обращая на ошибки и не лазая в документацию
— перед компиляцией (писал на давно забытой дельфи) пробежать по коду
— не использовать дебаггер… сразу
Был удивлен — оно сработало.
Была пара мелких багов, быстро выловились. Забыта фича, мгновенно дописалась, как вспомнилась. В доках пришлось посмотреть одну функцию и у одной порядок параметров. Дебагер не ипользовал.
Самое странное, не было ни одной моей «любимой» ошибки — когда я путаю больше и меньше в условиях. Обычно я их пложу пачками.
> писать большой кусок не обращая на ошибки и не лазая в документацию
При TDD это нормально. При прототипировании (на выброс) тоже.
> не использовать дебаггер… сразу
А лучше — никогда.
Вообще, я понял смысл вашей статьи только после этого комментария. Возможно, следовало озаглавить весь текст вопросом «Вам не страшно открывать редактор?», тогда ЦА была бы ясна и не нарастало бы по мере чтения раздражение от непонимания причин написания статьи. =)
При TDD это нормально. При прототипировании (на выброс) тоже.
> не использовать дебаггер… сразу
А лучше — никогда.
Вообще, я понял смысл вашей статьи только после этого комментария. Возможно, следовало озаглавить весь текст вопросом «Вам не страшно открывать редактор?», тогда ЦА была бы ясна и не нарастало бы по мере чтения раздражение от непонимания причин написания статьи. =)
Не хватает только тезиса что ошибки можно не исправлять, т.к. «минус на минус дает плюс». В реальных проектах реально иногда бывает что реальная ошибка реально исправляется другой реальной ошибкой, извините за реальную тавтологию:) Это да. Но полагаться на это — опасновато.
Нет, здесь другое. Надо переписать статью, то ли я неправильно написал то ли меня неправильно поняли ;)
Я не говорю, что не надо исправлять ошибки. Я говорю, что садясь писать программу, про ошибки надо забыть и не вспоминать их пока не дойдет до отладки/теститирования. То есть работать большими итерациями.
Дальше, не спешить обкладываться дебаг информацией. На времени отладки можно сэкономить если не аытаться ловить ошибки механически.
Я не говорю, что не надо исправлять ошибки. Я говорю, что садясь писать программу, про ошибки надо забыть и не вспоминать их пока не дойдет до отладки/теститирования. То есть работать большими итерациями.
Дальше, не спешить обкладываться дебаг информацией. На времени отладки можно сэкономить если не аытаться ловить ошибки механически.
Можно даже усерднее обобщить содержание, если правильно вас понимаю:
1. Идем от общего к частному.
2. Не отвлекаемся.
Если есть ясные требования, особенно сформулированные в виде тестов, можно писать код абсолютно как попало и знать, что а) ошибки от нас не ускользнут, и б) мы всегда успеем что-то улучшить и предусмотреть, не поломав программу. Но писать тесты к коду гораздо сложнее, чем код к тестам; а писать требования к тестам намного труднее, чем тесты к требованиям. Поэтому надо идти от общего к частному, от требований к реализации, не перепрыгивая через ступеньки. И тогда на душе будет спокойно :)
К слову, TDD освобождает голову тем же методом, что и GTD, Pomodoro, etc.: разделяй и властвуй. Если работа не скомкана в «истерически защитное» программирование со страхом что-то упустить, а разделена на внятные процессы (а-ля: collect stuff, process stuff, organize, do; write specs, write tests, write func stubs, remove *one* xfail mark and write func), всё получается легко и естественно.
1. Идем от общего к частному.
2. Не отвлекаемся.
Если есть ясные требования, особенно сформулированные в виде тестов, можно писать код абсолютно как попало и знать, что а) ошибки от нас не ускользнут, и б) мы всегда успеем что-то улучшить и предусмотреть, не поломав программу. Но писать тесты к коду гораздо сложнее, чем код к тестам; а писать требования к тестам намного труднее, чем тесты к требованиям. Поэтому надо идти от общего к частному, от требований к реализации, не перепрыгивая через ступеньки. И тогда на душе будет спокойно :)
К слову, TDD освобождает голову тем же методом, что и GTD, Pomodoro, etc.: разделяй и властвуй. Если работа не скомкана в «истерически защитное» программирование со страхом что-то упустить, а разделена на внятные процессы (а-ля: collect stuff, process stuff, organize, do; write specs, write tests, write func stubs, remove *one* xfail mark and write func), всё получается легко и естественно.
мне кажется, по этой технологии работают на ВАЗе. сначала собирают что-то похожее на автомобиль, главное ведь собрать, а потом начинают допиливать напильником.
а по сути, мне кажется, с увеличинием опыта работы, каждый изпытывает это на себе. если я в начале перепроверял себя после каждой строчки в ВУЗе, то сейчас, после пары лет работы, начинаю проверку после написания всего класса/функции.
пы.сы.: интересно, существует ли фобия неправильно написанного кода и как она называется? :)
а по сути, мне кажется, с увеличинием опыта работы, каждый изпытывает это на себе. если я в начале перепроверял себя после каждой строчки в ВУЗе, то сейчас, после пары лет работы, начинаю проверку после написания всего класса/функции.
пы.сы.: интересно, существует ли фобия неправильно написанного кода и как она называется? :)
А у меня наоборот. В вузе писал очень большими кусками. Сейчас стал мельчить. Да, задачки сейчас нетривиальные и постоянно приходиться что-то новое изучать пробовать, но надо наступать себе на хвост и ломиться вперёд;)
> пы.сы.: интересно, существует ли фобия неправильно написанного кода и как она называется? :)
наверняка существует. по крайней мере я точно тяжело страдаю тяжелой ее формой. как называется — не знаю и не уверен, что хочу ее лечить
наверняка существует. по крайней мере я точно тяжело страдаю тяжелой ее формой. как называется — не знаю и не уверен, что хочу ее лечить
Идея вобщем здравая, но как и все имеет свои последствия. Если разрабатывать что-то сравнительно большое то детали начинают ускользать сквозь пальцы и потом это легко вылезает в ощутимые проблемы.
Лично я прихожу к выводу, что не зависимо ни от чего ни на какой конкретный подход полагаться вообще нельзя, к сожалению. Всегда надо сидеть и соображать головой, иначе будет лажа. Будь то обвешивание всего ассертами или откладывание дебага и тестов на потом, или еще чего угодно. Имхо.
Лично я прихожу к выводу, что не зависимо ни от чего ни на какой конкретный подход полагаться вообще нельзя, к сожалению. Всегда надо сидеть и соображать головой, иначе будет лажа. Будь то обвешивание всего ассертами или откладывание дебага и тестов на потом, или еще чего угодно. Имхо.
имхо, достаточно в комментариях по ходу написания кода как попало обозначать возможные ошибки, а потом уже превращать эти комменты в новые тесты к коду и уже под тесты подгонять код в следующих итерациях. возможно, заодно куча подобных ошибок найдется, когда голова свободна от реализации конкретной функциональности.
Тема знакома, вспоминая с каким энтузиазмом не за деньги я програмил 8 лет назад, и с каким за деньги сейчас. Щас уже другие масштабы программирования, ты делаешь уже другой объем задач, ты это делаешь за деньги и ты ответственен за тот код который пишешь. Раньше, кстати я именно так и программировал, как автор, тупо в лоб кучу кода. Сейчас же всё изменилось.
Тут возникает одна дилемма:
1) либо програмить как пишет автор, не проверяя ошибок, но есть опасность забыть то место, например где ты исправлял, пробегаясь по коду, а потом потратить больше времени на поиск ошибок. Вообщем то, что предлагает автор идеально для написания кода с нуля. А вот когда ты вносишь коррективы сразу в кучу файлов, в разные места (ну к примеру 10 файлов), есть вероятность того, что ты забудешь из за чего у тебя в коде сыр-бор и где ты опечатался в одной переменной. Такой подход конечно быстрее, но на деле — ты можешь потратить больше времени на исправлении/переписывании логики, переменных и тд.
2) програмить, проверяя каждый блок. Такой способ аналогичен фразе «тише едешь дальше будешь». Вообщем он не идеален, если у вас горят сроки, зато вероятность что вы совершите ошибку — минимальная.
Я думаю что нет идеального способа. Каждый конкретный способ решения задач правильный для конкретного случая, раз на раз не приходится. Иногда и быдлокодить приходится, когда «красивость» не так важна, например для написания парсеров.
Несколько примеров из моей жизни:
У меня был случай, когда мне довелось програмить игру Зодор (типа Ночного Дозора) я писал движок в режиме онлайн, люди выполняли текущее задание, а я програмил следующее :) у нас была виртуальная гонка, мало того я был еще оператором, которому звонили или писали в icq некоторые команды и просили проверить найденный код и выдать след. задание (не у всех был инет с ноутом). Кстати в той игре, всё прошло гладко, за исключением одной маленькой ошибки, из-за которой мой скрипт в конце не засчитывал одной команде код, я так и не смог этот момент отладить, слишком много было написано, и пришлось статистику вручную корректировать и распечатывать, на меня тогда немного обозлились. А представьте я накосячу в игре Encounter, скандал на всю страну бы был.
Был и другой случай, когда мне нужно было составить 250 договоров за ночь и привезти их к утру в другой город. Каждый договор подшивался вручную, опечатывался пломбой, ставилась печать, подпись, у нас был целый конвейер, делали мы это в троём, то есть ошибок допускать было нельзя. Прежде чем печатать все 250 договоров, я печатал образцы, каждый договор был около 10 страниц, мы пробегались быстренько глазами, если всё ок я продолжал печатать остальные уже не проверяя. Хорошо что мой брат взял меня с собой, так как когда мы приехали в город выяснилось, что половина договоров оказалась не правильные, ошибка срабатывала на некоторые реквизиты. И это всё из-за одной моей маленькой ошибки, пришлось всё переписывать на месте уже не за ночь, а за 2 часа, так как время поджимало, договора надо было сдавать, я програмил прям в каком-то гос. учреждении где эти же договора и принимали (знаете забавно сидеть как попугаю, на которого все пялятся, нужно так от всех абстрагироваться, как будто ты тут один). Мы там даже принтер где-то нарыли, в городе Чкаловск в выходной день его достать было практически невозможно. Мне тогда было очень обидно, но опыт был получен бесценный, к счастью все договора в итоге приняли. Такие дела.
Тут возникает одна дилемма:
1) либо програмить как пишет автор, не проверяя ошибок, но есть опасность забыть то место, например где ты исправлял, пробегаясь по коду, а потом потратить больше времени на поиск ошибок. Вообщем то, что предлагает автор идеально для написания кода с нуля. А вот когда ты вносишь коррективы сразу в кучу файлов, в разные места (ну к примеру 10 файлов), есть вероятность того, что ты забудешь из за чего у тебя в коде сыр-бор и где ты опечатался в одной переменной. Такой подход конечно быстрее, но на деле — ты можешь потратить больше времени на исправлении/переписывании логики, переменных и тд.
2) програмить, проверяя каждый блок. Такой способ аналогичен фразе «тише едешь дальше будешь». Вообщем он не идеален, если у вас горят сроки, зато вероятность что вы совершите ошибку — минимальная.
Я думаю что нет идеального способа. Каждый конкретный способ решения задач правильный для конкретного случая, раз на раз не приходится. Иногда и быдлокодить приходится, когда «красивость» не так важна, например для написания парсеров.
Несколько примеров из моей жизни:
У меня был случай, когда мне довелось програмить игру Зодор (типа Ночного Дозора) я писал движок в режиме онлайн, люди выполняли текущее задание, а я програмил следующее :) у нас была виртуальная гонка, мало того я был еще оператором, которому звонили или писали в icq некоторые команды и просили проверить найденный код и выдать след. задание (не у всех был инет с ноутом). Кстати в той игре, всё прошло гладко, за исключением одной маленькой ошибки, из-за которой мой скрипт в конце не засчитывал одной команде код, я так и не смог этот момент отладить, слишком много было написано, и пришлось статистику вручную корректировать и распечатывать, на меня тогда немного обозлились. А представьте я накосячу в игре Encounter, скандал на всю страну бы был.
Был и другой случай, когда мне нужно было составить 250 договоров за ночь и привезти их к утру в другой город. Каждый договор подшивался вручную, опечатывался пломбой, ставилась печать, подпись, у нас был целый конвейер, делали мы это в троём, то есть ошибок допускать было нельзя. Прежде чем печатать все 250 договоров, я печатал образцы, каждый договор был около 10 страниц, мы пробегались быстренько глазами, если всё ок я продолжал печатать остальные уже не проверяя. Хорошо что мой брат взял меня с собой, так как когда мы приехали в город выяснилось, что половина договоров оказалась не правильные, ошибка срабатывала на некоторые реквизиты. И это всё из-за одной моей маленькой ошибки, пришлось всё переписывать на месте уже не за ночь, а за 2 часа, так как время поджимало, договора надо было сдавать, я програмил прям в каком-то гос. учреждении где эти же договора и принимали (знаете забавно сидеть как попугаю, на которого все пялятся, нужно так от всех абстрагироваться, как будто ты тут один). Мы там даже принтер где-то нарыли, в городе Чкаловск в выходной день его достать было практически невозможно. Мне тогда было очень обидно, но опыт был получен бесценный, к счастью все договора в итоге приняли. Такие дела.
Нет, к сожалению, для исправления ошибок — метод не применим. Одна ошибка — одна итерация. Да, возможно большая. Но исправлять пачку несвязанных ошибок я не рискну.
С дилеммой согласен. Но считаю, что код написать пока пишется, до упора. Вот как запал прошёл, можно заняться сборкой/тестирование/отладкой. Всё равно эксперимента показывали, что больше полутора часов кодирования мне в одну итерацию не удавалось уложить.
А было код иногда надо заставлять себя писать — если нужно сделать что-то одноразовое или быстрый макет, можно пожертвовать изящностью. Если оно окажется неодноразовым, моно будет переписать или облагородить.
Ну ночные работы на флажке каждый программист может припомнить, главное, чтобы как у вас всё кончалось хорошо и код был востребованным. Обиднее когда выкладываешься в последнюю секунду, а тебе говорят: «Молодец, правда инвестор сегодня приехать не сможет. Но ты всё равно молодец».
С дилеммой согласен. Но считаю, что код написать пока пишется, до упора. Вот как запал прошёл, можно заняться сборкой/тестирование/отладкой. Всё равно эксперимента показывали, что больше полутора часов кодирования мне в одну итерацию не удавалось уложить.
А было код иногда надо заставлять себя писать — если нужно сделать что-то одноразовое или быстрый макет, можно пожертвовать изящностью. Если оно окажется неодноразовым, моно будет переписать или облагородить.
Ну ночные работы на флажке каждый программист может припомнить, главное, чтобы как у вас всё кончалось хорошо и код был востребованным. Обиднее когда выкладываешься в последнюю секунду, а тебе говорят: «Молодец, правда инвестор сегодня приехать не сможет. Но ты всё равно молодец».
Я перестал бояться совершать ошибки в коде с тех пор как стал активно использовать TDD. Потом долго боялся совершить ошибку в тестах. Потом понял, что вероятность допустить ошибку и в тесте, и в коде очень мала, если не разделять по времени написание теста и кода, чтобы не писать код на основании теста, а писать его под действием образа о том, что я имел в виду когда писал тест. А так как юнит-тесты довольно малы, как и код их реализующий, то локализация ошибки элементарна. Да и по сфейлившему ассерту сразу видно где ошибку допустил (actual 10, expected 11 — если имел в виду, что 10 должно быть, значит в тесте, если что 11, то значит в коде). Так что что такое дебаггер почти забыл.
Но основная цель создания тестов не контроль кода в смысле нахождение и локализации ошибок, а поддержание гибкой и расширяемой архитектуры, чёткой локализации ответственностей и документирование их. В принципе тоже контроль, но более высокого порядка. В принципе тоже из-за страха, но немного другого — страха в будущих изменениях что-то упустить и нечаянно меняя одно не сломать другое. Причём сломать так, что ошибка и не сразу выплывет, и локализовать её будет затруднительно — половинным делением с наскоку не обойдешься, если код функциональности размазан по всему приложению. Тесты «заставляют» её не размазывать и поддерживают уверенность в отсутствии таких ошибок. Да, можно всё это делать и без них, в конце-концов код от тестов не зависит, но с тестами проще.
Но основная цель создания тестов не контроль кода в смысле нахождение и локализации ошибок, а поддержание гибкой и расширяемой архитектуры, чёткой локализации ответственностей и документирование их. В принципе тоже контроль, но более высокого порядка. В принципе тоже из-за страха, но немного другого — страха в будущих изменениях что-то упустить и нечаянно меняя одно не сломать другое. Причём сломать так, что ошибка и не сразу выплывет, и локализовать её будет затруднительно — половинным делением с наскоку не обойдешься, если код функциональности размазан по всему приложению. Тесты «заставляют» её не размазывать и поддерживают уверенность в отсутствии таких ошибок. Да, можно всё это делать и без них, в конце-концов код от тестов не зависит, но с тестами проще.
С двоичным делением, возможно, погорячился. На самом деле — у меня таких мест в коде код наплакал, но они есть, куда деваться. Не все можно, а главное нужно оборачивать в функции/методы.
Как правило стараюсь в таких местах писать «плавно» с короткими ветвлениями кода.
С отладкой же часто ловил себя на мысли, что в 80% случаях ошибку ловлю чуть выше места, где поставил «баголовку». Стал заставлять себя делать небольшое ревью вверх от места куда руки тянуться забить дебаг вывод. Оказалась нехилая экономия.
Как правило стараюсь в таких местах писать «плавно» с короткими ветвлениями кода.
С отладкой же часто ловил себя на мысли, что в 80% случаях ошибку ловлю чуть выше места, где поставил «баголовку». Стал заставлять себя делать небольшое ревью вверх от места куда руки тянуться забить дебаг вывод. Оказалась нехилая экономия.
В последнее время всё больше ембеддерством занимаюсь (ARM Cortex-M3, AVR), так там методы с использованием тестов пригождаются как нельзя лучше, т.к. найти баг обычно заметно сложнее, чем при разработке для PC: код запускается на целевом устройстве, а отлаживается через плату-отладчик (JTAG или SWD) на хосте через режим target remote в GDB. Вдобавок, если выполнение кода поставлено на паузу, это ещё не значит, что кристалл совсем ничего не делает — в нём может работать периферия (интерфейсные модули, таймеры, контроллер DMA), которая может менять содержание памяти и регистров независимо от основного кода, напрямую. Короче, здесь ковыряние в отладчике — удовольствие ниже среднего, и гораздо эффективнее писать тесты и расставлять ассерты по всему коду, иначе можно потратить полдня на поиск гейзенбага.
Прошу прощения, но какое отношения статья имеет к GTD? Есть блоги типа «разработка». Всё-таки разработка ПО в статье первична, а сама методология GTD в ней не упоминается вообще. Есть же тут не программисты, которые бы хотели видеть в блоге «GTD» статьи если уж не о самой GTD, то от общей продуктивности, тайм-менеджементе и чём-то близком, но не о продуктивности программиста, не имеющей к непрограммистам никакого отношения.
Программирую больше 3 лет один проект на делфи, иногда что-то переделываю. И вот мои наблюдения:
Полностью согласен, что чтобы не впасть в депрессию от выбора худшего зла (так как времени дается ограниченное количество), нужно начать писать код и возможно (как было как раз вчера), дойдя до нужного места, мысли придут сами собой.
А также лишние проверки работоспособности кода способны потратить чуть ли не 2 часа в день… А это четверть нормального рабочего дня. Но если их совместить в одну, то она выйдет гораздо короче, за пол часа все можно проверить и исправить.
И самое интересное, что когда на тебя давят и нужно сделать быстрее, то даже как-то не обдумывая начинаешь писать не проверяя. Быстро, по плану делать все доработки ничего не проверяя. А только потом в конце проверяешь и исправляешь синтаксис и другие мелкие ошибки.
Также недавно подумал: «надо быстрее написать, так что длинные переменные не для нас». Лучше я в декларации переменной добавлю комментарий, что она значит, а называться она везде будет CTL, а не CreateToolsLoaderObject. Благо в Delphi можно с контролом кликнуть по переменной (функции и т.п.) и посмотреть на ее объявление и быстро вернуться через ALT+Left.
В общем я за то, чтобы спланировать структуру ПО (функции, модуля), а дальше писать, запуская на проверку очень редко.
Полностью согласен, что чтобы не впасть в депрессию от выбора худшего зла (так как времени дается ограниченное количество), нужно начать писать код и возможно (как было как раз вчера), дойдя до нужного места, мысли придут сами собой.
А также лишние проверки работоспособности кода способны потратить чуть ли не 2 часа в день… А это четверть нормального рабочего дня. Но если их совместить в одну, то она выйдет гораздо короче, за пол часа все можно проверить и исправить.
И самое интересное, что когда на тебя давят и нужно сделать быстрее, то даже как-то не обдумывая начинаешь писать не проверяя. Быстро, по плану делать все доработки ничего не проверяя. А только потом в конце проверяешь и исправляешь синтаксис и другие мелкие ошибки.
Также недавно подумал: «надо быстрее написать, так что длинные переменные не для нас». Лучше я в декларации переменной добавлю комментарий, что она значит, а называться она везде будет CTL, а не CreateToolsLoaderObject. Благо в Delphi можно с контролом кликнуть по переменной (функции и т.п.) и посмотреть на ее объявление и быстро вернуться через ALT+Left.
В общем я за то, чтобы спланировать структуру ПО (функции, модуля), а дальше писать, запуская на проверку очень редко.
А вот с длинными переменными проблема решается с помощью тенинга набора и автокомплита. У меня память короткая. Я же завтра буду думать, что это флаг нажатия Ctrl.
На этом больше сэкономишь, чем потеряешь, другое дело, что CreateToolsLoaderObject — плохое название. ToolsLoader — лучше. Или LoaderObject. В зависимости от контекста — обычно двух слов хватает.
На этом больше сэкономишь, чем потеряешь, другое дело, что CreateToolsLoaderObject — плохое название. ToolsLoader — лучше. Или LoaderObject. В зависимости от контекста — обычно двух слов хватает.
Автокомплит несомненно необходимая вещь и без него сложнее намного, но в данном случае три буквы, точка, имя метода гораздо быстрее набирается нежели с использованием автокомплита и длинных названий. (и насколько бы человек тренирован не был, он все равно быстрее наберет короткое слово, чем более длинное, хоть и не целиком).
Завтра не забудешь, т.к. есть комментарий в объявлении переменной.
А если там лоадеры для нескольких тулов есть, то двух слов как бы недостаточно получается.
Минус только если ты в команде работаешь над данным модулем, т.к. разобрать код полностью состоящий из сокращений сложнее.
Завтра не забудешь, т.к. есть комментарий в объявлении переменной.
А если там лоадеры для нескольких тулов есть, то двух слов как бы недостаточно получается.
Минус только если ты в команде работаешь над данным модулем, т.к. разобрать код полностью состоящий из сокращений сложнее.
Да, в команде сложнее.
Плюс я не люблю мотаться по коду туда сюда, ради чтения комментария. У меня есть определенные соглашения на использование имен переменных для частных операций.
Как и стандарные: переменные цикла i,j,k,m (l — не люблю использовать — спутаешь с единицей — вот радости будет), s,str — «временные» строковые, tmp — для обмена.
Так и «свои» например result — для возврата (пошло кстати с дельфи), rec, — для записи БД или курсора, cur — для «текущей» рабочей переменной. А для нестандартных переменных — таки придумываю имена.
Кстати, лучше использовать сокращения, чем аббревиатуры например ctObj и т.д. Буквы экономятся, а контекст остаётся «читаемым».
Плюс я не люблю мотаться по коду туда сюда, ради чтения комментария. У меня есть определенные соглашения на использование имен переменных для частных операций.
Как и стандарные: переменные цикла i,j,k,m (l — не люблю использовать — спутаешь с единицей — вот радости будет), s,str — «временные» строковые, tmp — для обмена.
Так и «свои» например result — для возврата (пошло кстати с дельфи), rec, — для записи БД или курсора, cur — для «текущей» рабочей переменной. А для нестандартных переменных — таки придумываю имена.
Кстати, лучше использовать сокращения, чем аббревиатуры например ctObj и т.д. Буквы экономятся, а контекст остаётся «читаемым».
А также лишние проверки работоспособности кода способны потратить чуть ли не 2 часа в день…Автоматизировать их, не?
Автоматизировать проверку работы инструмента смещения вершины в 3D-редакторе, в котором нет возможности на данном этапе загрузить готовую сцену. Как?
Некоторые автоматизации я делал, например я сделал для себя давно прогу, которая рисует объекты, получая данные при дебаге в делфи программы. Наводишь курсор на переменную-массив точек и появляется хинт со значением переменной. Прога это перехватывает, забирает и рисует. Далее ты можешь навести на следующий и он тоже дорисуется и так далее. В общем графический такой дебаг переменных-полигонов.
Но не везде все можно автоматизировать, особенно проверку работы какого-то инструмента, который включается после загрузки ПО, создания сцены и т.п. Конечно можно свести к минимуму работу по кликам при проверке, но на это тоже надо тратить время и это рационально только тогда, когда уверен, что эту часть будешь еще долго отлаживать и дописывать.
Некоторые автоматизации я делал, например я сделал для себя давно прогу, которая рисует объекты, получая данные при дебаге в делфи программы. Наводишь курсор на переменную-массив точек и появляется хинт со значением переменной. Прога это перехватывает, забирает и рисует. Далее ты можешь навести на следующий и он тоже дорисуется и так далее. В общем графический такой дебаг переменных-полигонов.
Но не везде все можно автоматизировать, особенно проверку работы какого-то инструмента, который включается после загрузки ПО, создания сцены и т.п. Конечно можно свести к минимуму работу по кликам при проверке, но на это тоже надо тратить время и это рационально только тогда, когда уверен, что эту часть будешь еще долго отлаживать и дописывать.
Подсунуть инструменту фейковую сцену и фейковый пользовательский ввод? Честно говоря, я почти ничего не понял начиная со слова «смещения», потому конкретных методов предложить не могу. Но, например, я тестирую приложение по работе с БД без обращений к ней и даже не имея на дев-машине СУБД (к удаленной тоже не подключается). Конечно, потом тестирую и в реальном окружении ручками, но это редко, после завершения большого этапа. А так запускаю тесты десятки раз в день, если не сотню, но времени уходит немного на них.
Я конечно понимаю, что вы смогли расписать мои слова "свести к минимуму работу по кликам при проверке, но на это тоже надо тратить время и это рационально только тогда...", используя другие слова и модное слово «фейк». Но я уже написал, что это бывает очень не рационально.
Не понятны слова «3D-редактор» или «вершина»?
Объясню для вас подробнее:
допустим я на этот инструмент трачу один рабочий день вместе с отладками. Подготовить фэйковую сцену, сделать его автоматическую подгрузку и т.п. до самого этого инструмента займет около 2 рабочих дней. Это не нужно совсем, когда я на следующий день буду работать с совсем другой частью программы и мне не нужно будет грузить эту сцену вообще? Платят тут за скорость и результат, а не за идею правильно кодить. Так что расчитываю я для себя, нужна ли мне эта оптимизация в будущем или нет или когда потребуется тогда и напишу.
Не понятны слова «3D-редактор» или «вершина»?
Объясню для вас подробнее:
допустим я на этот инструмент трачу один рабочий день вместе с отладками. Подготовить фэйковую сцену, сделать его автоматическую подгрузку и т.п. до самого этого инструмента займет около 2 рабочих дней. Это не нужно совсем, когда я на следующий день буду работать с совсем другой частью программы и мне не нужно будет грузить эту сцену вообще? Платят тут за скорость и результат, а не за идею правильно кодить. Так что расчитываю я для себя, нужна ли мне эта оптимизация в будущем или нет или когда потребуется тогда и напишу.
«Загрузка готовой сцены» непонятна прежде всего из предметной области. «Проверка инструмента» из требований тоже, но уже непонятен необходимый уровень проверки. Что подаётся на вход проверки и что должно быть на выходе. Если на входе надо эмулировать перемещения мыши на уровне ОС это одна трудоемкость, Если достаточно вызвать из теста что-то вроде scene.getNodes(current_node).move(from_point, to_point), то другая. То же с выходом. Если нужно проверять действительно ли ОС вывела точку на экран, это одна, если достаточно проверить, что у узла изменились координаты, то другая.
При активном использовании автоматизированного тестирования с самого начала разработки обычно нет необходимости проверять всю систему, так как многие подсистемы уже проверены. В данном случае вполне может оказаться достаточной проверка изменения состояния сцены после вызова метода. Механизм трансляции действий пользователя (а точнее сообщений/событий ОС) в вызов методов модели уже оттестирован, равно как и механизм трансляции изменения модели в вывод на экран (а точнее в вызов API ОС).
При активном использовании автоматизированного тестирования с самого начала разработки обычно нет необходимости проверять всю систему, так как многие подсистемы уже проверены. В данном случае вполне может оказаться достаточной проверка изменения состояния сцены после вызова метода. Механизм трансляции действий пользователя (а точнее сообщений/событий ОС) в вызов методов модели уже оттестирован, равно как и механизм трансляции изменения модели в вывод на экран (а точнее в вызов API ОС).
Я думаю «сцена в 3D-редакторе» и «Инструмент в 3D-редакторе» является очень даже понятным большинству. Вот уровень проверки действительно может быть непонятен. Проверка включается в себя: включение инструмента (установка его текущим со всем выполняемыми проверками объектов сцены при включении), смена режимов работы инструмента (например, выбор вершины полигона, перетаскивание вершины, выбор нескольких вершин), изменение данных самого объекта сцены при выполнении работы инструмента, зависимость работы от типа выбранных объектов.
Я не спорю, что можно написать автоматизированную систему проверки и это ускорит в дальнейшем все тестирования и проверку правильности результатов. Но есть одно но: на это нужно потратить не мало времени, а его не выделяют под эти задачи и плюс ко всему вопрос в количестве рабочей силы.
Еще добавлю, что проект очень большой уже, а программиста всего 1.5.
Дальнейшее обсуждение вопроса тестирования проекта будет лишь холиваром (причем Вашим с планами моего начальства).
Я не спорю, что можно написать автоматизированную систему проверки и это ускорит в дальнейшем все тестирования и проверку правильности результатов. Но есть одно но: на это нужно потратить не мало времени, а его не выделяют под эти задачи и плюс ко всему вопрос в количестве рабочей силы.
Еще добавлю, что проект очень большой уже, а программиста всего 1.5.
Дальнейшее обсуждение вопроса тестирования проекта будет лишь холиваром (причем Вашим с планами моего начальства).
В последнее время, проанализировав свою работу, проблемы с мотивацией и т.п., понял одну простую вещь: спецификации писать надо. Тогда и ошибок будет намного меньше, и стоить их исправление будет дешевле, и мотивация не будет теряться из-за отсутствия видимого результата, т.к. будет виден прогресс по выполненным пунктам спеки.
Это да. В институте предчувствуя приход «полярного куся», выписывал порядок действий по изучению, написанию и сдачи хвостов. И этот магический листочек со спеками — оченно выручал. Поэтому из института меня выгоняли всего два раза;)
А в качестве спецификаций могут выступать тесты :) Извините, не удержался.
+1
Не согласен. (В этом месте сторонники TDD ставят мне минусы.) Вы так или иначе будете тестировать конкретную реализацию или конкретный интерфейс (что в коде, что в UI). А, значит, стадия проектирования никуда не девается. И как вы себе представляете проектирование в тестах?
В тестах я формализую неформализованные требования к методу, классу, подсистеме, системе в целом. Описываю что подаётся на вход и что должно быть на выходе. Проектированием занимаюсь при декомпозиции приёмочных/функциональных тестов на модульные и интеграционные.
Наверное, если сильно извратиться, то можно заменить спеку тестами. Только вот как потом с этим работать стороннему разработчику? Или даже банальнее — команде?
Да и не все протестировать возможно.
Да и не все протестировать возможно.
Почему извратиться? Просто пишете спеку не по-русски/английски, а на некоем DSL, который прочитать может даже не айтишник. А если у него есть хоть малейшая способность к индукции, то и написать многие кейсы по образцу. Для некоторых инструментов тестирования этот DSL даже является подмножеством естественного языка, без использования спецсимволов например, просто словарь и грамматика меньше и сильнее формализованы.
А как работать стороннему разработчику, если в разработке используется, например, система контроля версия, фреймворки какие-то, библиотеки? Или привлекают разработчиков уже знакомых с этими инструментами, или дают им время на освоение.
Вы же не пишете в спеке «подаём на вход то-то, неизвестно что получаем»? Если есть спецификация, то есть и способ проверки соответствия системы её требованиям. Проверять можно ручками, а можно автоматизировать этот процесс. Даже в тестировании приложения, непосредственно работающего с железом, можно свести ручную проверку к минимуму. Например, приложение в каких-то ситуациях должно зажигать лампочку, а в каких-то гасить. Вроде проверить нельзя автоматически, если не ставить фотодатчик, изолированный от других воздействий на время тестирования (хотя тоже вариант). Но можно написать один-два метода или функции вроде switchLampOn()/switchLampOff() или switchLamp(boolean), проверить его ручками (и глазками), а потом лишь проверять автоматически вызывается он или нет в нужных ситуациях.
А как работать стороннему разработчику, если в разработке используется, например, система контроля версия, фреймворки какие-то, библиотеки? Или привлекают разработчиков уже знакомых с этими инструментами, или дают им время на освоение.
Вы же не пишете в спеке «подаём на вход то-то, неизвестно что получаем»? Если есть спецификация, то есть и способ проверки соответствия системы её требованиям. Проверять можно ручками, а можно автоматизировать этот процесс. Даже в тестировании приложения, непосредственно работающего с железом, можно свести ручную проверку к минимуму. Например, приложение в каких-то ситуациях должно зажигать лампочку, а в каких-то гасить. Вроде проверить нельзя автоматически, если не ставить фотодатчик, изолированный от других воздействий на время тестирования (хотя тоже вариант). Но можно написать один-два метода или функции вроде switchLampOn()/switchLampOff() или switchLamp(boolean), проверить его ручками (и глазками), а потом лишь проверять автоматически вызывается он или нет в нужных ситуациях.
Возможно вы и правы. Лично я не верю, что тесты понятнее спеки и лучше помогают в написании кода по ним. Но у меня опыта в TDD — ноль, а все видимые мною тексты на эту тему, к сожалению, описывают проекты уровня hello world'a, а не чего-то адекватного.
Понятнее вряд ли. DSL всё таки не естественный язык: с одной стороны «мусора» больше, с другой — гибкость и выразительных средств меньше. То есть читаться читается и что хотели сказать в принципе понятно, но выглядит как речь человека, который недавно начал изучать иностранный язык и пытается на нём общаться, имея под рукой словарик небольшой и пару-тройку правил грамматики выучил.
А помогают больше. Проверить соответствие кода такой спеке можно одним хоткеем в современных IDE. Особенно заметны преимущества на интерпретируемых языках или языках/в IDE с хорошей поддержкой инкрементального компилирования, когда буквально каждую строчку можно практически моментально проверять.
А помогают больше. Проверить соответствие кода такой спеке можно одним хоткеем в современных IDE. Особенно заметны преимущества на интерпретируемых языках или языках/в IDE с хорошей поддержкой инкрементального компилирования, когда буквально каждую строчку можно практически моментально проверять.
(offtopic)
ИМХО Суворов писал не об отказе от контроля, а о получении удовольствия от риска.
(/offtopic)
ИМХО Суворов писал не об отказе от контроля, а о получении удовольствия от риска.
(/offtopic)
Создалось впечатление, что написание тестов позволило бы избежать множества проблем, описаных в статье.
ИМХО, Ваш принцип необходимо применять только вкупе с принципом «разделяй и властвуй». Т.е. для небольших участков кода. Написал законченный участок — пробежал код глазками на предмет ошибок. А для более крупного кода необходимо сразу проводить декомпозицию на такие мелкие участки, накидывать план. На этом уровне действительно не нужно думать над ошибками кодирования — на нем нужно думать над ошибками логики в целом.
Ну, и так далее. На каждом уровне — своя детализация и упор на разные типы ошибок. И, тем не менее, принцип маленьких, обозримых блоков, очень хорошо работает. С одной стороны — красивый и структурированный дизайн, с другой — не менее красивый и корректный код. Иногда некорректный — но процент подобных ошибок падает с опытом. Просто на автомате учитываешь разные варианты входных данных, не задумываясь.
Ну, и так далее. На каждом уровне — своя детализация и упор на разные типы ошибок. И, тем не менее, принцип маленьких, обозримых блоков, очень хорошо работает. С одной стороны — красивый и структурированный дизайн, с другой — не менее красивый и корректный код. Иногда некорректный — но процент подобных ошибок падает с опытом. Просто на автомате учитываешь разные варианты входных данных, не задумываясь.
Спасибо, тов. Автор. :) Пост длиннющий, но читается на одном дыхании и с удовольствием. Сразу видно, что Вам самому он нравится.
Еще и содержание позволяет взять что-то новое для себя.
В общем… Только спасибо могу сказать.
Еще и содержание позволяет взять что-то новое для себя.
В общем… Только спасибо могу сказать.
> Баги и переписывания всё равно будут. Но лучше разделить кодирование и отладку и на время кодирования об ошибках вообще забыть.
проблема: заказчик может быть несогласен. Он может с помощью экспертов вычитать код (или изменения в коде для поддержки legacy) и натыкать носом в «непрофессионализм», после чего послать в пешее эротическое путешествие.
Или вот совсем жесть: один из заказчиков требовал с нас гарантированное исправление бага, т.е. если баг помечен как «закрыт» («отправлен на тестирование», «wontfix» итп), то любые его переоткрытия и переисправления делаются уже за наши деньги (и делать мы их будем, потому что в условиях контракта заявлены критерии качества финального продукта).
проблема: заказчик может быть несогласен. Он может с помощью экспертов вычитать код (или изменения в коде для поддержки legacy) и натыкать носом в «непрофессионализм», после чего послать в пешее эротическое путешествие.
Или вот совсем жесть: один из заказчиков требовал с нас гарантированное исправление бага, т.е. если баг помечен как «закрыт» («отправлен на тестирование», «wontfix» итп), то любые его переоткрытия и переисправления делаются уже за наши деньги (и делать мы их будем, потому что в условиях контракта заявлены критерии качества финального продукта).
Тут моя ошибка — я не написал, что большой кусок кода — это работа по времени от получаса до нескольких часов. Потом небольшой период на холодное ревью и большой период на отладку.
Коммитить неотлаженный код — нельзя. Потому что нельзя никогда, разве что в бранч.
Идея в том, чтобы не перебивать рабочий порыв мелкими итерациями — кусок кода, запуск, отладка, где кусок кода — 5-10 строк. Лучше закончить сразу функциональный блок на одном дыхании. А потом его быстро вылизать.
Я стал мельчить из-за опасений. Что могу ошибаться и потом долго отлаживать большой кусок. Но попробовав работать простынями выяснил, что код получается более стабильный.
Коммитить неотлаженный код — нельзя. Потому что нельзя никогда, разве что в бранч.
Идея в том, чтобы не перебивать рабочий порыв мелкими итерациями — кусок кода, запуск, отладка, где кусок кода — 5-10 строк. Лучше закончить сразу функциональный блок на одном дыхании. А потом его быстро вылизать.
Я стал мельчить из-за опасений. Что могу ошибаться и потом долго отлаживать большой кусок. Но попробовав работать простынями выяснил, что код получается более стабильный.
Если требуется отладка, большая чем исправление опечаток, на кусок 5-10 строк, то разве не увеличится пропорционально время на отладку куска в 50-100-1000 строк? При том, что за несколько часов вполне можно выйти из контекста первых 5-10 строк и при ревью уже не заметить каких-то локальных логических ошибок, типа
a[i][j] = 0 вместо a[j][i] = 0, и долго отлаживать код ниже, вместо того чтобы быстро его отладить сразу после написания?Даже если и увеличится — это нестрашно. Код написанный одним куском потребует меньше времени, чем код написанный с «перекурами» на проверку. А время общей отладки будет в большинстве случаев меньше времени на отладку иттерационную.
При использовании ассертов — вообще сильно меньше. Но с ассертами — проблема в том, насколько они привычны программисту. Если написание вживлено на подкорку и пишуться на автомате — это одно. Если тормозят полет мысли — лучше ассерты бить во время ревью. Опять же при это код переосмыслится ещё раз, что не лишне.
Сам я ассерты в том или ином виде использую только в критически важных местах кода. Но это не суть методики — а мои привычки при самостоятельной работе.
При работе в команде, естественно, пишу «как здесь принято». И в конце дня стараюсь сделать ревью написанного за день, а то люблю костыль вбить или идиому новую попробовать. А проблема костыля не в том, что он костыль — системы подпорок и соплей порой успешно живут долгие годы, а в том, что либо он оторван от кода и коллегам не понятно, что это за фигня такая. Либо, что ещё хуже, когда коллегам не понятно, что это костыль. Соберешься потом его прибить, а там из костыля уже цельный емпайр-стейт-билдинг вырос.
При использовании ассертов — вообще сильно меньше. Но с ассертами — проблема в том, насколько они привычны программисту. Если написание вживлено на подкорку и пишуться на автомате — это одно. Если тормозят полет мысли — лучше ассерты бить во время ревью. Опять же при это код переосмыслится ещё раз, что не лишне.
Сам я ассерты в том или ином виде использую только в критически важных местах кода. Но это не суть методики — а мои привычки при самостоятельной работе.
При работе в команде, естественно, пишу «как здесь принято». И в конце дня стараюсь сделать ревью написанного за день, а то люблю костыль вбить или идиому новую попробовать. А проблема костыля не в том, что он костыль — системы подпорок и соплей порой успешно живут долгие годы, а в том, что либо он оторван от кода и коллегам не понятно, что это за фигня такая. Либо, что ещё хуже, когда коллегам не понятно, что это костыль. Соберешься потом его прибить, а там из костыля уже цельный емпайр-стейт-билдинг вырос.
Если писать код, а потом думать как его проверить или проверять ручками, то, да, несомненно больше. Но вот если сначала подумать как его можно проверить автоматически, сформулировать простой способ проверки (или разбить сложный на несколько простых), то собственно проверка будет практически моментальной, а локализация неуспешной будет тривиальна.
Ключевая фраза «проверка должна быть простая», следствие — проверяемый код тоже получается простым, 5-10 строк. В чём-то подход совпадает с вашим. Есть задача, как её полностью просто проверить не ясно, не то что как её решить. Ну и ладно. Выделяем какую-то подзадачу, которую понимаем как просто проверить и решить. Или подподподзадачу. Формулируем проверку (пишем тест): что на входе, что на выходе, какие побочные действия. Проверяем. Фейл, ведь код мы ещё не написали. Пишем код, он получается небольшой и простой, ведь проверка простая. О всяких «а вдруг придётся изменить логику», «вдруг это будет медленно», «что с результатом делать дальше» не думаем. Проверяем. Если нет — дебажим, это просто, код небольшой, сложной логической ошибки сделать не могли. Если всё ок решаем так же следующую «братскую» подподподзадачу (тест, код, возможно простейший дебаг). Проводим мини-ревью этих подподподзадач, видим общий или даже похожий код — выносим его в отдельный метод. Проверяем, что ничего не сломали в процессе (новый метод не тестируем специально, тестируем первые два, раз они работают — значит не сломали). Сломали — дебажим. Не сломали — следующего «брата». Опять мини-ревью. Ага, все подподподзадачи, имеющие общего родителя мы решили. Теперь можем просто проверить и решить её, подподподзадачи уже проверены, нюансы разные в них учтены и мы им доверяем. Пишем тесты на эту родительскую задачу, они получаются простые, ведь мы не проверяем то, что уже проверили в процессе решения «детских» подподподзадач. Пишем код, чтоб эти тесты проходили, код простой — вызов уже решенных и проверенных подподподзадач.
В итоге, мы ничего не делали на будущее, делали только то, что могли и знали как сейчас просто проверить и просто сделать. Если что-то решили неоптимально (пришёл гуру и сказал, что более идиотского велосипеда он не видел, что сортировать прямым перебором нубство, что в стандартной либе есть сортировка пузырьком, что если набрать вот такой запрос из пятнадцати матерных слов в гугле то на первом и единственном месте будет либа, сортирующая для этой задачи вообще моментально), то просто меняем решение на более оптимальное и проверяем, что ничего не сломалось.
Если вы пишите ассерты до того как пишите код, то вы уже сделали большой шаг в этом направлении :)
Ключевая фраза «проверка должна быть простая», следствие — проверяемый код тоже получается простым, 5-10 строк. В чём-то подход совпадает с вашим. Есть задача, как её полностью просто проверить не ясно, не то что как её решить. Ну и ладно. Выделяем какую-то подзадачу, которую понимаем как просто проверить и решить. Или подподподзадачу. Формулируем проверку (пишем тест): что на входе, что на выходе, какие побочные действия. Проверяем. Фейл, ведь код мы ещё не написали. Пишем код, он получается небольшой и простой, ведь проверка простая. О всяких «а вдруг придётся изменить логику», «вдруг это будет медленно», «что с результатом делать дальше» не думаем. Проверяем. Если нет — дебажим, это просто, код небольшой, сложной логической ошибки сделать не могли. Если всё ок решаем так же следующую «братскую» подподподзадачу (тест, код, возможно простейший дебаг). Проводим мини-ревью этих подподподзадач, видим общий или даже похожий код — выносим его в отдельный метод. Проверяем, что ничего не сломали в процессе (новый метод не тестируем специально, тестируем первые два, раз они работают — значит не сломали). Сломали — дебажим. Не сломали — следующего «брата». Опять мини-ревью. Ага, все подподподзадачи, имеющие общего родителя мы решили. Теперь можем просто проверить и решить её, подподподзадачи уже проверены, нюансы разные в них учтены и мы им доверяем. Пишем тесты на эту родительскую задачу, они получаются простые, ведь мы не проверяем то, что уже проверили в процессе решения «детских» подподподзадач. Пишем код, чтоб эти тесты проходили, код простой — вызов уже решенных и проверенных подподподзадач.
В итоге, мы ничего не делали на будущее, делали только то, что могли и знали как сейчас просто проверить и просто сделать. Если что-то решили неоптимально (пришёл гуру и сказал, что более идиотского велосипеда он не видел, что сортировать прямым перебором нубство, что в стандартной либе есть сортировка пузырьком, что если набрать вот такой запрос из пятнадцати матерных слов в гугле то на первом и единственном месте будет либа, сортирующая для этой задачи вообще моментально), то просто меняем решение на более оптимальное и проверяем, что ничего не сломалось.
Если вы пишите ассерты до того как пишите код, то вы уже сделали большой шаг в этом направлении :)
Ну это вопрос о первичности яйца или курицы.
Я если пишу ассерты, то чаще после кода который надо проверять, лишь иногда до. В принципе написание раньше — лучше организует, но немного тормозит. Имхо, это зависит от того как человек думает. Когда знаю, что должно получиться, но не знаю как, то сперва пишу условия. Когда знаю, как нужно сделать, но не уверен, что именно получится, то сперва код. Если знаю что и как, то все равно сперва код. Но опять же ассерты — для меня подстраховка в опасном месте. Поэтому — как то не сложилось.
Плюс в контексте статьи я бы предложил писать сразу несколько простых функциональных блоков. И прогонять их после того, как выдыхаешься.
Я если пишу ассерты, то чаще после кода который надо проверять, лишь иногда до. В принципе написание раньше — лучше организует, но немного тормозит. Имхо, это зависит от того как человек думает. Когда знаю, что должно получиться, но не знаю как, то сперва пишу условия. Когда знаю, как нужно сделать, но не уверен, что именно получится, то сперва код. Если знаю что и как, то все равно сперва код. Но опять же ассерты — для меня подстраховка в опасном месте. Поэтому — как то не сложилось.
Плюс в контексте статьи я бы предложил писать сразу несколько простых функциональных блоков. И прогонять их после того, как выдыхаешься.
А если тогда использовать TDD?
Спасибо за статью! Помогло сформулировать у себя в голове кое-что, осознал, что сам пытаюсь придерживаться такого подхода, но пропускаю стадию пред-отладки (вычитывание кода перед запуском), из-за чего ловлю много граблей.
Я бы не взял автора на работу.
Спасибо, есть что применить в практике.
P.S. заметную часть текста можно было бы заменить на фразу «мне нравится разработка сверху-вниз».
P.P.S. ещё хотелось бы уточнить правило до:«Когда ты перед экраном — садись и делай, но забудь про то, что можешь делать неправильно. Думать надо во время прогулки (езды в метро, пути на работы, ...).». Но как сделать, чтобы сий метод не выливался в перекуры каждые 30 минут на подумать — я не знаю.
P.S. заметную часть текста можно было бы заменить на фразу «мне нравится разработка сверху-вниз».
P.P.S. ещё хотелось бы уточнить правило до:«Когда ты перед экраном — садись и делай, но забудь про то, что можешь делать неправильно. Думать надо во время прогулки (езды в метро, пути на работы, ...).». Но как сделать, чтобы сий метод не выливался в перекуры каждые 30 минут на подумать — я не знаю.
В метро я работаю над сценариями, идеально, интернета нет — час ехать, программировать уже/ещё не хочется ;) На работе есть время пока приветствия чай кофе. Как раз поднять записи и наметить план наступления.
Хорошая кстати методика. Перед уходом с работы записать в рабочий блокнот, что хочется (ни в коем случае не планируется) сделать завтра. С утра читая записи, наметить, чем в первую очередь надо заняться и как.
В периоды тотальной разработки выручает сильно:
— план на один день актуален;
— он на тебя не давит;
— есть четкая картина, что делать;
— возможность играть с детализацией;
— есть возможность коррекции плана на свежую голову
Вечером новый план. В конце этапа пробежаться по блокноноту и посмотреть не сделанные или уже неактуальные задания. Перписывать задания не надо — вероятность забыть что-то важное небольшая. А неважное — оно неважное.
Хорошая кстати методика. Перед уходом с работы записать в рабочий блокнот, что хочется (ни в коем случае не планируется) сделать завтра. С утра читая записи, наметить, чем в первую очередь надо заняться и как.
В периоды тотальной разработки выручает сильно:
— план на один день актуален;
— он на тебя не давит;
— есть четкая картина, что делать;
— возможность играть с детализацией;
— есть возможность коррекции плана на свежую голову
Вечером новый план. В конце этапа пробежаться по блокноноту и посмотреть не сделанные или уже неактуальные задания. Перписывать задания не надо — вероятность забыть что-то важное небольшая. А неважное — оно неважное.
Очень хорошая статья. Спасибо.
Прочитал 3 первых абзаца, и остановился.
Причина 1: страшно читать эту статью. С редактором сейчас всё проще.
Причина 2: Сам углубился в анализ методик генерации собственного кода, и нахожусь в активной стадии порождения тезисов о более оптимальном программировании.
Причина 3: Прочитав эту статью, велика вероятность, что некоторые тезисы доработаются, некоторые рассеются. Но, вероятнее всего, как это обычно и бывает, почти полностью трансфомируется (читай: расеется) ресурс, задействованный на выявление собственных истин создания кода.
Всё-таки прийти своим умом к чему-то иногда бывает более правильным, нежели обратиться за подсказкой к гуру.
P.S. Стаж 5 лет.
Причина 1: страшно читать эту статью. С редактором сейчас всё проще.
Причина 2: Сам углубился в анализ методик генерации собственного кода, и нахожусь в активной стадии порождения тезисов о более оптимальном программировании.
Причина 3: Прочитав эту статью, велика вероятность, что некоторые тезисы доработаются, некоторые рассеются. Но, вероятнее всего, как это обычно и бывает, почти полностью трансфомируется (читай: расеется) ресурс, задействованный на выявление собственных истин создания кода.
Всё-таки прийти своим умом к чему-то иногда бывает более правильным, нежели обратиться за подсказкой к гуру.
P.S. Стаж 5 лет.
Именно так ;)
Понимаю, что статью надо переписывать. По крайней мере выкидывать начало и конец. А середину дорабатывать напильником;)
Хорошо очень писалось и я зачем-то воткнул два подраздела из задумываемой статьи по гейм-дизайну. Там ситуация немного другая и хотя корреляции тоже есть и я считаю, что они правильные, всё таки аргументации не хватает и сформулировано жестковато.
Понимаю, что статью надо переписывать. По крайней мере выкидывать начало и конец. А середину дорабатывать напильником;)
Хорошо очень писалось и я зачем-то воткнул два подраздела из задумываемой статьи по гейм-дизайну. Там ситуация немного другая и хотя корреляции тоже есть и я считаю, что они правильные, всё таки аргументации не хватает и сформулировано жестковато.
Да, все верно. Эта методика настолько эффективна, что действительно приводит к феерическим волшебным результатам. Даже в области, как моя, где упавший код на продакшене это проблема катастрофическая, даже тут ваш подход работает на ура. Сначала проводим грубую кривулину из точки А в точку Б, а потом допиливаем там, где падает.
На эту модель хорошо функциональные тесты ложатся.
На эту модель хорошо функциональные тесты ложатся.
Теперь редактор открывать не страшно. Но очень страшно нажимать кнопку «Run»…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вам не страшно открывать редактор?