Задать вопрос

Как повысить уровень программирования?

Свои силы оцениваю на уровне джуна.
Когда программирую, ловлю себя на мысли что мой код какой-то невыразительный что-ли. Т.е. видно что писал не синьор. Он получается плохо масштабируемый, каждый новый функционал добавляется все сложней.
Как перейти на новый уровень?
  • Вопрос задан
  • 9844 просмотра
Подписаться 65 Оценить 2 комментария
Пригласить эксперта
Ответы на вопрос 17
tiabc
@tiabc
Бизнес-партнер и консультант по технологиям
Хорошие разработчики постоянно развиваются и никогда не стоят на месте. Любое развитие состоит в делании дел, в решении конкретных задач и в обратной связи, которую ты получаешь от других или в результате рефлексии.

TL;DR: Читайте книжки, делайте дела, читайте чужой код.

Что можно начать делать прямо сейчас, чтобы стать программистом лучше?

1. Изучайте базу. Алгоритмы, сети, криптографию, архитектуру, ос, устройство браузеров, компиляторы и т.д. Изучение подобных вещей дает понимание какие задачи бывают в реальном мире и как "большие дядьки" решают возникающие проблемы. Это кладезь инсайтов.

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

3. Написание кода - не самая большая часть работы сеньор-девелоперов, я бы сказал. Но когда речь заходит о самом коде, нужно понимать что ты пишешь и зачем. Есть классические книжки, которые можно найти, например, в матрице компетентности программиста, есть современные, но полезные типа The Art of Readable Code, которую я очень рекомендую. Нужно читать книжки. На собеседовании я всегда спрашиваю какие книжки читал или читает соискатель и если ответ отрицательный, то это большой минус.

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

5. Наберитесь терпения. Это не случится за один день. Думайте над именованием, разделяйте обязанности, изучайте алгоритмы и экосистему, оптимизируйте ваше рабочее место, изучайте новые технологии, читайте статьи и в течение ближайших лет регулярных усилий вы обретете новый способ мышления и будете разрабатывать поддерживаемое и надежное ПО. Легкого пути, к сожалению, нет.
Ответ написан
Если хотите улучшить качество кода:
1) Изучите книги "Рефакторинг" и "Совершенный код".
2) Тренируйтесь на CodeWars - старайтесь более понятный и чистый код. А потом сравните с решениями других участников, берите на вооружение, как можно было сделать лучше.
3) Изучите шаблоны проектирования.
4) Берите большие опенсорс-проекты с хорошей архитектурой и пробуйте что-то в них изменить, улучшить. В процессе изучите, как они спроектированы, невольно будете учиться и перенимать эффективные методы решения многих задач.
Ответ написан
Комментировать
Почитайте про SOLID. DRY и KISS.
Применяйте их к своему коду.
Небольшой трюк: код далеко не всегда и не у всех сразу родится красивым, обычно его рефакторят, при этом вовсе не обязательно получать неописуемую красоту, достаточно, чтобы получилось "нормально"
Ответ написан
zualex
@zualex
Senior Software Engineer
Для того чтобы повысить свой уровень, нужно найти свои недостатки.
Из-за этого я составил карту развития веб-разработчика https://github.com/zualex/devmap

Как мне кажется путь повышения своего уровня индивидуален. Опишу как было у меня

1) Работал в веб-студии, клепал сайты один за одним, стало очень скучно, возомнил себя крутым и решил пойти на повышение, после первого собеседования понял что я никто)
Level up - осознания того что ты не крут

2) Стал изучать и самое главное применять новые для меня технологии: git, laravel, gulp и т.д. Изучал постепенно, не набрасывался на всё сразу, что-то отпадало, что-то становилось бесценным инструментом.
Level up - осознание что нужно постоянно развиваться

3) Со временем ко мне стали постоянно обращаться если возникали проблемы, нужен был совет, начал проводить технические собеседования. Пришло понимание, что нужно расти в сторону управления командой. Стал очень много читать книги. Книги очень хорошо заходили, чувствовал огромную пользу от них.
Level up - чтение книг

