Как мы ломали

Сколько он времени это писал и получил? Чисто интересно.

Ну если смотреть по ревизиям, получается где-то неделя. При том, что он первый раз залез в инвижн достаточно глубоко

Делали подобную вещь для блогов - 2 дня с учетом тестов.

Теперь вот можно судить о чистоте кода и времени, что бы в нем разобраться

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

Теперь вот можно судить о чистоте кода и времени, что бы в нем разобраться

Если вы найдёте систему, в которой можно разобраться быстрее, скажите

 

Это говорит о способностях разработчика, а не о том, что сложно разобраться в том, как IPB загружает и хранит аватары. В этом ничего сложного, на мой взгляд конечно, нет.

Говорю - таких систем много. Очень много. Правда, противоположных им - еще больше. Характеристикой таких систем является грамотное проектирование. И даже не в ООП дело, хотя уменьшение стоимости поддержки - это основное его преимущество.

Смотрели мой диф с капчей? Внимание, вопрос - сколько однотипных участков кода было вырезано и заменено на вызов метода? И второй вопрос - насколько быстрее можно было заменить капчу новому в IPB человеку с такой функцией, вместо того, что бы лазить по всему коду, опасать не пропустить очередной кусок? Кстати, кажется я тогда все же пропустил такие места... вроде в области публикации сообщений.

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

Но косяки в проектировании IPB очевидны. Или там было слабое проектирование, или проектировщик давно уже свалил и теперь все разработчки пишут кто как может.

Наоборот, проектировщик только появился.

 

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

 

P.S. И всё равно, приведите пример. Думается мне, при том уровне капитализации, который есть у IPS смотрится он вполне достойно, по сравнению со всеми цмс-форубно-блоговыми системами некорпоративного уровня.

Наоборот, проектировщик только появился.

Лучше поздно, чем никогда Учитывая продвигаемый со стороны PHP Team отказ от PHP4, остается надеятся на замечательный продукт... в будущем, которое увы для нас не актуально - работать нужно уже сейчас.

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

Класс капчи есть, но там только генеразия картинок, а работу с базой я там не увидел. Ну или плохо смотрел (ибо мне в голову придти не могло, что кто-то сделает функции но при этом не станет их вызывать ) или добавилось после 2.3.2.

P.S. И всё равно, приведите пример. Думается мне, при том уровне капитализации, который есть у IPS смотрится он вполне достойно, по сравнению со всеми цмс-форубно-блоговыми системами некорпоративного уровня.

О. если вы про существующие на рынке системы, то я пас - просто не изучал их. Радость в душе вызывал софт написанный на Руби с использованием рельсов (RoR). Наша CMS нравится, хотя есть уже приличный список того, что хотелось бы архитектурно изменить, если будет время

или добавилось после 2.3.2.

Это было уже в 2.2.2 Но в тот момент ребром стала проблема оптимизации парсинка и других вещей, видимо на этот момент забили.

 

А своё всегда нравится больше.

А своё всегда нравится больше.

 

Не всегда Смотришь, порой, на свое через год - и ужасаешься

Не всегда Смотришь, порой, на свое через год - и ужасаешься

Быстренько переписываешь - и снова счастлив

А может быть и наоборот - медленно и вдумчиво рефакторишь с применением тесткейсов.

Время рефакторинга, думается мне, обычно много меньше времени, которое должно пройти для

Смотришь, порой, на свое через год - и ужасаешься

там писалось к "быстренько переписываешь". когда имеется нормально отрефакторенный код продукта переписывать его как правило не приходится, расширять да - переписывать нет.

Тогда уж правильнее так:

медленно и вдумчиво пишешь с самого начала с применением тесткейсов

Был бы интерес

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

На самом деле за год квалификация может настолько вырасти, что не просто рефакторишь, но просто "с нуля" перепроектируешь. У нас так получилось, что для движка сайта было время написать первую версию, поиграться с ней, за это время разработчик почитал книжек, походил на мастерклассы... и в итоге переписали все фактически с нуля =)

О чем и разговор.

Если написано хорошо -> всё доелывается быстро.

Если плохо -> то пишется с нуля.

 

Это я к тому, что не вижу хорошего примера к этому сообщению, написать с нуля - это же уже не рефакторинг

смотря что ты понимаешь под словом "рефакторинг"

Стараюсь выработать похожую на принятую терминологию. Разве стоит называть переписку с нуля рефакторингом...

 

Хотя да, отчасти, только в таких случаях всё-же говорят "пишем с нуля"?

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

Все равно хоть с нуля, хоть с пол нуля. Если внешнее поведение приложения не изменится после действий по изменению внутренней структуры, то это рефакторинг.

 

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

Даже не буду спорить о возможности переписать большой проект "с нуля" не изменив внешнее поведение. Попробуйте.

Синоним слова рефакторинг - реорганизация. От этого и отталкивайтесь. И от того, что рефакторинг по своей сути подразумевает мелкие итерации.

Если нужно более авторитетное мнение, читаем Фаулера.

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