Всем привет!
Считается, что программисты из России намного сильнее немецких. Означает ли это, что IT образование в Германии слабое?

Кем считается и по каким критериям?

так считают русские программисты

Слабое очень, здеся все слабое. Образование, индустрия, культура. Ничего нет. Даже дорог нет. И солнца нет.

Мешки таскать, то да, сильнее

В России есть несколько вузов с сильной алгоритмической подготовкой. В итоге находятся любители экстраполировать успехи победителей всяких-разных конкурсов на всю отрасль. На самом деле:
1. Алгоритмика ещё не всё программирование.
2. Разброс качества образования в России намного выше чем в Германии. Средний уровень скорее даже ниже.
3. GCJ, Topcoder и Ко. в Германии просто малоизвестны.

А что, собственно, вы понимаете под "IT образование"?
Под этим можно понимать как курсы "выучи ПыХыПы за 2 часа" так и университет.
Про универ могу сказать. Я учился и в России и в Германии. Именно информатика у немцев ну... на порядок лучше была. Но. Все зависит от профессора. В России у нас были классные доценты по дискретке и теории информации. До сих пор многое помню. У немцев был только один откровенно плохой препод. А вот физику у нас преподавали лучше :)
Про "программисты из России намного сильнее немецких" я бы переделал как "программисты из России, приехавшие в Германию, за те же деньги работают лучше немцев". Русский после ВУЗа часто приходит на место на котором работыл выпускник курсов "ща я за 2 месяца стану Кнутом".

Вот я поработал в российском и немецком офисах одной и той же фирмы. Вывод: в России действительно большой разброс, в команде есть как звёзды программирования, так и туповатые или неорганизованные, недисциплинированные кодеры. В Германии все коллеги примерно одинаково пишут, пунктуально всё сдают, документируют и т.п. Особо никто не выделяется. Возможно, тут ещё культура это не приветствует.
Про образование не знаю. Я закончил российский ВУЗ и могу сказать: всех будущих программеров обязательно учат теории компиляторов, теории функций комплексного переменного и массе других вещей, полезных только будущему сотруднику оборонного НИИ, в то время как написание спецификаций, тестирование, системы контроля версий и масса других очень важных тем остаются за бортом.

в то время как написание спецификаций, тестирование, системы контроля версий и масса других очень важных тем остаются за бортом
------
И выпускник, разумеется, должен быть отправлен на 6-месячные курсы повышения квалификации что бы освоить какую-либо новую тулузу или технологию...
И как это Я, скромный выпускник, просто не видевший все эти примочки в виду их отсутствия в природе, далеко не лучшего ВУЗа, до сих пор выживаю без переобучения для всего этого?
Позавчера вообще было смешно - предложили сделать софт для сети в госпитале.. сеть - не стандартная, не ТЦП-ИП, и никто не в курсе как ее делать... мягко говоря - никто не в курсе даже как там провода скручивать... если задать вопрос изготовителю устройств - заказ перехватят... и как теперь с этим быть?

Ы? А еще в ВУЗе должны научить мыть руки перед едой, читать и не кидаться экскрементами в уборщиц?
Это - рабочая практика. Про UML в универе же рассказывают? При желании на курсы по RUP-у или там по SCRUM-у можно сходить. Можно книжку про Git прочитать. Это - ерунда. (хотя в России у нас был семестр "Основы технологии программирования", где как раз про документацию, ТЗ, и прочие бумажки рассказывали). А вот теория компиляторов - интересно. Хотя я ее себе не брал :)

Не надо за меня договаривать... как вы выживаете, я без понятия. Для меня факт, что я отсеивал программеров, которые не знали ни одной системы контроля версий, потому что некогда было ждать, пока они освоят — работать уже надо. А одного, который сказал, что более-менее знает и быстро подучится, так и не допинал до того, чтобы он подучился. Поэтому я бы предпочёл, чтобы его это уже в ВУЗе заставили пройти.

Я не собираюсь спорить, что в обучении нужно, а что не нужно. Конкретно та программа («Программное обеспечение...»), которую я прошёл, мне не понравилась: очень глубоко о том, что вряд ли пригодится, и полный ноль о том, что нужно позарез.

