А заказчик предоставил требования использовать буст? Как ты думаешь, повысится ли удовлетворенность заказчика от продукта после привлечения буста ? Далее, что нужно твоему руководству? Ему нужно что бы заказчик был доволен качеством софта. Раз заказчик покупает, значит его качеством он доволен. Далее, контора существует уже как ты сказал не первый год, в глазах руководства всё зашибись, софт делается, продукт скармливается заказчику. Тут нарисовываешься ты с заявой что всё нифига не зашибись, я знаю как сделать всё хорошо дополняя это туманными и совершенно непонятными аббревиатурами stl, boost... Как ты думаешь каковы шансы что тебе поверят? Далее, если ты умудришься заставить всех юзать stl и в этот счастливый момент будет какой-либо сбой с заказчиком (количество подпорок перешло критическоую массу, в момент демонстрации вылез старинный критичный баг, какой-то разработчик неверно понял документацию и некорректно воспользовался компонентом из boost, что привело к срыву срока, нужное полдчеркнуть или дописать ), то как ты думаешь, кто будет во всём виноват в глазах руководства?.
ZT>Неужели вот так и должно быть?
Нет ZT>Неужели большинство контор так и разрабатывает софт???
Увы, в РФ таких контор очень много, так что внимательнее при поиске следующего места работы .
Здравствуйте, Marduk, Вы писали:
A>>Насколько может быть маленький проект, чтобы отказаться от STL?
M>Можно зайти с другой стороны. Насколько может быть маленький проект, чтобы не было нужды использовать STL? Тут проблема в непринятии STL
Можно, наверное, привести примеры, когда stl по каким-то причинам не нужна.
Но для простых проектов нет никаких причин не использовать эту библиотеку.
Более похоже, что в фирме просто пишут, на С++, на Паскале, на Бейсике, не важно. И там и там есть похожие конструкции, их и используем. А в деталях ни у кого нет желания изучать. Это их дело. Раз работает фирма давно, значит всё нормально.
Только человеку, которому хочется развиваться лучшее — перейти в другую фирму.
Здравствуйте, Aviator, Вы писали:
A>Здравствуйте, ZiloT, Вы писали:
A>А заказчик предоставил требования использовать буст? Как ты думаешь, повысится ли удовлетворенность заказчика от продукта после привлечения буста ? Далее, что нужно твоему руководству? Ему нужно что бы заказчик был доволен качеством софта. Раз заказчик покупает, значит его качеством он доволен. Далее, контора существует уже как ты сказал не первый год, в глазах руководства всё зашибись, софт делается, продукт скармливается заказчику. Тут нарисовываешься ты с заявой что всё нифига не зашибись, я знаю как сделать всё хорошо дополняя это туманными и совершенно непонятными аббревиатурами stl, boost... Как ты думаешь каковы шансы что тебе поверят? Далее, если ты умудришься заставить всех юзать stl и в этот счастливый момент будет какой-либо сбой с заказчиком (количество подпорок перешло критическоую массу, в момент демонстрации вылез старинный критичный баг, какой-то разработчик неверно понял документацию и некорректно воспользовался компонентом из boost, что привело к срыву срока, нужное полдчеркнуть или дописать ), то как ты думаешь, кто будет во всём виноват в глазах руководства?.
Случилось однажды нечто подобное.
Один коллега попросил меня о помощи в решении одной проблемы. Ну я ему дал пример кода на STL, как это примерно можно сделать. И что вы думаете, он это значит вставил в свой код, немного подправил и получил неприятный баг. Баг однажды всплыл, долго не могли понять, в чём проблема. Выяснилось, что это в том STL-коде из-за его неверного применения. Виноватым оказался не он, а я! А ведь я всего лишь указал в ту сторону, куда надо было рыть для решения возникшей проблемы В очередной раз "отцы офиса" стали хаить и опускать STL!
Виновата не технология, а кривые руки!
Здравствуйте, 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>Софт сложный и громоздкий. Применяется в основном на различный заводах по производствую военной техники для автоматизации большинства этапов жизненного цикла изделия от этапа проектирования до утилизации. Объемы данных огромные.
В данной сфере твой интерес к изучению новых технологий и грамотного проектирования не оценят никогда .
Здравствуйте, nen777w, Вы писали:
N>А как вы думаете если он допустим не использовал STL или boost а плюнул и написал свой велосипед, а потом ушёл куда то в другое место писать "великие продукты".
Совершенно с вами согласен, но автор написал что там большинство(10 человек) сидят на этих велосипедах и наверно все таки разбираются в них .
2alpha21264
N>Ну... А Вы знаете почему военные до сих пор лампы применяют? Ну вот.
Потому что обыкновенный транзистор выходит из строя под воздействием EMP.
ZT>В фирме максимум что используется от ООП, так это классы с одиночным наследованием да редко проскальзывают виртуальные функции.
А что, крутость определяется глубиной вложенности наследования ? На серьезных структурах данных уже доходит, что крутость крутостью, а наследование — зло, агрегирование — добро (я тут как-то приводил пример в теме C#)
ZT>Ни о каких паттернах проектирования речи не идет. Когда я попросил приобрести для офиса книжку по паттернам Э. Гаммы, то на меня в очередной раз посмотрели как на идиота, типа нахера это нужно. Мы сами с усами и умнее всех, а паттерны от лукавого. Шаг в сторону — расстрел.
возможно и правильно посмотрели.
ZT>Но я не хочу так писать. Не хочу плыть по течению. Я вижу как "отцы офиса" уже перестали чем-либо в программировании интересоваться.
Отцы офиса интересуются бизнес-процессами и зарабатыванием денег, а не изысками кода, которые никто, кроме самого кодера, не оценит.
ZT> Они достигли какого-то уровня и всё. Больше ничего им не надо. А ведь они не такие уж старые, большинству около 30 или чуть выше.
Ну почему не надо. Им надо жить, что и делают. Молодцы.
ZT>Я ни хочу превращаться в таких как они. Хочу продолжать совершенствоваться.
Захочешь когда станешь "не таким уж старым отцом офиса".
ZT>В этой фирме я это делал в большинстве случаев в некоторый ущерб скорости разработки, потому что решал поставленные передо мной задачи не костылями, как делают остальные, а, может быть, не идеальными, но более менее грамотными выверенными решениями.
гы гы и еще раз гы. Вот они ключевые слова — "в некоторый ущерб скорости разработки".
Нафига оно тогда все нужно, если заказчик платит за результат ?
ZT>грамотными выверенными решениями
грамотными и выверенными с точки зрения тебя самого.
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>А что понимается под костылями? Задача, в идеале, должна быть решена максимально простым и понятным способом, без дополнительных изысков. Все это дело еще и поддерживать надо будет.
Поддерживать?? Гы Полученный код удается поддерживать только очередными костылями, после внедрения которых порушится что-нить ещё, написанное давно
Я не пишу каких-то там адских структур. Они прекрасно понимаются, если человек нормально разбирается в ООП.
ZT>Без какого-либо обсуждения архитектуры. Всё дается на откуп программисту. А как он там это сделает, никого не волнует, лишь бы в срок уложился. А то что полученное решение будет не расширяемым в виду не продуманности архитектуры, ни кого не волнует. Хотя потом это всё аукается и неоднократно. Уже не раз было, что добавили новую фичу куда-то, а в другом месте отвалилось и не могут понять почему. Все уже забыли про тот кусок кода и опять давай поновой разбираться...
Точно так же бывает и на решениях с "архитектурой", в жизни вообще как-то все обычно не так как на самом деле
E>>А как он там это сделает, никого не волнует, лишь бы в срок уложился
нужен результат, что тут удивительного. А не этюд по программированию
не берусь сказать хорошо это или плохо — с одной стороны хорошо, с другой — может и плохо.
если фирма существует и получает прибыль, то чем такой подход несостоятелен *?
E>>возможно и правильно посмотрели.
ZT>Чем же паттерны так плохи, кроме того, что если их не к месту применять???
Возможно там они были не к месту. или затраты на их применение были бы непропорциональны эффекту.
ZT>Ну заказчика понять конечно можно, но он постоянно в ахуе от того, что где-то отвалилось то, что раньше прекрасно работало... Просто мне кажется что всё это следствия гнилового проектирования, когда всё делается в попыхах и на скорую руку...
Может быть как проектирования, так и исполнения.
ZT>Понимаете, мы занимаем такую нишу рынка, где особой конкуренции нет. И мне кажется, вот поэтому ничерта не делается. Заказчику не и с чего выбирать. Были бы разные варианты, так он бы призадумался после стократного падения, а не поменять ли мне исполнителя...
Ну так, если вам удалось занять такую выгодную нишу, то слава труду. Чему быть недовольным ?
Если так важно "грамотно покодить", то надо действительно менять фирму. И убедиться, что там все точно так же
ZT>А я и не претендую на то что мои решения супер-пупер круты. Просто они реально в дальнейшем облегчают жизнь в развитии проекта, только в виду того что они написаны с применением boost'a, stl или просто на своих шаблонах, понять это в конторе к сожалению могу только я.
Ну раз понять свои шаблоны можешь только ты, то другим они не облегчат ведение проекта. А для себя можешь применять, почему нет (ведь насколько понимаю у вас всем пофиг кто как пишет).
Здравствуйте, ZiloT, Вы писали:
ZT>Мне 22 года. Работаю в одной средней компании, занимающейся написанием софта для автоматизации ZT>предприятий на с++, уже около 3-х лет. Это моя первая и пока последняя компания Программистов в конторе мало — 10 человек. ZT>Пришел я в эту компанию на 4 курсе института, ничего не смыслящим в промышленном программировании. ZT>За 3 года я очень сильно повысил свои знания в этом любимом мною занятии Освоил и стал применять на практике в ZT>рабочих проектах STL, boost, шаблоны. До меня в этой конторе никто этого не применял. Поразило меня непонимание остальными сотрудниками данных технологий и их полное обхаивание и принижение, причем без всякой должной аргументации. Всё чего не знают, страшатся ZT>В связи с тем, что никто и слухом не слыхивал об STL, "отцами офиса" было написано куча сомнительных "велосипедов" с гнилым содержанием.
<skipped>
Полностью тред не осилил...
1) Если это 3 года full-time или близко к нему, то вообще-то уже должен быть какой-то авторитет чтобы продвигать то, что считаешь нужным.
2) Не совсем понял — что значит "Освоил и стал применять на практике в рабочих проектах STL, boost, etc." — в смысле в этой конторе, где никто не знает типа даже STL ты пишешь на бусте? Тогда вывода два — контора действительно ничего не контроллирует, либо уже достаточно сильно доверяет (тебе). С другой стороны, за такие новшества в куче контор было бы предложено распрощаться либо если рано обнаружили, то переписать все с нуля. И были бы правы!
3) Что-то не нравится, не согласен, все up to you — должен двигать свои идеи, доказывть и т.д.
Смена работы это ортогональный путь решения, вышеприведенные пункты от этого никуда не денутся.
? Далее, что нужно твоему руководству? Ему нужно что бы заказчик был доволен качеством софта. Раз заказчик покупает, значит его качеством он доволен. Далее, контора существует уже как ты сказал не первый год, в глазах руководства всё зашибись, софт делается, продукт скармливается заказчику. Тут нарисовываешься ты с заявой что всё нифига не зашибись, я знаю как сделать всё хорошо дополняя это туманными и совершенно непонятными аббревиатурами stl, boost... Как ты думаешь каковы шансы что тебе поверят? 
.
В очередной раз "отцы офиса" стали хаить и опускать STL!
