Cyberax пишет:
>
> D>А нецензурно? Что плохого в использовании красивых зарекомендовавших
> себя методов, грабли которых относительно известны?
> В том, что большинство из них нужны раз в пятилетку. А попытки
> использовать их везде, где только можно, приводят к overdesign'у.
Где логика? Здесь говорят про использование паттернов, но нигде не
говорят, что их нужно пихать всегда и везде.
Тем ни менее, я все больше убеждаюсь в том, что знание, хотя бы с
большего, паттернов проектирования — действительно необходимость. Ну
зачем изобретать собственный велосипед с квадратными колесами, если в
данном месте прекрасно кладется какой-нибудь паттерн.

_Jane_ пишет:
>
> V>А вот представьте проект в котором большинство подобных студентов. И,
> V>он, этот проект даже живет неплохо и развивается и в сроки укладывается.
> V>Не спорю, тяжело, с профи, конечно сильно легче, но где ж их на всех
> V>наберешься.
>
> Я более чем уверена, что в этом проекте хорошо поставлено руководство
> этими студентами, контроль и так далее. То есть, не самотёк.
Ну что тебе сказать — моя кровушка ушла и в немалых количествах.
Контроль — фактически они контролируют сами себя — основная масса людей
самодисциплинированы сами по себе, если режим работы (тут все) не
провоцирует обратное.
Но главное, это не контроль — это вообще самое последнее. Главное, это
делегирование полномочий и ответственности, а люди сами себя прекрасно
контролируют, если видят в этом необходимость.

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

Решил вот добавить свои пять копеек.

Я тоже когда-то был студентом. И уже тогда считал себя офигенным программистом.
Но мои представления о программировании развеял в пыль мой первый босс.
За что я ему безмерно благодарен.
У него был очень простой подход — давал задание, кстати поначалу это были именно заморочки с чужим кодом. Очень помогает. Есть возможность посмотреть как другие люди делают и спросить — это круто или г@вно. И на своей шкуре понять, почему код в дряном стиле, каментов и весь замороченный это плохо.
Да, но вернемся к подходу. Давал он задание и ставил срок. Я ему отдавал код. А он мне в ответ писал: у тебя в программе столько то ошибок. И все. И делай что хочешь но найди их САМ и исправь. И никогда не говорил что именно не так. При ходилось биться об экран чтобы понять что еще не так. Результат — через какое-то время я был отпущен в самостоятельное плавание. Т.е. просто он перестал находить в том, что и писал, значимые недочеты. У меня не было другого выхода. Либо сделай, либо уйди.

Вот такой жесткий подход IMHO учит людей самостоятельности и приводит к отсеву. И unit тесты делать, и код читабельный писать, и каменты и тд. Просто человеческий мозг так устроен, что он ищет самый простой вариант. Если самый простой — это зачекинить без каментов какую-нибудь дрянь, а потом старшие товарищи соберутся и начнут объяснять — где и что не так, то так оно всегда и будет.
А если самый простой и единственный сделать все как следует самому, то те кто это может и ХОЧЕТ сделать — научатся и сделают, кто-то быстрее, кто-то медленнее, а кто не может или НЕ ХОЧЕТ — уйдет сам, т.к. просто не будет справляться с работой.

Еще вот вспомнил. Был у нас препод один, который лабы принимал.
Так вот он их ломал. Т.е. не просто показываешь, что все работает.
А он брал в руки шашку, и давай. И так и сяк.
Принимал только если не смог сломать.
Это тоже школа. Кто не хотел — сдавал другому, там была полная халява.
Вот большинство кто другому сдавал, так программистами и не стали.
Так что думаю это тоже подход. Можно и на работе применить.

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

AS>Так что думаю это тоже подход. Можно и на работе применить.

Я кстати и применяю. на рабочих-учебных задачах.

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

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

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

>> V>А вот представьте проект в котором большинство подобных студентов. И,
>> V>он, этот проект даже живет неплохо и развивается и в сроки укладывается.
>> V>Не спорю, тяжело, с профи, конечно сильно легче, но где ж их на всех
>> V>наберешься.
>>
>> Я более чем уверена, что в этом проекте хорошо поставлено руководство
>> этими студентами, контроль и так далее. То есть, не самотёк.
V>Ну что тебе сказать — моя кровушка ушла и в немалых количествах.
V>Контроль — фактически они контролируют сами себя — основная масса людей
V>самодисциплинированы сами по себе, если режим работы (тут все) не
V>провоцирует обратное.
V>Но главное, это не контроль — это вообще самое последнее. Главное, это
V>делегирование полномочий и ответственности, а люди сами себя прекрасно
V>контролируют, если видят в этом необходимость.

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

