Как я могу улучшить свои навыки, работая над реальными проектами, в отсутствие более опытных разработчиков? [закрыто]

Я ведущий разработчик в небольшой компании, работающей с C # и ASP.Net. Наша команда небольшая, 2-3 человека, без большого опыта разработки и дизайна. У меня нет возможности учиться у более старших разработчиков, в моей команде нет никого, кто бы помогал мне выбирать лучшие подходы, так как я сам забочусь о большинстве проектов.

Как я могу улучшить свои навыки разработки программного обеспечения, работая над реальными проектами, в отсутствие более опытных разработчиков?

Помимо более опытных коллег, есть много источников, из которых можно извлечь уроки: книги, блоги умелых разработчиков, Stack Exchange, лекции / конференции и т. Д. Обзоры кода также важны, а CodeReview.SE является ценным ресурсом.

Давайте посмотрим, как это может работать на примере.

пример

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

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

Чтобы ответить на эти вопросы, вы заимствуете книгу об ETL в своей местной библиотеке. Это объясняет, что некоторые процессы извлечения-преобразования-загрузки нелегко выполнить с помощью простого запроса SQL: не только фаза извлечения может иметь дело с несколькими, разнообразными опорами данных, не только реляционной базой данных, но также и этап преобразования может быть очень сложным для и проверка / нормализация данных и отображение их.

Теперь у вас есть четкое представление о том, что такое ETL, как его использовать, особенно когда вам нужен ETL и когда он не является подходящим инструментом. Между тем, вы реализовали небольшой ETL как личный проект. Этот проект позволяет вам обнаружить некоторые моменты, которые недостаточно ясны для вас и не охвачены книгой. Эти пункты довольно абстрактны и не имеют отношения к исходному коду, вы размещаете вопрос на сайте Programmers.SE .

Когда у вас есть возможность построить такую ​​в своей компании, вы начинаете ее создавать. У вас есть несколько вопросов. Некоторые из них связаны с кодом; Вы отправляете вопросы на переполнение стека . Другие связаны с базой данных; Вы задавать вопросы по DBA.SE .

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

Вы также начинаете следить за блогом разработчика, который годами работал над разными ETL. Интересно увидеть разные подходы, и через этот блог вы узнаете о ECCD; Вы заинтересованы, поэтому вы позаимствовали Ralph Kimball The ETW Toolkit Data Warehouse, книгу, в которой подробно рассказывается о процессе «извлекать, очищать, согласовывать и доставлять». В этом же блоге упоминается множество приложений, предназначенных для создания ETL без навыков программирования. Это особенно полезно для ETL, который вы сделали для своей компании, так как ваш начальник, нетехнический человек, постоянно просит вас внести небольшие изменения в то, что вы сделали.

Открывать вещи

ИМХО, трудная часть, когда у вас нет наставника или более опытного коллеги, состоит в том, чтобы обнаружить вещи, и под открытием я имею в виду переход от состояния «я никогда об этом не слышал» к «Я слышал об этом, но не очень хорошо знаю, что это такое ".

