Я начал писать код в своей комнате в доме моих родителей, когда мне было 14 лет. Я помню, как читал все, что мог, из-за моего медленного подключения к Интернету.
Затем, когда мне было 20, я подписал свой первый контракт, став веб-разработчиком и изучив PHP и JavaScript. Мне потребовалось 18 лет, чтобы понять, что программирование — это только часть профессии.
Имейте в виду, мне все еще нравится программировать.
Я не думаю, что когда-нибудь перестану программировать, даже если это просто хобби, но это гораздо больше, чем просто код. Вот почему я хочу поделиться своим опытом.
Я думаю, что иногда разработчики усваивают эти уроки слишком поздно.
1. Оставьте свое эго за дверью
Разработчики раздули эго.Это факт. Но почему? Я бы сказал, что любой, кто серьезно относится к своей профессии, считает себя в некотором роде художником.
Да, мы не поем перед миллионами и не рисуем Мону Лизу, но иногда мы пишем код, который решает сложные задачи настолько эффективно и элегантно, что мы не можем не гордиться своей работой.
Я думаю, что разработчик в силу своего подхода к проблемам является таким же художником, как и математиком.
И если это так, то мы склонны ползать по коду так же, как медведица ползает по своему потомству.
Мы пишем это, нам это нравится, и мы ненавидим, когда люди вокруг нас спорят о том, глючен ли код или нет. С другой стороны, это еще никому не помогло.
Мы любим свою работу, но должны понимать, что решаем проблемы.
Обсуждая наши идеи и решения с другими людьми, может появиться лучшая альтернатива.
Нет ничего плохого.
На самом деле сотрудничество обычно приводит к лучшим решениям.
Я видел самые разные виды эго, но никогда не видел ситуации, когда эго работало на разработчика.
Какой совет я могу дать? С той минуты, как вы начнете работать разработчиком, оставьте свое эго за дверью.
Съешьте это и послушайте, что другие люди говорят о вашей работе.
Примите тот факт, что ваши лучшие идеи могут прийти не из вашей головы и что они могут повысить ваш профессионализм.
Вам будет полезно услышать обратную связь.
2. Языки — это инструменты.
Ты знаешь только молоток? Тогда все проблемы как гвозди Перестаньте называть себя разработчиком Java или разработчиком JavaScript. Да, есть языки, которые вам нравятся из-за их синтаксиса или особенностей.
Это совершенно нормально.
Однако вам будет полезно потратить некоторое время на изучение чего-то еще.
Изучение новых языков, особенно если они следуют парадигме, отличной от той, к которой вы привыкли, может помочь вам открыть для себя разные подходы к решению проблем.
Я даже не могу сказать, насколько это важно: изучение новых языков и их использование принесут пользу вашим навыкам.
я читаю книгу Семь языков за семь недель несколько лет назад, и он открыл для меня множество возможностей только потому, что показал мне способы решения проблем, доступные на других языках.
Мы разработчики.
Мы знаем, как решать проблемы с кодом.
Не ограничивайте себя.
Выходите за рамки ограничений, думайте нестандартно, исследуйте другие варианты, языки, способы решения проблем.
Даже если вы не займетесь этим надолго, вы вернетесь к привычному инструменту со свежими идеями и более широким мышлением.
3. Речь идет не о запоминании алгоритмов, а о их поиске
Некоторые начинающие разработчики думают, что им нужно знать алгоритмы наизусть, поэтому они чувствуют себя плохо, как только понимают, что начали забывать, как писать цикл for. Это не только нормально.Я бы сказал, что это даже полезно.
Нам просто нужно слишком многое запомнить.
Но это тоже не обязательно.
Нам нужно принять тот факт, что Интернет — это всего лишь еще один инструмент, столь же необходимый, как и наша IDE, для поиска ответов.
Мы все это делаем.
И если вам от этого плохо, не тратьте время на это чувство.
Просто найдите ответ в Google и поймите свою проблему.
Думать об этом.
В каждом языке есть схожие, но немного разные способы реализации шаблона Observer. Что полезнее? Понимать, для чего нужен шаблон и какие проблемы он решает, или помнить, как его реализовать на каждом языке, с которым вы работаете? Если вы знаете, что шаблон решит вашу проблему, значит, вы ее уже решили.
Остальное — это просто Google, находящий лучший способ реализовать это.
Такой поиск не отнимает уважения к вам, вашему труду или вашему опыту.
То же самое относится и к любому другому поиску.
Сосредоточьтесь на том, что важно, на решении проблемы и позвольте Google разогреть вашу память.
Вот почему он существует.
4. Вы будете учиться на протяжении всей своей карьеры.
Или, скорее, ты должен учиться на протяжении всей своей карьеры.
Вам решать, хотите ли вы быть в курсе последних событий в отрасли.
Но лучше это сделать, если вы хотите удовлетворить запросы рынка.
Языки и технологии развиваются, и это совершенно нормально.
Конечно, некоторые экосистемы меняются быстрее, чем другие, и идти в ногу с ними может показаться непосильной задачей, но сосредоточьтесь на важных вещах, помните, что вы всего лишь человек и не можете знать всего.
Поэтому, если вам нужно чему-то научиться, я предлагаю научиться учиться.
Я знаю, это может показаться глупым, но это, наверное, навык номер один для разработчика.
Мы должны научиться быстро осваивать новые навыки.
В противном случае вы рискуете получить ярлык «устаревшего».
Именно здесь вступают в силу некоторые другие уроки из этой статьи.
Изменчивость, перемены, новые вызовы, отсутствие эго – все это поможет вам учиться и расширять спектр своих навыков.
Чем больше вы это практикуете, тем лучше.
Со временем вы поймете, что все языки похожи.
Вы начнете видеть их общие корни и сможете работать с любым из них.
Все, что вам нужно сделать, это прочитать пару ключевых вещей.
На протяжении всей карьеры вы будете изучать:
- Новые языки.
- Новые (и старые) парадигмы программирования.
- Новые подходы к работе.
- Новые способы решения проблем.
- Новые способы взаимодействия с товарищами по команде.
- Новые подходы к проверке и тестированию вашего кода.
Заметьте, я не сказал: «Уходите сейчас», но подумайте, готовы ли вы открыть свой разум для постоянного обучения.
5. То, что работает, лучше идеального
Как менеджер, я слышал это слишком много раз.Но мы, разработчики, склонны думать, что код должен быть идеальным перед выпуском.
И это не только неверно, но и потенциально проблематично.
Ранняя оптимизация — это проблема, потому что в конечном итоге вы тратите много времени и усилий на то, что может не нуждаться в оптимизации.
И в некоторых ситуациях, когда вы выполняете эти оптимизации, вы делаете предположения, которые нарушают функции.
Поэтому сосредоточьтесь на работе, которую необходимо выполнить, и на проблеме, которую вы пытаетесь решить.
После решения проблемы протестируйте решение, обработайте результаты и посмотрите, что ваша команда думает о вашем решении, даже если вы уже видите способы его улучшить.
Если вы собираетесь потратить еще два дня на то, чтобы довести код до совершенства, но он может быть запущен в производство прямо сейчас, то, скорее всего, он должен быть запущен в производство прямо сейчас.
В конце концов, вы решите проблему.
Чем быстрее вы решите проблему, тем лучше для ваших пользователей.
6. Заставьте код работать, а затем оптимизируйте
В соответствии с некоторыми из предыдущих пунктов, не попадайте в черную дыру ранней оптимизации.Даже если вы думаете, что сделаете код быстро, как только он выйдет в свет (если вообще когда-нибудь это произойдет), вы поймете, что эффект замедления реален.
Ваш главный приоритет как разработчика программного обеспечения, пишущего новую функцию или исправляющего ошибку, — заставить ее работать, независимо от того, насколько уродливым может выглядеть код или насколько неэффективным может быть решение.
Если код работает, вы только что доказали, что писать код возможно.
Это полдела.
Второй шаг – оптимизация.
Этот шаг не является обязательным.
Детали, которые некоторые люди склонны забывать.
Время, необходимое для оптимизации кода, зависит от многих переменных, которые иногда находятся вне вашего контроля.
Так что сосредоточьтесь на том, чтобы заставить код работать, а затем выясните, есть ли у вас время на его оптимизацию.
Ранняя оптимизация означает оптимизацию вашего кода по мере его написания.
Это опасная практика, поскольку при оптимизации мы делаем предположения о времени выполнения, требованиях к данным, требованиях к памяти и других факторах, которые мы еще не видели в действии.
Любое такое предположение может быть неверным, и в конечном итоге вы допустите ошибки в своей логике.
Подумайте о рабочем процессе TDD:
- Напишите тест, чтобы понять все, что должна делать ваша функция (тест завершится неудачей).
- Напишите свой код, чтобы тест прошел.
- Теперь позаботьтесь об оптимизации вашего кода.
Сначала нужно позаботиться о тесте, а значит функция работает. Тесту не важно, что вы используете в своих алгоритмах три вложенных оператора if. Это станет важным, возможно, на этапе проверки кода.
7. Последние 10% проекта занимают 90% времени.
Это особенно важно, если вы работаете в одиночку, но команды также страдают от неправильного понимания этой маленькой математической детали.
То же самое скажет любой, кто реализовал проект (и, честно говоря, это касается не только нашей отрасли).
Сначала вы спешите продумывать множество деталей, чтобы потом обдумать их.
И это совершенно нормально.
Мы склонны сначала сосредотачиваться на крупных функциях, оставляя мелкие детали или даже известные ошибки на самый конец.
Но, тем не менее, с ними нужно бороться – и вот тут появляются дополнительные 90%.
Вам предстоит протестировать, исправить код, протестировать еще раз, научить пользователей использовать решение, представить финальную версию решения и так далее.
Конечно, все зависит от контекста, от того, кто ваш клиент, и многих других факторов, но что-то всегда найдется.
Так что помните: когда вы думаете, что почти закончили с кодом, вы, вероятно, что-то забыли.
8. Когда ты в команде, тебе нужна абстракция.
Кодирование — это поведение абстракций.
Абстрагируя общую логику, мы можем повторно использовать ее в других местах, но вначале мы забываем о важности абстракций.
Вот мое личное правило: если код повторяется в двух местах, он переходит в функцию (метод, модуль); вы поняли идею.
Если два повторения кажутся вам небольшим числом, подумайте, что в будущем могут быть и другие места, где можно применить только что абстрагированный код. А сразу абстрагировав код, вы получите к нему немедленный доступ.
Абстракция масштабируется.
Часть абстрактной логики можно использовать снова и снова с минимальными усилиями, тогда как копирование (хотя и легкое в выполнении) требует больше усилий, чем больше вы его используете.
Подумайте, что бы произошло, если бы из-за ошибки вам пришлось изменить кусок логики, который повторялся 5 раз.
Чтобы исправить ошибку, вы буквально меняете один и тот же фрагмент кода 5 раз.
Та же логика применима и к повседневным задачам.
Если вы делаете что-то более одного раза, вероятно, это можно как-то автоматизировать.
Это залог эффективности, поэтому следите за повторением не только в своем коде, но и в своих действиях.
Если вы автоматизируете задачу, которая занимает 10 минут в день, вы сэкономите 5 часов в месяц.
9. Дополнительные проекты не обязательны, но могут помочь.
Некоторые говорят, что если вы хотите стать успешным разработчиком, вам нужны побочные проекты.
Я не думаю, что это правда.
Я лично знаю многих замечательных разработчиков, которые пишут код только на работе, «с 9 до 5».
Честно говоря, я восхищаюсь ими.
Они мастера своего дела и в свободное время наслаждаются жизнью, занимаясь чем-то другим.
В этом нет абсолютно ничего плохого.
Однако иногда вам нужна дополнительная практика.
Иногда вам кажется, что вы отстаете от своих коллег; Здесь могут помочь сторонние проекты.
Я не говорю о революции в отрасли — о разработке фреймворка с миллионами пользователей.
Пишите, если хотите, но я говорю о копировании чужих проектов, чтобы учиться на них.
Я также говорю об участии в проектах других людей, исправлении ошибок и добавлении функциональности.
Вы можете писать побочные проекты, чтобы испытать другие аспекты разработки, к которым вы обычно не прикасаетесь.
Если вы пишете модульные тесты по 8 часов в день, возможно, вам стоит подумать о написании чего-то с нуля или разработке какого-то функционала.
Если вы устали работать в одиночку, внесите свой вклад в существующие проекты других людей и узнайте, что значит координировать свою работу с другими.
Вы можете написать дополнительный проект, чтобы улучшить свои навыки, работая над своими слабыми местами.
Но опять же, не думайте, что вам нужно работать над ними, имея зеленую панель активности Github, чтобы считаться серьезным разработчиком.
Это просто глупо.
Заключение
Вот мои 9 тяжелых уроков, которые я усвоил как разработчик за последние 18 лет. Надеюсь, что, поделившись своим опытом, я пролил некоторый свет на ваше будущее или нынешнюю карьеру.Узнали ли вы что-нибудь еще, чем хотели бы поделиться? Мне бы хотелось услышать ваше мнение в комментариях, мне бы хотелось поучиться у вас чему-то.
- Профессия Веб-разработчик
- Профессия Java-разработчик
- Профессия Frontend-разработчик
- Профессия: технический хакер
- Профессия C++-разработчик
- Профессия Разработчик игр на Unity
- Профессия iOS-разработчик с нуля
- Профессия Android-разработчик с нуля
КУРСЫ
- Курс «Python для веб-разработки»
- Продвинутый курс «Машинное обучение Pro + Deep Learning»
- Курс машинного обучения
- Курс «Математика и машинное обучение для науки о данных»
- Курс JavaScript
- Курс анализа данных
- Курс DevOps
-
Покадровое Сравнение H.264 И Vp8
19 Oct, 24 -
Джемини Полетели На Орбиту?
19 Oct, 24 -
Playstation Suite Sdk: Релиз В Ноябре
19 Oct, 24 -
Столик Для Ноутбука
19 Oct, 24