_Jane_ пишет:
>
> Правильно, вот если они "попили кровушки", так значит надо было их
> вначале научить работать
Не они, начальство. А мне данное было просто интересно, получится или
нет, получилось.

> Люди-то могут быть самодисциплинированны, но всё же пока остаются
> джуниорами, а значит, нужен code review, нужно их как-то направлять и
> так далее. На это тоже время тратится...
Постольку, поскольку. Unit-tests эффективнее ну и еще когда они видят
реально рабочую систему (2-3 недели — сборка автоматом почти).
А code review — расслабляет людей сильно. Ну а направлять, конечно надо.

P.S. Имхо, не сильно важна красота или не красивость кода, важно, чтобы
код делал то, что надо, а это проходил тесты. А красивость — она с
опытом набирается.

P.P.S И самое главное — это поставить процесс разработки (у меня
получилась некая помесь RUP с XP).

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

V>Неа, я всегда смотрю в глаза и пытаюсь вывести человека на "искорку".
V>Если при рассказе о чем-то рабочем, у человека глаза заблестели, значит
V>и обучится, и разберется, и сделает, и следовать правилам будет (если
V>таковы разумны).

Мне как-то попадался человек с горящими глазами, но несколько безалаберный. Если интересна тема — будет работать на совесть (пока интересно), если нет (увы, не всегда есть только интересные задачи) — сделает как-нибудь; не всегда следует рабочим процессам, код правильно оформлять тоже "не интересно" — в общем, общая ситуация не очень утешительна. Хотя толковый и с "искоркой"...
В такой ситуации предпочту работать с надёжным середнячком.

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


V>P.P.S И самое главное — это поставить процесс разработки (у меня
V>получилась некая помесь RUP с XP).

Ну вот, значит всё-таки не самотёк

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

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

AS>>Так что думаю это тоже подход. Можно и на работе применить.

_J_>Я кстати и применяю. на рабочих-учебных задачах.

Одно только уточнение — подход такой же как в первом моем посте:
Программа сломана. Точка. Что именно не так — найди сам.
А не так, что у тебя там-то и там-то то-то и то-то не обрабатывается и не работает.
Все! Жестко! Заставляет либо сдаться, либо вылизывать до блеска, до звона. Чтобы нигде, ни полбайта не поскочило! А потом уже в привычку входит.

P.S. Я после таких экспериментов бывало находил ошибки в программе во сне. Спишь, снится код, ходишь мысленно по нему дебаггером, условия вариьируешь — потом в поту просыпаешься — вот же оно!
Раз к компу — смотришь — точняк! Но это конечно в самых тяжелых случаях...

_Jane_ пишет:
>
>
> Мне как-то попадался человек с горящими глазами, но несколько
> безалаберный. Если интересна тема — будет работать на совесть (пока
> интересно), если нет (увы, не всегда есть только интересные задачи) —
> сделает как-нибудь; не всегда следует рабочим процессам, код правильно
> оформлять тоже "не интересно" — в общем, общая ситуация не очень
> утешительна. Хотя толковый и с "искоркой"...
Да. Есть такое. Вот это самое место применения ПМа — вот это и есть
настоящая работа ПМа — как от такого человека получить максимальный
результат.

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

По пунктам выше:
Рабочие процессы — я имел возможность наблюдать оное от полного
отсутствия до полной дури.
Правильное оформление кода — то же, что и выше я написал. Я например
видел такие рулесы, где требовалось из каждой функции возвращать int.

> В такой ситуации предпочту работать с надёжным середнячком.
Это зависит от задач, которые вы делаете. По моему опыту — это 90%
контор програмерских в СНГовине, где нужны именно "винтики".

P.S. Но вообще, сколько работал в разных местах, пришел к очень
неутешительному выводу: самое бездарное руководство — в програмерских
конторах в СНГ. Отсюда и посты в стиле: "Приём на работу студентов. Как
обнаружить безнадежных".

_Jane_ пишет:
>
>
> Ну вот, значит всё-таки не самотёк
Конечно, нет. Я и не говорил про самотек.

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

AS>>>Так что думаю это тоже подход. Можно и на работе применить.
_J_>>Я кстати и применяю. на рабочих-учебных задачах.

AS>Одно только уточнение — подход такой же как в первом моем посте:
AS>Программа сломана. Точка. Что именно не так — найди сам.
AS>А не так, что у тебя там-то и там-то то-то и то-то не обрабатывается и не работает.
AS>Все! Жестко! Заставляет либо сдаться, либо вылизывать до блеска, до звона. Чтобы нигде, ни полбайта не поскочило! А потом уже в привычку входит.

Пишу как тестер обычно или даже как клиент, то есть не настолько конкретно и чётко. "найди сам, где не работает", по-моему, сильно жестоко

