Pull to refresh

Comments 129

Перенес топик из программирования в Учебный процесс в IT. Думаю, этот блог подходит лучше.
UFO just landed and posted this here
Такие кафедры есть по всей стране и, по крайней мере у нас, оба названия активно используются.
UFO just landed and posted this here
Вы удивитесь, но МГУ не единственный ВУЗ в России. И даже не единственный в котором есть ВМК. И уж совсем странно, но в некоторых ВУЗах это кафедра, а не факультет.

>А поскольку только на ВМК МГУ устоялась программа обучения студентов Computer Science

Да уж, больше в мире нигде не выпускают хороших специалистов ИТ.
UFO just landed and posted this here
«Не верю»

Сможете методом полного перебора доказать, что ни из одного вуза России, кроме МГУ, не выпускают хороших ИТ специалистов? Перебирать можно как по списку выпускников всех вузов России, так и по списку хороших ИТ специалистов всего мира. Любое другое доказательство не будет полным, насколько я понимаю логику.
UFO just landed and posted this here
Утверждение сформулировали вы и как раз мне интересно определение при котором оно будет истинно. Естественно кроме прямо удовлетворяющих утверждению: множество «хорошие ИТ специалисты российского выпуска» является подмножеством «выпускники ВМК МГУ»
Я благодарен вам, что вы внимательно прочли статью и высказали свою критику. Я думаю, что меня оправдает то, что я не учусь на ВМК МГУ, поэтому не приносил клятву верности традициям и непоколебимости названий. Впредь буду знать, спасибо.

А вообще, будьте проще. :)
Откуда столько пафоса? То МГУ институтом не назови, то ВМК ВМиКом. Чести вам такие комментарии не делают.
Ну МГУ институтом называть несколько неверно (хотя я его в глаза не видел), как и, например, ЛГУ (его видел), то есть учебные заведения, которые много лет назад создавались именно как университеты.

А вот сегодня познакомился со студентом своего института, в который поступал в первом как в университет потоке 19 лет назад (а история как института — 91 год до переименования в университет, плюс 5 лет как училища до того) — называет институтом несмотря на смену (имхо, формальную) вывески.
Понимаете. Вот я живу в подмосковье, тут около одной школы есть в полу-заброшенном здании университет: «Университет географии и геодезии» (ну или как-то так). Так что институт или университет — это синонимы, не отражающие уровня учреждения. А вот эта «кастовость» вызывает только смех, особенно учитывая то, что МГУ — далеко не первый ВУЗ на мировой арене.
Даже MIT — институт.
Вы не поняли мою посылку: университет или институт — это разные типы образования, уровень этого образования вообще к названию не относится. Тем не менее МГУ или ЛГУ я отношу к университетам, а свою альма-матер к институтам (не смотря на то, что она 19 лет носит название университет и её диплом в мире признаётся не только в буркина-фасо). Но меня тоже возмущает оттенок «кастовости», слышимый при произношении слова «универ» некоторыми студентами.
А можно поподробнее — в чем они столь разные?
Имхо, институт должен готовить специалистов/инженеров/практиков, университет — генералистов/ученых/теоретиков. Для первых упор на реализации задач, для вторых на их постановке. В учебных планах могут совпадать полностью не только название, содержание и часы предметов (дань образовательным стандартам), но не должны совпадать критерии оценок.
Странно. В мире полно институтов, выпустивших известных теоретиков и ученых. Думаю разделение все же очень условно и слова можно считать синонимами.
Нецелевое использование либо ресурсов вуза, либо названия :)
Ну может быть. Просто первый раз вижу человека, который проводит вот такие формальные различия.
На хабре мне единомышленники встречались :) Впрочем как и ваши. А также те, кто считает, что цель вузов вообще готовить «постановщиков задач», а не «исполнителей» — мол, реализовать уже алгоритмизированную задачу и обезьяна сможет, если вовремя ей давать банан и бить палкой.
UFO just landed and posted this here
не забудьте приручить его после выпуска из университета

ключевой момент. Иначе коллеги вас возненавидят ;)

Иначе может дойти до того, что вам дают задачу в legacy коде и вы не сможете добраться до самой задачи, так как первый же открытый вами класс потребуется «срочно привести в идеальное состояние!».
Всю мощь и нужность рефакторинга понимаешь тогда, когда начинаешь заниматься поддержкой проекта, который писали человек 10 до тебя, обладали разной квалификацией и придерживались разных стилей, подходов и технологий.
Вот именно! А если это короткая лаба на полстраницы, которую никто после тебя переделывать не будет (ведь его накажут за списывание!), то городить в ней иерархию классов с обертками для тестирования можно только в свое удовольствие, и рефакторить потом тоже только в свободное время.

