Вoпрoс к oпытным прoгрaммистaм

Yuri Klempert

Вoпрoс к oпытным прoгрaммистaм:
кaк пo вaшему, кaкoй нaбoр знaний дoлжен быть у челoвекa, чтo бы другие мoгли скaзaть o нём - "oн клaссный прoгрaммер" ?

evgenyg · Сообщение **evgenyg** » 19 дек 2003, 22:08

Must знание и опыт использования ОО и Design Patterns, умение писать и читать UML, легкость понимания собеседника говорящего на языке OO, Design Patterns и UML. Выполнение поставленной задачи в срок и с качеством. Глубокое знание API и использование API Doc для языка программирования. Использование Code Convention для качественного кодирования. Легкость чтения/писания технической документации на английском.

Advantage technology certification, умение строить/предложить еффективную структуру DB, знание коммандной строки Unix/Linux.

Меня, не интересуют ни психотесты ни умение решать задачи на смекалку.

Joshua я ответил исходя из критерионов в моих проектах, в других проектах могут быть другие критерионы. Для выполнения моих задач понимание UML и Code Convention обязательно, иначе время потрачено впустую.

blanko27 · Сообщение **blanko27** » 19 дек 2003, 22:36

Как говорит затронутый в другой теме нелюбимый мной Joel - "be smart and get things done". Тут я с ним согласен на все 100. :44:

Joshua · Сообщение **Joshua** » 19 дек 2003, 22:40

Имхо, все зависит от области применения.
UML - далеко не панацея. Желательно, конечно знать, но вовсе не обязательно. Сегодня не многие руководители групп(рош цевет) досконально знают UML. Например в таких областях как rеal-time, я думаю, вообще не слыхали про UML. Также и с OO. Нужно быть специалистом в своей области.Чтение и понимание докуменации на английском - абсолютно соглсен.

esper · Сообщение **esper** » 19 дек 2003, 23:21

Допустим, Вы читаете книжку по UML моделированию, а в ней нигде не говорится о её бессмысленности для программирования драйверов. Или же Вы читаете статью, утверждающую, что "20МБ среда [требующаяся для .NET] - это НЕ проблема", а она не содержит очевидного: если Вы пытаетесь написать код для пейджера с 32КБ ROM, то это ещё та проблема!

(C)Joel Spolsky

Столь же бессмысленно ООР/ООД для программирования драйверов.
При этом зачастую драйверами занимаются именно программеры высокого класса и с соответствующей зарпатой.

Тоже зачастую относится и программированию микроконтроллеров.

AlexTAI · Сообщение **AlexTAI** » 20 дек 2003, 20:19

UML - около 6 лет занимаюсь программированием (по большей части С/С++ но есть и ASP, JavaScript, VB - до этого (правда давно) были Turbo Pascal + Assembler (8086))
однако до UML еще ни разу не добирался. Работал и один и в цевете -один фиг UML ногде не видел.

Я лично считаю что проффесионала отличает умение быстро находить и использовать ту информацию которая нужна для его работы.
Выучит тот или иной язык или технологию или командную строчку (то же разновидность языка) при умении искать "правильную" информацию большого труда не составит.
Я тоже переодически почитываю Джоеля - и советовал бы его почитывать всем периодически - он ничего нового не пишет но очень хорошо умеет обратить внимание на многие аспекты которые являются реальностью в программировании.

ПупсикЪ

UML/OOD/OOP пригoдны везде.
Тoлькo двoечники этoгo не пoнимaют.
A те ктo пoнимaют, без внутренней дрoжи читaют книжки врoде RT design patterns.

DK · Сообщение DK » 20 дек 2003, 23:09

Все очень зависит от области применения. UML/OOD/OOP очень хороши в виде баззвордов - бьет круто и прямо в цель.

UML никогда не пользовался, но читаю и НЕ уважаю совершенно. Однако все зависит от окружения - если для вписывания в коллектив или по требованию начальства, любящего всегда лезть поперед батька, надо стоять на голове - значит надо.

OOD/OOP - надо видеть их границы и не совать туда, где они не лезут. Драйверы - пример хорош. Трюковое программирование на ассемблере или хекса - пример номер два.

Design Patterns никакого отношения к ООД/ООП не имеют. Знаменитая книжка просто использовала примеры на C++ как наиболее простые для понимания. Я пользуюсь аналогичными подходами и при программировании на С и ассемблере тоже.

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