пока они освоят
-------
??? - освоить check-out и check-in? Особенно в виде интегрированного в среду программирования пункта меню? Тогда ты на 100% прав - ждать освоения таких действий от программиста не стоит...
я бы предпочёл, чтобы его это уже в ВУЗе заставили пройти.
-----
В техникуме. Ибо у тебя запросы не на инженера/разработчика, а на техника/кодировщика.

Лицоладонь. а еще надо преподавать paint, notepad и minesweeper. Особенно будущим програмистов. И если он наизусть не знает как проставить автоматическию нумерацию страниц в верхнем колонтитуле в ворде 2010 - тоже не брать. Учить-то некогда.
Какую cистему вам преподавать? cvs, svn, bitkeeper, git, synergy (не дай бог)? Может еще баг-трекером в универе надо учить пользоваться?
В немецких университетах такого тоже не преподают. А вот на курсах "я - луччий быдлокодер" - да.
P.S. Интересно: которую часть времени ваши сотрудники проводят работая с котролем версий? Сколько по-вашему длится обучить "поправил файл сделай коммит"? А как вы думаете, насколько различается процесс внесения новой версии в, например, git и synergy?

а где индусы?
Почему тот, который *считает*, не учел индусов? Там полно гениальных чуваков.

ни х*я это не означает. Этот вопрос в стиле *средней температуры по больнице*.

по моему наблюдению, немцы хитрят (или я простодушный). Ни грамма лучше не сделают, а лишь бы сдать работу.
У нас на фирме, будущие проэкты (которые собираются продавать в будущем) делают те, кто захалтурил нынешние, которые сейчас приходиться переделывать, выбрасывая и переписывая заново огромные части, где уже невозможно гарантированно исправить лажи ввиду сплошных глобальных переменных и функций более 1000 строк. Комментарии поражают своей содержательностью. Типа: это конструктор, а это - деструктор, а здеь счетчик увеличивается :). Уверен, что писались такие комметнарии, потому что сказали - надо писать. Вроде исполняют что требуется, в тоже время - халтура. Сплошные копи-пасты кода, который можно было бы оформить в виде функции. Сплошь "волшебные числа". И т.д.
Не так давно новый тестер обнаружил что наш компилятор SFC не выявляет "unsafe" и "not reachable" конструкции(IEC 61131-3). Хотя уже 20 лет как не выявляет. Я за день сочинил, имплементировал и отладил алгоритм который ловит все возможные ситуации (которые я и тестер смогли придумать, включая упомянутые в IEC 61131-3). Почему 20 лет не было сделано то что стандартом IEC 61131-3 требуется?! По-моему очень просто: делается только то чтобы прошли тесты заказчика (на момент сдачи).

Ты крут да.

Nothing personal, just business. Мир капыталызма и чистогана. Кто оплатил ваше рабочее время, потраченное на реализацию стандарта? Клиент? Вряд ли, если он это не требовал. По-хорошему при обсуждении заказа клиенту должны были сказать что неплохо реализовать вот это и это, а то будут проблемы: вот такие и такие. Но редкий клиент думает мозгом. Большинство - кошельком. Это бесплатно? - Нет. Без этого работать будет? - в принципе да. Все, мне не надо.
А вот копи-пасты, спагетти из статический методов и сами методы по паре сотен строк это да. Индусятина у немцев в почете.
Наша фирма сейчас вкладывает тучу денег в улучшение кода. А почему? Через 10 лет проекта индеец Зоркий Глаз, т.е. топменеджеры в костюмах с удивлением обнаружили что 80% времени уходит на правку багов. "Итить! Прекратить и непущщать!" - сказали менеджеры. И аврально стали внедрять автоматическое тестирование, статический анализ кода и собирать статистику. Сейчас у нас функции с >20 ветвлениями запрещены. Все, где больше 5-и ветвлений должны быть проверены юнит-тестом и те де. Что не мешает отдельным товарисчам кропать очередные 20 статических методов и пхать их в один класс ServiceHelperUtil (не вру, именно так класс и называется). Ну и о том что для улучшения кода этот самый код надо менять топ-менеджеры того... ни шмогли подумать. Ресурсов на это не этого. Не выделено. О как. Так что индусятина будет цвести и процветать.
У нас, наверное, каждый 5-й нормальный программист. Остальные того, быдлокодеры. И это мягко сказано. (NB один из этих нормальных программистов таки индус :))