Учиться правильно программировать — нужно, но не на таких простейших заданиях. Потому что в данном случае как раз подход «весь код внутри main()» значительно выигрывает — его быстрее писать, он легче, лаконичнее, да даже понятнее. А все недостатки, ему присущие, тут-то как раз и не проявляются. Итог — мы учимся «правильному» методу на примере, для которого «неправильный» был бы лучше. И если студент не даун, он сам это понимает, и на будущее запоминает именно «неправильный» метод, потому что он НА ПРАКТИКЕ показал себя лучше.
Забавно написано, но всё в точку. Хотя я почти уверен что все эти слова были сказаны вхолостую. Мышление среднестатистического студента настроено на то чтобы скорее сдать, а не сделать качественный рабочий проект или разобраться в тематике и научиться чему-либо.
Тем не менее те студенты, которые планируют стать программистами, учитывают это, и в своих собственных решениях подобная ересь потихоньку уступает место современным методам разработки.
Безусловно, те кто планирует стать программистами, знают, что им нужно изучать. Но большинство тех, кто планирует работать на должности программиста… Сами догадываетесь что. Я когда подыскивал программиста на открывшуюся вакансию, таких «программистов» повидал, что плакать хочется.
Я тоже не могу найти толкового. Особенно поражают «программисты», которые приходят устраиваться на работу с кучей корочек разных курсов. Он видите ли и MCSA и MCSE в одном флаконе. К тому же еще и CCNA. А реально я бы ему включить сервер не доверил, не то что к клавиатуре прикасаться, да еще и с рутовскими правами.
Не знают. В университетах рассказывают сами знаете как и что. Тех.литература — в одной одно говорится, в другой другое, кому верить что и как? Пока не пошел на курсы Java-программирования в учебном центре Epam Systems (после 3 курса), не знал даже основ ООП. Вуз провинциальный, не Россия
я осознал, что учусь не для кого иного как себя, став подходить к заданиям творчески, только на 4-5 курсе. Большинство преподавателей тоже не сильно ждали от студентов творческого подхода и не сильно пытались заставить думать своей головой вместо копипасты учебников.
Я, впрочем, учился в вузе совсем иного профиля.
По своему опыту могу сказать, что «вредные советы» 1 и 2 зачастую преподавателями не воспринимаются как вредные. Или это было только в 90-х и те, кто тогда были рядовыми преподавателями (а сейчас зав. кафедры и деканы), теперь думают по-другому?

P.S. Процедурный стиль ориентирован на написание процедур (функций). Наверное это родитель большинства методик повторного использования кода (родитель — цикл) и, что ещё, по-моему, важнее, декомпозиции, а вы, наверное, имели в виду линейное исполнение (максимум — циклы).

P.P.S. для граммар-наци и сочувствующих: если с запятыми переборщил — в личку.
Думаю, насчет процедурного стиля я действительно переборщил (пойду, исправлю). Как вы верно заметили, я имел ввиду линейное исполнение без применения декомпозиции. Обычно ребята говорят «без функций/без классов/без модулей» и т.д., конечно. :)
Все проходили через паскаль)
Побольше бы таких статей. Чем-то напоминает статью "10 способов улучшить свои навыки программирования"
PS: Мне лично на первом курсе было очень сложно выделить время на создание «маленького» проекта, учитывая что помимо программирования я учил физику, мат.анализ, дискретную математику… Нагрузка нынче не позволяет строго выполнять все пункты которые были перечислены здесь.

Кстати, верная мысль насчет нагрузки. На работе я имею возможность полностью погрузиться в проект, учась в университете, первую половину дня сидишь на парах, потом надо решить с десяток задач по мат.ан.-у, написать лабу по Си, выучить топик по английскому и подготовиться к тестированию по курсу баз данных. Заниматься тщательным проектированием и аккуратной реализацией просто нет времени, к тому же нет необходимых для этого навыков. ИМХО, для того чтобы студент имел возможность развивать в себе «маленького гнусавого перфекциониста рефакторинга» нужно полностью изменить учебные программы вузов.
Менять конечно надо, но. Не обязательно начинать всё «по книжкам». На первом втором курсе вы пишите интересный вам проект как умеете. Потом, начиная с третьего курса, когда приходит некоторое понимание, вы постепенно его перепишите, исправите, короче, проведёте рефакторинг.

Это не голосновные заявления, а слова основанные на личном опыте.
И да, на большинство предметов можно «забить» (конечно, если вы не задались целью получить красный диплом), или учить для себя, а не для «сдачи».
Насчёт нагрузки, имхо, неверная мысль, если она основана на совмещении учёбы на дневном отделении и работы. Увы, нынешние реалии к этому вынуждают и мысль становится верной.
К первому пункту наряду с транслитом хочется добавить «комментарии на русском языке».
Да хоть какие-нибудь…
А зачем? Код у тебя на английском, значит и комментарии нужно писать на нем.
Старайся сделать свой код универсальным, т.е чтоб даже иностранец понимал о чем идет речь
Про то и речь. Это один из вредных советов
Код на языке программирования — то, что его токены совпадают с английскими словами лишь случайность (пускай закономерная). И, имхо, лучше хорошо выражать то, что он делает на удовлетворительном русском (а как сам код и объяснит), чем плохо — то, как он делает на плохом английском неизвестно что.
Зачастую комментарии пишутся на таком «английском», что лучше бы их вообще не было. Если код не будет покидать стен конторы, а работать с ним могут те, кто в школе учил немецкий, то вполне обоснованно комментировать и на русском, не вижу в этом никакой проблемы.
Опередили, но мой коммент выше :P
Стоп. Мы говорим о студентах. Какая контора? Лично я имел в виду open source
До сих помню один прекрасный исходник, в комментариях которого очень путались слова peak, peek и pick. Но даже такой английский лучше комментариев на русском.
Cпасибо, статья великолепная. Я сам преподаю в университете (аспирант), и меня также смущает использование тех самых «синтетических» примеров, но по другому часто не получается по ряду причин:
1) самая главная — если давать примеры из реальной жизни, просто не хватит времени уместить всё, что требуется, и всё, что хотелось бы.
2) зачастую, приходится преподавать исключительно по рабочим программам, шаг влево, шаг вправо — расстрел.
3) уровень студентов и их нежелание дополнительной самостоятельной подготовки.
Согласен с вами, я тоже преподаю в университете.

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

