Перед самым запуском не стоит, и времени может не хватить на переделку, и тесты придется прогонять по новой. Риск слишком велик.
Но если потом с этим кодом приходится иметь дело, наверное себе же дешевле будет его переписать. Это как с ремонтом в доме. Пока только протекает кран — можно подставлять кастрюльки. Но поломки, если их не чинить, накапливаются. Перегорает лампочка, забивается труба, перестает работать слив. Неисправление отнимает все больше времени.
Вроде бы, вопрос только в том, насколько быстро все рухнет. И вот здесь реальность меня удивила. Оно никогда не рухнет. Просто превратится в помойку, а удовольствия от жизни на помойке никакого.
Добавлю, что после таких «кредитов» в ущерб архитектуре обязательно должен идти этап восстановления и наведения красоты. Только вот этот этап обычно пропускают. Из-за менеджмента, который не видит целесообразности, и из-за программеров, которые исповедут принцип «работает — не трожь». В результате мусор накапливается, работа замедляется, сами себе же роют могилу, вместо исправления багов патчат битые данные в базе.
Еще думаю, что в принципе неправильно решать эту задачу копированием/модификацией исходного массива. Представим, что массив едва помещается в память. Я не в курсе, как работает RemoveRange в C#, но память, по-видимому, отъедается.
Это так, согласен. Но это не значит, что от решения таких задач нет толку. Смотрите, если все простые задачи уже решены за нас в стандартной библиотеке, значит нам остались только более сложные задачи, которых там нет. Как мы будем решать эти более сложные задачи, если мы не умеем решить даже простую задачу из стандартной библиотеки?
Я вам скажу как, опыта на этот счет достаточно. Очень хреново. Я делал проверку кода, когда работал в команде. Многие программисты не могли родить простейший код даже с 20 попытки! Они привыкли сидеть на готовом, они не способны написать что-то сложнее простой композиции foo(bar())
Ну такую задачу олимпиадник напишет мизинцами ног, по пьяни, в проруби, смской.
Я имел в виду обычных программистов, которые считают себя если не гениями, то уж лучшими в своей команде наверняка. То, что таким себя мнит каждый первый — феномен заслуживающий отдельной статьи.
Тут могут быть вопросы интерпретации, кого вы называете архитектором и кодером. Если архитектор — это средний чувак с гордым словом «architect» в названии должности и горой UML диаграмм на столе, а код он в глаза видел 5 лет назад, то кодерам без него будет гораздо лучше. Все равно вменяемой архитектуры с таким подходом он в жизнь не родит.
Повисает на input_string = 12
У меня был в точности такой же вариант, потом еще долго пилил, пока сделал костыль для случая когда среднее заканчивается на 0.5, а потом над ним делается Math.floor. В классической реализации это красиво решено.
Но если потом с этим кодом приходится иметь дело, наверное себе же дешевле будет его переписать. Это как с ремонтом в доме. Пока только протекает кран — можно подставлять кастрюльки. Но поломки, если их не чинить, накапливаются. Перегорает лампочка, забивается труба, перестает работать слив. Неисправление отнимает все больше времени.
Вроде бы, вопрос только в том, насколько быстро все рухнет. И вот здесь реальность меня удивила. Оно никогда не рухнет. Просто превратится в помойку, а удовольствия от жизни на помойке никакого.
Я вам скажу как, опыта на этот счет достаточно. Очень хреново. Я делал проверку кода, когда работал в команде. Многие программисты не могли родить простейший код даже с 20 попытки! Они привыкли сидеть на готовом, они не способны написать что-то сложнее простой композиции foo(bar())
l = 0, r = 1 ( в этом ошибка, должно быть arr.size — 1)
в конце первой итерации получаем l = 1, r = 0, и пошло плясать.
Правильно? Или уже гоню под конец дня.
Я имел в виду обычных программистов, которые считают себя если не гениями, то уж лучшими в своей команде наверняка. То, что таким себя мнит каждый первый — феномен заслуживающий отдельной статьи.
У меня был в точности такой же вариант, потом еще долго пилил, пока сделал костыль для случая когда среднее заканчивается на 0.5, а потом над ним делается Math.floor. В классической реализации это красиво решено.