4) Спустя время понял, что достиг потолка, начал ходить на собеседования, выявлялись разного рода недостатки.
Level up - ходить на собеседования

5) Новая работа, где устроенно все по другому (в хорошем смысле), новая команда, новые испытания
Level up - выход из зоны комфорта
Ответ написан
Комментировать
@imikh
Самое эффективное - работать в команде где делают код ревью синьёры. (Например, в нашей команде именно так).
Ответ написан
Комментировать
@di23
Топчетесь на месте? И простая практика не помогает?
Выйдите из зоны комфорта, прочь оттуда. Изучите что-то новое и интересное. ФП, SICP если еще не читали, какой-нить Haskell, Go.... Поиграйте в игрульку TIS-100. Купите Ардуинку. В общем разомните мозг.
Ответ написан
@xfg
Если говорим об ООП подходе, то прочитать книгу по DDD от Вон Вернона. Фактически автор описывает, как строить многоуровневую архитектуру, чтобы разделить кашу из бизнес-логики, работы с хранилищем, приложением и представлением, на отдельные слои с однонаправленным потоком данных. Книга задает вектор движения и позволяет минимизировать собственные творческие шатания из стороны в сторону, которые приводят в итоге к спагетти коду.
Ответ написан
Комментировать
SowingSadness
@SowingSadness
web-разработчик
Прочитайте что такое ООП, SOLID.
При чем вы должны понимать каждый термин строго. Чем отличается парадигма от принципа. Что такое полиморфизм и чем он отличается от параметрического. Что такое единая ответственность. Какие у нее критерии.