Я даже индивидуально каждому студенту (4 курс, «Интеллектуальные информационные системы») предлагал на выбор: либо задания, которые я им принёс, либо они сами себе придумают проект. Причем договорился с завкаф, что если кто-то хорошее задание себе подберет, его можно и на диплом. Итог, в общем-то, ожидаем: большей части студентов это нафиг не надо, никто свой проект не предложил. Да и мои-то задания решали с очень большим скрипом, хотя там делать — раз плюнуть.
Существует проблема пассивности и среди студентов и среди преподавательского состава. У меня опыт небольшой — 3 курса, за это время сложилось мнение, что эти проблемы, во-первых, очень тесно связаны между собой (не интересно студентам -> не интересно преподавателю -> он начинает спрашивать меньше, давать меньше -> студенты теряют всякий стимул к учебе), а во-вторых, со всеми остальными проблемами нашего образования (такой, например, как огромные наборы на первые курсы, проставление хилых троек из-за странной системы финансирования и выплат зарплат преподавательскому составу и т.д.)

Проблема есть — это факт. Единственное, что я на самом деле хотел объяснить студенту в этом топике, — что он сам себе должен помочь и обеспечить свои знания. При таком подходе и работа с преподавателем пойдет с толком.
Частичным решением проблемы может стать внедрение системы автоматического тестирования решений (САТР) на 1-2 курсе вуза.

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

Такая система позволит отвлечься от неблагодарной проверки и сосредоточится именно на процессе обучения. Появится больше времени на то, чтобы помочь студентам и указать на их ошибки. А студенты то точно пойдут к преподавателю, так САТР непоколебим. Не прошел тест — задача не засчитана. И ничего ты ему не скажешь, на жалость не надавишь. В общем — «бездушная машина».

Есть конечно и минусы:
1. Наполнение. Необходимо наполнить систему задачами и тестами для них. Причём: желательно сделать для каждого человека отдельный вариант задания; разносторонние тесты, которые покрывают граничные случаи, не позволяют сдать «перебор», и т.д. С одно стороны это минус, но всё равно пришлось бы придумывать тесты при приёме решения задачи у студента.
2. Списывание и сдача чужих решений. Наверное единственный способ защититься от недобросовестных студентов это просто проводить с ними устную беседу. Студенты, которыс «сдались» не самостоятельно обычно быстро «тонут».

Всё это не фантазии, а описание реального опыта.
Я на такой вот доморощенной системе САТР как-то набрал всего 90% в процессе тестирования.
Из-за того, что на один из вопросов ответил: struct {int X,Y;} point;
А правильный ответ такой: struct {int X; int Y;} point;
И к преподавателю идти было бесполезно. В общем, «бездушная машина» — это мягко сказано.
Судя по вашему комментарию, вы не поняли что должна делать система.
Это не тест, где ты выбираешь правильный ответ из имеющихся.
А система, которая берёт твоё решение, компилирует его (если надо было писать на компилируемом языке) и выполняет на разных входных данных и сверяет ответ с эталонным. Т.е. как вы реализовали системе всё равно. Главное, чтобы решение выдавало верный конечный результат за приемлемое время.

Подобные системы используются на олимпиадах по программированию.
И почему сразу доморощенной. Как вариант одной из дипломных работ можно дать задание одному из способных студентов адаптировать уже сущетвующую систему к нуждам вуза. Например ejudge.ru/
в действительности студента нужно просто гнать ссаными тряпками на гитхаб в реальный проект с нормальными задачами.

>реальные задания даются слишком поздно — студент уже привык писать код «лишь бы сдать», обычно это дурной код.

я честно не понимаю смысла такой методики обучения — несколько лет учить сферическую фигню, потом еще пару лет учить сферическую фигню, приближенную к реальности, а потом ВНЕЗАПНО начать делать какие-то реальные проекты, в которых решаемые проблемы будут находиться в совершенно другой плоскости.
Вы не считаете, что есть риск получить узко направленного специалиста?
И если неповезет, человек может тупо остаться без работы, потому что не сможет вовремя сменить специализацию.
«Сферическая фигня», на мой взгляд, как раз призвана развивать в человеке абстрактное мышление, умение мыслить категориями, а не понятиями на уровне того или иного языка.
>Вы не считаете, что есть риск получить узко направленного специалиста?

не считаю. откуда вы это взяли?

>«Сферическая фигня», на мой взгляд, как раз призвана развивать в человеке абстрактное мышление, умение мыслить категориями, а не понятиями на уровне того или иного языка.

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

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

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

>Дроп бокс, гит — это способ организации рабочего процесса

хранить файлы в VCS, ставить отступы и уметь работать в команде — это не специфические требования.
Что значит «гнать на гитхаб в реальный проект с нормальными задачами»? Заставлять его выкладывать свои решения на гитхабе? — Реально и даже может быть есть смысл. Заставить его подключиться к существующему проекту? — Нереально, имхо, по двум, как минимум, причинам: первая — коммьюнити может патчи студента не принять не смотря на их техническое совершенство, просто скажут «не… way» или «никому это не нужно»; вторая — у студента может элементарно не хватить данных преподавателем знаний, для выполнения реальной задачи. Про вопрос выбора проекта, к которому должен подключиться студент, я вообще промолчу.

