разработка через ж... - О работе

Здравствуйте, 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 Из того проекта вынес просто маниакальное желание писать понятный легко поддерживаемый код, чтоб круче чем у Макконела было все. Хреново напишу если — ночью кошмары будут и угрызения совести

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

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

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

В виллариба и виллабаджо снова дедлайн. Пока ребята из виллариба, чертыхаясь, делают дизайн на div'ах, парни из виллабаджо быстренько свестали всё на таблицах и уже давно е##шат друг друга в квейк.

... << RSDN@Home 1.2.0 alpha 4 rev. 1038>>

ZT>За 3 года я очень сильно повысил свои знания в этом любимом мною занятии

Освоил и стал применять на практике в
ZT>рабочих проектах STL, boost, шаблоны. До меня в этой конторе никто этого не применял.

Это очень правильное решение, придти в контору, объяснить всем что они дураки, скачать пятьдесят мегабайтов буста,
развернуть его в сто пятьдесят мегабайт исходников и закачать его в VSS или чего там

Думаю народ сразу будет резко счастлив...

Вероятно Вы молоды, горячи, переоцениваете свои силы и недооцениваете опыт других. Когда мне было 22, я думал что я самый умный, почему-то спустя пятнадцать лет я уже в этом не уверен...

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

[]

ZT>Основной девиз — максимально быстро удовлетворить требования заказчика.

Так и должно быть. Все остальное — вторично и должно служить этой цели.
Докажи своему руководству/коллегам, что boost/STL/<you-name-it> позволяет удовлетворять заказчика еще лучше.

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

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

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

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

ZT>Освоил и стал применять на практике в
ZT>рабочих проектах STL, boost, шаблоны. До меня в этой конторе никто этого не применял. Поразило меня непонимание остальными сотрудниками данных технологий и их полное обхаивание и принижение, причем без всякой должной аргументации. Всё чего не знают, страшатся

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

основная мотивация — прочитал книжку, хочу применить, а колеги не дають. попробуй четко ответить на вопрос:
— выгода от внедрения?
— риски?

ZT>Разработка софта в конторе просто катастрофическая. Багов неимоверно. Всё возникают мысли, как реальные люди потом с этим софтом работают...

немерено, это не число

попробуй числами оценить ситуацию. Почему от внедрения стл+буст+шаблонов ситуация станет лучше?

ZT>Что такое программистская документация начальство не знает и не видит в нем никакой пользы. Ведь оно будет отнимать драгоценное время на написание убогого софта. Про всякие там UML я вообще молчу, когда я об этом заикнулся, то меня послали глубоко и надолго...

спорный вопрос, в использовании юмл на разных стадия тоже есть преимущества и недостатки, можно делать как РУП с кучей доки и юмл, можно пробовать более agile подходы. Вообщем если продукты сделаны/внедряються/работают и в разработку можно подключать новых людей с без особых проблем, ситуация с документирования удовлетворительна

ZT>Основной девиз — максимально быстро удовлетворить требования заказчика.
правильный дивиз, что с ним не так?
попробой абстрагироваться, а то прочитал книжку, в ней красивый мир с бустом и патернами, а на практике не важно, что там

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

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

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

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

а внедрять новые идее лучше в следующих версиях, которые разрабатываються с нуля/серьезно переписываются, и может оказаться что это будут не буст/шаблоны а напримеш шарп

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

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

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

Z>Нормальная ситуация для долговечного продукта, который приносит деньги. Это вам не стартап где сразу можно напихать самых навороченных библиотек.Представим ситуацию, что вы написали какую то часть, использовали STL, boost и т.д., а потом сказали да ну вас нафиг с вашей осталостью, пойду писать действительно великие продукты

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

А как вы думаете если он допустим не использовал STL или boost а плюнул и написал свой велосипед, а потом ушёл куда то в другое место писать "великие продукты".
А коллегу попросили. А колега не в курсе дела. Как думаете что будет делать коллега? Правильно он будет разбираться как на этом велосипед е с квадратным и овальным колесом да ещё ис купкой маленьких колёскиков прикрученных к рулю можно ездить.
А написал он на STL или boost.
Что будет делать коллега? Правильно. Полезит в документацию, на крайняк прийдёт на rsdn и спросит. "Эй мужики! Вот тут код, непойму как он и что делает..." Тут же ему народ и растолкует...
Так что...

ZT>Меня начинает тошнит уже от такого гнилого процесса разработки.
ZT>Неужели вот так и должно быть?
ZT>Неужели большинство контор так и разрабатывает софт???

Если кратко, то — да. В России — да.

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

ZT>Неужели вот так и должно быть?

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

А потом попросят вашего колегу, который конечно не знает ничего исправить какие то мелкие баги. Сколько вы думаете займет у него времени на осваивание всего этого STL, boost и т.д.?
Если все таки хочется что то поменять то надо вскарабкиваться повыше, типа начальник отдела разработки и уже оттуда спускать свои новшества.

A>Очень всё правильно сказано, серьёзно правильно. Кроме одного — всё это не оправдывает рассказанный процесс разработки и коллег автора.

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

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

Сейчас работаю с неправильным процессом — очень доволен.

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

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

Совет: вали оттуда в темпе.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

H>Сейчас работаю с неправильным процессом — очень доволен.

Не путайте "правильность" и "тяжеловесность" процесса. Вы описываете именно тяжеловесный (очень тяжеловесный) процесс, который применен не к месту.

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

A>>Очень всё правильно сказано, серьёзно правильно. Кроме одного — всё это не оправдывает рассказанный процесс разработки и коллег автора.

H>Только молодой и наивный человек может думать что процесс разработки может быть легко изменен и что результат будет резко положительным если применять правильные технологии.
Да это так, кстати автор и не скрывает свою молодость. Что значит правильные технологии? Каков критерий правильности? АВ посте автора был лишь рассказ о явно странных решениях. Отказ от stl в сугубо прикладном продукте, даже вернее непонимание как им пользоваться, свидетельствует о явной нехватки профессионализма в коллективе. Тут техпроцесс вообще не причёмю

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

Кто вам сказал, что правильность заключается в использовании UML? Это часом не введении к мануале по розе написано?

Утверждая, что юнит тесты туфта эквивалентно утверждению "я не умею ими пользоваться и не хочу учиться". Я вот после того как начал их применять вообще перестал понимать как это я без них умудрялся разрабатывать раньше, дело не в правильности, а в технической поддержке рефакторинга. Без них после любого рефакторинга надо скрестить пальцы и думать где же свалится. Какая ещё среда для юниттестов? Имхо решарпера для запуска в студии и запуск из командной строки с формированием отчёта при автобилде хватает выше крыши

