Есть у нас вопросник.
Который мы даём всем кандидатам на роль программиста.
"ПРАВИЛЬНЫХ" ответов - там НЕТ. Ну то есть - ЕДИНСТВЕННО ПРАВИЛЬНЫХ. Мы обычно смотрим, что написал кандидат. Потом - беседуем. Задаём вопросы и смотрим на его реакцию.
Что ПЕРВОЕ мы там спрашиваем?
А вот что. Примерно так - "расскажите про ООП. Что такое инкапсуляция, наследование и полиморфизм".
Зачем эта часть?
А вот зачем - чтобы "проверить", что человек "реально в теме". Что он владеет примерно теми же понятиями, что и мы. И трактует их - примерно так же как и мы.
Чтобы мы понимали - "на каком языке" - мы дальше можем разговаривать с человеком, если мы будем вместе с ним работать.
Это - теория.
Есть и вторая часть.
В ней есть например такой вопрос - "когда целесообразнее применять наследование, а когда агрегацию? Чем они отличаются? И что у них общего? Какие у них плюсы и минусы?"
Что мы смотрим тут?
Тут мы смотрим, что человек ПОМИМО знания теории и определений - знает (ну или представляет себе) ПРАКТИКУ ПРИМЕНЕНИЯ.
Это - практика.
Две части ОДНОГО ЦЕЛОГО, называемого ОПЫТОМ.
ТЕОРИЯ и ПРАКТИКА.
И то, и другое может существовать отдельно друг от друга.
И такие случаи я встречал и не раз.
Но. Ценен тот специалист - у которого теория и практика - "встречаются вместе".
Посему я кстати с "лёгким предубеждением" отношусь к людям, который пишут в резюме "знаю 20-ть (придумываю) языков программирования".
Теорию - ДА - знать МОЖНО. А ПРАКТИКА ПРИМЕНЕНИЯ? На практику требуется - ВРЕМЯ. Продолжительное время.
Ну я сужу - лично по себе.
Некоторые мои коллеги возражают мне - "ну есть же люди, которые знают по 40-к естественных языков, которые сложнее". ДА! ЕСТЬ! Тут я развожу руками. Против практики (опять же) не попрёшь. Практика - критерий истины.
Скажем так. МОЁ ЛИЧНОЕ мнение - "ЕСТЬ УНИКУМЫ". Я не из их числа. Посему - я СУЖУ ПО СЕБЕ.
Теперь приведу пример из своей практики.
Я ДОЛГО программирую на Delphi. И у меня - ОБШИРНАЯ ПРАКТИКА ПРИМЕНЕНИЯ.
Некоторое время назад я стал программировать на Objective-C. И могу ли я сказать, что "я знаю Objective-C"?
В "теории" - наверное да. Я знаю синтаксис. Я знаю основные парадигмы. Я знаю даже как так устроен подсчёт ссылок.
Но!
НА ПРАКТИКЕ - я не могу сказать - "я ЗНАЮ Objective-C".
Почему?
Приведу маленький пример.
В API Objective-C есть функция - enumeratorAtPath. Которая возвращает объект-enumerator для перебора дочерних элементов каталога.
Мне надо было перебрать элементы каталога. И я "прочитав по-диагонали" документацию решил, что эта функция мне подходит.
И она - МНЕ ПОДОШЛА. Элементы каталога перебирались, я их сравнивал с какой-то "заданной маской". Отбирал нужные. И ВСЁ ПРЕКРАСНО работало.
Но! Структура каталога со временем - усложнялась и расширялась. Появлялись под-каталоги и под-под-каталоги. ВСЁ ПО-ПРЕЖНЕМУ продолжало работать. Но в какой-то момент - стало "подтормаживать" на мобильных устройствах.
В конечном итоге - я начал разбираться. И "ОКАЗАЛОСЬ", что enumeratorAtPath перебирал не ТОЛЬКО НЕПОСРЕДСТВЕННЫЕ элементы каталога. НО! И ИХ ДЕТЕЙ, причём РЕКУРСИВНО.
Я залез в документацию и прочитал её "УЖЕ не по-диагонали". И там - ВО ВТОРОМ же абзаце БЫЛО чёрным по белому написано. "this function returns enumerator that performs deep enumeration".
Всё чётко и ЯСНО. И надо отдать ДОЛЖНОЕ Apple - они ВСЁ в ДОКУМЕНТАЦИИ написали.
Только кто ж её читает...
Может быть я ОДИН ТАКОЙ БОЛВАН, но мой опыт показывает обратное...
В итоге я нашёл нужную функцию - contentsOfPath. Она правда возвращает НЕ enumerator, а МАССИВ (NSArray). Почему ТАК сделано - это уж на совести Apple. Я бы "конечно" так не сделал бы.
Но! Эта функция МНЕ ПОДОШЛА, заработала как надо и дала "определённый" ЗНАЧИТЕЛЬНЫЙ прирост производительности. В моём "частном случае".
Вот такой пример.
О ТЕОРИИ и ПРАКТИКЕ ПРИМЕНЕНИЯ.
Опять же - может быть я ОДИН ТАКОЙ БОЛВАН и другие бы сразу "сделали всё правильно". Может быть.
НО! Опять повторю - Я СУЖУ ПО СЕБЕ.
И то что я ПИШУ или ГОВОРЮ - проистекает из этих суждений.
Если кому-то мои высказывания кажутся "менторскими" или что "я учу жить" - так вот - КАЖУТСЯ.
Я - СУЖУ ПО СЕБЕ. И ПИШУ и ГОВОРЮ - о СВОЕЙ практике применения. И о том, что ЗНАЮ лично я.
И никому ничего не НАВЯЗЫВАЮ.
Ну кроме может быть - "непосредственных коллег", с которыми я работаю в ОДНОЙ КОМНАТЕ. ДА! Тут я могу (и делаю это) - НАВЯЗЫВАТЬ скажем использование FreeAndNil, а не ПРОСТО Free. Ну или что-то подобное.
Теперь ещё о практике применения.
Если человек программирует на "каком-то" языке - он должен знать только теорию или и ПРАКТИКУ ПРИМЕНЕНИЯ тоже? Он должен знать "внутреннее устройство языка" или нет?
Вот скажем есть функциональный язык. "Какой-то". Человек "должен знать" - КАК он обрабатывает "хвостовую рекурсию" или не должен?
К чему я это? Объясню в следующем посте.
А пока - закругляюсь.
Резюме - теория и практика применения - это НЕОБХОДИМЫЕ составляющие успеха. ВМЕСТЕ. А не порознь.
Который мы даём всем кандидатам на роль программиста.
"ПРАВИЛЬНЫХ" ответов - там НЕТ. Ну то есть - ЕДИНСТВЕННО ПРАВИЛЬНЫХ. Мы обычно смотрим, что написал кандидат. Потом - беседуем. Задаём вопросы и смотрим на его реакцию.
Что ПЕРВОЕ мы там спрашиваем?
А вот что. Примерно так - "расскажите про ООП. Что такое инкапсуляция, наследование и полиморфизм".
Зачем эта часть?
А вот зачем - чтобы "проверить", что человек "реально в теме". Что он владеет примерно теми же понятиями, что и мы. И трактует их - примерно так же как и мы.
Чтобы мы понимали - "на каком языке" - мы дальше можем разговаривать с человеком, если мы будем вместе с ним работать.
Это - теория.
Есть и вторая часть.
В ней есть например такой вопрос - "когда целесообразнее применять наследование, а когда агрегацию? Чем они отличаются? И что у них общего? Какие у них плюсы и минусы?"
Что мы смотрим тут?
Тут мы смотрим, что человек ПОМИМО знания теории и определений - знает (ну или представляет себе) ПРАКТИКУ ПРИМЕНЕНИЯ.
Это - практика.
Две части ОДНОГО ЦЕЛОГО, называемого ОПЫТОМ.
ТЕОРИЯ и ПРАКТИКА.
И то, и другое может существовать отдельно друг от друга.
И такие случаи я встречал и не раз.
Но. Ценен тот специалист - у которого теория и практика - "встречаются вместе".
Посему я кстати с "лёгким предубеждением" отношусь к людям, который пишут в резюме "знаю 20-ть (придумываю) языков программирования".
Теорию - ДА - знать МОЖНО. А ПРАКТИКА ПРИМЕНЕНИЯ? На практику требуется - ВРЕМЯ. Продолжительное время.
Ну я сужу - лично по себе.
Некоторые мои коллеги возражают мне - "ну есть же люди, которые знают по 40-к естественных языков, которые сложнее". ДА! ЕСТЬ! Тут я развожу руками. Против практики (опять же) не попрёшь. Практика - критерий истины.
Скажем так. МОЁ ЛИЧНОЕ мнение - "ЕСТЬ УНИКУМЫ". Я не из их числа. Посему - я СУЖУ ПО СЕБЕ.
Теперь приведу пример из своей практики.
Я ДОЛГО программирую на Delphi. И у меня - ОБШИРНАЯ ПРАКТИКА ПРИМЕНЕНИЯ.
Некоторое время назад я стал программировать на Objective-C. И могу ли я сказать, что "я знаю Objective-C"?
В "теории" - наверное да. Я знаю синтаксис. Я знаю основные парадигмы. Я знаю даже как так устроен подсчёт ссылок.
Но!
НА ПРАКТИКЕ - я не могу сказать - "я ЗНАЮ Objective-C".
Почему?
Приведу маленький пример.
В API Objective-C есть функция - enumeratorAtPath. Которая возвращает объект-enumerator для перебора дочерних элементов каталога.
Мне надо было перебрать элементы каталога. И я "прочитав по-диагонали" документацию решил, что эта функция мне подходит.
И она - МНЕ ПОДОШЛА. Элементы каталога перебирались, я их сравнивал с какой-то "заданной маской". Отбирал нужные. И ВСЁ ПРЕКРАСНО работало.
Но! Структура каталога со временем - усложнялась и расширялась. Появлялись под-каталоги и под-под-каталоги. ВСЁ ПО-ПРЕЖНЕМУ продолжало работать. Но в какой-то момент - стало "подтормаживать" на мобильных устройствах.
В конечном итоге - я начал разбираться. И "ОКАЗАЛОСЬ", что enumeratorAtPath перебирал не ТОЛЬКО НЕПОСРЕДСТВЕННЫЕ элементы каталога. НО! И ИХ ДЕТЕЙ, причём РЕКУРСИВНО.
Я залез в документацию и прочитал её "УЖЕ не по-диагонали". И там - ВО ВТОРОМ же абзаце БЫЛО чёрным по белому написано. "this function returns enumerator that performs deep enumeration".
Всё чётко и ЯСНО. И надо отдать ДОЛЖНОЕ Apple - они ВСЁ в ДОКУМЕНТАЦИИ написали.
Только кто ж её читает...
Может быть я ОДИН ТАКОЙ БОЛВАН, но мой опыт показывает обратное...
В итоге я нашёл нужную функцию - contentsOfPath. Она правда возвращает НЕ enumerator, а МАССИВ (NSArray). Почему ТАК сделано - это уж на совести Apple. Я бы "конечно" так не сделал бы.
Но! Эта функция МНЕ ПОДОШЛА, заработала как надо и дала "определённый" ЗНАЧИТЕЛЬНЫЙ прирост производительности. В моём "частном случае".
Вот такой пример.
О ТЕОРИИ и ПРАКТИКЕ ПРИМЕНЕНИЯ.
Опять же - может быть я ОДИН ТАКОЙ БОЛВАН и другие бы сразу "сделали всё правильно". Может быть.
НО! Опять повторю - Я СУЖУ ПО СЕБЕ.
И то что я ПИШУ или ГОВОРЮ - проистекает из этих суждений.
Если кому-то мои высказывания кажутся "менторскими" или что "я учу жить" - так вот - КАЖУТСЯ.
Я - СУЖУ ПО СЕБЕ. И ПИШУ и ГОВОРЮ - о СВОЕЙ практике применения. И о том, что ЗНАЮ лично я.
И никому ничего не НАВЯЗЫВАЮ.
Ну кроме может быть - "непосредственных коллег", с которыми я работаю в ОДНОЙ КОМНАТЕ. ДА! Тут я могу (и делаю это) - НАВЯЗЫВАТЬ скажем использование FreeAndNil, а не ПРОСТО Free. Ну или что-то подобное.
Теперь ещё о практике применения.
Если человек программирует на "каком-то" языке - он должен знать только теорию или и ПРАКТИКУ ПРИМЕНЕНИЯ тоже? Он должен знать "внутреннее устройство языка" или нет?
Вот скажем есть функциональный язык. "Какой-то". Человек "должен знать" - КАК он обрабатывает "хвостовую рекурсию" или не должен?
К чему я это? Объясню в следующем посте.
А пока - закругляюсь.
Резюме - теория и практика применения - это НЕОБХОДИМЫЕ составляющие успеха. ВМЕСТЕ. А не порознь.
Комментариев нет:
Отправить комментарий