И, кстати, почему именно гитхаб?

> подключиться к существующему проекту?

именно.

>патчи студента не принять не смотря на их техническое совершенство, просто скажут «не… way» или «никому это не нужно»

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

>у студента может элементарно не хватить данных преподавателем знаний, для выполнения реальной задачи

ну и нафиг он такой нужен, если нигде не может свои знания применить?

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

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

>И, кстати, почему именно гитхаб?

совершенно все равно, что именно.
> подключиться к существующему проекту?

именно.

Представляете себе студента сегодня узнавшего что такое программирование вообще и Си в частности и посылающего патчи, например, в ядро Линукс?
а это тоже хороший опыт — выяснить, что к коду предъявляются еще какие-то требования кроме «запускается и пишет правильные буквы»

Проект может писать «неправильные буквы» (создатели знают только ASCII, а про CP-1251, KOI8-U и, тем более, неоднобайтовые кодировки слышать не хотят, но использование только ASCII даже не документировано, а баг-репорты отклонены) и патч студента будет удовлетворять всем возможным требованиям, кроме «у проекта 5 пользователей, включая тебя, мы вчетвером сейчас пьём пиво у меня дома и обсуждаем твой патч — только тебе нужен этот оверхид для преобразования 0x40 в 0x40 через многомегабайтные таблицы — пиши по-английски, бро, ты же умеешь!»
ну и нафиг он такой нужен, если нигде не может свои знания применить?
Студент на ИТ-специальности должен уметь патчить ядро Линукса сразу после того, как ему рассказали о типах данных в Си?
если выбрать проект не получается, то его надо создать, как вы сами и написали в комментарии ниже.

У подавляющего большинства не получится выбрать так, чтобы хоть одну строку закоммитили в транк, равно как получить хоть один фидбэк от своего кода, а значит от «выгона в гитхаб» локальная разработка не получится.
>Представляете себе студента сегодня узнавшего что такое программирование вообще и Си в частности и посылающего патчи, например, в ядро Линукс?

с ядром линукса вы несколько загнули, но наверное я тоже погорячился и забыл про ту фазу обучения, когда человек «только сегодня узнал» как вообще пишут программы.
Просто хотел показать, что участие в реальных проектах для студентов несколько проблематично. Если он может, то зачем ему учиться?
3 Язык C никому не нужен, все пишут на Java/C#/PHP/etc

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

5 VCS? Unit-testing? Документация? Я же один работаю над своими крошечными лабораторными/курсовыми, мне все это не нужно

Если у вас есть возможность демонстрировать написание кода на аудиторию (через проектор например), то я бы показал пользу систем контроля версий исподволь. Специально бы большую часть пары писал не то, что надо в каком-либо шаблоне, так чтобы студенты не сразу просекли что пишется лажа. Потом ойкнуть, сказать что все неверно, откатить код и написать быстро все как надо. И только после этого сказать о пользе систем контроля версий.
В таком варианте студенты быстрее запомнят и пользу и практику использования таких систем. Такие экспромты запоминаются надолго. Не знаю, можно ли это расширить на применение тестов.
Откат, имхо, не самый лучший способ демонстрации пользы VCS. Не говоря о возможных административных и даже юридических проблемах («Препод нам что-то показывал полпары, а потом откатил — за что мы деньги платим?! или даже просто „Нафиг мы это конспектировали?!“).

Я бы демонстрировал пользу ВКС и автоматизированного тестирования на лабах/практике, а не на лекциях и именно в процессе групповой разработки. Грубо говоря задавал бы студентам на весь свой курс какую-то задачу (более-менее близкую к реальности), рассчитанную на то, что к концу курса группа его доведет до логического конца и показывал бы именно на их косяках важность тех или иных технологий. Если учебные планы и прочие стандарты мешают каждому студенту (или паре) давать отдельную подзадачу (по сути преподаватель выступает в роли ПМ и/или ТЛ), то мержить с основной веткой проекта наиболее лучшие ветви (и как раз тут покажут себя и откаты, и тесты — мержим решение первого студента, тестируем (с логами), откатываем, потом второго и т. д. — отлично ставим тем, чья ветка пошла в „релиз“ по объективным (в т. ч. и для студентов, показателям).
Это целый курс по использованию систем контроля версий и планированию, и совместной работе! ;) Больше тянет на факультатив, но идея хорошая, более комплексная.

Мой пример наверно был навеян байкой/былью кажется от Марка Твена: когда я был маленький отец повел меня смотреть на метеоритный дождь. Когда мы смотрели, он вдруг ни с того, ни с сего пребольно ударил меня прутом по попе. Мне было больно и обидно, ведь я не заслужил. На что отец ответил, что зато ты навсегда запомнишь этот момент. Запомнил, о чем и не жалею.

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

Когда я учился в школе, то часто откатывал в тетради целые страницы (а то и дневник целиком — эмулировал отказ носителя :) )

