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

H>>>Это теория. На практике бывают модули, которые весьма сильно связаны с другими. Что тогда?

SA>>Как что? Переписывать нафиг. Зависимости оформлять интерфейсами. А в юнит-тестах интерфейсы эмулировать mock-ами.

H>Только есть проблемы.

H>1) Переписать все очень дорого
Если написана через одно место старая система без ориентации на тестируемость, то юнит тесты действительно бесполезны, их надо было использовать изначально. Теперь остаётся только героически поддерживать .

H>2) Переписать все очень долго
Конечно, никто сладкой жизни и не обещал.

H>3) С высокой вероятностью получится то-же самое дерьмо что было в начале
Зависит от квалификации разработчиков, если такие же крутые парни, которые считаю тесты профанацией, то действительно получится тоже самое.

H>Очень часто "переписчики" страдают тем, что не могут разобраться в чужом коде, либо считают это ниже своего достоинства.
Бывает и такое, вы хотите об этом поговорить?

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

H>1) Переписать все очень дорого
H>2) Переписать все очень долго
H>3) С высокой вероятностью получится то-же самое дерьмо что было в начале
Довелось мне учавствовать в проекте, которые писали гении, похожие на тех, которых обсуждаем. Сомневаюсь, что тот проект когда-то удастся переплюнуть в плане "через ж...", круче того проекта я даже представить не могу, как ТО переплюнуть! Свой встроенный кривой и глючный язык программирования написали на основе XML (причем нестандартного XML), свой движок для рендеринга Html на основе этого мегаязыка, свой парсер XML, своя реализация строк, свой сервер приложений (во всем этом куча багов), свои протоколы передачи данных — все свое, даже что-то похожее на базу данных было свое, свой SQL Like язык запросов к этой мегабазе, наверно еще много чего интересного своего забыл. Это свое работает немного быстрее библиотечных средств (за счет того, что например не проверяются ошибки переполнения буфера, память выделяется с запасом путем умножения на константу и тому подобные приколы). Архитектура — все связано со всем. Передача параметров происходит через глобальные переменные (через глобальную map), в этой мапке сотни разных параметров, которые не удаляются . За счет этого система бесконечно расширяемо абсолютно без переписывания (в одной части кладешь что-то в мапку, в другой части это значение как-то влияет на результат нужным образом ), но нужно просто быть гением и умудряться держать в голове все связи. Баги фиксятся следующим образом — если находится ошибка, то добавляется if (данные, которые приводят к ошибке) return нужный результат, в результате имеем такую кучу мегавложенных ветвлений, иной раз на 5000 строк, что только гений разберется как это работает. Качество кода таково, что код вида:

Bool IsNumber (string str) {
    return (str.Replace ("0", "").Replace ("1", "").Replace ("2", "").Replace ("3", "").Replace ("4", "").Replace ("5", "").Replace ("6", "").Replace ("7", "").Replace ("8", "").Replace ("9", "").Length == 0);
}

я даже не называю смешным, я считаю что это сравнительно хороший код — я встречал гораздо более крутые шедевры творчества в свое время в том мегапроекте (довольно известном в хорошем плане с внешней стороны кстати, если не лезть внутрь). В общем ... первый год все хорошо. Второй удовлетворительно. Через 4 года уже сам черт не разберет, начинают привлекать больше людей для сохранения темпа. Но багов все больше и больше, темпы выдерживать не получается, релиз откладывается больше чем не год (за год можно было бы переписать с нуля). В результате конкуренты, которые изначально были сзади, вырываются вперед, заказчики переходят постепенно к конкурентам. Результат — проект умирает, компания поглощается конкурентами. Которые раньше очень сильно отставали.

Так вот, ИМХО — если забивать на качество кода, писать все на костылях, про рефакторинг говорить что это ненужная вещь — то все пойдет именно по такому сценарию (хоть и те шедевры переплюнуть практически невозможно). Хотя ... при таком процессе разработки да, можно на первом этапе сколотить очертененные деньги на первых порах, как не парадоксально.

PS Из того проекта вынес просто маниакальное желание писать понятный легко поддерживаемый код, чтоб круче чем у Макконела было все. Хреново напишу если — ночью кошмары будут и угрызения совести . Так вот, всем, кто оправдывает процесс разработки с помощью костылей, бездумно, как можно быстрее, не задумываясь о будующем — желаю поучавствовать в подобном проекте, возможно мнение бы и поменялось.

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

Прорвало, что называется
Подписываюсь под каждой строчкой. Сам уже насмотрелся на километры макарон, на if 10-й вложенности, на жоцкий хардкод и "реестр глобальных переменных".
Самое забавное, что находятся люди, которые в этом хозяйстве как-то разбираются! У меня просто моск сворачивается

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

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