AS>P.S. Я после таких экспериментов бывало находил ошибки в программе во сне. Спишь, снится код, ходишь мысленно по нему дебаггером, условия вариьируешь — потом в поту просыпаешься — вот же оно!
AS>Раз к компу — смотришь — точняк! Но это конечно в самых тяжелых случаях...

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

>> Мне как-то попадался человек с горящими глазами, но несколько
>> безалаберный. Если интересна тема — будет работать на совесть (пока
>> интересно), если нет (увы, не всегда есть только интересные задачи) —
>> сделает как-нибудь; не всегда следует рабочим процессам, код правильно
>> оформлять тоже "не интересно" — в общем, общая ситуация не очень
>> утешительна. Хотя толковый и с "искоркой"...
V>Да. Есть такое. Вот это самое место применения ПМа — вот это и есть
V>настоящая работа ПМа — как от такого человека получить максимальный
V>результат.

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

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

V>По пунктам выше:
V>Рабочие процессы — я имел возможность наблюдать оное от полного
V>отсутствия до полной дури.
V>Правильное оформление кода — то же, что и выше я написал. Я например
V>видел такие рулесы, где требовалось из каждой функции возвращать int.

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

>> В такой ситуации предпочту работать с надёжным середнячком.
V>Это зависит от задач, которые вы делаете. По моему опыту — это 90%
V>контор програмерских в СНГовине, где нужны именно "винтики".

Да, так оно и есть. задачи предполагают много "винтиков" и некоторое количество хорошо квалифицированных людей.

V>P.S. Но вообще, сколько работал в разных местах, пришел к очень
V>неутешительному выводу: самое бездарное руководство — в програмерских
V>конторах в СНГ. Отсюда и посты в стиле: "Приём на работу студентов. Как
V>обнаружить безнадежных".

_Jane_ пишет:
>
>
> V>Например, посмотрите на это с другой стороны, кто лучше его справиться с
> V>реально тяжелой и жутко ограниченной задачей по времени.
>
> Если она будет ему интересна ну и держать человека под конкретного рода
> задачи — это надо чтобы человек реально приносил на них пользы много.
Вот о чем и речь. Был у меня когда-то такой человек, тяжело было ему
здесь. Сейчас вполне неплохо в канадах програмит.

> V>видел такие рулесы, где требовалось из каждой функции возвращать int.
>
> Если рядом не было объяснения, зачем это нужно, правило кажется глупым.
> На самом деле оно может действительно актуальным по какой-либо причине.
Хорошо, назовите хоть одну причину для подобного в программе на С++.

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

>
> Да, так оно и есть. задачи предполагают много "винтиков" и некоторое
> количество хорошо квалифицированных людей.
Се ля ви. Точнее то программирование, котрым мы в СНГ занимаемся.

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

V>_Jane_ пишет:
>>
>>
>> V>Например, посмотрите на это с другой стороны, кто лучше его справиться с
>> V>реально тяжелой и жутко ограниченной задачей по времени.
>>
>> Если она будет ему интересна ну и держать человека под конкретного рода
>> задачи — это надо чтобы человек реально приносил на них пользы много.
V>Вот о чем и речь. Был у меня когда-то такой человек, тяжело было ему
V>здесь. Сейчас вполне неплохо в канадах програмит.

>> V>видел такие рулесы, где требовалось из каждой функции возвращать int.
>>
>> Если рядом не было объяснения, зачем это нужно, правило кажется глупым.
>> На самом деле оно может действительно актуальным по какой-либо причине.
V>Хорошо, назовите хоть одну причину для подобного в программе на С++.

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

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

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

>> Да, так оно и есть. задачи предполагают много "винтиков" и некоторое
>> количество хорошо квалифицированных людей.
V>Се ля ви. Точнее то программирование, котрым мы в СНГ занимаемся.

Угу.

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

В программировании есть только три вещи, понимание которых отличает программиста от непрограммиста. Это:

1. Рекурсия.
2. Указатели.
3. Биты.

Всё. Если человек способен понять эти вещи, то он может стать программистом. Если не способен, то он безнадёжен.

_Jane_ пишет:
>
> V>Хорошо, назовите хоть одну причину для подобного в программе на С++.
>
> Про int? тут могу только догадываться. Возможно, это пришло из С-шного
> кода, чтобы везде был одинаковый тип кодов возврата ну и чтобы вообще он
> был.
И даже в С, и даже в Фортране — это было глупостью, призванной тольк для
одной цели, обеспечить занятием толпу манагеров (кстати при резком росте
толпы манагеров "среднего звена"), этот момент отрабатывал всегда.

> А если программа С++ написана тоже в функциональном стиле (без
> классов-исключений), или хотя бы частично, то и там надо единый стиль
> возвращения какого-либо статуса.
А причем тут С++? Если С, тогда "логику особо извращенных" придумать можно.

