Я бы в первую очередь выделил 4 навыка, которые так или иначе требуются программисту, и обладание которыми позволяет быть существенно более привлекательным для работодателя, чем коллеги, этими навыками не владеющие. Правда, не сказать, что они не связаны с программированием: всё-таки мы ведём речь именно о нём, поэтому все они так или иначе с ним связаны.
Во-первых, это навык самообразования.
Важно, чтобы вы интересовались своей областью деятельности и регулярно читали книги и статьи по своей теме. Причём нужно читать и «классическую» литературу (книги по алгоритмам, по математике), и современную техническую (книги по языкам программирования, новым технологиям – обращайте внимание на год издания, не берите книги 4-5 летней давности!), а также следить за новостями из мира технологий и программирования, чтобы быть в курсе всех самых актуальных новинок.
Для последнего рекомендую читать специализированные сайты, лично я предпочитаю habrahabr. Кстати, можете добавить в ваше резюме про регулярное чтение литературы и список из последних прочитанных вами книг по специальности – хороший работодатель оценит! Второе — владение средствами командной разработки программ Сюда входят несколько компонент.
1) Системы учёта «багов» (ошибок). Это специальные системы, которые позволяют записывать и сохранять найденные ошибки в программах, а также записывать все задачи по разработке. Их ещё называют «багтрекеры». Например, возникла необходимость добавить какую-то функцию в программу (или исправить найденную ошибку). Однако зачастую сразу времени на это нет, а «потом» можно забыть. Поэтому в системе учёта создают так называемый «тикет»: запись, в которой указано, что нужно сделать, насколько это срочно и кто за это отвечает. Если есть система тикетов, то рабочий день программиста начинается с того, что он открывает свою личную страницу, на которой выведены все задачи, за которые он отвечает, в порядке убывания срочности.
Таким образом, программист сразу видит, какие задачи нужно решить лично ему, и какие из них нужно делать в первую очередь. Как только программист задачу решил, он отмечает это в системе (называется «закрыть тикет»). Так что, если какая-то задача была занесена в систему, никто уже про неё не забудет, так как всё это на виду. Наиболее популярные системы учёта ошибок и задач: Trac, Redmine. Вот с этими системами стоит познакомиться в первую очередь. Они бесплатны, их можно поставить себе на компьютер и «поиграть» с ними.
2) Системы контроля версий. Сейчас объясню, для чего они нужны. Представьте, вы работаете над программой. Работали-работали, и вдруг стало понятно, что за последние 2-3 часа вы чего-то не того наворотили в программе, что теперь она стала работать хуже. Да, такое бывает, что не всегда мысль уходит в верном направлении. Что делать? Хорошо было бы взять и вернуть всё на 3 часа назад и начать заново! Однако приходится вспоминать, что поменялось, и не всегда удаётся всё вспомнить. Первое решение, которое приходит на ум – время от времени делать копии и складывать в отдельную папку. Так появляется куча папок:
- Программа1
- Программа2
- Программа1_2
- Программа_1
- Программа_1_нов
- Программа_1_нов_измененная
- Программа_1_нов_измененная2 …
в которых уже никто не может разобраться. Даже если вы поступаете «по-умному» и называете папки, включая в название дату и время, это всё равно не поможет вспомнить, какие именно изменения вы вносили в эти часы.
Другая ситуация. Допустим, вы свою программу должны кому-то показать. Или заказчику показывать, или – если это ваш личный проект – то выложить текущую версию программы на сайт. Но параллельно вы делаете уже новую версию программы, с новой функцией, которая пока не доделана, и поэтому новая программа ещё не работает (ведь чтобы что-то достроить, иногда нужно чуть-чуть «поломать» старую часть).
Ладно, можно завести две копии программы и в одной держать рабочую версию, а в другой работать над новой функцией. Но вот обнаружилось, что в программе есть ошибка, и теперь исправление требуется внести сразу в две копии программы! А это чревато ошибками по невнимательности или по другой причине.
А если копий больше двух – то и вовсе морока вносить все эти исправления. К счастью, все вышеперечисленные проблемы легко решаются системами контроля версий. Эти системы хранят в себе все изменения вашего исходного кода, своеобразные «слепки» вашей программы. Системы контроля версий похожи на машину времени для программиста. Вы можете в любой момент вернуться к любому сохранённому состоянию программы (а затем вновь применить отменённые изменения), сравнить два варианта программы и посмотреть, чем различаются исходники.
Можно также поддерживать несколько версий программы параллельно, выборочно перенося изменения между версиями (как в случае с внесением исправлений в текущую и разрабатываемую версии). А затем, когда потребуется, можно «слить» две версии программы воедино. И очень большую часть работы по манипуляциям с исходными кодами система контроля версий выполняет за вас, спрашивая у вас совет лишь в случае, если какие-то задачи не может решить без вашего участия.
Рекомендую познакомиться со следующими системами: git и SVN. Почитайте статьи и книги по ним, поставьте себе на компьютер.
3) Системы автодокументирования. Как правило, при серьёзной разработке требуется сопровождать всю свою работу документацией – описанием вашего исходного кода, процедур, где прописано – какая процедура что делает и как. Существуют специальные системы, которые позволяют автоматически создавать часть документации по вашим исходникам. Вам остаётся только вставить специально оформленные комментарии в программу, где написать информацию для других разработчиков – что делает каждая процедура, какие входные параметры, что возвращает. Но это всё пишется прямо в коде программы, то есть не нужно отвлекаться на какие-то другие редакторы.
А затем система автодокументирования сама создаст документацию – хоть в PDF, хоть в виде HTML-сайта с удобной навигацией. Там уже всё будет красиво оформлено, расписано по табличкам. С какими системами познакомиться? Их достаточно много, и для каждого языка программирования есть свои наиболее популярные. Так что проще всего знакомиться с той, которая будет на работе, куда примут.
Но сразу вспоминается doxygen – достаточно часто эта система используется, поскольку сразу всплывает в памяти. Завершая рассказ про инструменты командной разработки, хочу дать очень полезный совет. Разберитесь с этими инструментами (особенно система контроля версий, но и остальные тоже) и начните их применять в своей ЛИЧНОЙ разработке.
Вы сразу почувствуете, что это удобно и спасает от кучи сложностей и неприятностей. Ну, если даже не сразу, то в какой-то момент у вас всё равно возникнет мысль, что надо было ими пользоваться. Технологии программирования Кроме вышеперечисленного, рекомендую познакомиться с технологиями программирования. Начиная от банальных «сверху вниз», «снизу вверх», «итеративное», но обязательно узнать и современные технологии: SCRUM, Agile и другие.
Есть вероятность, что в компании, где вы будете работать, будет применяться что-то из этого. Тогда у вас уйдёт гораздо меньше времени на то, чтобы во всём разобраться, да и устроиться на работу будет легче. Паттерны проектирования Обязательно познакомьтесь с паттернами проектирования. Паттерны – это шаблоны, типичные способы решения часто встречающихся проблем в проектировании программы.
Как в архитектуре: если большой зал, то нужно поставить колонну, чтобы подпереть потолок. Если вы знакомы с паттернами проектирования, то, встретив подобную типичную задачу в программировании, вы сразу примените паттерн и пойдёте в разработке дальше. А если не знаете – то будете сидеть и выдумывать: а не подвесить ли потолок на канатах, которые будут держать дирижабли? Или не делать большой зал и понаставить стен? Или колонны сделать горизонтальными под потолком, как балки, а потолок пусть на них опирается? Вот чтобы такого не городить, стоит изучить эту тему.
Ну и на собеседованиях про это тоже спрашивают почти всегда. Изучать можно начать с Википедии или с книги – есть книг, посвященные именно паттернам. Изучая, практикуйтесь в их применении. Юнит-тестирование Наконец, завершаю список дополнительных навыков программиста. Правда, я уже ушёл от темы «простых и несложных» навыков и рассказываю про то, что используют профессионалы – но вы ведь тоже хотите быть профи и получать достойную оплату, не так ли? Итак, ещё один навык, который пригождается – это написание юнит-тестов. Юнит- тестирование – это способ контроля качества программ. Поскольку в программе могут быть ошибки, а также они могут появляться при внесении изменений и новых функций, то пишут специальные дополнительные проверочные программки. Их задача – запустить некоторые ЧАСТИ вашей программы, передав им некоторые входные данные, для которых заранее известен ответ.
Допустим, у вас программа – калькулятор. Там есть функция сложения. Поэтому пишется программка, которая передаёт функции сложения два числа – 11 и 7. Она заранее знает, что ответ должен быть 18. Поэтому, получив от вашей функции сложения результат, она сравнивает его с 18, и если он отличается – то сигналит: «Внимание! Функция сложения работает с ошибкой!». А вы уже лезете и смотрите, что не так. Суть здесь в том, что проверяется программа именно по частям. Отдельно сложение, отдельно вычитание, отдельно – кнопка «обнулить результат». Таким образом, сразу видно, какая именно часть «сломалась».
Поэтому и называется «юнит-тестирование» — от слова «юнит», что примерно означает «программный модуль», самостоятельная часть программы. Важным здесь является то, что вся проверка делается не вручную, а автоматически. Достаточно лишь единожды написать набор тестов на каждую функцию. Затем, когда выходит очередная версия программы, то прежде чем выпустить её «в свет», её сперва прогоняют через все тесты. Это делает компьютер, мы только нажали кнопку и ждём.
И если все тесты пройдены – уже есть некоторая минимальная уверенность, что новая версия программы работает верно. Эта проверка помогает избежать множества мелких ошибок и недочётов и исправить их до выхода программы на публику. Программы и библиотеки тестирования для каждого языка программирования свои, поэтому здесь я не буду давать рекомендаций.
Освоение юнит-тестирования пока оставлю, так сказать, «со звёздочкой» — читателям, которые сильно стремятся к профессиональному росту. Есть ли у вас вопросы? Если у вас возникли вопросы, пишите их мне.