H>>1) Переписать все очень дорого
H>>2) Переписать все очень долго
H>>3) С высокой вероятностью получится то-же самое дерьмо что было в начале
E>Довелось мне учавствовать в проекте, которые писали гении, похожие на тех, которых обсуждаем. Сомневаюсь, что тот проект когда-то удастся переплюнуть в плане "через ж...", круче того проекта я даже представить не могу, как ТО переплюнуть!
Уррраааа, я не одинок. У меня _почти_ такой проект. Немного получше всё-таки. Хотя с какой стороны посмотреть. Веб приложеньице на пять страниц, класса "галочки порасставлять и имейлы разослать по результатам". Но ЭТО умудряются писать уже третий (или четвертый) год. Я отсюда пока что не ухожу. Тешу себя надеждой, что опыт в подобных проектах — это очень ценный опыт. Ну и плюс, дело движется в лучшую сторону (силами пары энтузиастов, включая меня).

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

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

H>Переписать все нафик — это любимое занятие программера, который мнит себя самам умным.
H>Только есть проблемы.

А никто вроде и не говорит что надо переписывать сразу всё. Надо по частям. В борьбе со сложностью пока придумали только один способ — "разделяй и властвуй".

H>1) Переписать все очень дорого
H>2) Переписать все очень долго

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

H>3) С высокой вероятностью получится то-же самое дерьмо что было в начале

Ну это только от исполнителей зависит.

H>Очень часто "переписчики" страдают тем, что не могут разобраться в чужом коде, либо считают это ниже своего достоинства.

Ну вот сейчас я начинаю переписывать проект. Ребята сделали прототип Web-приложения на Java, который как-то задышал, продемонстрировали заказчику — тому понравилось, всё хорошо. Но если оставить текущую архитектуру — проект неизбежно загнётся через пару лет. Spring-а нет (всё на статиках и HttpContext), для подключения к EIS вместо имплементации коннектора JCA — самописный аналог, про unit test-ы никто не слышал, про maven тоже. Окончательно меня добил вызов web redirect-а в коде обработки ответа в глубине протокола взаимодействия с EIS. Тестировать такое unit test-ами разумеется невозможно, нужно переписывать. К счастью это ещё не слишком поздно.

Ух! "Приятно" видеть, что я не одинок... жаль, что текст без хеппи-энда.

A>В данной сфере твой интерес к изучению новых технологий и грамотного проектирования не оценят никогда .

MWAHAHA! Ещё один знаток военных технологий
Пообщайся, что ли, на досуге с Gaperton'ом о качестве и постановке процесса в военных разработках.

Уже на баше появилась данная фигня.
E>Bool IsNumber (string str) {
E> return (str.Replace ("0", "").Replace ("1", "").Replace ("2", "").Replace ("3", "").Replace ("4", "").Replace ("5", "").Replace ("6", "").Replace ("7", "").Replace ("8", "").Replace ("9", "").Length == 0);
E>}

Вот еще пример совместной работы в некоторых фирмах:


из такой вещи

    if(fopen_s(&fp, path, _T("rb")) != 0)

для удобства работы с разными платформами было сделано вот так

#ifndef WIN_SOMETHING
        if(fopen_s(&fp, path, _T("rb")) != 0)
#else
        fp =fopen(strPath, _T("rb")) ;
        if(!fp)
#endif

в итоге после изменений сделанных некоторыми людьми, на свет появился вот такой код

#ifndef WIN_SOMETHING
        fp = fopen(path, _T("rb")) ;
        if(!fp)
#else
        fp =fopen(path, _T("rb")) ;
        if(!fp)
#endif

Отгадайте национальность программиста, сделавшего последние изменение!

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

ZT>Люди добрые, хочу услашать Ваши мнения по поводу

ZT>следующей ситуации.

ZT>Мне 22 года. Работаю в одной средней компании, занимающейся написанием софта для автоматизации

ZT>предприятий на с++, уже около 3-х лет. Это моя первая и пока последняя компания Программистов в конторе мало — 10 человек.
ZT>Пришел я в эту компанию на 4 курсе института, ничего не смыслящим в промышленном программировании.
ZT>За 3 года я очень сильно повысил свои знания в этом любимом мною занятии Освоил и стал применять на практике в
ZT>рабочих проектах STL, boost, шаблоны. До меня в этой конторе никто этого не применял. Поразило меня непонимание остальными сотрудниками данных технологий и их полное обхаивание и принижение, причем без всякой должной аргументации. Всё чего не знают, страшатся
ZT>В связи с тем, что никто и слухом не слыхивал об STL, "отцами офиса" было написано куча сомнительных "велосипедов" с гнилым содержанием.
ZT>Разработка софта в конторе просто катастрофическая. Багов неимоверно. Всё возникают мысли, как реальные люди потом с этим софтом работают...
ZT>Что такое программистская документация начальство не знает и не видит в нем никакой пользы. Ведь оно будет отнимать драгоценное время на написание убогого софта. Про всякие там UML я вообще молчу, когда я об этом заикнулся, то меня послали глубоко и надолго...
ZT>Основной девиз — максимально быстро удовлетворить требования заказчика.
ZT>Но я не понимаю, как можно так всё писать через одно место. Ведь мы пишем софт, который после его создания не кладется в черный ящик и не забывается на следующий день. Программируем "на коленке"...
ZT>когда я начинаю абстагироваться от поставленной задачи и пишу несколько более универсальное и эффективное решение с возможностью расширения, то на меня смотрят как на идиота и считают, что это всё изврат и полная ерунда. Но уже неоднократно было такое, что мои абстрагированные решения в будущем позволяли более просто и быстро решить новую задачу. Но этого никто не замечает.
ZT>В таких условиях я себя чувствую как белая ворона. Нет понимания со стороны других сотрудников.