ServiceHelperUtil - это шикарно.

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

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

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

А надо ли его добиваться? Мне мое спокойствие и чистая совесть дороже.

я не знаю о других фирмах. конечно это должно быть нормальным достичь положения высокопрофессиональной работой. Но у нас шефы, которые тоже раньше были программистами явно вырвались в шефы не благодаря своим умениям. Достаточно глянуть на их код написанный много лет назад - хочется плакать. Впрочем у меня (почти) нет претензий к их теперешней (не программистской) работе. Впрочем, недавно меня очень удивило что они поручили задание сторонней фирме из России, которые оценят (я так думаю) её минимум в месяц, то что лично я сделал бы за пару дней. Потом увидим.
Как-то несколько лет назад, как только я приобщился к проэкту, я высказал своё мнение на митинге (который только для этого и был собран) о недостатках архитекруры проэкта. А именно об использования COM внутри проэкта (для взаимодействи DLL-ек), а не для взаимодейсвия с внешними программами. COM предполагает IDL которые не есть C++, а потому ограничены. Нельзя например там использовать каккой нибудь класс, даже абстрактрый, или тот же CString или что либо из STL.
Использование COM в этом случае вообще не оправдано. Ни одного плюса, только минусы. Но митинг ничего не изменил. Позже я сам в тихую придумал способ как избавится от IDL, чтобы делать хорошо свою работу, вопреки "умным" идеям. Точнее я наследовал интерфейс от интерфейса в IDL, и перенёс ВСЕ методы из IDL в новый C++ интерфейс, что позволило использовать CString, STL и прочее из C++. От COMа осталось только создание объекта с помощью CoCreateInstance.

При чем тут совесть? Я не делаю ничего бессовестного. А добиваться... 1. профессиональная этика требует делать все на совесть. 2. помогает продлевать контракты и увеличивать ставки.

Такую фигню можно в большинстве проектов найти. И что? Это как-то мешает самому работать максимально высокопрофессионально? Или тебе за это досталось?

Ню-ню.

нет ни разу не досталось. только похвалы.
недоверие?
дело в том что "добавить некую фичу к ФИЧЕ" поручили людям которые пока ноль в этом деле. Саму ФИЧУ разработал я (точнее переделал с нуля что уже было но работало медленно и неудовлетворительно). Разумеется я там каждую мелочь знаю. И каждую мелочь "вылизал" чтоб было бысто и эффективно.
Я просто уверен, что после того как они сдадут свою работу, мне придётся зализывать их лажи. Такое уже было, правда там были их проэкты с нуля.

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

Не мешает, но резко снижает ценность собственной работы.

При таком раскладе может быть соотношение 1 к 10, да.

Эффективность уж скорее... Я тут тоже проковырялся кучу времени над простыми фишками. А все потому что приходится приводить в порядок вещи которые за 15 лет никто не удосужился сделать нормально...

Lambdasoft в свое время начала интересную либу для программирования COM в C++, правда так они её и забросили. А выглядело интересно - http://www.lambdasoft.dk/comet/index.htm
А вообще С++ для большинства задач плохо подходит...

Легаси код живет и процветает ;)

В легаси коде пишут на С, С++ там и не пахнет.

Легаси может быть на каком угодно языке.

Есть мнение, что legacy - любой код, не покрытый тестами, что в принципе верно.

Легаси - это просто старый код, что уже следует из определения :)

+1

вы посмотрите на свой код, написанный много лет назад и тоже заплачите.

