Помимо более опытных коллег, есть много источников, из которых можно извлечь уроки: книги, блоги умелых разработчиков, 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, а не просто посещали свои лекции.
Даже когда у них нет наставника, они все равно изучают все то, что не говорят в колледже.