<<Вернуться к Omega's Blog Матрица компетентности программиста ч.II.>>
|
Область программирования |
Уровень |
Комментарии | |||
|
|
2^n (Уровень 0) |
n^2 (Уровень 1) |
n (Уровень 2) |
log(n) (Уровень 3) |
|
|
Теория: |
|||||
|
Структуры данных |
Не понимает разницы между массивом и связным списком. | Может объяснить и использовать на практике массивы, связные списки, словари и т.д. |
Понимает плюсы и минусы использования тех или иных базовых структур данных (размер памяти, время выполнения операций с данными, в чем разница между массивами и связными списками в этом плане). Может объяснить как реализовать хэш-таблицы и как обработать коллизии. Приоритетные очереди и способы их реализации, и т.д. |
Знание сложных структур данных, таких как B-дерево, Биномиальная куча и Фибоначчиевская куча, АВЛ-дерево, Красно-чёрное дерево, Косое дерево, Список с пропусками, TRIE-структуры и т.д. | |
|
Алгоритмы |
Не может найти среднее значение массива чисел. (Тяжело поверить, но встречаются и такие кандидаты на собеседовании.) | Базовые методы сортировки и поиска. Обход и поиск в структурах данных. | Деревья, Графы, "простой путь" и "разделяй-и-властвуй" алгоритмы, понимает значимость уровней приведенной здесь матрицы. |
Может распознать и написать решение динамическим программированием, хорошо знает алгоритмы на графах, хорошо знает численные методы, может идентифицировать проблемы класса NP. |
Работать с теми, кто имеет хороший рейтинг в TopCoder - это невероятная удача! |
|
Системное программирование |
Не знает что такое компилятор, линковщик или интерпретатор. |
Базовое понимание компиляторов, линковщиков и интерпретаторов. Понимает, что такое ассемблерный код и как работают программы на уровне железа. Небольшое понимание виртуальной памяти и пэйджинга. |
Понимает чем отличается kernel mode от user mode, что такое мульти-трединг, способы синхронизации и как реализованы примитивы синхронизации, может читать ассемблерный код. Понимает, как работают сети, сетевые протоколы и может реализовать передачу данных через сокеты. |
Понимает как работает весь "программный стэк": железо (CPU + Память + Кэш + Прерывания + микрокоды), двоичный код, ассемблер, статическая и динамическая линковка, копиляция, интерпретация, JIT-компиляция, сборка мусора, куча, стэк, адресация памяти….. | |
| Навыки: | |||||
|
Контроль версий исходников |
Бэкап исходников в папку с датой бэкапа. | VSS и основы CVS/SVN в качестве пользователя | Специалист по возможностям CVS and SVN. Знает как разветвить и слить, настроить репозитарий и т.д. | Знает распределенные системы VCS. Пробовал Bzr/Mercurial/Darcs/Git | |
|
Автоматизация build'ов |
Знает как запустить Build из среды программирования. | Умеет билдить из командной строки. | Может настроить скрипт для сборки основной системы. | Может настроить скрипт для сборки системы и документации, инсталляторов, генераторов "release notes" и добавит скрипт в систему контроля версий исходников. | |
|
Автоматизированное тестирование |
Думает, что тестирование - это работа тестеров. | Написал автоматизированные юнит-тесты и может создавать свои хорошие юнит-тесты для кода, который пишет в настоящее время. | Пишет код в стиле Test-driven Development (TDD). | Понимает и может настроить автоматические тесты на функционал, пользовательский интерфейс и загрузку/производительность.. | |
| Программирование: | |||||
|
Декомпозиция задачи |
Просто последовательные строчки кода, а copy/paste -для повторного использования кода. | Может разбивать решение задачи на несколько функций. |
Способен создавать многократно используемые функции/объекты, которые решают общие задачи. |
Использует соответствующие структуры данных и алгоритмы. Создает общий/объектно-ориентированный код, который инкапсулирует те условия задачи, которые могут быт изменены. |
|
|
Декомпозиция системы |
Не способен думать о системе, сложнее одного класса или файла. | Может произвести декомпозицию задачи и спроектировать систему в пределах одной платформы или технологии. | Может спроектировать систему, которая охватывает несколько технологий/платформ. | Может визуализировать и проектировать сложные системы с несколькими линейками продуктов и интеграцией с внешними системами. Также должен уметь проектировать системы поддержки работы: мониторинг, генерация отчетов, аварийные переходы на использование запасных ресурсов. | |
|
Общение |
Не может выразить свои мысли/идеи. Плохо с правописанием и грамматикой. |
Его понимают. Хорошие правописание и грамматика. | Может эффективно общаться. |
Может понимать и объяснять мысли/дизайн/ идеи/специфику в точно выраженной форме, в общении соответствует ситуации. |
Важность этого критерия для программиста часто недооценивают. С увеличением аутсорсинга разработки ПО в те страны, где английский не является родным языком, этот вопрос стал более актуальным. Я знаю несколько проектов, которые провалились потому, что программисты не могли понять смысл обсуждения. |
|
Организация кода в файле |
Нет четкой организации в файле. | Методы сгрупированны логически и по вызовам. | Код разделен на регионы, имеет хорошие комментарии, в т.ч. со ссылками на другие файлы исходников. | Файл имеет разделы "license header", "summary", хорошие комментарии, непротиворечивую расстановку пробелов и табуляции. Файл должен выглядеть красиво. | |
|
Организация кода между файлами |
Не приходит в голову мысль четко организовать код с помощью разделения на файлы. |
Похожие файлы группируются в папку. |
Каждый физический файл предназначен для чего-то одного, например, служит для объявления одного класса или для реализации одного функционала и т.д. |
Организация кода на физическом уровне точно соответствует проекту, и, глядя на имена файлов и структуру папок, можно понять как спроектирована данная реализация. | |
|
Организация дерева исходников |
Все в одной папке. | Простое разделение кода в логические подкаталоги. | Нет "круговых" зависимостей. Бинарники, либы, документация, билды, сторонний код -- все разложено в соответствующие папки. |
Структура дерева исходного кода соответствует логической иерархии и организации кода в проекте.
Глядя на имена файлов и структуру папок, можно понять как спроектирована данная система. |
Разница между этим пунктом и предыдущим состоит в масштабе организации. Организация дерева исходников относится к всему комплексу продуктов, которые определяют систему. |
|
Читабельность кода |
Односложные имена. | Хорошие имена файлов, переменных, классов, методов и т.д. | Нет длинных функций, а нестандартный код, багфиксы и допущения в коде поясняются комментариями. | Допущения в коде сопровождаются assert'ами, поток операций в коде естественный - нет глубокой вложенности условий или методов. | |
|
Безопасное программирование (defensive coding) |
Не понимает данной концепции. |
Проверяет все аргументы и ставит assert'ы на критические допущения в коде. | Убеждается, что проверил возвращаемое значение и что обрабатывает исключения в потенциально бажном коде. | Имеет свою собственную библиотеку помогающую в безопасном программировании, пишет юнит-тесты которые эмулируют сбои. | |
|
Обработка ошибок |
Пишет код для "идеального" случая, когда все работает и нет сбоев. | Обработка ошибок в коде, который либо кидает исключение, либо генерирует ошибку. | Убеждается, что после того, как произошла ошибка/исключение, программа продолжает работать, а ненужные более ресурсы, коннекшоны и память были корректно освобождены обработчиком ошибки. |
Пишет код так, чтобы определять возможные ошибки на раннем этапе, придерживается последовательной стратегии обработки исключений во всех слоях кода, разрабатывает общие принципы обработки исключений во всей системе. |
|