Как только вы почувствуете что понимаете каждый термин и как он на практике реалезуется, тогда удивитесь, на сколько ваш код стал лучше. Но на это уйдет много времени.
Ответ написан
Комментировать
Jeer
@Jeer
уверенный пользователь
Привет!
Фраза "я не могу в яваскрипт" очень общая. Хоть многие поливают говном этот волшебный язык, я считаю его одним из самых красивых и выразительных. Расскажу, как у меня было, начал на нём писать в явовской системе J2SE, где js был внутренним скриптовым языком (тогда же прочитал книгу с носорогом, самую популярную у начинающих, ну и не дочитал, мне нужен был только синтаксис). В работе были прям основные вещи: объявление переменных, циклы, условия, работа со списками. В принципе, задачи не сложные, всё решалось и ладно.
Затем была веб-разработка. Имея некие основные навыки включиться было не сложно. Возникаемые задачи решались гугл + стак оверфлоу. Но на выходе получалось, прям вот как вы говорите, некрасивый код. Поддержка его была, в основном, так называемым кастыльным программированием. Затем я прочитал книгу jQuery (o'really с Петром I на обложке), ну как прочитал, пролистал, можно сказать. И дело в том, что я узнал всего лишь больше jQuery-функций, вроде бы ничего, но для меня это было нечто новое. Я просто узнал, что можно делать не одним топорным способом, а есть еще и другие варианты. У меня даже запросы в гугл стали более изящными, более чёткими что ли. Затем я прочитал книгу "Графика на JavaScript" (всё тот же O'Really). Там интересные вначале оптимизации, но сама организация кода, я так никогда не делал и мне понравилось. Хотя я не занимался графикой, я просто хотел посмотреть на яваскрипт с другой стороны. И не прогадал. Тогда же наткнулся на статейку с хабра, ООП в яваскрипт. Таких статеек много, не знаю, какую читал именно я. Но объеденил что было в книге и пользуюсь по сей день. Повторюсь, я просто не знал, что так можно было.
После этого я решил посмотреть в сторону node.js, купил какую-то маленькую книжку, поигрался, понял, что всё сырое, что-то не понравилось, для себя поковырялся, ну и забросил. Но я опять не пожалел, что уделил этому своё какое-то свободное время :) после этого я стал разбираться в callback'ах, я до этого примерно знал, что это такое, но не работал с этим, никак не использовал. А тут узнал, что можно и так, и это вполне законно и это работает не только в ноде, но и в клиенте.
Теперь иногда только попадаются статейки с хабра или гт, в одной был продвинутый node.js, там рассказывалось, к примеру, про асинхронный код, promise и прочее. Сейчас я не пользуюсь этим, но хотя бы узнал, что так можно. И если мне что-то понадобится, я полезу в гугл, но теперь я хотя бы смогу сформулировать то, что хочу.
Еще недавно наткнулся на статью (приведу хоть одну ссылку) https://habrahabr.ru/post/154105/ - функциональное программирование в js. Раньше я из-за интереса смотрел что это такое, опять же, просто для себя, не очень понравилось, решил не тратить на это много времени. А тут вполне понятным языком, для чайников, да еще и на примерах яваскрипта. Я ни в коем случае не призываю становиться функциональщиком, я лишь говорю, что есть разные подходы и их нужно посмотреть хотя бы для ознакомления.
Подводя итог: практика необходима, она у меня была всегда, хотя js никогда не был моим основным языком. Книги нужны и книги важны, тут уже сказали, и мне очень нравится эта фраза "хотите быть писателем, много читайте". Посмотрите на язык с другой стороны. То есть, если вы занимаетесь клиентским js+jQuery, попробуйте написать игру на html5 (space invaders или др.), ну или другие варианты, примеры я привёл. Тематические рассылочки с хабра и gt позволяют держаться в тонусе. И самое последнее - упорство и время
Ответ написан
Комментировать
@Nwton
Хабр + практика.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Учитесь проектировать и правильно применять шаблоны проектирования.
Ответ написан
Комментировать
@MrCheater
Full-Stack JS. В прошлом программист-олимпиадник
Ответ носит общий характер для любой профессии: нужно просто ебашить, потратить 10.000 часов, оттачивая навыки.
Ответ написан
Комментировать
iCoderXXI
@iCoderXXI
React.JS/FrontEnd engineer
От 10 до 20 тысяч часов практики с постоянным самосовершенствованием, обязательно стараясь не наступать на одни и те же грабли в перспективе, с достаточным количеством здоровой лени, регулярно возвращаясь к своему коду былых лет.

Код надо стараться писать так, словно после тебя с ним будет работать психопат, который знает где ты живешь. :)
Ответ написан
Комментировать
@montecazazza
Node, GraphQL, React
Я бы порекомендовал вот что:
Изучить паттерны проектировани - это однозначно будет полезно
Изучить другую парадигму - если вы из ООП, изучите Функциональное программирование
Если пишите на JavaScript прочитайте что-нибудь на тему object composition vs class inheritance
Ну и конечно изучите что-нибудь на тему Алгоритмы и Структуры данных если с этой темой не знакомы

Из всего этого я бы выделил изучение нового подхода (Функционального) - по ходу изучения узнаете много интересного
Ответ написан
Комментировать
KMaxI
@KMaxI
Руководитель группы программистов
Попробуйте придумать свой стартап, или поучавствовать в чужом. Как правило решаемые в новых проектах задачи уникальны и интересны. И не зацикливайтесь на одном виде работы.
Ответ написан
Комментировать
@red-barbarian
мое мнение.
все банально)
хотите быть писателем, много читайте.
все хорошие книги типа "чистый код" это как теория. как должно быть и что делать. писать свой код очень полезно, но без критики (вычитки) можно писать, то что понятно себе и не понятно через год самому.
чтение хорошего чужого кода прививает, как говорят, вкус. незаметно.
ну и знать основы. например SOLID. эти принципы направлены на то что-бы разбить систему на максимально независимые и понятные части.
еще думаю полезно будет изучить ТДД. по моему очень полезно.
Ответ написан
Комментировать
@private_tm
JAVA dev
LeUDIC1aV7M.jpg
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы