Часто ли вы застряете на мелочах?

Пример. Допустим, у вас стоит задача создания списка простых объектов из данных в плоском формате (к примеру, CSV). Можно сделать 2-мя способами:

1. Сделать простое преобразование в цикле (парсить строку для каждого свойства объекта).
2. Написать свою библиотеку, которая позволит вам преобразовывать все 1-м вызовом метода (пометить каждое свойство объекта аттрибутом, в котором будет задан формат преобразования).

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

Допустим, написание библиотеки + тесты + документация займет 1 неделю. А написание простого цикла и парсинга по формату -- максимум 30 минут. При этом, понятное дело, у проекта ограничен и бюджет и сроки.

Какой бы вариант выбрали вы? Какие видите проблемы в простом парсинге значений в цикле?

Здравствуйте, 0K, Вы писали:

0K>Какой бы вариант выбрали вы? Какие видите проблемы в простом парсинге значений в цикле?

Отдельную библиотеку городить это перебор, сделал бы shared class который не торчит наружу с функцией parse.

Здравствуйте, UA, Вы писали:

0K>>Какой бы вариант выбрали вы? Какие видите проблемы в простом парсинге значений в цикле?
UA>Отдельную библиотеку городить это перебор, сделал бы shared class который не торчит наружу с функцией parse.

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

Реально получается 1 неделя против 30 минут.

Ну или поставим вопрос по другому. На какое соотношение вы готовы ради такой "красоты" (то есть если простым способом делается 30 минут, сколько готовы потратить на сложный способ)? И какую проблему видите в ручном парсинге, если нет дублирования кода (только дублирование поведения)?

Здравствуйте, 0K, Вы писали:

0K>Ну или поставим вопрос по другому. На какое соотношение вы готовы ради такой "красоты" (то есть если простым способом делается 30 минут, сколько готовы потратить на сложный способ)? И какую проблему видите в ручном парсинге, если нет дублирования кода (только дублирование поведения)?

Проблема одна: кривые велосипеды + поддержка версионности форматов + поддержка валидации формата.
P.S. XML/XSD частично решает эту проблему.

0K>Какой бы вариант выбрали вы? Какие видите проблемы в простом парсинге значений в цикле?

Нельзя писать то, что не требуется прямо сейчас. Даже если оно понадобится через 15 минут. Это мешает естественной эволюции дизайна.

Здравствуйте, 0K, Вы писали:
0K>Часто ли вы застряете на мелочах?
0K>Какой бы вариант выбрали вы? Какие видите проблемы в простом парсинге значений в цикле?
простой парсинг в цикле.

Здравствуйте, 0K, Вы писали:

0K>Какой бы вариант выбрали вы? Какие видите проблемы в простом парсинге значений в цикле?

если самому писать, то простой цикл.
в частном случае с CSV можно вполне погуглить готовое решение минут за 10

Здравствуйте, ilnar, Вы писали:

I>если самому писать, то простой цикл.
I>в частном случае с CSV можно вполне погуглить готовое решение минут за 10

Для CSV готовое решение. Но там нет создания экземпляра объекта -- просто список в виде строк. Эти строки нужно привести к числам, DateTime (все в разном формате) + создать объект и рефлексией установить значения полей.

Здравствуйте, UA, Вы писали:

UA>Проблема одна: кривые велосипеды + поддержка версионности форматов + поддержка валидации формата.
UA>P.S. XML/XSD частично решает эту проблему.

В таком формате данные возвращает сторонний сервис -- ничего не поделаешь. Такова реальность.

Здравствуйте, 0K, Вы писали:

0K>Какой бы вариант выбрали вы? Какие видите проблемы в простом парсинге значений в цикле?
Сделал бы так:
1) Вначале ASAP имплементация просто в цикле + тест. Интерфейс выхова простой — на входе строка, на выходе список распарсенных данных;
2) Когда выяснится, что этот вариант чем то не устраивает, переписываю и переключаю на новую реализацию. Прогоняю тест — он не падает, значит сделал.
Но, если буду на 100% уверен, что через месяц один хрен все переписывать и один хрен нужно будет делать более сложную реализацию, а показывать что все работает срочно не надо, сделаю сразу шаг 2, ибо ленив, и лишнюю работу делать не хочется

