Советы начинающему программисту

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

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

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

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

Изучать чужой код. Точнее читать много кода, который был написан выдающимися программистами. Не только хорошими, как тот парень в соседней комнате, а действительно выдающимися. Благодаря наличию огромного количества опен-сорс проектов, сегодня это сдлелать очень просто. Когда я изучал Java, я изучал код проекта Tomcat, CI сервера и Cruise Control. За то время я изучил много хорошего кода.

Первое время логичным может быть изучать код начиная с main(), но поступая так, вы будете вынуждены тратить много времени на исследование установочного кода, парсинга коммандной строки и прочих фрагментов которые повторяются практически один в один от проекта к проекту. Я предпочитаю просмотреть названия файлов для того что бы найти что нибудь интересное и потом погрузиться в их изучение. Мне не нужно понимать весь проект, или его точки входа и выхода, все это вы сделаете и сами. Читайте кода. Смотрите на коментарии, смотрите что делает автор и как он это делает.

Тщательно изучайте возможность инструментов которыми вы пользуетесь. Я думаю что самая большая потеря времени не в отладке или переписывании кода, а в бесчисленных секундах которые тратятся изза того что разработчики не всегда знают как пользоваться тем или иным инструментом. Я говорю о: среде разработки, языке, билд-системе и системе контроля версий. Из этого списка самыми важными являются среда разработки и язык програмирования. После нескольких недель практики вы должны знать почти все горячие комбинации клавиш в среде разработке – это позволит в одно касание сделать то на что иначе понадобиолсь бы несколько секунд. Если вы знаете горячие комбинации – вы знаете комманды. Если вы используете только мышь – вы знаете только меню на которое вы будете нажимать снова и снова. Знание среды разработки – это основа.

Для того что бы хорошо изучить какой то большой язык, как например Java или C++ потребуется больше врмени. Они огромны, так же как и их библиотеки. Я думаю что здесь лучше все поможет чтение. Чтение кода в котором используются новые для вас идиомы и применяемые подходы. Книги (в большей степени чем блоги) другой замечательный источник знаний. Читайте о тех возможностях, с которыми вы уже знакомы и о тех, которые еше не появились но скоро появятся. Знания о билд-системах и системах контроля версий поможет вам стать незаменимым членом большой команды – которые не тратит время попусту из-за незнания важных операций.

Планируйте свой код перед тем как приступить к написанию. Я думаю это самый сложный пункт в моем списке. Но, он дает больше всего эффекта. Здесь я не говорю о формальном проектировании – в данном случае, это не то что нам нужно. Я говорю о планировании того как вы будете реализовывать код с точки зрения конструкций языка. Самый простой способ – это подготовить небольшой документ (я часто его называю мозговой картой): Какие требования к коду? Как вы собираетесь это реализовать? Что еще нужно узнать, прежде чем начинать работу? Какие объекты мне нужны или какие нужно создать? Ответы на все эти вопросы следует записать. После начала работы вы найдете что код стало намного проще писать, документировать и корректировать. Сохраняйте свои записи – они отличный ссылочный материал.

Пишите много кода и делайте его ревью. Еслы ваш код не подвергается ревью, делайте это сами. Найдите самого лучшего программиста, который может дать вам ценные советы в понятной для вас форме. Не будьте паразитом, но и не стесняйтесь данного процесса и не убеждайте себя что у вас на это нету времени или что все это не имеет смысла. Ревью кода должно стать частью вашей профессиональной жизни. Будте креативны. Попробуйте парное программирование с более опытным коллегой, хотя бы один раз. Самая главная суть этого – вам нужен такой отзыв со стороны, которого вы не в состоянии предоставить себе сами.

Пишите тесты к своему коду. Этот совет является достаточно спорным. Это не относится к TDD. Говоря о его спорности я подразумаеваю что тесты не позволят проверить работу вашего кода в всех возможных сценариях. Начните с юнит-тестов проверяющих ваш код на граничные значения. Например, проверьте что будет с вашим кодом если к нему поступит отрицательное или максимально возможное целочисленное значение. Если ваш код не приспособлен к подобной ситуации должен ли он бросать информативное исключение или просто игнорировать подобные значения? Если нету исключений, есть ли у вас список значний которые должны проверяться? Если да, проверьте их с помощью юнит-тестов. Используйте планирование о котором мы говорили выше, создайте симулирующий объект, и после этого проверьте как работает ваш код с его использованием. Это позволит прояснить многие проектные вопросы вашего кода и объектов которые еще не написаны. Сохраните ваши тесты и выполняйте их во время каждого коммита, таким образом они позволят сохранять ваш код в рабочем состоянии все время и бысто выявлять появляющиеся ошибки.

Существует больше количество других советов которые моугт быть добавлены в этот список. Но это и является источником проблемы о которой мы говорили в самом начале: существует чрезвычайно много всевозможных советов, что становиться действительно сложно понять с чего ничнать. По этой причине, я ограничил наиболее важные рекомендации этими пятью пунктами. Если вы с усердием начнете их применять на практике, вы скоро обнаружите два интересных момента: вы постепенно станете способны выполнять более серьезные и важные задачи, и вы со смущением будете смотреть на ваш код который написали два месяца назад.

Оба эти моментя явные признаки вашего прогресса, удачи!   

By Andrew Binstock, July 16, 2013

http://www.drdobbs.com/architecture-and-design/advice-to-a-new-programmer/240158341