LINUX.ORG.RU

[культурка программирования] Лучшее — враг хорошего


0

2

Допустим, вы написали некий кусок кода. Достаточно сложный. По пути вам пришлось решить некую проблему, например, у вашего сервера слишком быстро заканчивались файловые дескрипторы или еще что-то. Вы эту проблему как-то по-своему решили, и знаете, что оно продержится до некоего граничного случая, и случай этот вполне возможен, хотя и при достаточно редких обстоятельствах. Кроме того, тот код, хотя и работает, но достаточно страшен.

Ну да ладно. Вы о том коде уже забыли, работаете над другим куском кода в том же проекте. И тут во время гугления чего-то там для себя по этому куску или просто «отдыха с самообразованием», находите элегантное и правильное с самого начала решение той, еще давнишней, проблемы. Но все равно ваш код выдирать, а новый впаивать — немного поработать и поотладить придется, полдня так точно.

Что будете делать?

Бросите текущую задачу и будете ремонтировать старый код, который еще и не сломался пока что? А что, если это время потрачено даром?

Или забьете на потом, с риском, что когда ударит гром, у вас на тестирование так много времени не будет, как сейчас, да и вы позабудете, где начало-конец вашего костыля? А так бы поремонтировали сразу, ничего бы и не было...

Или оставите какую-то закладку на решение и на свой код в месте костыля, чтобы к нему вернуться при ближайшем намеке на свободное от других задач время? Как разруливаете ситуацию с тем, что эти закладки имеют неизбежное свойство накапливаться?

★★★★★

Последнее исправление: shimon (всего исправлений: 1)

Откладываю на тот время когда мозг откажется креативить (как говорят олдфаги «нет вдохновения») вот тогда то можно заниматься всякой рутиной типо вылизывания старого кода, рефакторинга и т.п., а заниматсья новым кодом в таком состояния низя 8)

wfrr ★★☆
()
Ответ на: комментарий от wfrr

А как решаешь вопрос, чтобы вылизывалки-рефакторилки к тому времени не порастерялись или чтобы решить, какая из них была бы важнее вот прям сейчас?

shimon ★★★★★
() автор топика
Ответ на: комментарий от shimon

Первое TODO-шками, второе по настроению интуиции и тому какая часть системы «загружена» в сознание (немудрено, что в модуль который не трогался полгода нужно некоторое время «въезжать»)

wfrr ★★☆
()
Ответ на: комментарий от wfrr

TODO-шками прямо в коде, потом IDE позволяет все это просмотреть, да и в голове откладывается.

wfrr ★★☆
()

> Что будете делать?

зависит от срочности и критичности того что делаю сейчас. если это возможно, то займусь переделкой асап. если нет - зашедулю на ближайшее будущее.

isden ★★★★★
()
Ответ на: комментарий от shimon

> А как решаешь вопрос, чтобы вылизывалки-рефакторилки к тому времени не порастерялись или чтобы решить, какая из них была бы важнее вот прям сейчас?

осильте таки GTD и подобных вопросов у вас не будет :)

isden ★★★★★
()

Чтобы нормально можно было рефакторить, нужно, я считаю, писать тесты.

Тогда, если решаю что-то перепилить, процесс выглядит обычно так: 1) прогоняю тесты, чтобы убедиться, что функционал работает как надо 2) собственно рефакторинг 3) если после рефакторинга тесты также проходят, все ок. Ну, если нет, то тут, как говорится, начинаются варианты.

Вообще, стараюсь писать, по возможности, без костылей (ну, это, конечно же, невозможно). Если приходится оставлять явный костыль, пишу комментарий, в котором кратко описываю, почему это костыль, и что нужно сделать, чтобы от него избавиться (т.е. возможный ход решения). Что-то типа TODO:/FIXME:

Насчет тестов я серьезно. А как еще проверить, работает ли функционал, который я собрался перепилить? Далеко не всегда можно «вживую» проиграть все возможные варианты его использования. Да, на это уходит время, но зато потом можно проверить, точно ли все работает, как заявлено.

shylent
()

А вот можно поставить KLUDGE - «типа работает, но это ужасно» (обычно следствие неведения относительно существования Ъ метода), и потом по настроению grep -rn «KLUDGE» *. TODO не подойдёт потому что на момент написания велосипеда ещё не ясно что именно и как нужно переделывать.

quasimoto ★★★★
()

>оставите какую-то закладку на решение и на свой код в месте костыля, чтобы к нему вернуться при ближайшем намеке на свободное от других задач время

а еще, бывает что все эти проблемы находятся в версии 1.0, и если я точно знаю что после 1.0 практически сразу я буду заниматься 2.0, то переношу туда (не забывая оформить задачку в трекере)

k0l0b0k ★★
()
Ответ на: комментарий от anonymous

Что бы безопасно рефакторить не нужно 100% покрытий. Если ключевые вещи протыкать, и то уже хорошо.

dizza ★★★★★
()
Ответ на: комментарий от anonymous

И покрытие тестами у вас наверное достигает 100%?!

Ага, а в военное время достигает 200%.

Если серьезно, то, конечно же, нет.

В большинстве случаев, добивать до 100% - непрактично. На эти последние проценты и уходит большая часть времени (80-20, да?). Времени, которое можно было бы потратить на, собственно, написание кода.

shylent
()

>Бросите текущую задачу и будете ремонтировать старый код, который еще и не сломался пока что? А что, если это время потрачено даром?

Манагер скажет, что на улучшизмы опять нет времени ;) Потом все забудут, пока не придет ретивый студент и втихаря перепишет, когда все уже уйдут домой.

slackwarrior ★★★★★
()
Ответ на: комментарий от shylent

> В большинстве случаев, добивать до 100% - непрактично. На эти последние проценты и уходит большая часть времени (80-20, да?). Времени, которое можно было бы потратить на, собственно, написание кода.

Ну, голубчик, кто же пишет тесты после кода? Их перед кодом писать надо...

shimon ★★★★★
() автор топика
Ответ на: комментарий от shimon

Это если разрабатывать через тестирование, не забывайтесь :)

Jetty ★★★★★
()
Ответ на: комментарий от shimon

Я, кажется, нигде этого и не отрицал.

Да и потом, перед - это в идеальном случае. Иногда получается так, что сначала делается некий прототип функционала, потом оказыватеся, что это уже совсем и не прототип. Ну а что потом делать, выкидывать его? Можно и выкинуть, а можно привести в порядок и добавить тесты.

В любом случае, это в тысячу раз лучше, чем использовать нетестированный код.

shylent
()

заведу тикет да и все. ибо сабж по сути баг

VladimirMalyk ★★★★★
()

Если сроки позволяют, то определенно, без вариантов, сразу. В Code Complete, помоемому, написанно - если можешь сделать хорошо, делай либо сейчас, либо никогда. Все эти @TODO, @FIXME потом скапливаются и имеют тенденцию не исправлятся. Менеджер обычно говорит: да конечно, потом отведем время на рефакторинг, но я уже не надеюсь на такие обещания. А если появляется не ожидаемое поведение, то это баг, и тогда лучше в трекер написать отдельную ишую, с повышенным приоритетом.

b0oh
()

Тема к программированию не имеет абсолютно никакого отношения. Ты просто не умеешь планировать свою деятельность, как и часть отписавшихся здесь.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.