.

H>Сейчас работаю с неправильным процессом — очень доволен.

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

H>Очень правильная мысль! Процесс должен быть адекватен задаче и команде, а то в команде где 5 человек — UML, юнит тестирование, все как "у взрослых" — а в реале разбазаривание времени на "туфту"

Конечно, нафига писать юниттесты, документацию, использовать контроль версий! Реальные пацаны могут чиста сесть и всё написать

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

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

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

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

ZT>Неужели вот так и должно быть?
Нет

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

Совет №1. Пока молодной — сваливай оттуда. В таких конторах научиться чему-либо сложно, а тебе сейчас учиться важнее всего.
Совет №2. Побереги нервы, не пытайся доказать свою правоту. Если люди в течние 5 и более лет так работают, то они уверены что это вполне правильный подход к разработке.

Программистов в конторе мало — 10 человек.
ZT>Пришел я в эту компанию на 4 курсе института, ничего не смыслящим в промышленном программировании.
ZT>За 3 года я очень сильно повысил свои знания в этом любимом мною занятии

Освоил и стал применять на практике в
ZT>рабочих проектах STL, boost, шаблоны. До меня в этой конторе никто этого не применял. Поразило меня непонимание остальными сотрудниками данных технологий и их полное обхаивание и принижение, причем без всякой должной аргументации. Всё чего не знают, страшатся

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

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

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

Хочется просто поддержать товарища

1. Надеюсь, это твоя не последняя компания, и надеюсь так же, что непоследней она станет в ближайшее время

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

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

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

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

N>А как вы думаете если он допустим не использовал STL или boost а плюнул и написал свой велосипед, а потом ушёл куда то в другое место писать "великие продукты".

Совершенно с вами согласен, но автор написал что там большинство(10 человек) сидят на этих велосипедах и наверно все таки разбираются в них

.

2alpha21264

N>Ну... А Вы знаете почему военные до сих пор лампы применяют? Ну вот.

Потому что обыкновенный транзистор выходит из строя под воздействием EMP.

Знакомо и актуально. Работаю на госпредприятии последние 1.5 года (после окончания университета) и наблюдаю это дело с момента приёма и в более выраженном виде.

Много чего передумал за это время... Похоже это системное явление.
Основная проблема во всём этом — избыток перекосов и парадоксальных ситуаций.

Например подходит ко мне за помощью девочка и спрашивает почему у неё из такой-то таблицы цифры неправильно сортируются. В таблице для поля "месяц" отведено char(10) — меняю на tinyint и бурчу про типы данных. На след. день девочка приходит и обиженно говорит, что в старых отчётах нолики перед цифрами 1-9 не рисуются — заказчики в панике.
Таким образом, я оказываюсь засланцем-вредителем, "слишком умным" и т.п., а те, у которых "char(10)" и хранение незначащих ноликов в БД не вызывало вопросов — белые и пушистые.
Один из многих и самый простой случай.
ясно, что нужно линейкой по рукам, но у меня на это нет не полномочий, ни желания — приходиться убеждать и договариваться в вопросах, которые в иных местах даже не появлялись бы.

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

И всё бы ничего — пусть девочки рисуют свои таблицы — плохо, то что рано или поздно это упадёт и именно на твою голову. В подобных организациях 90% времени приходиться тратить на проблемы, созданные другими. Это действует на нервы.

Кстате этой ветке очень близка такая http://rsdn.ru/forum/message/2906102.flat.aspx

Остановился на мысли, что решается сменой места работы.

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

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

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

.

H>Вы реальный мир видели? Или Вы в институте студентов учите?

Вот прямо сейчас рефакторю событийно-ориентированный движок

