97 этюдов для программистов. Опыт ведущих экспертов

Как правило, программы, которые вы пишете на работе, не удовлетворяют ваши самые честолюбивые мечты программиста. Может статься, вы разрабатываете ПО для огромной страховой компании, а хотели бы работать в Google, Apple, Microsoft или начать собственный стартап, который совершит следующую революцию. Вы никогда не придете к своей цели, разрабатывая программы для систем, которые вам не интересны.

К счастью, для вашей проблемы есть решение: open source, то есть проекты с открытым исходным кодом. В мире тысячи проектов с открытым исходным кодом, причем многие весьма активные, в которых программист может получить любой опыт, какой душа пожелает. Если вас влечет идея разработки операционной системы, выберите для себя какой-нибудь из десятка имеющихся проектов операционных систем. Если вы хотите работать над музыкальными программами, приложениями для анимации, криптографии, робототехники, играми для ПК, массовыми онлайн-играми, программами для мобильных телефонов или заниматься чем-то еще, вы почти наверняка найдете по крайней мере один действующий проект с открытым исходным кодом в соответствующей области.

Разумеется, за все нужно платить. Вам придется пожертвовать своим личным временем, ведь едва ли ваш работодатель позволит вам заниматься разработкой видеоигры с открытым исходным кодом в рабочее время. Кроме того, участие в открытых проектах очень редко приносит доход: некоторые зарабатывают на этом, но большинство — нет. Вы должны быть готовы отказаться от части развлечений (это не смертельно, если вы станете меньше играть в видеоигры или смотреть телевизор). Чем больше труда вы будете вкладывать в проект с открытым исходным кодом, тем быстрее осознаете, где лежат ваши истинные амбиции как программиста. Необходимо также учитывать условия вашего контракта с работодателем — иногда условия контракта ограничивают участие в посторонних проектах даже в личное время. Кроме того, нужно следить за тем, чтобы не нарушать законы об интеллектуальной собственности в отношении авторских прав, патентов, торговых знаков и коммерческой тайны.

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

Начать работать в открытых проектах довольно просто. Существует огромный объем документации по инструментам, которые вам понадобятся (системам управления исходным кодом, редакторам, языкам программирования, системам сборки и т. д.). Выберите проект, с которого хотите начать, и изучите инструменты, которые в нем используются. Документация о собственно проектах обычно бывает скудной, но это едва ли имеет большое значение, потому что лучше всего учиться, самостоятельно исследуя код. Для начала можно предложить свою помощь в составлении документации. Либо вызваться написать код для тестирования. Это может выглядеть не столь заманчиво, но написание тестового кода для чужих программ позволяет учиться гораздо быстрее, чем практически все прочие виды программистской деятельности. Пишите тестовый код, действительно хороший тестовый код. Ищите дефекты, предлагайте исправления, заводите друзей, работайте над проектом, который вам нравится, и удовлетворяйте свои честолюбивые программистские желания.

Золотое правило проектирования API Майкл Фезерс

Проектировать интерфейсы прикладного программирования (API) сложно, особенно в общем случае. Разрабатывая API, у которого будут сотни или тысячи пользователей, нужно думать о том, что со временем его, скорее всего, придется изменять, и эти изменения способны нарушить работу клиентского кода. Кроме того, нужно учесть возможное воздействие на ваш API со стороны его пользователей. Если класс API вызывает собственный метод, следует помнить, что пользователь способен создать подкласс вашего класса и переопределить этот метод, а это может привести к катастрофе. И вы не сможете изменить этот метод, потому что некоторые ваши пользователи придали ему другой смысл. Вы попадаете в зависимость от своих пользователей в том, что касается выбора внутренней реализации.