Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 107
Можно уложить в четыре слова — «не болейте синдромом рефакторинга».
Если вы можете доказать пользователям что им не нужна данная функция — я вам завидую =)
простое правило — «багфиксы — бесплатно, фичи — за $».
Это в большей степени характерно для заказной разработки. Я в статье говорю всё-таки про продуктовую.
Да и в этом случае сильно зависит от заказчика. Если заказчик хочет чтоб была одна кнопка «сделать красиво» то без багов не получится как не старайся, а если заказчик опытный админ/художник/итд (зависит от софта) то ему наоборот надо «автоматики» поменьше, а побольше «свободы действий». Например если заказывается сайт за которым будет будет следить опытный человек, то никакие wysiwyg-и ему не нужны, наоборот даже, чем меньше «наворотов» тем больше ему понравится.
хм… Я просто говорю им, что её не будет. Это нормально. Тут нет криминала.
Можно подумать, программисты из одного только стремления к красоте шлифуют код.
Можно представить себе, например, склад. Бизнес-задача кладовщиков — быстро и без потерь выдавать затребованное. Чтобы успешно выполнять эту задачу, они иногда переставляют контейнеры и стеллажи, проводят инвентаризации и т.д.
Можно представить себе, например, склад. Бизнес-задача кладовщиков — быстро и без потерь выдавать затребованное. Чтобы успешно выполнять эту задачу, они иногда переставляют контейнеры и стеллажи, проводят инвентаризации и т.д.
И это правильно, черт возьми!
НО если бы они все свое рабочее время проводили инвентаризацию, переставляли контейнеры чтобы теперь вот этот товар было проще всего достать, то им просто некогда было бы отгружать и принимать товар, потому что именно вот этот контейнер сейчас находится в процессе «перестановки» и в него нельзя ничего класть.
НО если бы они все свое рабочее время проводили инвентаризацию, переставляли контейнеры чтобы теперь вот этот товар было проще всего достать, то им просто некогда было бы отгружать и принимать товар, потому что именно вот этот контейнер сейчас находится в процессе «перестановки» и в него нельзя ничего класть.
Ясное дело, что «постоянная инвентаризация» не дает выполнять первичную бизнес-задачу. Но она не менее важна, ибо без нее скоро прекратится «выдача товара».
Приведу еще аналогию с шофером гендира. Его бизнес-задача очевидна. Но он не должен забывать о бензине и вообще о ТО, иначе он подведет гендира в самый ответственный момент.
Приведу еще аналогию с шофером гендира. Его бизнес-задача очевидна. Но он не должен забывать о бензине и вообще о ТО, иначе он подведет гендира в самый ответственный момент.
Конечно не только из одного стремления к красоте. Разумный рефакторинг — это жизненно важный шаг в процессе разработки.
Я говорю именно о «неразумном» шлифовании. Когда код пишется ради кода, а архитектура создаётся ради архитектуры. К сожалению, это встречается сплошь и рядом среди программистов. Особенно — среди хороших программистов с горящими глазами, которые увлечены своим делом.
Я говорю именно о «неразумном» шлифовании. Когда код пишется ради кода, а архитектура создаётся ради архитектуры. К сожалению, это встречается сплошь и рядом среди программистов. Особенно — среди хороших программистов с горящими глазами, которые увлечены своим делом.
Давненько я с такими не встречался, увы:(
У нас на фирме таких двое (включая меня :-)
Я молодым программерам рассказываю такую байку о смене тенденций в программировании:
— в 80-е годы главное требование к программам было в малом размере кода
Код программы должен был занимать как можно меньше памяти, чтобы оставить место для данных и в сумме с ними не вылезти за те 500 кБ, что оставалось после загрузки DOS
— в 90-е годы главное требование к программам было в высокой скорости работы кода
Гонка процессоров уже шла полным ходом, хорошая программа должна была уметь не «тормозить» и работать быстрее, чем юзер нажимает на кнопки
— в нашем веке главное требование к программам стало в высокой гибкости кода
Требования к программе меняются быстрее, чем идет ее разработка и внедрение, текучка кадров приводит к тому, что программист часто работает с чужим кодом, и поэтому он должен быть легко читаемым и быстро модифицируемым.
Так что переписывание старого кода — не блажь, а необходимость. А «преждевременная оптимизация» — это нормально, если в более спокойные периоды программист тратит время на то, чтобы сэкономить его потом, когда будет срочная работа.
Я молодым программерам рассказываю такую байку о смене тенденций в программировании:
— в 80-е годы главное требование к программам было в малом размере кода
Код программы должен был занимать как можно меньше памяти, чтобы оставить место для данных и в сумме с ними не вылезти за те 500 кБ, что оставалось после загрузки DOS
— в 90-е годы главное требование к программам было в высокой скорости работы кода
Гонка процессоров уже шла полным ходом, хорошая программа должна была уметь не «тормозить» и работать быстрее, чем юзер нажимает на кнопки
— в нашем веке главное требование к программам стало в высокой гибкости кода
Требования к программе меняются быстрее, чем идет ее разработка и внедрение, текучка кадров приводит к тому, что программист часто работает с чужим кодом, и поэтому он должен быть легко читаемым и быстро модифицируемым.
Так что переписывание старого кода — не блажь, а необходимость. А «преждевременная оптимизация» — это нормально, если в более спокойные периоды программист тратит время на то, чтобы сэкономить его потом, когда будет срочная работа.
Совершенно согласен.
Согласен.
Но тем не менее для рефакторинга выделяется специальное время, и в это время (если не вылезли критические баги) можно спокойно подумать, переделать и протестировать. А делать рефакторинг в попыхах — все равно, что втыкать палки в колеса.
P.S. Это касается средних и крупных рефакторингов. Микро-рефакторинги должны выполняться во время разработки по мере необходимости.
Но тем не менее для рефакторинга выделяется специальное время, и в это время (если не вылезли критические баги) можно спокойно подумать, переделать и протестировать. А делать рефакторинг в попыхах — все равно, что втыкать палки в колеса.
P.S. Это касается средних и крупных рефакторингов. Микро-рефакторинги должны выполняться во время разработки по мере необходимости.
Должно быть чёткое определение, что такое «достаточно хороший код». Иными словами, «definition of done».
Например, код считается хорошим, когда он
* проходит все юнит-тесты (написанные исходя из ТЗ)
* не содержит хаков
* не нарушает общую архитектуру
* удовлетворяет общим требованиям к производительности
Имея подобное чёткое определение, известное каждому члену команды, работать становится намного проще.
Например, код считается хорошим, когда он
* проходит все юнит-тесты (написанные исходя из ТЗ)
* не содержит хаков
* не нарушает общую архитектуру
* удовлетворяет общим требованиям к производительности
Имея подобное чёткое определение, известное каждому члену команды, работать становится намного проще.
Это точно. Проблема, как всегда, в деталях:
* что такое «хак»?
* как определяется «общая архитектура»?
Ну и этих факторов, конечно же не достаточно. Но, в общем, критерии «достаточно хорошего кода» сильно бы помогли. Впрочем, выработать их — очень непростая задача и зависит от конкретного продукта / проекта.
* что такое «хак»?
* как определяется «общая архитектура»?
Ну и этих факторов, конечно же не достаточно. Но, в общем, критерии «достаточно хорошего кода» сильно бы помогли. Впрочем, выработать их — очень непростая задача и зависит от конкретного продукта / проекта.
Разумеется, «проблема в деталях» и «зависит от конкретного продукта / проекта». Именно поэтому в моём предыдущем посте маячат слова «например» и "подобное определение" :)
Я описал лишь общий подход, а уж каждая конкретная реализация — на усмотрение ведущего проекта.
Я описал лишь общий подход, а уж каждая конкретная реализация — на усмотрение ведущего проекта.
По порядку важности:
1) Обеспечивает прохождение всех тестов
2) Не содержит дублирующего кода
3) Выражает намерения программиста
4) Использует минимальное количество классов и методов
Кент Бек.
1) Обеспечивает прохождение всех тестов
2) Не содержит дублирующего кода
3) Выражает намерения программиста
4) Использует минимальное количество классов и методов
Кент Бек.
Вот это ближе к жизни.
Код считается хорошим, когда:
* Просто работает. Хотя бы иногда.
* Количество хаков меньше половины всего кода.
* Есть хоть какая-то архитектура. Ну хотя бы общая задумка.
* Если тормозит, то всегда можно что-то выкинуть, или повесить красивый прогресс-бар.
Код считается хорошим, когда:
* Просто работает. Хотя бы иногда.
* Количество хаков меньше половины всего кода.
* Есть хоть какая-то архитектура. Ну хотя бы общая задумка.
* Если тормозит, то всегда можно что-то выкинуть, или повесить красивый прогресс-бар.
Вспомнилась интересная статья про программистов «бортовой группы шаттла»:
Что действительно поражает, так это то, как хорошо это ПО работает. Это ПО никогда не падает. Оно никогда не требует перезагрузки. Оно не содержит ошибок. Оно совершенно, настолько совершенно, насколько человек смог этого достичь. Посмотрите на статистику: последние три версии этой программы – каждая по 420.000 строк кода – имели всего по одной ошибке в каждой. Последние 11 версии этого ПО имели в сумме 17 ошибок. Коммерческие программы, подобного уровня сложности имели бы 5.000 ошибок."
И опять же, помимо профессионализма тех ребят, в их работу вкладываются огромные деньги.
я бы сказал что в их работу вкладываются Жизни людей. Если в ПО складского учета цена ошибки это 10 минут (час, день) потерянного времени и может быть какая-то сумма денег, то там цена ошибки это чьято жизнь.
И там не такие жёсткие ограничения по времени.
То есть, случаев когда за неделю до сдачи, какие нибудь маркетологи, попросили бы добавить «розовую кнопочку с цветочками» я себе представить не могу, там я думаю ТЗ сначала составляется, потом уточняется, а уже потом всё пишется. (А не как в коммерческом софте, каждую минуту приходят изменения «сверху»)
То есть, случаев когда за неделю до сдачи, какие нибудь маркетологи, попросили бы добавить «розовую кнопочку с цветочками» я себе представить не могу, там я думаю ТЗ сначала составляется, потом уточняется, а уже потом всё пишется. (А не как в коммерческом софте, каждую минуту приходят изменения «сверху»)
И тем не менее один раз получилось, что они cannot into метрическая система.
интересная статья про программистов «бортовой группы шаттла»За последние дни я более глубоко осознал суть работы этих парней (про них я знал давно), прочитав «2001: Космическая одиссея» Артура Кларка.
Разработка ПО для шаттлов — как раз хороший пример ПО, для которого понятие «достаточно хорошее» фактически сливается с понятием «идеальное». Как я уже говорил в тексте, при этом применяются совершенно другие подходы и методики (о чём, собственно, в приведённой статье и написано).
Проблема в том, что зачастую решения первоначальной задачи (решение которой заняло, скажем, месяц) становится недостаточно и требуются новые фичи. Предлагаешь клиенту «за неделю я сделаю костыли, за две перепишу всё по новой с учётом новых задач» — выбирают «за неделю». Новая задача — «за две — костыли, за три по новой». Следующая «за четыре костыли, за пять -по новой»… И т. д. пока сам не понимаешь. что очередной костыль делать дольше, чем переписать по новой. При условии, что клиент не ушёл на стадии «но ведь это лишь одна лишняя строчка на экране, вы сделали их 100 500 за месяц, как ещё одна может требовать неделю».
Рефакторинг — это как раз способ не переписывать по новой. За две недели вы возможно и напишите 30 000 строк кода, но наверника не учтете все case-ы.
Рефакторинг, как часть рабочего процесса и нужен, что бы не попадать в подобные ситуации.
Рефакторинг, как часть рабочего процесса и нужен, что бы не попадать в подобные ситуации.
Рефакторингом называют сейчас всё что угодно — от переименования переменной цикла до изменения архитектуры. Вы про какой? :)
Я о том, что заставляет вас делать костыли. Сомневаюсь что это имена переменных.
Если у вас появляется необходимость еще и в видоизмененном варианте какого-то алгоритма (выбираемым например по параметру из config-а или базе) можно действовать двумя способами:
1. Вставить пару тройку if-ов
2. Выделить логику в отдельную стратегию (рефакторинг) и создать еще одну стратегию с видоизмененной логикой.
Второй вариант в первый раз займет в два раза больше времени. Зато во второй раз эти затраты примерно сравняются.
Все как вы сказали
Если у вас появляется необходимость еще и в видоизмененном варианте какого-то алгоритма (выбираемым например по параметру из config-а или базе) можно действовать двумя способами:
1. Вставить пару тройку if-ов
2. Выделить логику в отдельную стратегию (рефакторинг) и создать еще одну стратегию с видоизмененной логикой.
Второй вариант в первый раз займет в два раза больше времени. Зато во второй раз эти затраты примерно сравняются.
Все как вы сказали
К стати интересная мысль. Затраты на внесение изменений с рефакторингом надо сравнивать не с изменениями без него. А со следующими изменениями без рефакторинга. :)
Есть два типа приложений.
1) Прототип. Изначально пишется для того, чтобы показывать в качестве демки. Не предполагает поддержки, расширения и т.д. Допускает наличие косяков, недочетов и т.д. Может падать. Главная цель — наглядно показать, как будет работать система, чтобы можно было на ранних стадиях как можно лучше зафиксировать требуемый функционал. Как правило реализуется заранее фиксированным набором людей в относительно короткие сроки.
2) Промышленное приложение. Пишется один раз, учитывает возможную смену требований и оформления, должно обеспечивать возможность настройки, не допускается наличие косяков, которые препятствуют использованию системы по назначению (т.е. основные use-cases), не допускается нарушение прав доступа, не допускается повреждение или утечка данных. Время жизни как минимум составляет несколько лет, в это время добавляются новые фичи, состав команды разработчиков меняется, появляются новые клиенты, использующие систему, появляются юридические документы, обязанности по которым необходимо соблюдать, и т.д.
То, что Вы описываете — это первый пункт. Поскольку у первого и второго пунктов координально разные цели, постепенное превращение первого во второе сулит существенные затраты как по бюджету, так и по времени. И стоимость ошибок, допущенных при первом подходе, при переходе во второй очень сильно возрастает.
1) Прототип. Изначально пишется для того, чтобы показывать в качестве демки. Не предполагает поддержки, расширения и т.д. Допускает наличие косяков, недочетов и т.д. Может падать. Главная цель — наглядно показать, как будет работать система, чтобы можно было на ранних стадиях как можно лучше зафиксировать требуемый функционал. Как правило реализуется заранее фиксированным набором людей в относительно короткие сроки.
2) Промышленное приложение. Пишется один раз, учитывает возможную смену требований и оформления, должно обеспечивать возможность настройки, не допускается наличие косяков, которые препятствуют использованию системы по назначению (т.е. основные use-cases), не допускается нарушение прав доступа, не допускается повреждение или утечка данных. Время жизни как минимум составляет несколько лет, в это время добавляются новые фичи, состав команды разработчиков меняется, появляются новые клиенты, использующие систему, появляются юридические документы, обязанности по которым необходимо соблюдать, и т.д.
То, что Вы описываете — это первый пункт. Поскольку у первого и второго пунктов координально разные цели, постепенное превращение первого во второе сулит существенные затраты как по бюджету, так и по времени. И стоимость ошибок, допущенных при первом подходе, при переходе во второй очень сильно возрастает.
если кто-то захочет, это можно доказать чисто математически
Очень интересно, сделайте же это.
Очень интересно, сделайте же это.
Любой код, исправляющий ошибку потенциально может содержать новую ошибку. Т.е. вероятность появления новой ошибки всегда больше нуля. Получается предел — количество ошибок стремится к нулю. Идеал недостижим.
Ваше рассуждение было бы верным, если бы код был бесконечно делим. Но исходный код — дискретное множество. В пределе мы приходим к некоторой единице кода — если она содержит ошибку, мы просто исправляем её. Эта единица кода не может быть верна на сколько-то процентов, поэтому процесс исправления ошибок обязательно завершится.
Ок. Согласен что математически показатель 0 ошибок в НЕ бесконечном объеме кода когда-нибудь будет достигнут. Не из-за дискретности множества команд, а из-за конечности суперпозиций — вариаций комбинации команд.
На практике же объем кода действительно стремится к плюс бесконечности: появляются новые фичи, исправляются старые ошибки.
На практике же объем кода действительно стремится к плюс бесконечности: появляются новые фичи, исправляются старые ошибки.
Было бы здорово, если это было бы правдой, но КОД ПИШУТ ЛЮДИ :-)
Кроме того, существуют методы написания гарантировано безошибочного кода. Насколько я помню, доказательство идёт по индукции. Сначала доказывается корректность одной простейшей команды, потом корректность суперпозиции простейших команд и т.д.
Нам на эту тему читали вводную лекцию сотрудники ИСП РАН, у них там ведётся большая работа на эту тему. К сожалению, сходу не могу найти ссылку.
Нам на эту тему читали вводную лекцию сотрудники ИСП РАН, у них там ведётся большая работа на эту тему. К сожалению, сходу не могу найти ссылку.
Это вовсе не значит, что на практике действительно возможно исправить абсолютно все ошибки. Даже у NASA, насколько я знаю, есть какая-то норма на тыс. строк кода.
Но ни о каком математическом доказательстве, по-моему, речи быть не может.
Но ни о каком математическом доказательстве, по-моему, речи быть не может.
А Ахиллес никогда не догонит черепаху, да.
Это не математическое доказательство. Это псевдоматематическое рассуждение по индукции
Та же теория вероятности допускает создание безошибочного кода с первого раза, в котором не потребуется вносить ошибки. Любой, сколь угодно маловероятный исход может наступить при первом испытании.
Только в том случае, если бы сложность структуры всегда возрастала.
Если же сложность не превысит некоторой константы, то возможно исправление ошибки без внесения новых. Таким образом, занимаясь только исправлением ошибок (без расширения функционала системы), которые не приводят к бесконечному увеличению сложности, можно исправить все подобные ошибки.
Конечно, остается открытым вопрос наличия ошибок, приводящих к бесконечному увеличению сложности. Здесь можно ответить, что наличие подобных ошибок может быть вызвано лишь попыткой реализовать то, что впринципе нельзя реализовать.
Если же сложность не превысит некоторой константы, то возможно исправление ошибки без внесения новых. Таким образом, занимаясь только исправлением ошибок (без расширения функционала системы), которые не приводят к бесконечному увеличению сложности, можно исправить все подобные ошибки.
Конечно, остается открытым вопрос наличия ошибок, приводящих к бесконечному увеличению сложности. Здесь можно ответить, что наличие подобных ошибок может быть вызвано лишь попыткой реализовать то, что впринципе нельзя реализовать.
Посмотрите на Google. Он так и не сделал категории, которые в то время были у всех поисковиков и сложно было представить, как вообще «можно без них».
Сюрприз
Непонятно, почему нельзя добиться безбажности продукта. Я не говорю о потенциальных ошибках, или об ошибках, о которых знаете только вы, я говорю об ошибках, которые видны пользователю. Если пользователь сообщил вам об ошибке, вы не будете ее фиксить? Вы, конечно, можете возразить, что вот мол, жизни не хватить исправить все ошибки. Не знаю, зависит от сложности и объема системы, наверное. Но и не только.
Из собственной практики: только что завершили новый продукт на работе. Тестировать его начали практически одновременно с разработкой. В какой-то момент количество багов было пугающим, но постепенно пофиксили все. Все, что нашли тестеры. Теперь на очереди выборочное тестирование у пользователей. Найдут новые баги — пофиксим и их тоже. И те, которые потом найдут реальные пользователи. Почему не?
Красивый код, кстати, подразумевает легкость выявления, локализации и устранения ошибок. Так почему бы не писать красивый код? (Я не имею в виду идеальный код, но просто хорошо структурированный, хорошо документированный, оттестированный, в меру отрефакторенный и т.д.)
Из собственной практики: только что завершили новый продукт на работе. Тестировать его начали практически одновременно с разработкой. В какой-то момент количество багов было пугающим, но постепенно пофиксили все. Все, что нашли тестеры. Теперь на очереди выборочное тестирование у пользователей. Найдут новые баги — пофиксим и их тоже. И те, которые потом найдут реальные пользователи. Почему не?
Красивый код, кстати, подразумевает легкость выявления, локализации и устранения ошибок. Так почему бы не писать красивый код? (Я не имею в виду идеальный код, но просто хорошо структурированный, хорошо документированный, оттестированный, в меру отрефакторенный и т.д.)
Красивый код — это, на мой взгляд, один из основных критериев «живучести» ПО. Действительно, чёткая архитектура и аккуратный код обычно ведут к лёгкому пониманию и критическому увеличению скорости исправления ошибок и добавления новых функций.
Но это говорит не о том, что ошибок нет. Это говорит о том, что большинство ошибок легко исправить.
> Если пользователь сообщил вам об ошибке, вы не будете ее фиксить?
Не всегда, к сожалению. Мир не идеален и очень часто приходится выбирать между исправлением мелкой и незначительной ошибки и добавлением нужной функции, например. IRL очень часто из двух зол приходится выбирать меньшее.
Но это говорит не о том, что ошибок нет. Это говорит о том, что большинство ошибок легко исправить.
> Если пользователь сообщил вам об ошибке, вы не будете ее фиксить?
Не всегда, к сожалению. Мир не идеален и очень часто приходится выбирать между исправлением мелкой и незначительной ошибки и добавлением нужной функции, например. IRL очень часто из двух зол приходится выбирать меньшее.
Если ошибка незначительна, почему ее нельзя поправить? Почему надо обязательно выбирать между исправлением ошибки и добавлением новой функциональности? В нормальных конторах одно другому не мешает — лишь выставляются приоритеты, скажем мы делаем новую функциональность и попутно исправляем баги — если баг мелкий, фиксим не больше одного в неделю (грубо говоря).
Может быть, я неправильно выразился. Мелкой и незначительной с точки зрения влияния на продукт, но достаточно объёмной с точки зрения объёма работы. Я ни в коем случае не говорю, что ошибки исправлять вообще не нужно :).
А приоритеты — обязательны. Без них просто нельзя организовать нормальную работу. Собственно, я говорю о том, что иногда приходится жертвовать исправлением мелких недоработок в пользу движения продукта вперёд. У меня создалось впечатление, что мы с Вами как раз говорим об одном и том же. Нет?
А приоритеты — обязательны. Без них просто нельзя организовать нормальную работу. Собственно, я говорю о том, что иногда приходится жертвовать исправлением мелких недоработок в пользу движения продукта вперёд. У меня создалось впечатление, что мы с Вами как раз говорим об одном и том же. Нет?
Примерно. Но беда в том, что ваш пост, для нас с вами понятный, и очевидный — может быть воспринят молодыми разработчиками как призыв плевать на рефакторинг, на красивость кода, и даже на баги. А это уже не есть гуд.
Ну, я надеюсь, что у таких молодых и горячих голов найдутся здравые и трезвые руководители, которые, собственно, за проект отвечают, и которые смогут донести настоящие ценности. Впрочем, всякое, конечно, бывает в жизни. Бывают, к сожалению, и «самоорганизующиеся» команды. Причём — далеко не самым лучшим образом.
Рано или поздно продукт стабилизируется, и требований новых фич становится все меньше и меньше. Соответственно, появляется время на исправление старых ошибок, и их число начинает уменьшаться. Единственный вопрос, что кончится раньше: ошибки или поддержка продукта.
пиши красивый, никто не мешает. но главное — «вам шашечки или ехать»?
В данном случае, боюсь, что без шашечек далеко вряд ли уехать удастся… Другое дело — сколько времени на эти шашечки уйдёт.
Нет, в данном случае это неправильно. Потому что вопрос будет не про шашечки, а «вам вообще доехать надо?» или «как предпочитаете — с нормальным мотором или вот тут у меня баг — выхлопная труба имеет выход в салон...?»
> Непонятно, почему нельзя добиться безбажности продукта.
Потому что в реальности программа работает не в вакууме (на абстрактной машине Тьюринга), а во вполне конкретных условиях. Может быть избалованные процессорной мощью и объемами оперативки десктопные программисты и забывают об этом. Хотя примеры вcпомнить можно, допустим, тот же самый баг с сопроцессором в каких-то древних Пентиумах (помните? или поискать ссылку?). Как добиться правильности программы, если процессор считает неправильно? Или другая версия операционной системы работает по-другому? Или еще какой-то драйвер глючит?
Мне лично чаще приходится бороться не с багами в моей программе, а с тем «окружением», в котором работает моя программа (j2me-программирование на мобилах). Счиать ли багом то, что программа не работает по причине банальной нехватки оперативки? Считать ли багом программы если она не смогла сохранить данные по причине нехватки места на флешке? Считать ли багом программы невозможность соединения с сервером если у юзера банально не настроен доступ в интернет на телефоне? Для пользователя — это баг. А для разработчика — это головная боль
Грубо говоря — можно ли считать notepad.exe бажной программой если он не может открыть файл в 100 мегабайт (по нынешним временам — не так уж много)? Можно ли писать баг-репорт в Адобе если вы не смогли открыть файл размером 100500x100500?
Потому что в реальности программа работает не в вакууме (на абстрактной машине Тьюринга), а во вполне конкретных условиях. Может быть избалованные процессорной мощью и объемами оперативки десктопные программисты и забывают об этом. Хотя примеры вcпомнить можно, допустим, тот же самый баг с сопроцессором в каких-то древних Пентиумах (помните? или поискать ссылку?). Как добиться правильности программы, если процессор считает неправильно? Или другая версия операционной системы работает по-другому? Или еще какой-то драйвер глючит?
Мне лично чаще приходится бороться не с багами в моей программе, а с тем «окружением», в котором работает моя программа (j2me-программирование на мобилах). Счиать ли багом то, что программа не работает по причине банальной нехватки оперативки? Считать ли багом программы если она не смогла сохранить данные по причине нехватки места на флешке? Считать ли багом программы невозможность соединения с сервером если у юзера банально не настроен доступ в интернет на телефоне? Для пользователя — это баг. А для разработчика — это головная боль
Грубо говоря — можно ли считать notepad.exe бажной программой если он не может открыть файл в 100 мегабайт (по нынешним временам — не так уж много)? Можно ли писать баг-репорт в Адобе если вы не смогли открыть файл размером 100500x100500?
Баг — это не отсутствие некоторых возможностей программы, или ограничения, а неадекватная реакция программы на попытку выйти за пределы этих ограничений.
Если программе не хватает памяти, попытайтесь оптимизировать, ужать код, если это невозможно, отловите момент, когда нехватка может наступить и сообщите об этом пользователю — пусть он сам решает, что делать дальше.
Если нет места на флэшке, также сообщите об этом пользователю — это его головная боль, а не ваша, он должен очистить место, а вы должны дать знать ему о том, что места недостаточно.
Если нельзя соединиться с сервером, не просто сообщите юзеру об этом, а приведите список возможных причин и как их устранить.
Если файл слишком велик и его нельзя открыть, сообщите об этом и предложите возможные пути решения (разбить файл, сжать, не знаю что еще). Если ваша программа тупо крэшится в ответ на попытку открыть большой файл — вот это баг.
Поймите, отстутствие багов не обязательно означает их реальное отсутствие, это означает то, что вы знаете, что не все в программе работает идеально, и проявляете заботу о пользователе. Комфортная работа с программой — вот что такое отсутствие багов.
И вообще, как это для разработчика баг может быть головной болью? Это наш хлеб, в конце концов! :)
Если программе не хватает памяти, попытайтесь оптимизировать, ужать код, если это невозможно, отловите момент, когда нехватка может наступить и сообщите об этом пользователю — пусть он сам решает, что делать дальше.
Если нет места на флэшке, также сообщите об этом пользователю — это его головная боль, а не ваша, он должен очистить место, а вы должны дать знать ему о том, что места недостаточно.
Если нельзя соединиться с сервером, не просто сообщите юзеру об этом, а приведите список возможных причин и как их устранить.
Если файл слишком велик и его нельзя открыть, сообщите об этом и предложите возможные пути решения (разбить файл, сжать, не знаю что еще). Если ваша программа тупо крэшится в ответ на попытку открыть большой файл — вот это баг.
Поймите, отстутствие багов не обязательно означает их реальное отсутствие, это означает то, что вы знаете, что не все в программе работает идеально, и проявляете заботу о пользователе. Комфортная работа с программой — вот что такое отсутствие багов.
И вообще, как это для разработчика баг может быть головной болью? Это наш хлеб, в конце концов! :)
> Красивый код, кстати, подразумевает легкость выявления, локализации
> и устранения ошибок. Так почему бы не писать красивый код? (Я не имею
> в виду идеальный код, но просто хорошо структурированный, хорошо
> документированный, оттестированный, в меру отрефакторенный и т.д.)
Потому что «красивый код» — это не объективный критерий, а функция от многих переменных, в том числе от t (то есть от времени). То что красиво вчера — будет некрасиво сегодня и безобразно завтра. Меняется остальная часть программы, меняется среда в которой эта программа работает. Мне, право же, трудно приводить примеры, которые нельзя было бы оспорить, но по-моему такое встречается сплошь и рядом. Если сейчас свежим взглядом посмотрть, допустим, на рендеринг сцен в каком-нибудь DOOM? Неужели програмист, который владеет DirectX оценит тот код начала 90-ых годов и скажет «вах, красиво, Вася!»
> и устранения ошибок. Так почему бы не писать красивый код? (Я не имею
> в виду идеальный код, но просто хорошо структурированный, хорошо
> документированный, оттестированный, в меру отрефакторенный и т.д.)
Потому что «красивый код» — это не объективный критерий, а функция от многих переменных, в том числе от t (то есть от времени). То что красиво вчера — будет некрасиво сегодня и безобразно завтра. Меняется остальная часть программы, меняется среда в которой эта программа работает. Мне, право же, трудно приводить примеры, которые нельзя было бы оспорить, но по-моему такое встречается сплошь и рядом. Если сейчас свежим взглядом посмотрть, допустим, на рендеринг сцен в каком-нибудь DOOM? Неужели програмист, который владеет DirectX оценит тот код начала 90-ых годов и скажет «вах, красиво, Вася!»
И инженера спокойно терпят ежедневные политинформации? Или им приплачивают?
плюсанул.
красава.
разделяю точку зрения.
практики поддержат, теоретики — поднимут вой и хай
красава.
разделяю точку зрения.
практики поддержат, теоретики — поднимут вой и хай
Полностью согласен с автором. У меня есть код, который я писал 11 лет назад, когда только осваивал Перл. Этот код ужасен. Но он работает так, как задумано. Уже 11 лет подряд, круглосуточно в системе для одного GSM-провайдера. И не думаю, что до конца жизни проекта его кто-то будет переписывать.
Как написали выше — практики поймут, а теоретики начнут холивар :)
Как написали выше — практики поймут, а теоретики начнут холивар :)
По-моему, статья совсем о другом. И холивар тоже о другом. У меня тоже есть продукт, который был написан почти 10 лет назад, и код был ужасен, и архитектура была ужасна (да и не было там по сути никакой архитектуры), и он, так же, как и ваш, работает тем не менее. Никто не говорит о том, чтобы перелопачивать и переписывать старый уродский код. Но теперь, когда вы старый матерый волк, теперь-то вы уж стараетесь сделать ваш новый код покрасивее, правда? И не спешите написать его как можно скорее, «лишь бы работало»?
А вот это уж зависит от того, для чего нужен код. Если это одноразовый парсер, который требуется ровно один раз, чтобы перегнать один формат в другой — то почему бы не написать а-ля «поток сознания» вместо того, чтобы писать всё красиво? Экономится куча времени, которое можно посвятить тому же Хабру :)
Очень часто в мире программирования есть сроки. И если стараться всегда вписываться в сроки — то не всегда получается вписываться в «красивость».
Но, разумеется, если есть время — то у меня есть куча кода, который переписывался раз 3-5, но даже после пятого раза всегда можно к чему-нибудь придраться. Идеал недостижим :)
Очень часто в мире программирования есть сроки. И если стараться всегда вписываться в сроки — то не всегда получается вписываться в «красивость».
Но, разумеется, если есть время — то у меня есть куча кода, который переписывался раз 3-5, но даже после пятого раза всегда можно к чему-нибудь придраться. Идеал недостижим :)
Когда написание красивого, структурированного кода войдет у вас в привычку, вы даже одноразовый код будете делать хорошо. Я не имею в виду, что надо городить кучу классов и сложную иерархию, когда можно обойтись без классов вообще, но скажем, выделить в отдельные методы (функции) повторяющийся код, не использовать магические числа, давать функциям осмысленные имена и тому подобные мелочи, которые делают код красивым — все это как минимум поможет сделать даже одноразовый код правильным. Ведь вам надо убедиться, что код отпарсил и сконвертировал все правильно? Возможно, придется написать парочку простых тестов. И кто знает, вдруг вы захотите использовать этот код в дальнейшем? Или использовать его для конвертирования других форматов?
Опять же, речь вовсе не о переписывании идет, а о написании хорошего кода с нуля. И дело не в том, чтобы комар носа не подточил, а в том, чтобы этим кодом потом можно было воспользоваться дальше, чтобы он не имел багов только потому, что написан по-уродски и т.д.
Опять же, речь вовсе не о переписывании идет, а о написании хорошего кода с нуля. И дело не в том, чтобы комар носа не подточил, а в том, чтобы этим кодом потом можно было воспользоваться дальше, чтобы он не имел багов только потому, что написан по-уродски и т.д.
В общем то все правильно. Только вот некоторые части системы (к примеру, касающиеся безопасности) лучше отдать делать параноику-перфекционисту.
Чрезмерная шлифовка ~~ онанизм.
Я вот иногда, когда вырисовывается необходимость добавления в продукт нового функционала, дёргаю всех имеющих к нему отношение людей (программистов, тестеров, руководство, клиентов), обрисовываю ситуацию и спрашиваю, в каком объёме нужно реализовать задачу.
А дальше:
20% самых масштабных ответов выбрасываю — это перфекционисты, нам с ними не по пути
20% самых коротких ответов выбрасываю — это леняи, аналогично
Из оставшегося берём среднее арифметическое и добавляем 20%. Вот это и есть идеальный план. Чаще всего такой план высказывается специалистами, ответственными за внедрение разработки на объекте заказчика. Они очень хорошо понимают, что ни полностью идеальный продукт через 10 лет, ни детская поделка через 2 дня никому нафиг не нужны.
А дальше:
20% самых масштабных ответов выбрасываю — это перфекционисты, нам с ними не по пути
20% самых коротких ответов выбрасываю — это леняи, аналогично
Из оставшегося берём среднее арифметическое и добавляем 20%. Вот это и есть идеальный план. Чаще всего такой план высказывается специалистами, ответственными за внедрение разработки на объекте заказчика. Они очень хорошо понимают, что ни полностью идеальный продукт через 10 лет, ни детская поделка через 2 дня никому нафиг не нужны.
Мое маленькое имхо-лично я код пишу не для галочки, не для начальника или еще кого-я пишу код для себя. Пишу и правлю какой-то код ровно до тех пор, пока он не начинает мне нравится, когда я понимаю что в этот раз я лучше уже не напишу. Вот когда я это понимаю-я пишу что-то другое. Не хочу идти на какие то компромисы по принципу-я что нито напишу, не на полную силу, не идеально, типа сойдет. Я уже давно отказался от этого, потому что пишу свой софт в первую очередь для пользователей, а тут предельно важно, чтобы пользователь был доволен. Для меня довольный пользователь гораздо важнее довольного начальника или довольного тестера, потому что они всего лишь прослойка между пользователем и мной.
У вас по работе наверно бывает оч много конфликтов?
А сроки на разработку той или иной фичи Вы сами указываете? Вы их как-то обосновываете? Почему-то кажется, что в вашем случае это реальная проблема. Я прав?
сроки это результат договоренности с заказчиком. он называет что ему надо, я говорю сколько на это потребуется времени. если его не устраивают сроки, мы переносим какие то фичи на следующие релизы. сроки являются реальной проблемой когда они спускаются разрабтчикам сверху менеджерами, которые имеют слабое понимание процесса разработки ПО. Бывает, что и разработчики, пытаясь угодить начальству, называют или заранее нереальные сроки, или сроки, взятые с потолка на глазок. Это не наш метод и мы такие случаи даже не рассматриваем
Получается, что Вы сами взаимодействуете с заказчиком? Т.е. сами себе ПМ? В этом случае я могу только пожелать Вам удачи в поисках заказчиков, которые соглашаются на ваши сроки. Это — главное.
пользователь никогда не увидит кода, ему главное чтобы работало так, как он ожидает от софта.
но мне зато этот код потом модифицировать, фиксить, расширять… ну или не мне а другому девелоперу. гораздо приятнее и эффективнее работать с хорошо написанным кодом, чем с помойкой
ну или вот-вы скажем конструктор и делаете автомобиль. покупателю все равно, что там под капотом и под брюхом, вы можете там какую угодно кашу из проводов и деталей сделать, но если что-то сломается, то вам или вашим коллегам придется в эту кашу залезать, чтобы исправить проблему. Поэтому гораздо более разумно под капотом привести все в полный порядок
Простите, но «сведение количества ошибок к нулю. Да это и невозможно (если кто-то захочет, это можно доказать чисто математически)»
противоречит
«ошибок в жизненно важных частях бизнес логики быть не должно»
И это вполне по силам заметить на слух. Так что подозреваю, что «очень проникновенная речь» не получилось. Возможно так же что немного уменьшился авторитет в глазах некоторых участников команды.
Что же до сабжа — я тоже думаю, что уже давно наступила эпоха «наивных реализаций», но не все себе ещё в этом признались.
противоречит
«ошибок в жизненно важных частях бизнес логики быть не должно»
И это вполне по силам заметить на слух. Так что подозреваю, что «очень проникновенная речь» не получилось. Возможно так же что немного уменьшился авторитет в глазах некоторых участников команды.
Что же до сабжа — я тоже думаю, что уже давно наступила эпоха «наивных реализаций», но не все себе ещё в этом признались.
ИМХО для оценки «достаточности» можно воспользоваться правилом Парето: например уделять особое внимание 20% наиболее важной функциональности, 20% наиболее критических ошибок и т.п. Естественно, что это может быть не 20%, а где-то рядом, и, естественно, что я не призываю забить на остальные 80% функционала и ошибок.
Для реализации всего-то необходимо: оценка важности чего-то (функции, ошибки и т.п.) и мониторинг ситуации в реальном времени.
Для реализации всего-то необходимо: оценка важности чего-то (функции, ошибки и т.п.) и мониторинг ситуации в реальном времени.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О «достаточно хорошем» ПО