> V>Вот именно поэтому я считаю данное ничем иным, как ИБД. Архитектор
> V>должен задавать стиль написания, остальные в большей или меньшей степени
> V>следуют ему.
>
> Чтобы следовали, надо чётко определиться, что важно, а что не очень.
Вот вот, именно этот момент меня умиляет. Чтобы было очень четко,
необходимо просто писать одному за всех — все остальное ИБД.

Вообще говоря у меня требования стилю есть:
1. Не изобретать велосипеды с квадратными колесами, до вас уже давно
разработали с круглыми (это и STL и boost и patterns).
2. Все платформо-зависимое или требующее сторонних библиотек в отдельное
место и через прослойку.
3. Голые указатели — это мне долго доказывать придеться его необходимость
4. Каменты на уровне, чтобы через полгода сам понять мог, че написал.

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

> V>Се ля ви. Точнее то программирование, котрым мы в СНГ занимаемся.
>
> Угу.
Вот видишь, здесь мы сходимся. Фактически наш спор — это спор об
отношении к разработчикам здесь. А это отношение вытекает из задач.

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

V>_Jane_ пишет:
>>
>> V>Хорошо, назовите хоть одну причину для подобного в программе на С++.
>>
>> Про int? тут могу только догадываться. Возможно, это пришло из С-шного
>> кода, чтобы везде был одинаковый тип кодов возврата ну и чтобы вообще он
>> был.
V>И даже в С, и даже в Фортране — это было глупостью, призванной тольк для
V>одной цели, обеспечить занятием толпу манагеров (кстати при резком росте
V>толпы манагеров "среднего звена"), этот момент отрабатывал всегда.

Если честно, не поняла мысли

>> А если программа С++ написана тоже в функциональном стиле (без
>> классов-исключений), или хотя бы частично, то и там надо единый стиль
>> возвращения какого-либо статуса.
V>А причем тут С++? Если С, тогда "логику особо извращенных" придумать можно.

При том, что стиль программирования и язык — это всё-таки не одно и то же. Можно написать функциональную программу и на С++.

>> V>Вот именно поэтому я считаю данное ничем иным, как ИБД. Архитектор
>> V>должен задавать стиль написания, остальные в большей или меньшей степени
>> V>следуют ему.
>>
>> Чтобы следовали, надо чётко определиться, что важно, а что не очень.
V>Вот вот, именно этот момент меня умиляет. Чтобы было очень четко,
V>необходимо просто писать одному за всех — все остальное ИБД.

V>Вообще говоря у меня требования стилю есть:
V>1. Не изобретать велосипеды с квадратными колесами, до вас уже давно
V>разработали с круглыми (это и STL и boost и patterns).
V>2. Все платформо-зависимое или требующее сторонних библиотек в отдельное
V>место и через прослойку.
V>3. Голые указатели — это мне долго доказывать придеться его необходимость
V>4. Каменты на уровне, чтобы через полгода сам понять мог, че написал.
>> "Интуитивно" не все понимают.
V>Архитектор, который может говорить, он может внятно и четко объяснить,
V>зачем нужно то или другое, если немой, написать может. Ежели не может ни
V>того, ни другого — то это не архитектор проекта.

А я о чём говорю. Что надо сделать "вводную" людям.

>> V>Се ля ви. Точнее то программирование, котрым мы в СНГ занимаемся.
>>
>> Угу.
V>Вот видишь, здесь мы сходимся. Фактически наш спор — это спор об
V>отношении к разработчикам здесь. А это отношение вытекает из задач.

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

M>>Моя статистика, в которой у меня нет оснований сомневаться, говорит мне, что на группу в 30 студентов:
M>>* 0-2 -- годятся в программисты
M>>* 5-10 -- годятся во вспомогательные рабочие (тестеры, сисадмины, техписатели)
M>>* прочие годятся только чтобы торговать телефонами в киоске
LD>У меня в группе из тех, кто остался к 5 курсу работают программерами все! (11 или 12 человек)
LD>3 отчислили.
Да я тоже в шоке от приведенной статистики... (из двух групп, в которых я учился на первом в/о — ннгу/вмк/инф.системы — процентов 80 работает сейчас программерами/тестерами/сисадминами. но то было четыре года назад, неужто сейчас все так плохо?)

LD>Кстати, начиная с 4 курса нам давали именно программерские дисциплины. (Теория алгоритмов, комп. графика, выч. геом. и пр.)
что-то поздновато алгоритмы... я их чуть ли не с первого курса помню... ну и дискретки(под разными названиями) четыре или пять лет — мало не покажется

LD>IMHO, ваша статистика не совсем верна.
+1