Я большой сторонник разбития или какого-то отмечания студентов по предметам на тех, кому это действительно интересно/нужно и на тех, кому нужно лишь для галочки. Когда я учился на инженера-системотехника (желая учиться на инженера-программиста, в то время когда в соседней группе по той же специальности люди учились наоборот, но наша беда была в том, что они случайно набрали на один балл больше чем я), то приближение к этому у нас было реализовано лишь на «английском», там разделяли на «продвинутых» и, извиняюсь, похуистов даже не по фактическим знаниям, а по желанию (так я был в «субпотоке» «продвинутых» вместе с одногруппником, который знал английский на уровне Си и Бэйсика, но хорошо владел французским).
Когда на программистов будут идти только те, кто действительно хочет научиться и работать в профессии, а не те, кто просто тянет лямку ради корочек, или кого родители отправили получать высшее образование куда-нибудь попрестижнее. Вот тогда всё написанное в статье будет иметь смысл. Стараться ради одного-двух человек на потоке ни один преподаватель не станет, это бессмысленно, он ведь тоже на зарплате сидит. Я сам не так давно был студентом, и хорошо помню ситуацию не только в нашем потоке, но и в младших потоках. Везде всё одинаково: 1-2 человека, кому это надо, и 50, которые тянут лямку и 1+1 не могут сложить так, чтобы получить 10.
Это касается, имхо, не только программирования, но и вообще системы ВО в целом. Очень многим студентам нужен только диплом, а не знания и навыки. Хорошо даже если студент выбрал учёбу, как инвестиции в будущее (экономическое и социальное), даже если специальность ему противна, но он самоотверженно ею овладевает (меня на такой подвиг хватило на три года — профессия инженера-системотехника не привлекала, хотел стать инженером-программистом, но все равно «инвестировал» в общеинженерную подготовку с надеждой получить когда-нибудь второе ВО, когда она закончилась — забил, показалось что «инвестиции» непосредственно в разработку софта выгоднее). Идеально, если такой процесс инвестирования связан с реальным интересом.
А чем плоха разработка своей CMS? Я в студенчестве делал сайт кафедры на своей CMS, которую после доработки продавал. А теперь на ней крутятся серьезные проекты с 200к человек в сутки, которые бы не потянул друпал или вордпресс.
Кстати да, написание своей цмс — очень познавательный процесс.
В данном случае чтобы сделать сайт из двух-трех страниц имхо нет смысла писать свою CMS.
… как и использовать CMS для 3х страниц.

Для обучения они должны писать своими руками, а не устанавливать готовое решение.
Я думаю, что при умелом подходе, можно попробовать написать CMS в качестве задания, и это будет полезно и пзнавательно. Отговаривал я этих ребят тогда потому, что сам немного занимался сайтами, и идея «написать собственную CMS, чтобы сделать один сайт» мне показалась глупой. О пользе для обучения я тогда подумать не успел — все пришло со временем. :)
Я думаю написание CMS за семестр-два было бы отличным групповым заданием — кроме навыков собственно алгоритмизации и реализции задач, дало бы навыки командной разработки и т. п. Тем более, что легко, имхо, было бы оценить вклад (а значит и оценку) каждого студента статистически, хотя бы ориентировочно (потом можно устроить защиту своей ориентировочной оценки, на случаи «у него брат ведущий» и т. п.)
как же всё знакомо. «повезло» мне поступить когда-то на только что открытую специальность инженер-программист в местном (ныне федеральном) ВУЗе.
Преподы сами не знали чему учить, в итоге упор вообще увели с программистов на ИТ-менеджеров.
Все по делу написано. Спасибо. Мне бы такое прочитать года 2-3 назад. Я многое из перечисленного знал, но не использовал (на самом деле не хватало времени: матан, физка и тд и тп). Реально понял необходимость указанного только когда пошел работать в коллектив, где есть опытные сотрудники, всегда готовые помочь, подсказать и спокойно указать на ошибки. Теперь всегда нахожу время в каждой лабе и тем более курсаче для написания тестов, а также создания репозитория в SVN.
По делу. Донести бы это до первокурсников it-специальностей…

А насчет Си, еще Джоэль Спольски говорил, что если вы не понимаете, почему while(*(pointer++)) бежит по списку, то вы не программист.
По списку? Или все-таки по строке? :-)
А по делу, я тут не согласен с Джоэлем. Если ты программируешь на питоне, то на кой тебе эти поинтеры?
pointer может быть указателем на любой тип — хоть на char, хоть на структуру. В этом прелесть арифметики указателей — операция инкремента смещает указатель на размер структуры в памяти, на которую этот указатель указывает(простите за тафтологию).

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

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

list_orig = [1, {"yo":1}]
list_copy = list_orig[:]

assert list_copy[1]["yo"] == 1, "wanna 1 here"

list_orig[1]["yo"] = 2

assert list_orig[1]["yo"] == 2, "wanna 2 here"
assert list_copy[1]["yo"] == 1, "Опаньки, что это у нас тут???? АААА1111 ОТКУДА?7777"


