Здравствуйте, ZiloT, Вы писали:
ZT>Люди добрые, хочу услашать Ваши мнения по поводу
ZT>следующей ситуации.
ZT>Мне 22 года. Работаю в одной средней компании, занимающейся написанием софта для автоматизации
ZT>Освоил и стал применять на практике в ZT>рабочих проектах STL, boost, шаблоны. До меня в этой конторе никто этого не применял. Поразило меня непонимание остальными сотрудниками данных технологий и их полное обхаивание и принижение, причем без всякой должной аргументации. Всё чего не знают, страшатся ZT>В связи с тем, что никто и слухом не слыхивал об STL, "отцами офиса" было написано куча сомнительных "велосипедов" с гнилым содержанием.
основная мотивация — прочитал книжку, хочу применить, а колеги не дають. попробуй четко ответить на вопрос:
— выгода от внедрения?
— риски?
ZT>Разработка софта в конторе просто катастрофическая. Багов неимоверно. Всё возникают мысли, как реальные люди потом с этим софтом работают...
немерено, это не число попробуй числами оценить ситуацию. Почему от внедрения стл+буст+шаблонов ситуация станет лучше?
ZT>Что такое программистская документация начальство не знает и не видит в нем никакой пользы. Ведь оно будет отнимать драгоценное время на написание убогого софта. Про всякие там UML я вообще молчу, когда я об этом заикнулся, то меня послали глубоко и надолго...
спорный вопрос, в использовании юмл на разных стадия тоже есть преимущества и недостатки, можно делать как РУП с кучей доки и юмл, можно пробовать более agile подходы. Вообщем если продукты сделаны/внедряються/работают и в разработку можно подключать новых людей с без особых проблем, ситуация с документирования удовлетворительна
ZT>Основной девиз — максимально быстро удовлетворить требования заказчика.
правильный дивиз, что с ним не так?
попробой абстрагироваться, а то прочитал книжку, в ней красивый мир с бустом и патернами, а на практике не важно, что там
ZT>когда я начинаю абстагироваться от поставленной задачи и пишу несколько более универсальное и эффективное решение с возможностью расширения, то на меня смотрят как на идиота и считают, что это всё изврат и полная ерунда. Но уже неоднократно было такое, что мои абстрагированные решения в будущем позволяли более просто и быстро решить новую задачу. Но этого никто не замечает.
особо порадовало "не замечает", если колеги этого не заметили, то может оно и не помогло?
высказывания из разрядо "руский програмист хочет все переписать" — он прочитал книжку, теперь колеги его не понимают
"универсальное и эффективное решение с возможностью расширения" это, как я понимаю, библиотека, которая может реюзаться в проектах? но ведь уже поминались "велосипеды", они ведь тоже реюзаються? значит есть общее решение и его используют. И соответственно возникает вопрос — как и зачем внедрять более общее решение? оно ведь создаст проблемы прямо сейчас(как минимум уйдет больше времени на проектировани и кодирование, повылазят новые баги, на проект где его впервых внедрят удет больше времени и сил), а выгоду(ее оценивали?) принесет только в будущем
ZT>Меня начинает тошнит уже от такого гнилого процесса разработки.
Вообщем тут надо попробовать понять мотивацию коллег, а не кричать про гнилой процесс. он ведь контору не первый год кормит, а ты предлагаеш ламать и перестроить, а они в этом не видять выгоды и видять риски. то что уже налажено и работает не трогают просто так. только если видять проблему, или приближающуюся проблему а внедрять новые идее лучше в следующих версиях, которые разрабатываються с нуля/серьезно переписываются, и может оказаться что это будут не буст/шаблоны а напримеш шарп
Здравствуйте, 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>Пришел к выводу, что лучше стоит поменять себе работу и уберечь свои нервы. Всё равно в этой конторе я врядли чему-то ещё научусь да и не держит меня здесь ничего Спасибо всем! Мне аж легче стало, после того как излил душу и выслушал все Ваши конструктивные комментарии
Знакомо и актуально. Работаю на госпредприятии последние 1.5 года (после окончания университета) и наблюдаю это дело с момента приёма и в более выраженном виде.
Много чего передумал за это время... Похоже это системное явление.
Основная проблема во всём этом — избыток перекосов и парадоксальных ситуаций.
Например подходит ко мне за помощью девочка и спрашивает почему у неё из такой-то таблицы цифры неправильно сортируются. В таблице для поля "месяц" отведено char(10) — меняю на tinyint и бурчу про типы данных. На след. день девочка приходит и обиженно говорит, что в старых отчётах нолики перед цифрами 1-9 не рисуются — заказчики в панике.
Таким образом, я оказываюсь засланцем-вредителем, "слишком умным" и т.п., а те, у которых "char(10)" и хранение незначащих ноликов в БД не вызывало вопросов — белые и пушистые.
Один из многих и самый простой случай.
ясно, что нужно линейкой по рукам, но у меня на это нет не полномочий, ни желания — приходиться убеждать и договариваться в вопросах, которые в иных местах даже не появлялись бы.
Тут же возникают проблемы самоопределения, вроде "гений vs команда", т.к. твой самый пьяный чих в большинстве случаев оказывается технически правильнее решений местных "заслуженных работников", несмотря на то, что раньше себя к гениям не относил...
И всё бы ничего — пусть девочки рисуют свои таблицы — плохо, то что рано или поздно это упадёт и именно на твою голову. В подобных организациях 90% времени приходиться тратить на проблемы, созданные другими. Это действует на нервы.
ZT>когда я начинаю абстагироваться от поставленной задачи и пишу несколько более универсальное и эффективное решение с возможностью расширения, то на меня смотрят как на идиота и считают, что это всё изврат и полная ерунда.
В виллариба и виллабаджо снова дедлайн. Пока ребята из виллариба, чертыхаясь, делают дизайн на div'ах, парни из виллабаджо быстренько свестали всё на таблицах и уже давно е##шат друг друга в квейк.
ZT>За 3 года я очень сильно повысил свои знания в этом любимом мною занятии Освоил и стал применять на практике в ZT>рабочих проектах STL, boost, шаблоны. До меня в этой конторе никто этого не применял.
Это очень правильное решение, придти в контору, объяснить всем что они дураки, скачать пятьдесят мегабайтов буста,
развернуть его в сто пятьдесят мегабайт исходников и закачать его в VSS или чего там Думаю народ сразу будет резко счастлив...
Вероятно Вы молоды, горячи, переоцениваете свои силы и недооцениваете опыт других. Когда мне было 22, я думал что я самый умный, почему-то спустя пятнадцать лет я уже в этом не уверен...
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Здравствуйте, ZiloT, Вы писали:
ZT>>когда я начинаю абстагироваться от поставленной задачи и пишу несколько более универсальное и эффективное решение с возможностью расширения, то на меня смотрят как на идиота и считают, что это всё изврат и полная ерунда.
СТ>В виллариба и виллабаджо снова дедлайн. Пока ребята из виллариба, чертыхаясь, делают дизайн на div'ах, парни из виллабаджо быстренько свестали всё на таблицах и уже давно е##шат друг друга в квейк.
Пока в виллабаджио пытаются в воскресенье вечером заставить хоть как-то заставить задышать неработающую систему и понять, что вообще ожидает заказчик, в виллариба уже давно продемонстрировали версию, получили задачи на следующую и пьянствуют уже второй день .
Здравствуйте, Handie, Вы писали:
ZT>>За 3 года я очень сильно повысил свои знания в этом любимом мною занятии Освоил и стал применять на практике в ZT>>рабочих проектах STL, boost, шаблоны. До меня в этой конторе никто этого не применял.
H>Это очень правильное решение, придти в контору, объяснить всем что они дураки, скачать пятьдесят мегабайтов буста, H>развернуть его в сто пятьдесят мегабайт исходников и закачать его в VSS или чего там Думаю народ сразу будет резко счастлив...
H>Вероятно Вы молоды, горячи, переоцениваете свои силы и недооцениваете опыт других. Когда мне было 22, я думал что я самый умный, почему-то спустя пятнадцать лет я уже в этом не уверен...
Очень всё правильно сказано, серьёзно правильно. Кроме одного — всё это не оправдывает рассказанный процесс разработки и коллег автора.
Здравствуйте, Aviator, Вы писали:
СТ>>В виллариба и виллабаджо снова дедлайн. Пока ребята из виллариба, чертыхаясь, делают дизайн на div'ах, парни из виллабаджо быстренько свестали всё на таблицах и уже давно е##шат друг друга в квейк. A>Пока в виллабаджио пытаются в воскресенье вечером заставить хоть как-то заставить задышать неработающую систему и понять, что вообще ожидает заказчик, в виллариба уже давно продемонстрировали версию, получили задачи на следующую и пьянствуют уже второй день .
A>Очень всё правильно сказано, серьёзно правильно. Кроме одного — всё это не оправдывает рассказанный процесс разработки и коллег автора.
Только молодой и наивный человек может думать что процесс разработки может быть легко изменен и что результат будет резко положительным если применять правильные технологии. Мне довелось видеть, когда "неравильный" процесс разрабоки приводил к весьма интересным продуктам, и наоборот, изумительный по правильности процесс приводил к полному дерьму в результате.
Недавно я очень недолго проработал в одной конторе. Там все "очень правильно", сначала рисуешь UML диаграммы, затем кодируешь, затем пишешь юнит тесты, работаешь в собственом бранче. Только вот результаты оказались печальные — две трети времени занимаешься полной профанацией, притом знаешь что в UML туфта, но перерисовывать пятнадцать диаграмм не хочется, знаешь что юнит тесты тоже туфта — они написаны не для того чтобы ловить баги, а чтобы от человек отстали (при этом нет автоматической авторегресии, и никому не охота их прогонять). Среда юнит тестирования — это вообще песня, никогда такого убожества не видел (доморощенный продукт написанный неквалифицированым программистом). Меня эта работа утомила быстро, да и коллектив специфический.
Сейчас работаю с неправильным процессом — очень доволен.
Здравствуйте, Handie, Вы писали:
A>>Очень всё правильно сказано, серьёзно правильно. Кроме одного — всё это не оправдывает рассказанный процесс разработки и коллег автора.
H>Только молодой и наивный человек может думать что процесс разработки может быть легко изменен и что результат будет резко положительным если применять правильные технологии.
Да это так, кстати автор и не скрывает свою молодость. Что значит правильные технологии? Каков критерий правильности? АВ посте автора был лишь рассказ о явно странных решениях. Отказ от stl в сугубо прикладном продукте, даже вернее непонимание как им пользоваться, свидетельствует о явной нехватки профессионализма в коллективе. Тут техпроцесс вообще не причёмю
H>Недавно я очень недолго проработал в одной конторе. Там все "очень правильно", сначала рисуешь UML диаграммы, затем кодируешь, затем пишешь юнит тесты, работаешь в собственом бранче. Только вот результаты оказались печальные — две трети времени занимаешься полной профанацией, притом знаешь что в UML туфта, но перерисовывать пятнадцать диаграмм не хочется, знаешь что юнит тесты тоже туфта — они написаны не для того чтобы ловить баги, а чтобы от человек отстали (при этом нет автоматической авторегресии, и никому не охота их прогонять). Среда юнит тестирования — это вообще песня, никогда такого убожества не видел (доморощенный продукт написанный неквалифицированым программистом). Меня эта работа утомила быстро, да и коллектив специфический.
Кто вам сказал, что правильность заключается в использовании UML? Это часом не введении к мануале по розе написано? Утверждая, что юнит тесты туфта эквивалентно утверждению "я не умею ими пользоваться и не хочу учиться". Я вот после того как начал их применять вообще перестал понимать как это я без них умудрялся разрабатывать раньше, дело не в правильности, а в технической поддержке рефакторинга. Без них после любого рефакторинга надо скрестить пальцы и думать где же свалится. Какая ещё среда для юниттестов? Имхо решарпера для запуска в студии и запуск из командной строки с формированием отчёта при автобилде хватает выше крыши.
H>Сейчас работаю с неправильным процессом — очень доволен.
A>Каков критерий правильности? АВ посте автора был лишь рассказ о явно странных решениях. Отказ от stl в сугубо прикладном продукте, даже вернее непонимание как им пользоваться, свидетельствует о явной нехватки профессионализма в коллективе. Тут техпроцесс вообще не причёмю
Слово правильные должно было быть в кавычках. Использование или неиспользование STL — это решение которое принимается изходя из конкретного случая. Сугубо прикладные продукты чаще всего лучше писать в управляемой среде. Если люди не использут STL — это еще не значит что они "лохи", возможно для этого есть причины. Я обычно использую STL, но только тогда когда у меня есть понимание для чего это нужно.
A>Кто вам сказал, что правильность заключается в использовании UML? Это часом не введении к мануале по розе написано?
Правильные должны были быть в кавычках. Не вижу причин чем использование UML может навредить, но в данном случае все было доведено до маразма — все описывалось настолько мелко, что быстро рассихронизировалось с действительностью. Вместо описывания интерфейсов UML использовали для описания внутреннего "дерьма".
A>Утверждая, что юнит тесты туфта эквивалентно утверждению "я не умею ими пользоваться и не хочу учиться". Я вот после того как начал их применять вообще перестал понимать как это я без них умудрялся разрабатывать раньше, дело не в правильности, а в технической поддержке рефакторинга. Без них после любого рефакторинга надо скрестить пальцы и думать где же свалится.
Когда unit тесты — это главный вид тестирования (а многие верят что это так), то это становится профанацией. Тестирование должно быть сбалансированным. Авторегрессии не было, а юниты без регресиии — это профанация.
A>Какая ещё среда для юниттестов? Имхо решарпера для запуска в студии и запуск из командной строки с формированием отчёта при автобилде хватает выше крыши.
Кто будет создавать окружение для модуля? Что, модуль сам себя тестировать будет? Среда тестирования — это обвязка вокруг модуля которая эмулирует для него внешний мир, эмулирует интерфейсы других модулей и выдает отчет.
Имхо решарпера для запуска в студии и запуск из командной строки с формированием отчёта при автобилде хватает выше крыши.
А мне уже "маловато будет!"
Пользую самопальное расширение Spring.Testing.AbstractDependencyInjectionSpringContextTests + Rhino.Mock + ReSharper. И тоже не представляю, как без них обходился раньше
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
а внедрять новые идее лучше в следующих версиях, которые разрабатываються с нуля/серьезно переписываются, и может оказаться что это будут не буст/шаблоны а напримеш шарп 
...