Здравствуйте, 0K, Вы писали:

0K>Для CSV готовое решение. Но там нет создания экземпляра объекта -- просто список в виде строк. Эти строки нужно привести к числам, DateTime (все в разном формате) + создать объект и рефлексией установить значения полей.

http://filehelpers.sourceforge.net/]данеможетбыть[/url].

А если по теме — редко, но бывает, что застреваешь на какой-нибудь мелочи, возишься с ней несколько часов, потом находишь простое решение и думаешь — Как же я сразу до него не догадался? Самый эффективный выход из такой ситуации ИМХО — обсудить проблему с коллегами, если даже не смогут решить задачу для тебя, то возможно процесс обсуждения поможет упорядочить мысли и найдешь решение сам.

Здравствуйте, Ахмед, Вы писали:

А>http://filehelpers.sourceforge.net/]данеможетбыть[/url].

Не попадалась, нужно будет посмотреть что там есть.

А>А если по теме — редко, но бывает, что застреваешь на какой-нибудь мелочи, возишься с ней несколько часов, потом находишь простое решение и думаешь — Как же я сразу до него не догадался? Самый эффективный выход из такой ситуации ИМХО — обсудить проблему с коллегами, если даже не смогут решить задачу для тебя, то возможно процесс обсуждения поможет упорядочить мысли и найдешь решение сам.

Не эта ситуация. Вы сразу видите простое решение. Простое, понятно, быстрое. Но там дублирование логики (не кода а логики). А более сложное занимает, допустим, в 20 раз больше времени -- никакого профита кроме якобы того, что не будет дублирования логики.

0K>Для CSV готовое решение. Но там нет создания экземпляра объекта -- просто список в виде строк. Эти строки нужно привести к числам, DateTime (все в разном формате) + создать объект и рефлексией установить значения полей.

Не факт что CSV помещается в памяти. Что цикл, что класс, что либа делается максимум за пару часов.
Есть и "сложные решения", например для Qt есть plain-text SQL driver, который работает с CSV как SQL таблицей

Для Qt я бы написал "парсер" за 3-5 минут.

class CSVReader
{
public:
    CSVReader(QString file) :
       cvsFile(file)
    {
        file.open(QIODevice::ReadOnly);
        if(!file.isOpen())
           throw something;
    }

    bool readNextLine(QList<QByteArray> &outData)
    {
        QByteArray line = file.readLine();
        if(line.size()==0)
           return false;
        outData = line.split(",");
        return true;
    }

private:
    QFile cvsFile;
}

Понятно, что это упрощенная версия без валидации количества полей. Добавить раз плюнуть.

Здравствуйте, 0K, Вы писали:

0K>Здравствуйте, ilnar, Вы писали:

I>>если самому писать, то простой цикл.
I>>в частном случае с CSV можно вполне погуглить готовое решение минут за 10

0K>Для CSV готовое решение. Но там нет создания экземпляра объекта -- просто список в виде строк. Эти строки нужно привести к числам, DateTime (все в разном формате) + создать объект и рефлексией установить значения полей.

вот зачем все эти сложности?

Здравствуйте, Handie, Вы писали:

0K>>Для CSV готовое решение. Но там нет создания экземпляра объекта -- просто список в виде строк. Эти строки нужно привести к числам, DateTime (все в разном формате) + создать объект и рефлексией установить значения полей.

H>Не факт что CSV помещается в памяти. Что цикл, что класс, что либа делается максимум за пару часов.
H>Есть и "сложные решения", например для Qt есть plain-text SQL driver, который работает с CSV как SQL таблицей

Фишка в библиотеки авто-конвертации с помощью рефлексии.

Здравствуйте, ilnar, Вы писали:

0K>>Для CSV готовое решение. Но там нет создания экземпляра объекта -- просто список в виде строк. Эти строки нужно привести к числам, DateTime (все в разном формате) + создать объект и рефлексией установить значения полей.

I>вот зачем все эти сложности?

Понятия не имею. Но люди делают. Может специально, чтобы показать видимость работы? А может и думают что это более правильно.

H>>Не факт что CSV помещается в памяти. Что цикл, что класс, что либа делается максимум за пару часов.
H>>Есть и "сложные решения", например для Qt есть plain-text SQL driver, который работает с CSV как SQL таблицей