у меня всегда, даже много лет назад, было отношение к коду: писать так чтобы было приятно смотреть. Сейчас правда я больше уделяю внимания простоте как самого кода так и лёгкости отладки, чем раньше. Кодировать это вроде искусства. Любые изменения в чужом коде я обязательно комменитирую, как минимум своими инициалами, чтобы видели автора изменений. Ну а свои файлы подписуются в шапке файла (впрочем это требование фирмы, которое, правда, не все соблюдают).
Очень раздражает небрежно написанный код. Еще больше раздражает если кто-то такую вставку сделает в моём коде, т.к. еще кто-то может подумать что это написал я! (был случай когда мне предъявили притензии за чужую вставку в моём коде). Сейчас у меня и таких проблем нет. Т.к. я написал утилиту которая парсит все проэкты и сообщает мне о любых измениниях как в моих файлах, так и в моих вставках в чужих файлах. И ежели я не согласен со стилем изменений (с правильностью кода - само собой) то как минимум добавляю коммент - кто там напартачил.

Для этого существует система контроля версий. Лишнего в коде быть не должно. Blame, история изменений, толковые submit-messages дают полную информацию и не засоряют код.

Уже лет 7-8 как не плачу глядя на свой старый код.

Мы работаем с TFS. Но там можно поставить нотификацию только на изменение в файле целиком. Нет возможности контролировать только одну функцию к примеру или даже часть функции в несколько строк.
Это верно что лишнего ничего не должно быть. Авторская подпись - это не лишнее. Т.к. ясно к кому обращаться с вопросами если возникнут. Кроме этого (кроме тривиальных случаев конечно) надо указать почему были внесены изменения и ссылочку на дополнительные описания(у нас это TFS ID, где обычно еще и доплнительные файлы ложатся, картинки, видео и прочее).
По истории системы контроля бывает не легко найти автора кода. Как минимум приходиться тратить время. А бывает вообще невозможно, если commit делал не автор.

Что такое нотификация? Что значит "контролировать"?

Кто автор класса или функции если я изменил половину? Современные методики не предполагают индивидуального авторства.

http://msdn.microsoft.com/en-us/library/bb385979.aspx

Коммитить полагается не мегабайтами, а отдельными фичами/багами/whatever; с понятными описаниями коммита.

Это что за бардак?

нотификация - уведомление. В TFS можно сделать чтоб письмо высылалось. Контролировать - здачит знать об изменениях и что изменения корректны. Некорректным может быть даже просто стиль. Напр. у нас некоторые до сих пор объявляют переменные в начале функции, а не поближе к использованию. Или переменную цикла переиспользуют несколько раз в нескольких циклах, или "просто так" сделают функцию виртуальной. Или не заботятся о контантности функции, если она таковой по смыслу является (тоже относится и к аргументам). Вот чтобы не захламить хотябы мой код чужими вставками я его контролирую.
наполовину ты. Но такое допустимо, ежели предыдущий автор вообще покинул команду, или если все в комманде строго следят за правилами. Я напр. стараюсь чтобы функции были маленькими, а кто-то возьмёт да в ставит 200 строчек в мою фунцию, вместо того чтобы эти 200 строк отдельной функцией(лучше штук пять) и вставить только вызов. Много есть моментов, которые я считаю бардаком и хотябы мой код берегу от него. Хотябы на уровне функций стараюсь сохранить индивидуальное авторство.
там тоже есть недостатки. Даже если кто только пробельчик для красоты добавил или удалил, или орфографическую ошибку в комментарии исправил: annotate теперь его как автора показывать будет. Хотя вещь полезная.
но и мегабайтами тоже приходится. Например при смене системы контроля. Мы уже на третью переходим.
один товарищ у нас работает с парнями из России. Они коммитят в отдельную ветку, а мерджем в основную ветку занимается он. И автором всегда он получается.
Ну еще бывает что с коллегой обсуждал, и закоммители вместе на то том компе где сидели, ну а авторство владельцу компа приписывается.

А code review не хотите делать?

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

про TFS . есть классная книга Sam Guckenheimer , Software Engineering with Microsoft Visual Studio Team System.

Скорее, из России если и едут программисты в Германию, то чаще всего сильные.
А так бы - не сказала.

вы очень уверены в себе.
ещё врагов среди коллег не нажили?

оставлять свой автограф в комменте к изменениям - это требование Code Guidelines. Правда, я заметил что не все во всём им следуют (а некоторые похоже вообще на них забили).
Поэтому даже если я за когото добавлю его автограф к его изменениям - то это корректировка для соответсвия Code Guidelines.
Такие поправки случаются весьма редко. Так что пока никто не возмущался.
Зато что хорошо с этим парсером, что я всегда вкурсе если ктото влез в мой код. Даже если какую мою лажу исправят - я сразу об этом узнаю. Ну а если наоборот лажу внесут, то чем раньше её убрать, тем лучше.

