Як я можу вдосконалити свої навички під час роботи над актуальними проектами за відсутності більш досвідчених розробників? [зачинено]

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

Як я можу покращити свої навички розробки програмного забезпечення під час роботи над реальними проектами за відсутності більш досвідчених розробників?

Є багато джерел, щоб дізнатися окрім досвідчених колег: книги, блоги вмілих розробників, обмін стеками , лекції / конференції тощо. Огляди коду також є вирішальними, а CodeReview.SE - цінним ресурсом.

Подивимося, як це могло працювати на прикладі.

Приклад

Ви читаєте допис у блозі, де згадується термін "ETL". Ви не знаєте сенсу цього, але з цієї статті ви смутно розумієте, що це свого роду процес чи робочий процес, який переміщує дані з однієї підтримки даних до іншої.

Ви переходите до Вікіпедії та інших ресурсів і отримуєте більш точне бачення речі. Досі не дуже ясно, коли було б корисно використовувати ETL. Зрештою, здається набагато простіше написати запит SQL, який зробить всю роботу, а не витрачати занадто багато часу на створення справжнього ETL.

Щоб відповісти на ці запитання, ви позичите книгу про ETL в місцевій бібліотеці. Це пояснює, що деякі процеси завантаження витяг-перетворення не легко виконати за допомогою простого SQL-запиту: не тільки фаза вилучення може працювати з декількома різноманітними підтримками даних, не лише реляційною базою даних, але й крок перетворення може бути дуже складним для як перевірка / нормалізація даних, так і їх відображення.

Тепер у вас є чітке уявлення про те, що таке ETL, як ним користуватися і особливо, коли вам потрібен ETL і коли це не підходящий інструмент. Тим часом ви реалізували невеликий ETL як особистий проект. Цей проект дозволяє виявити деякі моменти, які недостатньо зрозумілі для вас і не охоплені книгою. Якщо пункти є досить абстрактними і не пов'язані з вихідним кодом, ви ставите запитання на Programmers.SE .

Коли у вас є можливість побудувати її у вашій компанії, ви починаєте її створювати. У вас є кілька питань. Деякі пов'язані з кодом; Ви надсилаєте запитання на " Переповнення стека" . Інші стосуються бази даних; Ви задавати питання по DBA.SE .

Нарешті, існує конференція, проведена висококваліфікованим розробником щодо оптимізації ETL. Ви відвідуєте цю конференцію, і вона дає вам дорогоцінну підказку про вдосконалення, які ви можете зробити для свого проекту.

Ви також починаєте вести блог розробника, який працював над різними ETL роками. Цікаво бачити різні підходи, і через цей блог ви дізнаєтесь про ECCD; Ви зацікавлені, тому Ви запозичили ETL Toolkit Data Warehouse, книга, яка детально розповідає про процес "вилучення, очищення, узгодження та доставки". У цьому ж блозі також згадується безліч додатків, призначених для створення ETL без навичок програмування. Це особливо корисно для ETL, який ви зробили для своєї компанії, оскільки ваш начальник, не технік, постійно просить вас зробити невеликі зміни у тому, що ви зробили.

Відкриття речей

ІМХО, найважча частина, коли ти не маєш наставника чи досвідченого колеги, - це відкривати речі, і, виявивши, я маю на увазі перехід від штату "Я ніколи не чув про це" до "Я чула про це, але не дуже добре знаю, що це ".

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

Якби ніхто не розповідав мені про стиль, як би я знав, що така річ існує?

Тут дуже зручні ресурси, такі як блоги або обмін стеками. Вікіпедія не допоможе (якщо ви не витрачаєте дні, переглядаючи випадкові сторінки про програмування), а книги рідко говорять про ці речі.

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

Щойно ви відкрили новий термін, дізнатися про нього досить легко. Якщо ви дали новий термін "кодові контракти" і ви розробник C #, ви можете легко знайти достатньо інформації про MSDN (або, ще краще, в книзі Джона Скіта).