0K>Фишка в библиотеки авто-конвертации с помощью рефлексии.

А может дурью не заниматься? авто-конвертация и рефлексия никак не относятся к чтению CSV. CSV — это формат данных, не более того. ORM можно наворачивать поверх CSV "драйвера".

Но я бы навряд-ли стал делать хренотень с маппингом поверх CSV, ипортировал бы в SQL лучше

Здравствуйте, 0K, Вы писали:

0K>Пример. Допустим, у вас стоит задача создания списка простых объектов из данных в плоском формате (к примеру, CSV). Можно сделать 2-мя способами:
0K>Какой бы вариант выбрали вы? Какие видите проблемы в простом парсинге значений в цикле?

Грязный цикл сразу, если еще где нужно будет, скопипащу, после 3-го случая пойму все подводные камни и сделаю либу узкоспециализированную.

Здравствуйте, 0K, Вы писали:

0K>Часто ли вы застряете на мелочах?
0K>...
0K>Допустим, написание библиотеки + тесты + документация займет 1 неделю. А написание простого цикла и парсинга по формату -- максимум 30 минут. При этом, понятное дело, у проекта ограничен и бюджет и сроки.

Так, по-моему, Вы сами написали ответ на свой вопрос. Если жмут сроки, то простой цикл и делов-то. Если проект — "сделал и забыл", то, имхо, библиотеки не нужно. Серьезная экономия времени преобладает. Если же проект долгосрочный, то все это можно обсудить при планировании эстимейта. Опять же, можно сделать сначала в виде цикла, и если через время потребуется, то порефакторить и переписать "красиво".

Когда пишу "для себя", то всегда делаю ч-з либы. Это не требует большого документирования и юнит-тестов, время не критично, но дает возможность в очередной раз применить "хороший стиль". На работе, обычно, для основного проекта пишутся либы, которые потом реюзаются во вспомогательных утилитах. Т.е. как таковых "костылей" нет. Для диагностических поделок, которые, кроме программеров никем не используются пишется цикл или вообще копи-паст.

Здравствуйте, 0K, Вы писали:

0K>Часто ли вы застряете на мелочах?

0K>Пример. Допустим, у вас стоит задача создания списка простых объектов из данных в плоском формате (к примеру, CSV). Можно сделать 2-мя способами:

0K>1. Сделать простое преобразование в цикле (парсить строку для каждого свойства объекта).
0K>2. Написать свою библиотеку, которая позволит вам преобразовывать все 1-м вызовом метода (пометить каждое свойство объекта аттрибутом, в котором будет задан формат преобразования).
мне кажется, что тему вы назвали неправильно
не вижу тут мелочей, я бы назвал это "страстью к обобщению"
стремления к обобщениям присущи некоторым программистам
лично у меня есть "это".
я люблю выделять подзадачи и выполнять их в отрыве от контекста использования
да, это овердизайн
да, это мечты о дальнейшем реюзе
но мой немалый опыт работы в командах подсказывает мне, что я иду в правильном направлении
меня пугают "быстрые" решения, которые делают члены команды. они дублируют друг друга (в том числе и баги), а рефакторинг слишком опасно делать, ибо "код работает, не трожь"
добиваться хорошего coverage довольно затратно при таком подходе, а ведь начальство хочет цифры, поэтому тесты тоже приходится дублировать
в итоге имеется куча библиотек с похожими алгоритмами, а ведь реюз был бы очень кстати
мне недавно предлагали выводить в формате CSV, но я убедил начальство, что именно этот формат ненужен
потому что он для меня сложен
да, да, он сложен
если вы хотите вывести значения столбцов через запятую — то это одна задча, и она проста для меня
если же вы упомянули формат CSV, то будьте любезны поддерживать его полностью (в том числе для возможности экспорта данных)
я перфекционист и это негативно влияет на мою продуктивность, но положительно влияет на code base и дальнейшую работу всей команды
я не пишу для себя, я пишу для всех и, как мне кажется, это главная особенность командной разработки

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

первая ссылка из гугла про нюансы формата: http://creativyst.com/Doc/Articles/CSV/CSV01.htm