попробуйте объяснить, что тут происходит человеку, который не понимает указателей.
Он то же говорил про рекурсию и был прав. У нас почему-то принято учить рекурсии на примерах, вообще не подходящих для этого, вроде тех же чисел Фибоначчи. Если бы показывали свёртку, например, это было бы полезнее:
www.joelonsoftware.com/articles/TestYourself.html
Я прошёл это тест лишь благодаря тому, что сейчас активно занимаюсь функциональным программированием и уже успел вынести себе мозг рекурсией по самое не балуй. Но большинство студентов вряд ли интересуются подобными темами, и результат печален.
Простите мою отсталость, но чем плохо использование рекурсии для чисел Фибоначчи (или факториала), кроме потенциального переполнения стэка (при слишком «глубоких» исходных данных), свойственного любому языку без оптимизации хвостовой рекурсии (или при коде, не использующем эту возможность)?
Тем, что числа фиббоначи можно вычислить за O(log(n)) времени, а рекурсия выполняется за O(n).
Преждевременная оптимизация не зло?
Но ведь вы же не используете везде пузырьковую сортировку до того, как начали профилировать?
В данном случае выбор алгоритма не скажется ни на чем, кроме процедуры вычисления самих чисел Фиббоначи — следовательно не является таким опасным, как именно «преждевременная оптимизация» не алгоритмической части проекта.
Я использую сортировку из стандартных библиотек. Если её там нет (сложно представить), начну, пожалуй, именно с пузырьковой как с первой придуманной (и примененной для практических задач) лет 20-25 назад (несколько лет я изобретал пузырьковую сортировку, как потом оказалось после попадания в мои руки первой книги по алгоритмам). Если при профилировании окажется, что «самопальная» пузырьковая сортировка значимого значения не имеет, то не стану её трогать, даже если в стандартную введут что-то более навороченное.
Что касается оптимизации — все же надо соблюдать разумный баланс между «надо все заоптимизировать сразу» и «преждевременная оптимизация — зло, пишу первое попавшееся».
Если всегда руководствоваться вторым правилом — окажется, что проделана куча лишней работы и надо много переделывать. Особенно если на этапе создания быстрое и медленное решения требуют практически одинаковых трудозатрат.
Ведь если с самого начала выбрать неверную платформу разработки, неправильную БД, реализовать медленный алгоритм — в конце концов окажется, что после профилирования ничего конкретного не тормозит, потому что все части работают одинакого медленно.
По-моему очевидно, что если заведомо известно, что из двух возможных альтернатив одна хуже по всем критериям, то бросать монетку не стоит. А вот если вес скорости разработки много больше веса скорости исполнения или потребляемой памяти, то писать нужно то, что знаешь как быстро написать.
В данном конкретном случае, если говорить уж о применимости рекурсии — то она тут правда очень слабо применима и ничему хорошему не учит. Тогда уж если показывать — то лучше обход дерева делать.
В любом нормальном проекте такие базовые задачи лучше решать уже зарекомендовавшими себя базовыми алгоритмами, чтобы избежать потом ошибок с тем же переполнением стека.
Честно говоря, не помню что такое числа Фибоначчи, помню, что они подаются в качестве примера реализации рекурсии почти столь же часто, как расчёт факториала — его помню, но на практике тоже не использовал, не считая «одноразовых» скриптов для расчёта вероятностей. Что рекурсию лучше двавать на примере обхода деревьев полностью согласен — не каждый способен понять сам, что у них много общего.

Числа Фибоначчи — рекуррентная последовательность:
[1; 1; 2; 3; 5;…; (a[n-2] + a[n-1])].

Если использовать рекурсию, то мы будем считать n-нное число так:
let rec fib n = 
    match n with
    | 0 | 1 -> 1 //если n - 0 или 1
    | _ -> fib(n-1) + fib(n-2) // в любом другом случае


Т.е., для вычисления fib 5 будет такая последовательность вызовов:

fib 5 -> (fib 4, fib 3) -> ((fib 3, fib 2), (fib 2, fib 1)) ->…

Уже на третьем шаге видно, что fib 2 будет посчитан дважды. Именно для похожих случаев пригодно динамическое программирование. В данном случае нам достаточно запомнить 2 числа — предыдущее и предпредыдущее (ну, и буфер для обмена):
let fib n =
    match n with
    | 0 | 1 -> 1
    | _ ->
        let mutable preN, curN, newN  = 1, 1, 0
        for i = 0 to n - 2 do
            newN <- preN + curN
            preN <- curN
            curN <- newN
        curN

Теперь мы считаем снизу вверх и гораздо быстрее.
Вспомнил :) Как-то даже реализовывал на Бэйскике :), но помню, что алгоритм был сверху вниз, но повторные вычисления fib 2 кэшировались в глобальном (но в Бэйсике всё глобально) массиве.
Аха, так тоже можно (с глобальным массивом). Это даже ближе получится к типичным применениям динамического программирования.
Если человек применяет рекурсию для расчета чисел Фибоначчи, он просто слабо представляет, сколько лишних вычислений производит его программа.
А если знает, то зачем писать плохо, если можно хорошо? Тем более если это нетрудно в данном случае.
В принципе я знаю, что большинство (все?) рекурсий можно развернуть в цикл, но если мне проще реализовать функцию в виде данного мне рекурсивного определения, то зачем заморачиваться разворачиванием? Цикл «по и от 1 до 10» сработает заведомо быстрее если его тело откопипастить 10 раз, заменив переменную цикла на хадкорное в каждой «итерации» значение при каждом использовании этой переменной в теле. Вы часто этим занимаетесь?
Тут дело не в цикле, а в повторном использовании уже рассчитанных значений. Посмотрите инфу по динамическому программированию.
Числа Фибоначчи гораздо лучше иллюстрируют такую вещь, как динамическое программирование — получается ясный и быстрый алгоритм. И очень плохо демонстрируют рекурсию. В результате студенты уходят с представлением, что они понимают рекурсию, хотя они имеют о ней весьма смутное представление.
По списку или по массиву с нулем в качестве конца? Если второе неверно, то совсем я Си забыл…
Конечно, всё это верно, НО: этому просто так не научить — человек сам должен понять все плюсы и минусы, глупо пытаться вдалбливать в него какие-то идеи, которые ему просто напросто не нужны.
Те же стили, структуризация, юнит-тесты — их необходимость проявляется лишь в больших проектах. Пусть учащийся сам попробует создать что-нибудь большое и полезное, и тогда он поймёт сам, намного лучше. Ваши доводы «это понадобится в реальных проектах» скорее отпугнут человека от программирования вообще.

P. S.: насчёт «кодирования» — кодирование информации, кодирование от алкоголизма в конце концов. Но с программированием это звучит плохо. В том то и дело, что учат «кодированию» — просто писать код. Студент же должен понимать структуру программ, цели тех или иных средств и методов, которыми он должен пользоваться. Он должен понять почему, а не думать, что просто «так надо/принято/требуют».
Пусть лучше вся группа в процессе обучения пишет один большой проект. И пусть он будет полезным.
А то все эти «найдите среднюю длину слов в массиве строк» уже задолбало, кому это интересно?
СЕОшникам для оценки работ реврайтеров? :)

Насчёт одного большого проекта (пускай на семестр) согласен, насчёт полезности — нет. Он должен быть реальным, пускай (а может даже лучше) клоном существующего, польза от его использования необязательна.
Закончил первый курс специальности «Информационные технологии» в ЮУрГУ.
Честно сказать, по началу меня жутко бесило делать процедуры или функции для 3-ёх строчек вывода или ввода данных, но задачки нам давали специально такие, чтобы со временем без этого «дробление» никуда не деться. Были отдельные лабораторные по созданию библиотек, потом эти библиотеки неоднократно применялись в след. лабораторных. Преподаватель спрашивал как будет заполнятся стек при вычислении факториала через рекурсию, просил показать как будет происходит сортировка таким-то или таким-то метод прямо по шагам. К чему я это — преподаватель попался хороший, а сами задания были созданы с головой, т.е. не всё так плохо. Да есть ребята, которые лишь хотят всё сдать быстрее, но заинтересованность руководители и студента даст отличные результаты. Это была практика.
А на теории, в смысле на лекциях по программированию мы решали задачки практически ручкой. Задачи были порой не обязательно, но я лично старался выполнять большую часть. Написал пару несколько игр (крестики нолики, с помощью canvas; игру угадайку типа «akinator» и игру жизнь). И опять же к чему я это? — Я не просто выполнял задачу, а старался красиво сделать. Программировал на Delphi. Делал меню, делал сохранения, загрузку, о программе и тд, даже выпускал обновления и выкладывал на свои страничке, давал друзьям и знакомым попробовать. В общем старался сделать приятный продукт, именно продукт, которым смогу пользоваться не только я, но и кто-то, пусть и из узкого круга людей, но всё-таки…
В общем главное старание и желание.
И забавно, что программирование на Assembler'e вёл другой преподаватель и, честно сказать, я мало чему научился. Да, я не сильно упирался в его изучение, но прочитал книжку, сайтов парочку. Но вот само отношение преподавателя, наверное, всё и погубило, весь интерес… Хотя слабая отмазка.
Были отдельные лабораторные по созданию библиотек, потом эти библиотеки неоднократно применялись в след. лабораторных.

Замечательная, по-моему, практика, даже (ещё лучше?) если такой подход в рамках одного семестра и повторное использование кода (создание библиотек) явно не позиционируется.
«взрастите в себе маленького гнусавого перфекциониста рефакторинга (не забудьте приручить его после выпуска из университета);»
К сожалению, это приводит к другой болезни. Для некоторых проектирование и рефакторинг становятся карго-культам: «надо нарисовать побольше UML-диаграмм», «тут можно сделать обобщение...»
А с остальным согласен, особенно про VCS и open-source проекты.
Так даже вы процитировали, что «не забудьте приручить его после выпуска из университета»…
А зачем учить чему-то изначально неправильному?
Оно не изначально неправильно, оно не эффективно в некоторых ситуациях, но эффективно в других.
Мне кажется, гораздо важнее некая «интуиция» — когда задачу решать в достаточно общем виде, а когда только вот для этого конкретного случая. А она только с опытом появляется. Если показывать студентам хороший, красивый и правильный код — они не будут писать говно изначально. И да, я вообще большой противник акцента на объектно-ориентированных методиках — особенно в обучении. В небезызвестном университете Carnegie Mellon вообще отказались от обучения ООП, оставив его как дополнительный курс. Рефакторинг, всё же — явление весьма дискуссионное (зачем писать код, который изначально планируется переписывать?). Но я уже несколько отхожу от темы.
Внятных аргументов, почему паскаль и си это хорошо, а остальное — плохо (ибо «не абстрактно») не существует, более того, есть косвенные контрагрументы. Nobody cares, мантра «паскаль — лучший язык для обучения» не умрет никогда.
Мне нравится вот это: www.stolyarov.info/pvt/anti_c
На мой взгляд, действительно неплохое объяснение почему паскаль — более подходящий язык для обучения.

P.S: У нас в своё время на первом курсе было так: семестр паскаля, семестр — Си.
Эти самые рассуждения — «они ничего не поймут!!1» — опровергаются любым опытом обучения не паскалю. Все все понимают. Люди не настолько глупы, как их пытаются представить
Скорее те, кому дано понять алгоритмизацию и программирование, поймут обучение хоть на брейнфаке, а кому не дано, те не поймут даже на Лого.