Цікавість допомагає

Працюючи з інтернами, я завжди помічаю, що найкращі - це ті, кому цікаво було поза лекціями. Вони можуть знати, що є річ, яка називається функціональним програмуванням, навіть якщо ніхто з їхніх викладачів ніколи про це не згадував, і хоча вони не знають жодної функціональної мови, вони все ще можуть пояснити загальними поняттями, що таке FP і чим вона відрізняється від інших парадигми. Вони можуть знати про Agile, або про Unicode, або про модель з частковою довірою / пісочницею, тільки тому, що вони читали блоги та використовували Stack Exchange, а не просто відвідували їх лекції.

Навіть коли у них немає наставника, вони все одно вивчають все те, про що не кажуть у коледжі.

Я в подібній ситуації: ми невелика команда, і наша основна робота над розробкою продуктів в основному полягає в поступових змінах на основі коду, якому вже кілька років.

Кілька методик, якими я користуюся, щоб бути в курсі сучасних і вдосконалювати свої навички.

На роботі:

• Читайте: книги, блоги, PR-матеріали. Я стежу за низкою RSS-каналів. Коли сьогоднішній день угоди O'Reilly за технологією, про яку я не чув, я читав опис книги. Якщо технологія має велике відношення до всього, над чим я працюю, я витрачаю п’ять-десять хвилин на дослідження трохи більше, як у відповіді MainMa. Я повторюю це з кількома різними RSS-стрічками.
• Створіть план навчання з вашим керівництвом, який може бути підтриманий ресурсами компанії (час та / або гроші)
• Всупереч тенденціям більшості програмістів, спробуйте прийняти зміни та нові варіанти дизайну. Зміни заради змін не є гарними , але я вважаю, що надто часто розробники уникають використання нового дизайну або рамки через зміни. Це тонка лінія, коли потрібно крокувати, і не поспішайте з обов'язковими рішеннями, але слідкуйте за новими способами вчинків. Деякі зміни можуть мати несподівані переваги: ​​перехід до DVCS дозволить мені простіше експериментувати на нашій кодовій базі та спробувати нові технології там.
• Дехто любить конференції; Я виявив, що окупність за вкладений час невелика.

Поза роботою:

Я виявив, що робота над моїми навичками поза повсякденною роботою є надзвичайно важливою. Свобода експериментувати, помилятися та переслідувати інтереси змушує мене займатися ІТ. Якби я мав лише свої робочі проекти і мені потрібно було обмежити своє навчання тим, що було негайно корисним, я швидко перегорів би.

• Долучайтесь до неробочого проекту. Для мене це розробка функціонального веб-сайту, пов’язаного з особистим інтересом. Я вільно рефактор і активно намагаюся експериментувати з різними технологіями. За допомогою відкритого коду ви отримаєте також вплив коду інших людей. Це також дасть вам хороший матеріал, щоб поділитися для інтерв'ю з компанією, яка матиме більш досвідчених розробників.
• Code Camp: Якщо у вашому районі є кодовий табір, відвідуйте. Оскільки це не в робочий час і безкоштовно, ви відчуваєте свободу відвідувати будь-які сесії на теми, які вас цікавлять особисто. У порівнянні з типовими конференціями, як правило, це місцеві та охоплюють широкий спектр технологій, тому я вважаю, що є більш концентрована цінність.

І не забудьте часто відвідувати SO або Programmers.SE.

Відповіді тут, ймовірно, будуть корисними, але я хотів би наголосити на чомусь: ніщо не може замінити роботу з кимось кращим за вас (для довільних та особистих визначень кращих) 8 годин на день, 5 днів на тиждень. Стільки певного.

Якщо ви такий тип розробника, який завжди хоче покращитись, завжди хоче вчитися, то з часом вам доведеться перейти до іншої компанії. Це багато чого неминуче, і його слід планувати.

Коли ви знайдете підходящу для вас компанію, ви виявите, що можете продовжувати рости в ній, ніж рости з неї.