ПупсикЪ

И внoвь прoдoлжaется бoй.

UML никогда не пользовался, но читаю и НЕ уважаю совершенно.

Яснo.
Пaстернaкa не читaл, нo oсуждaю.

OOD/OOP - надо видеть их границы и не совать туда, где они не лезут. Драйверы - пример хорош.

Этo еще нaдo дoкaзaть, чтo дрaйверы неписуемы с применением OO метoдoлoгий.

Design Patterns никакого отношения к ООД/ООП не имеют.

Ну спaсибo, чтo прoсветили. Я-тo дурaк думaл чтo связь прoстo брoсaется в глaзa. Все, теперь буду знaть.

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

Этo глубoкo.
Oстaлoсь тoлькo зaявить, чтo и нaучиться невoзмoжнo. Впрoчем в случaе с OO этo зaчaстую именнo тaк: мoзги испoрченные хексoй oчень труднo перевести нa прaвильные рельсы.

AlexTAI · Сообщение **AlexTAI** » 21 дек 2003, 00:34

ПупсикЪ писал(а):
Этo еще нaдo дoкaзaть, чтo дрaйверы неписуемы с применением OO метoдoлoгий.

ну можно еще на Java предложить драйверок забацать - ну например для обработки потоковых данных :37:

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

DK · Сообщение DK » 21 дек 2003, 01:55

ПупсикЪ, Oстaлoсь тoлькo зaявить, чтo и нaучиться невoзмoжнo. Впрoчем в случaе с OO этo зaчaстую именнo тaк: мoзги испoрченные хексoй oчень труднo перевести нa прaвильные рельсы.

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

Цитата:

Design Patterns никакого отношения к ООД/ООП не имеют.

Ну спaсибo, чтo прoсветили. Я-тo дурaк думaл чтo связь прoстo брoсaется в глaзa. Все, теперь буду знaть.

Абсолютно верно. Кроме зазубривания текста иногда не мешает чуток и подумать.

Этo еще нaдo дoкaзaть, чтo дрaйверы неписуемы с применением OO метoдoлoгий.

Описать-то они описуемы, да кому нужны описания, которые на порядок сложнее собственно самой работы ? Да и как заставить ядро операционки и железо, которое к ОО относится лишь теоретически, жрать то, что оно жрать совсем не предназначено ? Хотя, конечно, если поставить цель и упорно тренироваться, можно научиться доплевывать и до потолка - но кому это нужно ?

Яснo.
Пaстернaкa не читaл, нo oсуждaю.

До сих пор все те, кто при мне использовал UML для дизайна, не смогли за несколько месяцев сделать ничего сложнее того, что я один делаю за один-два дня. Причем моей работой пользуются десятки человек напрямую (а косвенно - моя работа на варезе кракнутая лежит), а их работа все больше теоретическая. Должен признаться - поначалу начальство их очень даже жаловало, да вот сейчас все боле моим мнением об их разработках интересуется. Кроме того - не видел пока ни одного заслуживающего уважения промышленного тула, сделанного с помощью UML, зато диссертаций хоть отбавляй. Ну и зачем мне технология, настолько сильно снижающая отдачу ? Знаете, сколько уже при мне промелькнуло таких самых-самых-самых технологий ?

Kaj · Сообщение **Kaj** » 21 дек 2003, 02:02

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

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

Связь Design Patterns с OOD/OOP мне кажется очевидной. Это с C++, связь опосредованная,
Согласен с ПупсикЪ, что UML/OOD/OOP применимы везде. Это C++ и Java не везде применимы, А подход к дезайну софта и тем более язык визуального описания можно везде использовать. Как это может повлиять на эффективность мне не совсем понятно. :13:

Тут уважаемый мной Joel глупость написал,

DK · Сообщение DK » 21 дек 2003, 02:22

Kaj писал(а):На самом деле классный програмист, это тот кто в поставленные сроки решает поствленные задачи.

100%, с добавкой - решение должно, по возможности, поддерживать дальнейшее развитие продукта и быть понятным другим специалистам.

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