Если кто-то просматривает мой код и говорит, что я действительно должен начать использовать некоторые соглашения о стилях, с небольшим любопытством я могу обнаружить, что в программировании существуют разные стили написания кода, что следует придерживаться стиля для данного языка и кодовой базы, и что во многих языках есть инструменты для реализации стиля (например, StyleCop для C #).

Если никто не скажет мне о стиле, как я узнаю, что такая вещь существует?

Вот где пригодятся такие ресурсы, как блоги или Stack Exchange. Википедия не поможет (если вы не проводите дни, просматривая случайные страницы о программировании), и книги редко говорят об этом.

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

Как только вы обнаружили новый термин, узнать об этом довольно легко. Если вы дали новый термин «контракты по коду» и являетесь разработчиком на C #, вы можете легко найти достаточно информации на MSDN (или, что лучше, в книге Джона Скита).

Любопытство помогает

Когда я работаю со стажерами, я всегда замечаю, что лучшие - это те, кому было любопытно вне их лекций. Они могут знать, что существует такая вещь, как функциональное программирование, даже если никто из их учителей никогда не упоминал об этом, и хотя они могут не знать ни одного функционального языка, они все же могут объяснить в общих чертах, что такое FP и чем оно отличается от других. парадигм. Они могут знать о Agile, или о Unicode, или о модели частичного доверия / песочницы, просто потому, что они читали блоги и использовали Stack Exchange, а не просто посещали свои лекции.

Даже когда у них нет наставника, они все равно изучают все то, что не говорят в колледже.

Я нахожусь в похожей ситуации: мы небольшая команда, и основной продукт нашей разработки - это в основном постепенные изменения в кодовой базе, которой несколько лет.

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

На работе:

• Читайте: книги, блоги, PR материалы. Я слежу за несколькими RSS-лентами. Когда речь идет о технологии О'Рейли, о которой я не слышал, я прочитал описание книги. Если технология имеет какое-либо отношение к чему-либо, над чем я работаю, я потрачу пять или десять минут, исследуя ее немного глубже, подобно ответу MainMa. Я повторяю это с несколькими различными RSS-лентами.
• Создайте план обучения с вашим руководством, который может быть поддержан ресурсами компании (время и / или деньги)
• Вопреки тенденциям большинства программистов, попробуйте принять изменения и новые варианты дизайна. Изменения ради перемен не очень хорошие , но я считаю, что слишком часто разработчики избегают использования нового дизайна или фреймворка из-за изменений. Это тонкая линия, по которой нужно идти, и не спешите с принятием обязательных решений, но следите за новыми способами ведения дел. Некоторые изменения могут иметь неожиданные преимущества: переход на DVCS позволил мне легче экспериментировать с нашей кодовой базой и пробовать там новые технологии.
• Некоторые люди любят конференции; Я обнаружил, что выигрыш небольшой за потраченное время.

Вне работы:

Я обнаружил, что работа над моими навыками вне повседневной работы очень важна. Свобода экспериментировать, совершать ошибки и преследовать интересы удерживает меня в сфере ИТ. Если бы у меня были только проекты на рабочем месте, и мне нужно было ограничить свое обучение тем, что было немедленно полезным, я бы быстро сгорел.

• Примите участие в неработающем проекте. Для меня это разработка функционального сайта, связанного с личным интересом. Я свободно занимаюсь рефакторингом и активно пытаюсь экспериментировать с разными технологиями. Вклад в Open Source поможет вам познакомиться с кодом других людей. Это также даст вам хороший материал для обмена мнениями с компанией, в которой будут более опытные разработчики.
• Кодовый лагерь: если в вашем районе есть кодовый лагерь, следите. Поскольку они не в рабочее время и бесплатны, вы чувствуете свободу посещать любые занятия по темам, которые вас лично интересуют. По сравнению с обычными конференциями они обычно являются локальными и охватывают широкий спектр технологий, поэтому я считаю, что здесь есть более концентрированная ценность.

И не забывайте посещать SO или Programmers.SE часто.

Ответы здесь, вероятно, будут очень полезны, но я хотел бы подчеркнуть кое-что: ничто не может заменить работу с кем-то лучше, чем вы (для произвольных и личных определений лучше) по 8 часов в день, 5 дней в неделю. Это наверняка.

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

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

Разработка программного обеспечения - командный вид спорта. Как и в спорте, чтобы играть на очень высоком уровне, вы должны быть рядом и соревноваться с другими, которые делают то же самое. Ищите возможности передвигаться.

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

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

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

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

Однажды у меня не было технических способностей и уверенности, чтобы завершить проект. Часто я покупал книгу, читал довольно технический блог и оказывался «вне моей глубины». Я думаю, что самой большой проблемой для меня был тот факт, что я не имел доступа к крупным корпоративным приложениям. Довольно часто я делал бы что-то хорошо, но рядом со мной не было бы никого, кто бы подтвердил то, что я сделал.

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

Если вы не хотите покидать компанию, я бы предложил книги, написанные пионерами нашей отрасли. Я бы начал с Прагматичного Программиста Эндрю Ханта. Книга содержит множество полезных аналогий, которые очень легко запомнить. Первые несколько глав этой книги побудили меня выбрать совершенно другой язык программирования, нежели тот, который мы используем на работе. Я начал читать нетехническую литературу - теперь я верю, что чтение романов и научной фантастики сделает меня лучшим программистом. Написание эссе не далеко от написания чистого кода. Некоторые писатели хорошие, а некоторые плохие. Эта книга заставила меня задуматься о том, что я пишу. Одна из аналогий называется «Разбитые окна». Вы оставляете машину брошенной на улице на несколько дней, и с ней ничего не происходит. Раз вы разбили одно окно, автомобиль, вероятно, будет уничтожен на следующий день. Код не отличается. Если вы видите испорченный или плохо написанный код, то сразу исправьте его, не оставляйте его там, потому что рано или поздно он снова станет «преследовать» вас. Как только вы начнете изучать эту книгу, вы обнаружите множество аналогий, которые заставят вас думать о коде по-другому.

Затем я бы предложил вам перейти к «Чистому коду» Роберта К. Мартина. Эта книга более практична, так как заставляет вас читать плохой и хороший (чистый) код. Автор использует примеры кода из одного из проектов с открытым исходным кодом. Вы говорите, что нет никого, чтобы направлять вас. Есть прекрасная возможность взглянуть на чужой код, сравнить его со своим и посмотреть, как вы можете его улучшить. Для меня чтение этой книги было похоже на слежку за кем-то, работающим над проектом. В книге также сделан упор на самое простое - разделение интересов. Автор спросил пионеров нашей отрасли, что они считают «чистым» кодом. Прочитав их ответы, вы сможете сравнить их с собственным мнением о том, что такое чистый код.

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

Как я уже говорил в своем первоначальном ответе, этого не произойдет за ночь. Я занимаюсь этим уже несколько лет, и почти каждый день узнаю, что делаю это неправильно.

Удачи!

Практикуйтесь в решении проблем. Прочитайте и поработайте, чтобы понять чужой код (github - отличный ресурс для этого) и представить в него улучшения. Консультационная работа действительно может помочь вам расширить свои навыки.