Дикари. Система поверсионного хранения сырцов спасет отцов русской демократии - сразу будет видно, кто версию чек-инил.

ты имеешь в виду типа TFS, SVN?
Кстати не так давно перешли c TFS на SVN (точнее нынешние версии так и остались на TFS, а следующяя и будущие версии уже будут на SVN). В результате вся история накрылась.
А еще более ранние версии хранятся в SourceSafe, при переходе на TFS тоже история пошла с нуля.

а почему ушли с ТФС?

причину этого я знаю только поверхностно, т.к. не я это решал а высшее руководство. Ну а причина (как я понял) что SVN хорошо работает с Polarion (в чём это выражается я пока не знаю), наша шеф-фирма от которой мы сильно зависим уже давно с Polarion работает давно и от нас того же желает. Да вроде еще Polarion для ведения докомунтации получше TFSа. Хотя мои познания Polarion и SVN пока не глубоки.

мой отдел на тфс уже пять лет кайфует.. ибо прожект менеджер, тестер, разработчик роли оболденно работают. Контролируем жизнь продукта
СВН полная лохундра, глючит не даёт базинес валью

у нас есть один коллега который пришел к нам не так давно, как раз в то время как об SVN заговорили. Так он удивлённо поведал, что на предыдушей фирме перешли с SVN на TFS, посчитав TFS лучше...
Начальству виднее. Мне лично почти всё равно. Почти, т.к. под TFS я yже наработал несколько полезных утелиток интегрировав их в VisualStudio как AddIn-ы. Для SVN придётся переделывать.

Переведи плз.
Если руки кривые, никакая система не подойдет. С svn вполне можно работать.

Мы уже несколько лет назад на гит переехали, как вспомню о svn, так вздрогну :-)

У нас есть отдел, который занимается ALM. Так говорят, что в последнее время у клиентов спрос только на TFS и Git.

(раз уж пошла такая трёхбуквенная пьянка)... А я знаю контору на несколько тысяч сотрудников, которая пользуется только MKS! Клиент на жабе, интегрирует в себя работу с source control и систему тикетов.

в TFS, как и SourceSafe, в истории видно кто файл изменил. Мы в комменте пишем коротко что было изменено.
А что бы не возмущаться кодом коллег придложи ввести фирменные Code Guidelines.
Мы у нас в фирме в своё время инвестировали и создали свои Code Guidelines, что бы код более менее стандартный был.

Короче, Склифасофский.....
Блин, вопрос кривовастый... IT-Тема очень обширная. Я тоже айтилер, но я не програмист. А тут по ходу только программеры собрались...
К айтилерам и телефонщики относятся, так как это тоже информационная телекоммуникация....

К чему был написан этот капитанско-очевидностный пост, не несущий никакой информации?

....по сути любой пользователь ПО тоже ИТ-шник...
короче я признаю только два типа..так называемых ИТ.шников...сетевой администратор и разработчик ПО...
всё остальное - простой пользователь...

а как же дба и админы стореджей ?

у Майкрософта разделение на 3 группы:
Administration
Development
Usage

лАхи пазорные!

блин, так и думал

кстати, developers-developers-developers!!! в отставку собирается

да, сегодня читал. наверно, из-за win8 и таблетов :о)
такие люди уходят... как дальше жить? :"-(

+ 10000
Британские ученые наконец установили что 100 % пользователей интернет таки пользуются интернетом.


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

один DBA администрирует, другой девелопает а третий юзает ? :)

дешевле пристрелить их всех к чертовой матери и не морочить себе голову 8-)

Ого какие тут радикальные настроения пошли)

*ну, а чего они?!* :о)
каждый IT-шник, который мечется и не может найти себе место в списке, должен знать, что его ожидает 8-)

но пристреливают обычно они, правда пока только сессии в базе :)

у микрософта есть еще software engineer in test

балмера давно надо было в отставку...

И ваще, любое деление на группы напоминает деление музыки на рок и поп.