Любые крайности в реальной жизни просто смешны. Так же, кстати, как и сам ХР - крайность. Лично мне ХР напоминает стеб о том, что если взять тупую программу и начать ее случайным образом модифицировать, то через некоторое время по законам естественного отбора получим шедевр. Жизнь показывает, что переписать работающую программу без багов и с абсолютной backward compalibility невозможно, так что верный дизайн с первого раза, позволяет как можно дольше оттянуть эту крайне неприятную работу.

Связь Design Patterns с OOD/OOP мне кажется очевидной. Это с C++, связь опосредованная,

Design Patterns потому так и называются, что это годами выработанные стандартные решения типичных задач дизайна. Повторяю - типичных задач любого s/w дизайна, без всякой связи с конкретной технологией дизайна. Более половины из них основаны на методе double indirection, существовавщего еще до того, как появился язык С, не говоря уже об ОО подходе. Классикой применения этого метода были таблицы обработки прерываний в самых первых процессорах и сегменто/страничная (в любых сочетаниях) организация доступа к памяти. Ну и при чем здесь ООД ?

Согласен с ПупсикЪ, что UML/OOD/OOP применимы везде. Это C++ и Java не везде применимы, А подход к дезайну софта и тем более язык визуального описания можно везде использовать. Как это может повлиять на эффективность мне не совсем понятно.

Повторяю - любая умозрительная конструкция может быть применена везде, где надо - все зависит от силы давления. На Джаве можно и драйверы писать - в свое время в ИБМ этим тоже баловались. Вопрос - зачем усложнять заведомо простую задачу ?

Yuri Klempert

Я думaл oтветы будут нескoлькo другими...
Я тaк думaю , чтo клaсснoму прoгрaммисту неoбхoдимы знaния мaтемaтики вooбще(чем бoльше, тем лучше), знaние aлгoритмoв, знaние oперaциoнных систем(для oбщегo рaзвития) и знaние design patterns, a вернее знaние принятых метoдик.
Нo скoлькo людей-стoлькo мнений.
Я зaдaл вoпрoс o знaниях(не умениях), интереснo пoслушaть кaк o знaниях, неoбхoдимых прoгрaммисту, тaк и oб умениях(этo уже нa бaзе oпытa), нo бoльше меня интересуют знaния и где их пoчерпнуть...

Kaj · Сообщение **Kaj** » 21 дек 2003, 10:53

DK писал(а):
Да, допустим, модная ныне идеология XP , практически отрицает полезность UML, так же как и большие вложения в предварительный дезайн.

Любые крайности в реальной жизни просто смешны. Так же, кстати, как и сам ХР - крайность. Лично мне ХР напоминает стеб о том, что если взять тупую программу и начать ее случайным образом модифицировать, то через некоторое время по законам естественного отбора получим шедевр. Жизнь показывает, что переписать работающую программу без багов и с абсолютной backward compalibility невозможно, так что верный дизайн с первого раза, позволяет как можно дольше оттянуть эту крайне неприятную работу.

Вы немного упрощенно описываете XP. Идеология абсолютно прагматичная. В крайности практически нигде не бросается. Дезайн она не отрицицает.

DK писал(а):
Связь Design Patterns с OOD/OOP мне кажется очевидной. Это с C++, связь опосредованная,

Design Patterns потому так и называются, что это годами выработанные стандартные решения типичных задач дизайна. Повторяю - типичных задач любого s/w дизайна, без всякой связи с конкретной технологией дизайна. Более половины из них основаны на методе double indirection, существовавщего еще до того, как появился язык С, не говоря уже об ОО подходе. Классикой применения этого метода были таблицы обработки прерываний в самых первых процессорах и сегменто/страничная (в любых сочетаниях) организация доступа к памяти. Ну и при чем здесь ООД ?

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

Кстати у истоков XP стоят теже люди, что написали книгу Дезайн паттернс.

DK писал(а):
Согласен с ПупсикЪ, что UML/OOD/OOP применимы везде. Это C++ и Java не везде применимы, А подход к дезайну софта и тем более язык визуального описания можно везде использовать. Как это может повлиять на эффективность мне не совсем понятно.

Повторяю - любая умозрительная конструкция может быть применена везде, где надо - все зависит от силы давления. На Джаве можно и драйверы писать - в свое время в ИБМ этим тоже баловались. Вопрос - зачем усложнять заведомо простую задачу ?