Знаю людей, которые успешно учились программированию на Фортране, и знаю, которым не помог ни Паскаль, ни Си, ни Фортран, ни Ассемблер, ни C++ (в рамках одной группы студентов, набравших одинаковый суммарный балл (16 по десятибалльной системе) на вступительных по физике и математике). Лабы кое-как сдавали (не без моего участия, прежде всего на уровне алгоритмизации), но не более.
До 4-го курса я и мои одногруппники, не являющиеся имбецилами в программировании, старались следовать описанной вами инструкции. Но в конце-концов все поняли, что делать это на нашей кафедре — дурной тон, по-другому это называется «метание бисера перед свиньями». Делать что-то крутое, вкладывать в это душу, чтобы потом очередной «преподаватель», не отличающий мышку от клавиатуры, придрался к шрифту в твоем отчете? Увольте. Я лучше сделаю что-нибудь на работе или буду писать свои проекты, не связанные с университетом.

PS Да, разумеется, студенты всегда считают себя умнее преподавателей, зачастую необоснованно. Но, я думаю, большинство здесь со мной согласятся, что преподавательский состав на IT-специальностях нынче объективно слабоват.
«Объективно слабоват» для чего? «Шрифт в отчёте» явно не критерий (особенно если шрифт ГОСТом не предусмотрен).
Для преподавания IT-дисциплин. Он и смотрит на оформление отчета, потому что в код залезать боится (я серьезно), так как это сразу обнаружит его некомпетентность.

Из-за этого студенты просто рисовали формы в билдере или акцессе, делали скрины для отчета и сдавали, не написав ни строчки кода. Если у преподавателя прокатывает такое, он не слабоват? В итоге после выпуска у нас код умеют писать ровно 3 человека. Как мне кажется, такой результат — это уже вина кафедры, а не студентов.

PS На всякий случай скажу, что кафедра не чисто программерская, специальность «прикладная информатика в экономике».
Ну, не знаю — в свое время нас сначала мурыжили на предмет соответствия отчёта ГОСТам (так сказать первая линия), а потом смотрели код. Причём смотрели так, что находили баги типа «а что будет если строка длиной больше 65535 байт?»
В дополнение к этому можно вспомнить, что «предварительная оптимизация — зло», и весь этот дополнительный рефакторинг никому не нужен — кодом-то и пользоваться не будут. Посему, в глазах программиста-практика, коим зачастую является преподаватель, такой труд тоже не очень-то обоснован.
Так и есть, только Вы слово оптимизация применили абсолютно не к месту, при проведении рефаторинга в стиле «а вдруг когда-нибудь пригодится» речь идёт о нарушении принципа YAGNI. Гораздо лучше будет, если синтетическая задача будет реально располагать к рефакторингу, так польза от него запомнится лучше, чем в случае вымученного и неуместного рефакторинга ради галочки.
Ну не совсем не к месту — это «оптимизация вероятных будущих затрат на реализацию предполагаемой функциональности». А необходимость (вернее эффективность) рефакторинга часто обусловлена взаимодействием кода и тестов — «лучше я изменю 5 строчек кода и напишу тест на 5 строк, чем не буду ничего менять и писать тест на 20 строк, создавая моки и стабы».
Нам с преподавателем, наверно, повезло.
Он специально ломал проги. Плюс писали тесты к ним(МГТ, черный и т.п.). И пока не сдашь, программу, которая будет проходить по всем необходимым входным данным, то зачет не получишь.

С одной стороны, это, конечно, хорошо, однако получить зачет, таким образом, представляет из себя очень трудоемкий процесс.
Я Вам как студент IT специальности скажу. В программе некоторых ВУЗов есть вполне крупные «дырки». Программировать учат… ну как учат… кто хочет — научится, а кто не хочет — никто никого заставлять не будет. Так вот. Проходили мы первые два курса С и Джаву. Ну как вполне успевающий студент в голове возникают тайные мысли, что предел уже достигнут и можно идти устраиваться программистом «хоть щас». Какого же было мое удивление, когда на первом собеседовании в своей жизни (после первого семестра второго курса) я оказался практически полным нулем. Конечно, сыграла свою роль, что я не «на программиста» учусь, а на инженера-электронщика, но тем не менее… Было реально обидно.
А завалили на банальщине. На абстрактных классах (тогда я думал, что это такая злая выдумка специально для лабораторной… типа из оперы фигур Лиссажу и прочих лабораторок), на базах данных (ну, тут я реально не знал, т.к. проходили мы их позже), ну и на сервлетах (проходилось поверхностно, поэтому внимание не было уделено на должном уровне). И вот… 15 вопросов из них правильно 5-6. Эпик фэйл.
Так вот, это я все к тому, что студенты (особенно 1-2 курсы) не совсем понимают для чего им это надо. А когда понимают — бывает достаточно поздно и приходится все начинать сначала.
Не надо гнать на Лиссажу, привыкли, понимаешь, к диджитальности…
Никто на них не гонит. Только студент первого курса просто не понимает ЗАЧЕМ оно нужно.
Я вас понял, что фигуры Лиссажу это конкретно злая выдумка, в отличии от абстрактных классов, о которых вам просто забыли рассказать зачем они нужны.
Вы абсолютно правыВы абсолютно правы
Никто на них не гонит. Только студент первого курса просто не понимает ЗАЧЕМ оно нужно.
Ох, не туда отписал коммент. Сорри.
Sign up to leave a comment.

Articles