Терминология. Навыки программирования.
1. "Конкретные" навыки. Это навыки использования различных библиотек, технологий, фреймворков, и т.п. Например, знание определенного API, конкретной базы данных, навыки создания драйверов и т.д. То есть это то, на что делают упор большинство программистов. Образно говоря, тут изучается как работать с "мясом". Возможно, сюда же относятся навыки работы с компилятором, отладчиком, декомпилятором и т.д.
2. "Абстрактные" навыки. Это навыки использования языка программирования, не связанного с конкретной ОС, железом и т.д. Тут развиваются навыки создания алгоритмов, использования всяких парадигм типа ООП, ФП и т.п. Например, в C++ навык использования классов, шаблонов, STL... Это уже навык работы со "скелетом". То есть это те основы с которых начинается изучение языка. Но редко кто стремится делать упор на этом.
3. "Поэтические" навыки. Вероятно, эти навыки должны быть у архитекторов или аналитиков. Это навыки писать читаемый и гибкий код. То есть код, который можно будет использовать несколько раз, код который можно будет легко понять и изменить. Частично сюда относится оформление кода, правильное именование переменных. Но главная наука состоит в том, как правильно группировать данные и функции, какие из них спрятать, а какие показать и т.д. Вероятно, это навыки работы с читателем. Это навыки, о которых часто говорят, пишут в книгах, но редко можно увидеть, чтобы кто-то их пытался развивать.
Может ещё какие-то навыки есть. Но мне было бы интересно хотя бы узнать, как называют эти типы навыков. Или может есть какая-то другая, более чёткая классификация навыков?
Упреждая ответ про тему о Programmer Competency Matrix. Там уж слишком конкретно и субъективно. Оно не является адекватной классификацией.
не, у тебя слишком просто. так не пойдет. :D
Звучит как "Сильные руки и крепкая голова. Вот и весь навык в боксе".
так таки и немаловажно :) и практически к этому сводится :)
Понятное дело. Но тогда чтобы стать хорошим боксером надо только качать руки и укреплять голову. То есть лучший боксёр - это штангист-тяжеловес.
Возможно, надо на примерах пояснить. "Конкретные" навыки у меня мало прокачаны, потому приведу возможно не очень удачный пример:
http://forum.codenet.ru/showpost.php?p=57283&postcount=2
Наверное, вот этот пример пойдет для иллюстрации "абстрактных" навыков:
http://forum.codenet.ru/showpost.php?p=280175&postcount=2
Третий тип навыков труднее проиллюстрировать. Наверное, будет наглядно, если я покажу диаграмму для компонента графика:
http://forum.codenet.ru/attachment.php?attachmentid=3333&d=1231783010
Возможно, надо на примерах пояснить. "Конкретные" навыки у меня мало прокачаны, потому приведу возможно не очень удачный пример:
http://forum.codenet.ru/showpost.php?p=57283&postcount=2
Наверное, вот этот пример пойдет для иллюстрации "абстрактных" навыков:
http://forum.codenet.ru/showpost.php?p=280175&postcount=2
Третий тип навыков труднее проиллюстрировать. Наверное, будет наглядно, если я покажу диаграмму для компонента графика:
http://forum.codenet.ru/attachment.php?attachmentid=3333&d=1231783010
Всё понятно и так, можно не пояснять. Лично моё IMHO следующее:
[QUOTE=Kogrom]
1. "Конкретные" навыки. Это навыки использования различных библиотек, технологий, фреймворков, и т.п. Например, знание определенного API, конкретной базы данных, навыки создания драйверов и т.д. То есть это то, на что делают упор большинство программистов. Образно говоря, тут изучается как работать с "мясом". Возможно, сюда же относятся навыки работы с компилятором, отладчиком, декомпилятором и т.д.
[/QUOTE]
Этот навык нужно развивать постольку поскольку - в процессе написания программы. Конкретные технологии меняются, фреймворки меняются и эти знания устаревают.
2. "Абстрактные" навыки. Это навыки использования языка программирования, не связанного с конкретной ОС, железом и т.д. Тут развиваются навыки создания алгоритмов, использования всяких парадигм типа ООП, ФП и т.п. Например, в C++ навык использования классов, шаблонов, STL... Это уже навык работы со "скелетом". То есть это те основы с которых начинается изучение языка. Но редко кто стремится делать упор на этом.
Это как раз то, что нужно. Только я бы побольше выделил алгоритмизацию и математику. Это вечные вещи и эти знания не устареют никогда.
3. "Поэтические" навыки. Вероятно, эти навыки должны быть у архитекторов или аналитиков. Это навыки писать читаемый и гибкий код. То есть код, который можно будет использовать несколько раз, код который можно будет легко понять и изменить. Частично сюда относится оформление кода, правильное именование переменных. Но главная наука состоит в том, как правильно группировать данные и функции, какие из них спрятать, а какие показать и т.д. Вероятно, это навыки работы с читателем. Это навыки, о которых часто говорят, пишут в книгах, но редко можно увидеть, чтобы кто-то их пытался развивать.
Считаю, что специально это не нужно развивать. Это придёт как само собой разумеющееся на определённом уровне развития (уж никак не на начальном).
Кстати, programmer competency matrix считаю вполне объективной. По отдельным пунктам можно всегда поспорить, но в целом картина достаточно правдивая.
Этот навык нужно развивать постольку поскольку - в процессе написания программы. Конкретные технологии меняются, фреймворки меняются и эти знания устаревают.
Ой ли? Навык не менее важен, чем мат. часть. Подтягивать его нужно все время. Иначе это грозит постоянным изобретением велосипедов.
Здесь тоже не согласен :) Само не придет никогда. Это также надо учить, учить и учить (по книгам, по коду более опытных коллег). Если этот навык не развивать, то так и будешь на любом уровне "развития" писать быдлокод, хотя и вполне работоспособный.
В общем, согласен. Но в некоторых технологиях очень обширная теория, много особенностей, которые с наскока не поймешь. А если не поймешь, то будешь писать менее эффективные программы, или затратишь на их создание больше труда. Не зря же популярны книги типа тех, что Рихтер пишет.
Ну, математика - это тема для отдельного холливара :)
Но я не только про алгоритмизацию говорил. Например, использую STL можно обойтись без знания тонкостей реализации некоторых алгоритмов. И хотя эта библиотека может устареть, в ней есть некоторые "вечные вещи", которые я не могу отнести ни к алгоритмизации, ни тем более к математике.
То есть говорю не только о книгах Кнута, но и о книгах Страуструпа и Александреску (знаю, что последнего часто критикуют).
В том и проблема, что приходится заставлять себя писать читаемый код. Как только теряешь бдительность, как только поспешишь - он опять превращается в кашу. Не зря же Мартин Фаулер и Кент Бек столько книг понаписали на эту тему.
Я согласен, что та таблица дает какие-то ориентиры, памятки, что было бы неплохо знать и применять. Но там нет никакой четкой системы - автор просто поделился опытом, как развивался он и его коллеги. Поэтому многие пункты можно критиковать. Например, многие строки можно изучать от третьего левела к первому.
Но я не только про алгоритмизацию говорил. Например, использую STL можно обойтись без знания тонкостей реализации некоторых алгоритмов. И хотя эта библиотека может устареть, в ней есть некоторые "вечные вещи", которые я не могу отнести ни к алгоритмизации, ни тем более к математике.
Например?
Ну, например, являются ли контейнеры STL алгоритмами или математикой? Вроде нет. Разные виды итераторов являются алгоритмами? А функторы? Потоки ввода-вывода? Умные указатели?
Если не говорить именно про STL, являются ли шаблоны алгоритмами? А классы? Спорные, но классические признаки ООП: инкапсуляция, наследование, полиморфизм являются ли алгоритмами?
И это я только про C++ говорю.
Это структуры данных. Второй компонент "программ".
И это - "вечная вещь"? Обобщение итератора (т.е. цикла) - рекурсивный алгоритм.
Это классы специального вида.
Они к "вечности" близки, но все же не подходят на роль "не-алгоритмов" - это общесистемый подход (т.е. алгоритм, паттерн) к передаче данных.
Тоже претендуют на "вечность"?
Но не алгоритм же, так?
Почему не "вечная"? В том или ином виде оно было перенято другими языками (не буду спорить, кто первый изобрел).
И потом, итератор - это не цикл, а элемент, который используется в циклах. По смыслу это что-то вроде ссылки.
Опять не алгоритм. Хотя про функторы я бы возмутился "и это - вечная вещь"? Как я понимаю, это всё-таки навороченная замена лямбде. Хотя, может и вру.
Паттерн - не алгоритм, во многих случаях . Класс - не алгоритм. Иерархия классов - не алгоритм.
Про умные указатели - спорное утверждение. Если брать не только те из них, что есть в современном C++, но и те, что будут в будущей версии, то это некоторая альтернатива сборщику мусора. Это не является промежуточным звеном к нему, а именно альтернативой. Потому, возможно, она и вечна.