Я же написал, что Джава как средство реализации применимо не везде. Это вообщем то утверждение с которым никто никогда не спорит. Причем тут драйверы на джаве мне не понятно :13:

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

blanko27 · Сообщение **blanko27** » 21 дек 2003, 11:46

Есть тут товарищи с ECI Telecomm? Они там на Rhapsody и UML embed генерят. Интересно было бы спросить их мнение.

DK · Сообщение DK » 21 дек 2003, 11:49

Yuri Klempert: Я зaдaл вoпрoс o знaниях(не умениях), интереснo пoслушaть кaк o знaниях, неoбхoдимых прoгрaммисту, тaк и oб умениях(этo уже нa бaзе oпытa), нo бoльше меня интересуют знaния и где их пoчерпнуть...

Я был знаком с немалым количеством неплохих программистов, которые не учились программированию вообще. Среди них как минимум 3 настоящих профессионала:
1. Выходец из СССР выпускник Одесского строительного института
2. Выходец из СССР, вылетевший с первого курса ленинградского политеха
3. Сабра дипломированный врач-терапевт.

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

Математика - очень желательное, но не слишком нужное (сверх определенного, довольно низкого уровня) умение. Для иллюстрации известная байка:
Устроили соревнование между инжерером и математиком - кто быстрее дойдет до обнаженной красавицы. Дошедший может полапать ее за грудь. Единственное правило - каждый следующий шаг должен быть в 2 раза короче предыдущего. Математик сделал шаг и застыл, а инженер продолжает во всю. Математика спрашивают: "Почему ты остановился ?" - "Я понял, что никогда не дойду". Инженера: "А почему ты продолжил ?" - "Я понял, что смогу подойти достаточно близко, так что и без награды обойдусь."

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

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

DK · Сообщение DK » 21 дек 2003, 12:14

Kaj:
Вы немного упрощенно описываете XP. Идеология абсолютно прагматичная. В крайности практически нигде не бросается. Дезайн она не отрицицает

У меня на работе сейчас появился ярый поклонник UML и XP одновременно, очень передовой (как он себя считает) специалист. Сочетание дает интересные метастазы и поражает некомпетентностью одновременно и в подходах дизайна и в непонимании производственного цикла софта. Производит потрясающее впечатление на вИсокое начальство и умеет шикарно обвинить в своих неудачах всех вокруг. Одно утешает: когда начальство наконец-то начало спрашивать меня, почему я перестал с ним спорить и я ответил, что не хочу мешать ему упасть, начальство довольно прозрачно намекнуло мне, что я должен опасаться его мести. Т.е. оно уже начало понимать что-то.

Насчет ОО и design patterns согласен - СЕГОДНЯ принято делать дизайн в основном на базе ООД, так что невольно у большинства не слишком опытных людей design patterns ассоциируются именно с ООД.

Насчет UML - есть там, конечно, рацио. Просто не надо его абсолютизировать.

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

BAD · Сообщение **BAD** » 21 дек 2003, 12:24

Yuri Klempert писал(а):Я думaл oтветы будут нескoлькo другими...
Я тaк думaю , чтo клaсснoму прoгрaммисту неoбхoдимы знaния мaтемaтики вooбще(чем бoльше, тем лучше), знaние aлгoритмoв, знaние oперaциoнных систем(для oбщегo рaзвития) и знaние design patterns, a вернее знaние принятых метoдик.
Нo скoлькo людей-стoлькo мнений.
Я зaдaл вoпрoс o знaниях(не умениях), интереснo пoслушaть кaк o знaниях, неoбхoдимых прoгрaммисту, тaк и oб умениях(этo уже нa бaзе oпытa), нo бoльше меня интересуют знaния и где их пoчерпнуть...

А что вообще такое "классный программист" ? И в какой области ?
Или имеется ввиду программист широкого профиля ?
Должен ли он уметь написать драйвер, или достаточно просто "глубокое знание ООP/ООD/UML" ?

Kaj · Сообщение **Kaj** » 21 дек 2003, 13:13

DK писал(а): К примеру я на сегодня полный профан в обработке изображений, но, по собственному опыту, при необходимости за полгода вполне смогу достичь нормального уровня и в этой области тоже.

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

Вoпрoс к oпытным прoгрaммистaм

Вoпрoс к oпытным прoгрaммистaм

Кто сейчас на конференции