Розробка програмного забезпечення - це командний вид спорту. Як у спорті, щоб грати на дуже високому рівні, вам потрібно бути разом і змагатися проти інших, хто робить те саме. Шукайте можливості пересуватися.

Пам’ятайте, що практика стає постійною, тому, якщо ви не працюєте постійно над кращою технікою та знаннями, якщо працюєте у відриві, не маючи критики чи зразка для наслідування, ви можете виявити, що ваші навички не зростають.

По всьому світу речі стають більш конкурентоспроможними, тому очікуйте, що ваша ніша буде тимчасовою, і підготуйтеся до такого виду можливостей, який відповідає вашим критеріям задоволення роботи, і в той же час виведе вас за межі зони комфорту для роботи з вищим колективом.

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

Якщо ви реалізуєте проекти, але відчуваєте, що є багато місця для вдосконалення, ніж це гарна річ.

Одного разу я не мав технічних можливостей і впевненості, щоб завершити проект. Часто я купував би книгу, читав би досить технічний блог і опинився б "поза глибиною". Я думаю, що найбільшою проблемою для мене було те, що я не зазнав жодних великих корпоративних програм. Я досить часто робив би щось добре, але я не мав би нікого зі свого боку, щоб підтвердити те, що я зробив.

Це було мотиваційним і складним, тому я бачу, звідки ви родом. Як я вирішив це питання? Я покинув компанію і приєднався до добре створеного будинку з розробки програмного забезпечення, що допомогло мені набути багато досвіду в минулому році.

Якщо ви не хочете покинути компанію, я б запропонував книги, написані піонерами нашої галузі. Я б почав з Прагматичного програміста Ендрю Ханта. Книга містить багато корисних аналогій, які дуже легко запам’ятати. Перші кілька розділів цієї книги спонукали мене підібрати зовсім іншу мову програмування до тієї, яку ми використовуємо на роботі. Я почав читати нетехнічну літературу - зараз вірю, що читання романів та наукової фантастики зробить мене кращим програмістом. Написання нарисів недалеко від написання чистого коду. Деякі письменники хороші, а деякі - погані. Ця книга змусила мене дбати про те, що я пишу. Одна з аналогій називається "Зламані Windows". Ти залишаєш машину, покинуту на вулиці днями, і з цим нічого не відбувається. Щойно ви зламаєте одне вікно, автомобіль буде, мабуть, знищений на наступний день. Код не відрізняється. Якщо ви бачите зламаний або погано написаний код, то виправте його відразу, не залишайте його там, бо рано чи пізно він повернеться до вас "переслідувати". Як тільки ви почнете працювати над цією книгою, ви підберете десятки подібних аналогій, які змусять вас думати про код по-іншому.

Тоді я б запропонував вам перейти до «Чистого кодексу» Роберта К. Мартіна. Ця книга більш практична, оскільки вона змушує читати поганий і добрий (чистий) код. Автор використовує зразки коду одного з проектів з відкритим кодом. Ви кажете, що вас ніхто не керував. Є прекрасна можливість подивитися чужий код, порівняти його з власним і побачити, як ви можете його вдосконалити. Для мене читання цієї книги було схоже на затінення когось, хто працює над проектом. Книга також робить сильний акцент на найлегшій найважчій справі - розділенні проблем. Автор запитав у піонерів нашої галузі, що вони вважають "чистим" кодом. Ознайомившись з їхніми відповідями, ви зможете порівняти їх з власною думкою про те, що таке чистий код.

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

Як я вже говорив у своїй оригінальній відповіді, це не відбудеться протягом ночі. Я цим займаюся вже кілька років і майже кожного дня з’ясовую, що я робив це неправильно.

Удачі!

Практикуйте розв’язувати проблеми. Читайте та працюйте, щоб зрозуміти код інших (github - чудовий ресурс для цього) та подайте до нього вдосконалення. Консультаційна робота може допомогти вам розширити набір навичок.