ZT>Меня начинает тошнит уже от такого гнилого процесса разработки.


ZT>Неужели вот так и должно быть?
ZT>Неужели большинство контор так и разрабатывает софт???

вы на какой машине ездите, в каких странах отдыхаете?
а почему не на ... и не в ...

вот и заказчики\собственники довольствуются чем есть, что устраивает.

Бизнес есть для зарабатывания денег, а не способ просрать бабло на красивые кнопочки и формочки.
Последнее в ИТ легче всего реализуется

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

ZT>Люди добрые, хочу услашать Ваши мнения по поводу

ZT>следующей ситуации.

Работал аналогично — только у меня еще половина работы была никому не нужна — стошнило — ушел ...
думаю — что надо развиваться всегда ...
если С++ программер не знает stl который идет в стандарте ну тогда не знаю —
это как врач который до сих пор лечит воспаление не антибиотиками а кровопусканием ... что будет эффективнее ?
По поводу буста — может его знать и не необходимо — но почему вы купили себе скажем форд , а не ездите на копейке?
она же ездит
по поводу буста —
Я практически буст не пользую ,но не думаю что стремление узнать чтото новое делает меня хуже ...
а знание без применения ?
Просто надо находить золотую середину между воткнуть все супермеганавороченное в новый проект или
сдать его побыстрее ...

О! Я не одинок в своей любви к printf.

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

T>О! Я не одинок в своей любви к printf.

Чувак! Нас много!!!

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

H>>Очень часто "переписчики" страдают тем, что не могут разобраться в чужом коде, либо считают это ниже своего достоинства.

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

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

Я не верю в наличие кода, который им нельзя исправить:) Даже sendmail (я его всем привожу как образец "смотрите, что получается, если 20 лет развивать методом построения нашлёпки на нашлёпке без изменения начального дизайна) и то может быть достаточно легко приведён в порядок, лишь бы за него взяться как следует.

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

H>cout << format("%s at %s with %s\n") % x % y % z;

H>или

H>printf("%s at %s with %s\n", x, y, z);

H>Первый из них — кошерный, новомодный, typesafe, второй — древний и без проверки типов. Теперь скажите честно, какой код читабельней?

Скорее первый. Хотя я бы предпочёл что-то вида

cout << format"%s at %s with %s\n", x, y, z);

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

SD>>Да — именно так. Из-за нехватки квалификации и нежелания эту самую квалификацию поднимать. Закостенелость и замшелость. Это та причина, по которой немолодые конторы имеют крайне заторможенный процесс развития и реакцию.
H>Немолодые конторы доказали жизнеспособность своей бизнес-модели, в то время как молодые, при всех boost'ах и прочих монстрах как правило нет.

Зависит от степени замшелости. Впрочем, это уже обсудили.

В маленьких конторах — часто. Сам созерцал очень долго, как компания все прилаживала и прилаживала безнадежно устаревшее ПО, созданое еще уйму лет назад (двузначное число), латала его и т.д., пока не разбежались наконец все разработчики. Идеология руководства компании сводилась не к выпуску продукта, а к ублажению конкретно взятого клиента: "Отложим выпуск версии, которая не будет падать по полнолуниям, будет делать еще то и это, на... ну на потом, короче. Главное заменить те пуговицы на перламутровые, как заказал вооон тот клиент". В результате этого все конкурирующие компании обошли данную, хоть и имели стартовую позицию намного хуже.

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

ZT>Да нет. Можно и без изысков ООП хорошо писать. Например, тот же STL.

Пардон — за оффтоп — но где в STL вы нашли ООП? Где наследование, полиморфизм подтипов, инкапсуляция данных наконец? Ведь STL спроектирована с идеей разделения алгоритмов и данных (о ужас, с точки зрения апологета ООП).

(ПС наследование в итераторных тегах используется для реализации параметрического полиморфизма).

Работал некоторое время в фирме E***. Кто с ними общался — тот поймёт.

Так вот — их флагманский продукт, написанный на VB6 в 90-х годах, использовал (через .net interop) СОМ-объекты, написанные на С# (в 2005-2006 годах). С#-объекты, в свою очередь, использовали самописный протокол связи, реализованный в виде unmanaged С++ объектов (написанных ориентировочно в начале 2000-х годов на VC6). Эта термоядерная смесь технологий падала примерно каждые полчаса, и в отладчик загружалась около 20 минут