Максимально изолирую код по отдельным и почти не связанным интернальным классам на базе интерфейсов, потом для каждого такого классика пишу юниттест, потом уже пишу для взаимодействия нескольких (2-3 сразу) таких классов и т.п.
В начале описал контракт при помощи Rhino, на одних заглушках. Параллельно завершению отдельных классов заменяю ими заглушки (но в новой версии теста контракта).
А Вы говорите "сложный объект"... Сложный — значит, невозможно тестировать. Невозможно тестировать — значит, он непредсказуем и рефакторить его низзя.
Так что при всем желании с Aviator`ом в данном не поспоришь

A> Когда старая команда разбежится новая без проблем напишет перепишет проект, так как разбираться со старым барахлом возможности нет.

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

Можно, например, давать гарантию на какой-то определенный срок. Скажем, в течении полугода заказчик может предъявлять претензии по найденным багам, они будут исправляться. Во-первых, за полгода вся команда не разбежится. Во-вторых, за полгода программисты не успеют все начисто забыть, и исправят баги без подробной программисткой документации и UML-диаграмм. При этом полгода достаточный срок, чтобы заказчик в полной мере протестировал продукт. А потом все, забыли об этом проекте, новые на очереди. Возможно, в каких-то случаях такая схема будет более выгодна, чем сопровождать проект до бесконечности.

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

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

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

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

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

?
Просто надо находить золотую середину между воткнуть все супермеганавороченное в новый проект или
сдать его побыстрее ...

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

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

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

предприятий на с++, уже около 3-х лет. Это моя первая и пока последняя компания

Программистов в конторе мало — 10 человек.
Пришел я в эту компанию на 4 курсе института, ничего не смыслящим в промышленном программировании.
За 3 года я очень сильно повысил свои знания в этом любимом мною занятии

Освоил и стал применять на практике в
рабочих проектах STL, boost, шаблоны. До меня в этой конторе никто этого не применял. Поразило меня непонимание остальными сотрудниками данных технологий и их полное обхаивание и принижение, причем без всякой должной аргументации. Всё чего не знают, страшатся

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

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

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

Здравствуйте, ZiloT, Вы писали:
ZT>когда я начинаю абстагироваться от поставленной задачи и пишу несколько более универсальное и эффективное решение с возможностью расширения

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

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

Категорически согласен!

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

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

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

e_k>Ну а выше уже сказали — если вам лично не нравится происходящее, то либо меняйте к нему отношение, либо работу

Насколько может быть маленький проект, чтобы отказаться от STL?

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

S>Здравствуйте, ZiloT, Вы писали:
ZT>>Меня начинает тошнит уже от такого гнилого процесса разработки.

S>Платят хорощо? А это основной фан от работы.
Зарплаты в компании далеки от тех, что сейчас установились на рынке... До какого-то времени меня это устраивало, потому что я сам считал, что на большее и не имею права расчитывать в виду своих знаний и навыков. Но потихоньку с повышением уровня квалификации это стало очень сильно напрягать...

Здравствуйте, Zzzzzzz, Вы писали:
Z>Если все таки хочется что то поменять то надо вскарабкиваться повыше, типа начальник отдела разработки и уже оттуда спускать свои новшества.

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

e_k>Ну а выше уже сказали — если вам лично не нравится происходящее, то либо меняйте к нему отношение, либо работу.

По поводу сложности разрабатываемого софта.
Софт сложный и громоздкий. Применяется в основном на различный заводах по производствую военной техники для автоматизации большинства этапов жизненного цикла изделия от этапа проектирования до утилизации. Объемы данных огромные.

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

D>Работа в канторе, где руководство заклинило на собственном универсальном фрейморке
От работы с универсальными фреймворками сразу бежать как от огня без оглядки

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

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

S>>Здравствуйте, ZiloT, Вы писали:
ZT>>>Меня начинает тошнит уже от такого гнилого процесса разработки.

S>>Платят хорощо? А это основной фан от работы.
ZT>Зарплаты в компании далеки от тех, что сейчас установились на рынке... До какого-то времени меня это устраивало, потому что я сам считал, что на большее и не имею права расчитывать в виду своих знаний и навыков. Но потихоньку с повышением уровня квалификации это стало очень сильно напрягать...

Вы еще сомневаетесь?

3 года — это уже опыт, достаточный, чтобы думать не только работать на опыт, но и работать на перспективу.

А насчет разработки. Все зависит от задач. Да, зачастую бизнес ориентирован на получении прибыли сейчас ( зарплату-то вы сейчас хотите, а не потом, если повезет ). Основная причина в том, что в IT какая-либо ниша долго не пустует. Вот и приходится балансировать между сроками и качеством.

С применением новых технологий, которые до этого не применялись, тоже могут быть варианты и свои крайности. Когда это выглядит как стрельба по воробьям из пушки (вспомните шутку про эфолюцию разработчика на примере Hello World приложения, в частности пример, в котором написан COM-объект), то подобные навороты несколько излишни. Есть еще такой момент, как затраты. Любая инновация требует инвестиций, как по времени, так и по финансам. Поэтому тоже могут так скептически относиться к вашим инициативам.

Но если это просто глухая стена, то тут ничего не поделаешь. Если вы не обломались сейчас, то это непременно произойдет потом. И в этом случае, вы знаете, что нужно делать

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

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

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

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

e_k>>Ну а выше уже сказали — если вам лично не нравится происходящее, то либо меняйте к нему отношение, либо работу

A>Насколько может быть маленький проект, чтобы отказаться от STL?

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

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

А заказчик предоставил требования использовать буст? Как ты думаешь, повысится ли удовлетворенность заказчика от продукта после привлечения буста

? Далее, что нужно твоему руководству? Ему нужно что бы заказчик был доволен качеством софта. Раз заказчик покупает, значит его качеством он доволен. Далее, контора существует уже как ты сказал не первый год, в глазах руководства всё зашибись, софт делается, продукт скармливается заказчику. Тут нарисовываешься ты с заявой что всё нифига не зашибись, я знаю как сделать всё хорошо дополняя это туманными и совершенно непонятными аббревиатурами stl, boost... Как ты думаешь каковы шансы что тебе поверят?

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

.

ZT>Неужели вот так и должно быть?
Нет
ZT>Неужели большинство контор так и разрабатывает софт???
Увы, в РФ таких контор очень много, так что внимательнее при поиске следующего места работы

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

A>>Насколько может быть маленький проект, чтобы отказаться от STL?

M>Можно зайти с другой стороны. Насколько может быть маленький проект, чтобы не было нужды использовать STL? Тут проблема в непринятии STL

Можно, наверное, привести примеры, когда stl по каким-то причинам не нужна.
Но для простых проектов нет никаких причин не использовать эту библиотеку.
Более похоже, что в фирме просто пишут, на С++, на Паскале, на Бейсике, не важно. И там и там есть похожие конструкции, их и используем. А в деталях ни у кого нет желания изучать. Это их дело. Раз работает фирма давно, значит всё нормально.
Только человеку, которому хочется развиваться лучшее — перейти в другую фирму.

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

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

A>А заказчик предоставил требования использовать буст? Как ты думаешь, повысится ли удовлетворенность заказчика от продукта после привлечения буста

.

Случилось однажды нечто подобное.
Один коллега попросил меня о помощи в решении одной проблемы. Ну я ему дал пример кода на STL, как это примерно можно сделать. И что вы думаете, он это значит вставил в свой код, немного подправил и получил неприятный баг. Баг однажды всплыл, долго не могли понять, в чём проблема. Выяснилось, что это в том STL-коде из-за его неверного применения. Виноватым оказался не он, а я! А ведь я всего лишь указал в ту сторону, куда надо было рыть для решения возникшей проблемы

В очередной раз "отцы офиса" стали хаить и опускать STL!
Виновата не технология, а кривые руки!

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

S>>Платят хорощо? А это основной фан от работы.
ZT>Зарплаты в компании далеки от тех, что сейчас установились на рынке...

Мы работаем за зарплату. Выводы делай сам.

Здравствуйте, ZiloT, Вы писали:
ZT>Случилось однажды нечто подобное.
Неудивительно, ещё повезло что это не произошло перед руководством с выставлением тебя главным вредителем.

ZT>Виновата не технология, а кривые руки!
Да, но в твоём коллективе убеждать в этом я бы не стал

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

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

A>>Насколько может быть маленький проект, чтобы отказаться от STL?

Если stl используешь, то такой вопрос не возникнет, как не возникает вопроса "насколько должен быть маленьким обед, что бы не мыть перед ним руки", более прямой пример приводить не стану

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

A>Более похоже, что в фирме просто пишут, на С++, на Паскале, на Бейсике, не важно. И там и там есть похожие конструкции, их и используем. А в деталях ни у кого нет желания изучать. Это их дело. Раз работает фирма давно, значит всё нормально.
A>Только человеку, которому хочется развиваться лучшее — перейти в другую фирму.

В фирме максимум что используется от ООП, так это классы с одиночным наследованием да редко проскальзывают виртуальные функции. Ни о каких паттернах проектирования речи не идет. Когда я попросил приобрести для офиса книжку по паттернам Э. Гаммы, то на меня в очередной раз посмотрели как на идиота, типа нахера это нужно. Мы сами с усами и умнее всех, а паттерны от лукавого. Шаг в сторону — расстрел.
Но я не хочу так писать. Не хочу плыть по течению. Я вижу как "отцы офиса" уже перестали чем-либо в программировании интересоваться. Они достигли какого-то уровня и всё. Больше ничего им не надо. А ведь они не такие уж старые, большинству около 30 или чуть выше. Я ни хочу превращаться в таких как они. Хочу продолжать совершенствоваться. В этой фирме я это делал в большинстве случаев в некоторый ущерб скорости разработки, потому что решал поставленные передо мной задачи не костылями, как делают остальные, а, может быть, не идеальными, но более менее грамотными выверенными решениями.

ZT>Софт сложный и громоздкий. Применяется в основном на различный заводах по производствую военной техники для автоматизации большинства этапов жизненного цикла изделия от этапа проектирования до утилизации. Объемы данных огромные.

Ну например у нас часть сложного и громоздкого софта принципиально пишется не на C++, а на чистом С, потому что по ряду причин это элементарно удобнее и быстрее.

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

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

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

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

e_k>>Ну а выше уже сказали — если вам лично не нравится происходящее, то либо меняйте к нему отношение, либо работу.

ZT>По поводу сложности разрабатываемого софта.
ZT>Софт сложный и громоздкий. Применяется в основном на различный заводах по производствую военной техники для автоматизации большинства этапов жизненного цикла изделия от этапа проектирования до утилизации. Объемы данных огромные.

Ах, так это военный проект!
Ну... А Вы знаете почему военные до сих пор лампы применяют? Ну вот.
Еще можно вспомнить что означают цифры в названии АК-47

ZT>Меня начинает тошнит уже от такого гнилого процесса разработки.
ZT>Неужели вот так и должно быть?
ZT>Неужели большинство контор так и разрабатывает софт???

А может это agile? Наверняка на твои предложения изменить что то к лучшему, боссы прикрывались этим модным словом

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

ZT>В фирме максимум что используется от ООП, так это классы с одиночным наследованием да редко проскальзывают виртуальные функции. Ни о каких паттернах проектирования речи не идет. Когда я попросил приобрести для офиса книжку по паттернам Э. Гаммы, то на меня в очередной раз посмотрели как на идиота, типа нахера это нужно. Мы сами с усами и умнее всех, а паттерны от лукавого. Шаг в сторону — расстрел.
ZT>Но я не хочу так писать. Не хочу плыть по течению. Я вижу как "отцы офиса" уже перестали чем-либо в программировании интересоваться. Они достигли какого-то уровня и всё. Больше ничего им не надо. А ведь они не такие уж старые, большинству около 30 или чуть выше. Я ни хочу превращаться в таких как они. Хочу продолжать совершенствоваться. В этой фирме я это делал в большинстве случаев в некоторый ущерб скорости разработки, потому что решал поставленные передо мной задачи не костылями, как делают остальные, а, может быть, не идеальными, но более менее грамотными выверенными решениями.

Врядли их получится "перевоспитать". Им этого не нужно. У людей своих проблем хватает.
Если есть выбор, то лучше менять работу. Только не спешить, а неторопясь выбирать по требуемым параметрам. А то может получится, что поменяешь шило на мыло.

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

A>>>Насколько может быть маленький проект, чтобы отказаться от STL?

A>Если stl используешь, то такой вопрос не возникнет, как не возникает вопроса "насколько должен быть маленьким обед, что бы не мыть перед ним руки", более прямой пример приводить не стану

.

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

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

ZT>По поводу сложности разрабатываемого софта.
ZT>Софт сложный и громоздкий. Применяется в основном на различный заводах по производствую военной техники для автоматизации большинства этапов жизненного цикла изделия от этапа проектирования до утилизации. Объемы данных огромные.
В данной сфере твой интерес к изучению новых технологий и грамотного проектирования не оценят никогда

ZT>В фирме максимум что используется от ООП, так это классы с одиночным наследованием да редко проскальзывают виртуальные функции.

А что, крутость определяется глубиной вложенности наследования ? На серьезных структурах данных уже доходит, что крутость крутостью, а наследование — зло, агрегирование — добро (я тут как-то приводил пример в теме C#)

ZT>Ни о каких паттернах проектирования речи не идет. Когда я попросил приобрести для офиса книжку по паттернам Э. Гаммы, то на меня в очередной раз посмотрели как на идиота, типа нахера это нужно. Мы сами с усами и умнее всех, а паттерны от лукавого. Шаг в сторону — расстрел.

возможно и правильно посмотрели.

ZT>Но я не хочу так писать. Не хочу плыть по течению. Я вижу как "отцы офиса" уже перестали чем-либо в программировании интересоваться.

Отцы офиса интересуются бизнес-процессами и зарабатыванием денег, а не изысками кода, которые никто, кроме самого кодера, не оценит.

ZT> Они достигли какого-то уровня и всё. Больше ничего им не надо. А ведь они не такие уж старые, большинству около 30 или чуть выше.

Ну почему не надо. Им надо жить, что и делают. Молодцы.

ZT>Я ни хочу превращаться в таких как они. Хочу продолжать совершенствоваться.

Захочешь когда станешь "не таким уж старым отцом офиса".

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

гы гы и еще раз гы. Вот они ключевые слова — "в некоторый ущерб скорости разработки".
Нафига оно тогда все нужно, если заказчик платит за результат ?

ZT>грамотными выверенными решениями

грамотными и выверенными с точки зрения тебя самого.

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

E>А что, крутость определяется глубиной вложенности наследования ? На серьезных структурах данных уже доходит, что крутость крутостью, а наследование — зло, агрегирование — добро (я тут как-то приводил пример в теме C#)

Да нет. Можно и без изысков ООП хорошо писать. Например, тот же STL. Просто хотелось как-то подчеркнуть, что разработка ведется на очень низком уровне. Без какого-либо обсуждения архитектуры. Всё дается на откуп программисту. А как он там это сделает, никого не волнует, лишь бы в срок уложился. А то что полученное решение будет не расширяемым в виду не продуманности архитектуры, ни кого не волнует. Хотя потом это всё аукается и неоднократно. Уже не раз было, что добавили новую фичу куда-то, а в другом месте отвалилось и не могут понять почему. Все уже забыли про тот кусок кода и опять давай поновой разбираться...

E>возможно и правильно посмотрели.

Чем же паттерны так плохи, кроме того, что если их не к месту применять???

E>Отцы офиса интересуются бизнес-процессами и зарабатыванием денег, а не изысками кода, которые никто, кроме самого кодера, не оценит.

E>Ну почему не надо. Им надо жить, что и делают. Молодцы.

ZT>>Я ни хочу превращаться в таких как они. Хочу продолжать совершенствоваться.

E>Захочешь когда станешь "не таким уж старым отцом офиса".

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

E>гы гы и еще раз гы. Вот они ключевые слова — "в некоторый ущерб скорости разработки".
E>Нафига оно тогда все нужно, если заказчик платит за результат ?

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

ZT>>грамотными выверенными решениями

E>грамотными и выверенными с точки зрения тебя самого.

А я и не претендую на то что мои решения супер-пупер круты. Просто они реально в дальнейшем облегчают жизнь в развитии проекта, только в виду того что они написаны с применением boost'a, stl или просто на своих шаблонах, понять это в конторе к сожалению могу только я.

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

ZT>В фирме максимум что используется от ООП, так это классы с одиночным наследованием

Очень верный шаг. За множественное наследование надо вообще руки отрывать.

ZT>да редко проскальзывают виртуальные функции.

И они далеко не всегда нужны.

ZT> А ведь они не такие уж старые, большинству около 30 или чуть выше.

О! оказывается это во мне старость говорит

ZT>Я ни хочу превращаться в таких как они.

Судя по всему зря не хочешь.

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

А что понимается под костылями? Задача, в идеале, должна быть решена максимально простым и понятным способом, без дополнительных изысков. Все это дело еще и поддерживать надо будет.

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

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

ZT>>В фирме максимум что используется от ООП, так это классы с одиночным наследованием

KP>Очень верный шаг. За множественное наследование надо вообще руки отрывать.

Как уже выше ответил, не верно выразился.

ZT>>да редко проскальзывают виртуальные функции.

KP>И они далеко не всегда нужны.

ZT>> А ведь они не такие уж старые, большинству около 30 или чуть выше.

KP>О! оказывается это во мне старость говорит

Извиняюсь, "такие уж" убрать

ZT>>Я ни хочу превращаться в таких как они.

KP>Судя по всему зря не хочешь.

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

KP>А что понимается под костылями? Задача, в идеале, должна быть решена максимально простым и понятным способом, без дополнительных изысков. Все это дело еще и поддерживать надо будет.

Поддерживать?? Гы

Полученный код удается поддерживать только очередными костылями, после внедрения которых порушится что-нить ещё, написанное давно

Я не пишу каких-то там адских структур. Они прекрасно понимаются, если человек нормально разбирается в ООП.

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

ZT>Без какого-либо обсуждения архитектуры. Всё дается на откуп программисту. А как он там это сделает, никого не волнует, лишь бы в срок уложился. А то что полученное решение будет не расширяемым в виду не продуманности архитектуры, ни кого не волнует. Хотя потом это всё аукается и неоднократно. Уже не раз было, что добавили новую фичу куда-то, а в другом месте отвалилось и не могут понять почему. Все уже забыли про тот кусок кода и опять давай поновой разбираться...

Точно так же бывает и на решениях с "архитектурой", в жизни вообще как-то все обычно не так как на самом деле

E>>А как он там это сделает, никого не волнует, лишь бы в срок уложился

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

E>>возможно и правильно посмотрели.

ZT>Чем же паттерны так плохи, кроме того, что если их не к месту применять???

Возможно там они были не к месту. или затраты на их применение были бы непропорциональны эффекту.

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

Может быть как проектирования, так и исполнения.

ZT>Понимаете, мы занимаем такую нишу рынка, где особой конкуренции нет. И мне кажется, вот поэтому ничерта не делается. Заказчику не и с чего выбирать. Были бы разные варианты, так он бы призадумался после стократного падения, а не поменять ли мне исполнителя...

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

ZT>А я и не претендую на то что мои решения супер-пупер круты. Просто они реально в дальнейшем облегчают жизнь в развитии проекта, только в виду того что они написаны с применением boost'a, stl или просто на своих шаблонах, понять это в конторе к сожалению могу только я.

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

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

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

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

<skipped>

Полностью тред не осилил...

1) Если это 3 года full-time или близко к нему, то вообще-то уже должен быть какой-то авторитет чтобы продвигать то, что считаешь нужным.
2) Не совсем понял — что значит "Освоил и стал применять на практике в рабочих проектах STL, boost, etc." — в смысле в этой конторе, где никто не знает типа даже STL ты пишешь на бусте? Тогда вывода два — контора действительно ничего не контроллирует, либо уже достаточно сильно доверяет (тебе). С другой стороны, за такие новшества в куче контор было бы предложено распрощаться либо если рано обнаружили, то переписать все с нуля. И были бы правы!
3) Что-то не нравится, не согласен, все up to you — должен двигать свои идеи, доказывть и т.д.

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

Thanks,
ZakiMa

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

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

ну ведь 3 года назад тебя это устраивало? и если бы тебя тогда заставили использовать все эти voost-шаблоны, ты бы также матерился по-чёрному. это нормально для программиста, тем более начинающего — расти. когда-то эта контора тянула тебя вверх, затем была тебе впору, сейчас ты её перерос. переходи в другую, раз в несколько лет это совершенно нормально

ps: для меня к примеру весь c++ — вчеращний день и если тебе предложат изучать то, на чём работаю я, ты вряд ли въедешь

ZT>Поддерживать?? Гы

ZT>Я не пишу каких-то там адских структур. Они прекрасно понимаются, если человек нормально разбирается в ООП.

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

У тебя есть всего два выхода. Либо постепенно, в течение 3-5 лет (быстрее не получится — по собственному опыту говорю) демонстрировать в отдельных частях преимущества современного подхода к разработке. Если сможешь — молодец. Будут ценить. Правда, через эти годы придет очередной юнец и будет доказывать преимущества какого-нибудь еще более нового подхода, а на RSDN он будет поливать тебя помоями, обзывая замшелым дедом с бородатыми идеалами.

Второй выход — найти себе такую компанию, где ДЕЙСТВИТЕЛЬНО занимаются интересующими тебя разработками. Благо, у тебя нет обязательств перед семьей или кем-то еще, в кредитное рабство ты вроде не влез и вообще мобилен. Лично от себя рекомендую второй путь, он более перспективен, хоть и с некоторыми кратковременными рисками.

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

ZT>>Поддерживать?? Гы

ZT>>Я не пишу каких-то там адских структур. Они прекрасно понимаются, если человек нормально разбирается в ООП.

SD>Да успокойся ты.
SD>Такая замшелость присутствует в подавляющей части больших контор с длинной историей. У них уже есть свои "бородатые гуру", которые из года в год пахали землю лошадьми с плу... тьфу, писали код на С с классами, называя это "ООП".

SD>У тебя есть всего два выхода. Либо постепенно, в течение 3-5 лет (быстрее не получится — по собственному опыту говорю) демонстрировать в отдельных частях преимущества современного подхода к разработке. Если сможешь — молодец. Будут ценить. Правда, через эти годы придет очередной юнец и будет доказывать преимущества какого-нибудь еще более нового подхода, а на RSDN он будет поливать тебя помоями, обзывая замшелым дедом с бородатыми идеалами.

SD>Второй выход — найти себе такую компанию, где ДЕЙСТВИТЕЛЬНО занимаются интересующими тебя разработками. Благо, у тебя нет обязательств перед семьей или кем-то еще, в кредитное рабство ты вроде не влез и вообще мобилен. Лично от себя рекомендую второй путь, он более перспективен, хоть и с некоторыми кратковременными рисками.

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

Спасибо всем! Мне аж легче стало, после того как излил душу и выслушал все Ваши конструктивные комментарии

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

SD>У тебя есть всего два выхода. Либо постепенно, в течение 3-5 лет (быстрее не получится — по собственному опыту говорю) демонстрировать в отдельных частях преимущества современного подхода к разработке. Если сможешь — молодец. Будут ценить. Правда, через эти годы придет очередной юнец и будет доказывать преимущества какого-нибудь еще более нового подхода, а на RSDN он будет поливать тебя помоями, обзывая замшелым дедом с бородатыми идеалами.

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

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

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

N>>А как вы думаете если он допустим не использовал STL или boost а плюнул и написал свой велосипед, а потом ушёл куда то в другое место писать "великие продукты".

Z>Совершенно с вами согласен, но автор написал что там большинство(10 человек) сидят на этих велосипедах и наверно все таки разбираются в них

.

Z>2alpha21264

N>>Ну... А Вы знаете почему военные до сих пор лампы применяют? Ну вот.

Z>Потому что обыкновенный транзистор выходит из строя под воздействием EMP.

Эх парень! Вот однажды модернизировали ЗРК С-75.
Лампы решили заменить не транзисторы.
Полевые, специально для этого случая разработанные — ВАХ загнали куда надо,
радиации и прочей фигни они не боятся, корпус специально как у ламны — чтобы
просто взять и вставить туда где раньше лампа стояла.
Ага.
Один-два вставляешь — все работает. Когда число замен доходит до 50% —
скрючивает блок питания — катодного тока-то нет!!!

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

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

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

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

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

ZT>то на меня смотрят как на идиота и считают, что это всё изврат и полная ерунда. Но уже неоднократно было такое, что мои абстрагированные решения в будущем позволяли более просто и быстро решить новую задачу. Но этого никто не замечает.
ZT>В таких условиях я себя чувствую как белая ворона. Нет понимания со стороны других сотрудников.

Возьму на себя смелость дать несколько советов...
Не считай профессию программиста чем-то особенным, чаще всего это рутинная работа, цели которой вращаются вокруг оси под названием деньги.
Не забывай что любая платформа\язык\библиотека это всего навсего инструмент который помогает решить определённую проблему. Можно даже сказать какую именно проблему — "удовлетворить потребности заказчика максимально эффективным с точки зрения финансов способом".
Не поверишь, но чаще всего наиболее простое решение — с точки зрения архитектуры\удобства инструмента\и т.п. — и является самым лучшим и оптимальным.
Я не призываю вернуться к

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

Меняй работу.

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

Конечно же нет.
Хотя... на первом и на моих двух последних местах работы всё обстоит похожим образом.
Что самое интересное, во всех трёх случаях коренные изменения были или не нужны, или невозможны.

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

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

Спасибо всем! Мне аж легче стало, после того как излил душу и выслушал все Ваши конструктивные комментарии

Да, именно так мы и убираем конкурентов

)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, BulatZiganshin, Вы писали:
BZ>когда-то эта контора тянула тебя вверх
Такое встречается увы далеко не так часто как хотелось бы

...

Здравствуйте, Сергей Туленцев, Вы писали:

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

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

СТ>В виллариба и виллабаджо снова дедлайн. Пока ребята из виллариба, чертыхаясь, делают дизайн на div'ах, парни из виллабаджо быстренько свестали всё на таблицах и уже давно е##шат друг друга в квейк.
Пока в виллабаджио пытаются в воскресенье вечером заставить хоть как-то заставить задышать неработающую систему и понять, что вообще ожидает заказчик, в виллариба уже давно продемонстрировали версию, получили задачи на следующую и пьянствуют уже второй день

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

ZT>>За 3 года я очень сильно повысил свои знания в этом любимом мною занятии

Освоил и стал применять на практике в
ZT>>рабочих проектах STL, boost, шаблоны. До меня в этой конторе никто этого не применял.

H>Это очень правильное решение, придти в контору, объяснить всем что они дураки, скачать пятьдесят мегабайтов буста,
H>развернуть его в сто пятьдесят мегабайт исходников и закачать его в VSS или чего там

Думаю народ сразу будет резко счастлив...

H>Вероятно Вы молоды, горячи, переоцениваете свои силы и недооцениваете опыт других. Когда мне было 22, я думал что я самый умный, почему-то спустя пятнадцать лет я уже в этом не уверен...

Очень всё правильно сказано, серьёзно правильно. Кроме одного — всё это не оправдывает рассказанный процесс разработки и коллег автора.

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

СТ>>В виллариба и виллабаджо снова дедлайн. Пока ребята из виллариба, чертыхаясь, делают дизайн на div'ах, парни из виллабаджо быстренько свестали всё на таблицах и уже давно е##шат друг друга в квейк.
A>Пока в виллабаджио пытаются в воскресенье вечером заставить хоть как-то заставить задышать неработающую систему и понять, что вообще ожидает заказчик, в виллариба уже давно продемонстрировали версию, получили задачи на следующую и пьянствуют уже второй день

.

"Нет, сынок, это ж фантастика"

... << RSDN@Home 1.2.0 alpha 4 rev. 1038>>

A>Каков критерий правильности? АВ посте автора был лишь рассказ о явно странных решениях. Отказ от stl в сугубо прикладном продукте, даже вернее непонимание как им пользоваться, свидетельствует о явной нехватки профессионализма в коллективе. Тут техпроцесс вообще не причёмю

Слово правильные должно было быть в кавычках. Использование или неиспользование STL — это решение которое принимается изходя из конкретного случая. Сугубо прикладные продукты чаще всего лучше писать в управляемой среде. Если люди не использут STL — это еще не значит что они "лохи", возможно для этого есть причины. Я обычно использую STL, но только тогда когда у меня есть понимание для чего это нужно.

A>Кто вам сказал, что правильность заключается в использовании UML? Это часом не введении к мануале по розе написано?

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

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

Когда unit тесты — это главный вид тестирования (а многие верят что это так), то это становится профанацией. Тестирование должно быть сбалансированным. Авторегрессии не было, а юниты без регресиии — это профанация.

A>Какая ещё среда для юниттестов? Имхо решарпера для запуска в студии и запуск из командной строки с формированием отчёта при автобилде хватает выше крыши

.

Кто будет создавать окружение для модуля? Что, модуль сам себя тестировать будет? Среда тестирования — это обвязка вокруг модуля которая эмулирует для него внешний мир, эмулирует интерфейсы других модулей и выдает отчет.

Имхо решарпера для запуска в студии и запуск из командной строки с формированием отчёта при автобилде хватает выше крыши

.

А мне уже "маловато будет!"

Пользую самопальное расширение Spring.Testing.AbstractDependencyInjectionSpringContextTests + Rhino.Mock + ReSharper. И тоже не представляю, как без них обходился раньше

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

H>Слово правильные должно было быть в кавычках. Использование или неиспользование STL — это решение которое принимается изходя из конкретного случая. Сугубо прикладные продукты чаще всего лучше писать в управляемой среде. Если люди не использут STL — это еще не значит что они "лохи", возможно для этого есть причины. Я обычно использую STL, но только тогда когда у меня есть понимание для чего это нужно.

Да причины есть, например они его не знают, о чём свидетельствуют посты автора

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

A>>Кто вам сказал, что правильность заключается в использовании UML? Это часом не введении к мануале по розе написано?

H>Правильные должны были быть в кавычках. Не вижу причин чем использование UML может навредить, но в данном случае все было доведено до маразма — все описывалось настолько мелко, что быстро рассихронизировалось с действительностью. Вместо описывания интерфейсов UML использовали для описания внутреннего "дерьма".
Например в DDD/TDD роль uml сведена к минимуму. Фактически он вообще не нужен в классическом понимании.

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

H>Когда unit тесты — это главный вид тестирования (а многие верят что это так), то это становится профанацией. Тестирование должно быть сбалансированным. Авторегрессии не было, а юниты без регресиии — это профанация.

Юниттесты не могут быть главным методом или неглавныим методом. Юниттесты и функциональное тестирование являются разными вещами, это как складывать метры с километрами. Юниттесты проверяют соответсвие кусков кода ожидаемому поведению, функуциональность приложения не затрагивается. Функциональное тестирование, т.е. тестирование в своём классическом понимании, проверяет функционирование приложения, т.е. корректность работы всех возможных (точнее документированных) сценариев использования ПО.

H>Кто будет создавать окружение для модуля? Что, модуль сам себя тестировать будет? Среда тестирования — это обвязка вокруг модуля которая эмулирует для него внешний мир, эмулирует интерфейсы других модулей и выдает отчет.

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

Rhino.Mock рулит

, но это самом собой разумеется и к тулзам я не отнёс.

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

A>>

Это прям новое свово в технологии юнит тестирования. Бесплатный совет — посмотрите опенсурс проекты с применением этой технологии, посмотрите как пишут юниттесты, для чего они предназначены и как применяются. Суть теста в том, что вы проверяете маленький, очень маленький

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

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

H>Человек, который занает как все должно быть "правильно" вызывает у меня очень большие сомнения.
Тоакого человека нет и о нём никто не говорит, есть общепринятые нормы разработки софта.

H>Суть в том, что мир очень разнообразен и модули бывают большие и маленькие, легкотестируемы и трудностестируемые, для одних создать "внешний мир" — раз плюнуть, для других это в десять раз больше работы чем написать сам модуль. Вот протетируйте ка модуль который реализует реал-тайм реакцию на кучу асинхронных событий разного рода, тогда учите меня как надо правиль но жить.
что бы ваш код был тестируемый он должен состоять из слабосвязных небольших компонентов. и тестируют отдельно куски компонентов, иначе толку от такого юнит теста будет нуль. Вы путаете юнит тест с функциональным и нагрузочным тестированием. Это совершенно разные вещи и решаются они совершенно разными методами. Повторяю, что юнит тест не проверяет работу функционала, он проверяет работу куска кода. При граммотном проектировании с ориентацией на тестируемость принципиальных проблем не возникнет. Если у вас один компонент использует 100 других и в одном методе обрабатывает сообщения от сотни связанных с ним компонентов, стоит серьёзно задуматься о качестве и поддерживаемости кода имхо

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

Unit-test — тест модуля (юнита), под модулем может пониматься все что угодно — модуль из одного файла, модуль из сотни файлов, модуль который занимает 1/10 файла. Понятие модуля четко не определено.

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

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

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

.

Вы реальный мир видели? Или Вы в институте студентов учите?

A>Очень всё правильно сказано, серьёзно правильно. Кроме одного — всё это не оправдывает рассказанный процесс разработки и коллег автора.

На мой взгляд, в коллективе из 10 программистов расказанный процесс разработки вполне допустим (учитывая, что они, видимо, не вдесятером одну программу пишут, а ведут параллельно несколько проектов, скажем, по 4-5 человек в каждом). Чтобы 4-5 программистам договориться друг с другом, UML не обязателен. Вот если бы было 100 программистов, да еще с постоянной текучкой, и новым приходилось дописывать код, начатый уволившимися — тогда да, с таким процессом далеко не продвинешься. А для нескольких программистов внедрение "правильного" процесса разработки может, наоборот, замедлить разработку на порядок.

H>Слово правильные должно было быть в кавычках. Использование или неиспользование STL — это решение которое принимается изходя из конкретного случая. Сугубо прикладные продукты чаще всего лучше писать в управляемой среде. Если люди не использут STL — это еще не значит что они "лохи", возможно для этого есть причины. Я обычно использую STL, но только тогда когда у меня есть понимание для чего это нужно.

На самом деле, 99.99999% таких решений вида "мы не используем STL/boost/что_там_еще" принимаются именно потому, что "страшно", "мы не справимся", "у наших разработчиков нет квалификации", "в своём коде мы в случае чего можем исправить ошибки, а в xxx — нет", и другие причины, которые я бы назвал отмазками.
Да — именно так. Из-за нехватки квалификации и нежелания эту самую квалификацию поднимать. Закостенелость и замшелость. Это та причина, по которой немолодые конторы имеют крайне заторможенный процесс развития и реакцию.

Здравствуйте, Handie, Вы писали:
H>Вы реальный мир видели? Или Вы в институте студентов учите?
Студентов не учил никогда. За код, не поддающийся тестированию отрывал бы руки сразу

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

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

SD>На самом деле, 99.99999% таких решений вида "мы не используем STL/boost/что_там_еще" принимаются именно потому, что "страшно", "мы не справимся", "у наших разработчиков нет квалификации", "в своём коде мы в случае чего можем исправить ошибки, а в xxx — нет", и другие причины, которые я бы назвал отмазками.

Почему я не использую boost...
Сейчас мой проект в SVN занимает менее 1MB total
Если добавить boost, то он будет занимать ~150MB total
При этом exe вырастет тоже нехило.

BOOST — это монстр, части которого написаны отлично, а части — отвратительней некуда.
Некоторые части boost меня вводят в глубокий ступор:

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

или

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

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

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

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

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

H>Почему я не использую boost...
H>Сейчас мой проект в SVN занимает менее 1MB total
H>Если добавить boost, то он будет занимать ~150MB total

А нельзя залить туда только релевантные части boost'а?

H>При этом exe вырастет тоже нехило.

С чего бы?

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, второй — древний и без проверки типов. Теперь скажите честно, какой код читабельней?

Одинаково?

П>На мой взгляд, в коллективе из 10 программистов расказанный процесс разработки вполне допустим (учитывая, что они, видимо, не вдесятером одну программу пишут, а ведут параллельно несколько проектов, скажем, по 4-5 человек в каждом). Чтобы 4-5 программистам договориться друг с другом, UML не обязателен. Вот если бы было 100 программистов, да еще с постоянной текучкой, и новым приходилось дописывать код, начатый уволившимися — тогда да, с таким процессом далеко не продвинешься. А для нескольких программистов внедрение "правильного" процесса разработки может, наоборот, замедлить разработку на порядок.

Очень правильная мысль! Процесс должен быть адекватен задаче и команде, а то в команде где 5 человек — UML, юнит тестирование, все как "у взрослых" — а в реале разбазаривание времени на "туфту"

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

H>Почему я не использую boost...
я тоже не использую

H>Сейчас мой проект в SVN занимает менее 1MB total
метр исходников — вполне нормальный размер проекта, чтоб юзать там вполне себе "большие" либы...

H>Если добавить boost, то он будет занимать ~150MB total
H>При этом exe вырастет тоже нехило.
уже сказали что надо отрезать ненужные куски

H>Некоторые части boost меня вводят в глубокий ступор:
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, второй — древний и без проверки типов. Теперь скажите честно, какой код читабельней?

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

H>Немолодые конторы доказали жизнеспособность своей бизнес-модели, в то время как молодые, при всех boost'ах и прочих монстрах как правило нет.
согласен, вообще изначально все похоже на "пустите я все перепишу пи..то!" — я такое видел во *всех* конторах и проектах где работал

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

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

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

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

SD>>На самом деле, 99.99999% таких решений вида "мы не используем STL/boost/что_там_еще" принимаются именно потому, что "страшно", "мы не справимся", "у наших разработчиков нет квалификации", "в своём коде мы в случае чего можем исправить ошибки, а в xxx — нет", и другие причины, которые я бы назвал отмазками.

H>Почему я не использую boost...
Да причём тут буст? Кто в этой ветке активно агитировал за буст? Правильно, никто, это был пример не более чем, а что вы за него так уцепились мне совершенно непонятно. Я даже полностью согласен, что привлечение буста должно быть очень серьёзно обоснованно. А отказ от stl по причине его незнания — верх маразма. Нетистируемость кода — недопустимо, преписать всё с нуля

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

H>Сейчас мой проект в SVN занимает менее 1MB total
Да, это очень большой проект, в таких проектах никогда не рефакторят

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

A>> Когда старая команда разбежится новая без проблем напишет перепишет проект, так как разбираться со старым барахлом возможности нет.

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

П>Можно, например, давать гарантию на какой-то определенный срок. Скажем, в течении полугода заказчик может предъявлять претензии по найденным багам, они будут исправляться. Во-первых, за полгода вся команда не разбежится. Во-вторых, за полгода программисты не успеют все начисто забыть, и исправят баги без подробной программисткой документации и UML-диаграмм.

UML кстати вообще обладают спорной полезностью при поддержке кода

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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

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

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

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

Прорвало, что называется

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

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

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

H>>1) Переписать все очень дорого
H>>2) Переписать все очень долго
H>>3) С высокой вероятностью получится то-же самое дерьмо что было в начале
E>Довелось мне учавствовать в проекте, которые писали гении, похожие на тех, которых обсуждаем. Сомневаюсь, что тот проект когда-то удастся переплюнуть в плане "через ж...", круче того проекта я даже представить не могу, как ТО переплюнуть!
Уррраааа, я не одинок.

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

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

В частности, удалось избавиться от самописного отчетного движка

... << RSDN@Home 1.2.0 alpha 4 rev. 1038>>

Здравствуйте, 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

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

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

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

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

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

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

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

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

[EOF]

Здравствуйте, 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'ах и прочих монстрах как правило нет.

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

	От:	shrecher
	Дата:	09.04.08 23:49
	Оценка:	3 (1) +2 -6

	От:	elmal
	Дата:	15.04.08 10:32
	Оценка:	+5

От:	Сергей Туленцев	http://software.tulentsev.com
Дата:	13.04.08 17:30
Оценка:	3 (1)

	От:	Handie
	Дата:	13.04.08 18:47
	Оценка:	6 (1) +2 -1

От:	Alxndr	http://www.google.com/profiles/alexander.poluektov#buzz
Дата:	10.04.08 07:04
Оценка:	3 (1) +3

От:	cencio	http://ua-coder.blogspot.com
Дата:	10.04.08 17:03
Оценка:	1 (1) +2 -1

	От:	nen777w
	Дата:	10.04.08 08:57
	Оценка:	1 (1) +2

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	14.04.08 06:39
Оценка:	+2

От:	Roman Oksyukovski	http://oksyukovski.blogspot.com
Дата:	10.04.08 11:21
Оценка:

От:	egaron	http://127.0.0.1
Дата:	10.04.08 12:53
Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	10.04.08 14:02
Оценка:

	От:	Sergey Astakhov
	Дата:	14.04.08 20:48
	Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	22.04.08 15:51
Оценка:

	От:	carpenter
	Дата:	18.04.08 07:31
	Оценка:	+1