Ответы пользователя по тегу IT-образование
  • Как учиться алгоритмизации? И стоит ли?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Я на кодварсе гоняю желающих вкачать алгоритмы и структуры данных, хотя бы до 4 кью надо вкачаться имхо.

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

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Всё, что умеет компьютер - это взять данные "там-то", что-то вычислить, положить или отправить "туда-то"... Весь сложный функционал крутится вокруг этих простых функций. Поэтому без структур данных и алгоритмов никуда.

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

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

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

    В целом это и есть процесс программирования. И тут нужно 99% упорной практики и щепотка теории.

    Если достаточно упорно и долго практиковать, то со временем, многие решения уйдут на подкорку и будут получаться автоматически, не задумываясь, тогда можно переключаться на более сложные абстракции, типа паттернов и пр.
    Ответ написан
  • PHP+JS Трудности с выбором учебно-боевого проекта?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Если нет опыта успешного и эффективного решения олимпиадных задач, то ситуация патовая.
    Ответ написан
  • Как вы учите программирование?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Ты наивно полагаешь, что в программировании нет рутины? Её там есть, вагонами. Из сотни проектов дай Бог 3-4 будут увлекательными, всё остальное легаси с костылями вместо архитектуры.

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

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

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

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

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

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

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

    Если нужно вставить пистон и промыть мозг, стучись в скайп. :)
    Ответ написан
  • Как учиться фронтенду?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Фронтенду учатся точно так же, как и любому другому занятию - усваивают контексты и отрабатывают их на практике. Проблема заключается в том, что современный фронтенд сделал огромнейший рывок в сторону энтерпрайза и дичайше усложнился в последние несколько лет. Парить себе мозг jQuery не рекомендую, сейчас куда как важнее уметь на голой ванильке. Раз есть опыт на С++, то очень хорошо, но какой именно опыт - очень большой вопрос. Сегодня во фронтенде без алгоритмов и структур данных делать нечего. Я обычно за этим отправляю на кодварс решать задачки.
    Ответ написан
  • Какой путь изучения программирования выбрать?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Ухх как все сложно...

    Чтобы научиться плавать нужно, для начала, зайти в воду... Стоя на берегу плавать учиться затруднительно.

    Если бы я так заморачивался в своё время, то даже не начал бы.

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

    Одновременно нужно подучить язык, на котором будешь программировать. Как по мне, самый простой для освоения язык сегодня - это JavaScript. Нужно зарешать хотя бы 50-100 задачек, этим ты покроешь основные кейсы, чего для начала более чем достаточно. Я обычно отправляю с этим на кодварс.

    Далее нужно научиться рекурсивной декомпозиции. Софт скиллы решают, потому что далеко не всегда тебе будут сгружать продуманное готовое задание. Гораздо чаще тебе придется выяснять, задавать наводящие вопросы, уточнять, переуточнять.

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

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

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

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

    Вот как-то так. Дорогу осилит идущий, но нужно постоянно делать следующий шаг.

    Ну и напоследок - в программировании очень решает оперативная память. Нужно в голове удерживать массу фактов одновременно, иначе получается фигня. Поэтому прокачивай оперативную память...
    Ответ написан
  • Есть ли хорошие источники для изучения ReactJS?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Всё зависит от твоего предыдущего опыта. Если ты уверенно умеешь программировать на любом языке, это одно дело. Если нет - другое. Если ты уверенно чувствуешь себя во фронтенде и можешь, в принципе, решать задачи на голом html+css+js, это одно. Если нет - другое.

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

    А вот если на один из вопросов выше ты ответил отрицательно, то в реакт тебе пока рано, и надо подтягивать базу.
    Ответ написан
  • Программирование - что для старта выучить ребенку?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Я начал в 13, сам. Причем до этого попробовал разные компьютерные игры - не зашло.

    В некотором смысле программирование - это авторитарная диктатура. Я диктую машине что делать, а она выполняет моментально и беспрекословно. Или не выполняет, если я натупил... Пёрло меня с этого нипадецки. Плюс никто не объяснил вовремя, что это трындец как сложно. А потом стало получаться...

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

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

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

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    ИМХО лучший клавиатурный тренажер всех времен и народов у Шахиджаняна, давным давно когда я этим вопросом интересовался он назывался "Соло на клавиатуре". Вроде нынче существует онлайн версия.
    Ответ написан
  • Поможете выбрать ресурс по изучению JS?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Я наставничаю в той самой htmlacademy, и частенько студенты приходят, не умеющие программировать от слова совсем. Им курс дается тяжело, приходится их вытягивать буквально за жабры и разжевывать все мелочи, что, в целом, в мои обязанности и не входит вовсе.

    Поэтому перед академией я настоятельно рекомендую на три круга прослушать под запись курсы Zorax Или JavaScript weird parts на ютубе, почитать/послушать Кантора, это раз.

    Прорешать 30-40 задачек на кодварс (я там прокачиваю некоторых своих студентов), это два.

    И вот уже после этого идти в академию, тогда от курса будет максимальный толк и отдача.
    Ответ написан
  • Как (и возможно ли) дотянуться до Junior JavaScript Developer в кратчайшие сроки?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Во первых: совершенству нет предела.
    Во вторых: невозможно объять необъятное и впихнуть невпихуемое.
    В третьих: как ты не крутись, а технологии развиваются быстрее, поэтому отставание неминуемо, как следствие приходится всегда чем-то жертвовать ради чего-то более важного.

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

    Джуниористость/синьористость конкретного разработчика - штука весьма условно субъективная. На собственном опыте скажу, что одно дело, когда ты первый и единственный парень на деревне - ты почти что бог, потом с той же головой, теми же руками, опытом и знаниями оказываешься в среде подобных себе, разной степени синьористости божков, и, внезапно, ты сырой джун но с очень хорошим потенциалом.

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

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

    Меня на программирование пропёрло весьма рано, лет в 14-15. Я ощущал собственное безграничное могущество, послушная железяка выполняла любое моё повеление, любой мой каприз, при условии, что он правильно сформулирован. Если железка не делала что нужно, или делала что не нужно, то это всегда была моя вина, это значило что я прокосячился. Подобное осознание настигло меня весьма скоропалительно, после чего мозг начал усиленно дисциплинироваться, и количество лютых фейлов пошло на убыль.

    Коммерческая разработка - это, примерно, от 70% времени/сил на дебаг и фиксы, потому что мало где процессы поставлены грамотно. По хорошему до сего дня (а мне под 40) я только одну команду видел, где процессы прям вообще очень хорошо поставлены и мне посчастливилось какое-то время с ними поработать. За эти несколько месяцев я подрос на целую голову. Самостоятельно достичь сходных результатов было бы весьма затруднительно.

    Сам я сменил стек совсем недавно, начал в конце 15 года, и процесс продолжается до сих пор. Сменил я по одной простой причине - во всех моих прежних проектах большая часть логики с бэка уехала на фронт, и прекраснейший jQuery перестал справляться чуть более чем полностью. Он, по прежнему, хорош, но задачи, которые приходится решать, требуют совершенно других подходов. Для себя я выбрал React, но в целом на рынке имеются альтернативы. По моим данным очень большим спросом пользуется Angular 2+.

    Когда говорят о фронтенд разработке, постоянно говорят о технологиях, стеке, но почти никто не упоминает, что не стеком единым... Существенная часть разработки - это, для начала, понять задачу и построить у себя в голове модель. Заказчики бывают разные, от очень толковых, до очень безтолковых. Соотношение первых ко вторым примерно 1% и всё остальное... Т.е. в большинстве случаев тебе скажут минимум, своеобразно, плюс ты это поймёшь по своему. Потом, по ходу пьесы, в самые неподходящие моменты, начнут всплывать подробности, которые: забыли упомянуть; ну это же очевидно, ты же профи; мы сами не знали, это только выяснилось; ну это же мелочи, мы думаем тебе это будет не сложно; а ты не спрашивал; и т.п....

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

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

    Если ты попадешь в команду, где люди будут понимающие, квалифицированные, процессы выстроены, а джуну задачи будут сгружать джунские, то, считай, тебе крупно повезло. Шансов на это примерно 1%. Особенно учитывая, что джуны это обычно студенты лет в районе 20...

    Когда я менял стек, то я тоже был какое-то время 35-летним джуном. С этим ничего не поделать, потому что, внезапно, стек это не просто так, и имеется масса нюансов, которые с наскоку не освоишь. Чтобы все пощупать, попробовать на зубок, понять и осознать требуется время и усилия, иногда много времени и много усилий. Да, весь прежний багаж служит опорой и поддержкой, и там, где настоящий джун будет копаться недели, ты за пару часов по аналогии поймаешь идею и двинешь дальше. Но эти пару часов никто не отменял, а идей которые нужно отловить сотни, если не тысячи...

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

    Даже если тебе попадается практически идеальный проект, внезапно оказывается, что твоя оперативная память это 5-7+-2 объекта, а удерживать в голове одновременно нужно сотни...

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

    Термин "фигак-фигак и в продакшен" встречается повсеместно, т.к. ресурсы (деньги, время, кадры) практически всегда весьма жестко ограничены и ничего ты с этим не поделаешь.

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

    С другой стороны сейчас предпочитают фронта, который еще и неплохо верстает. Слава флексбоксам и современным браузерам, сейчас это делать намного проще, чем годы назад.

    Теперь относительно того что делать - если в бэкграунде нет сильных скиллов по алгоритмике и структурам данных (олимпиады по программированию, универский курс информатики), то прям очень сильно рекомендую прокачать. Будучи наставником на нескольких курсах фронтенда я постоянно встречают студентов, которые "вроде бы" знают язык, но затрудняются скомпоновать пару циклов с условиями, вот буквально просто виснут на неопределенное время, причем без результата. Лично я рекомендую кодварс. Своих студентов я прокачиваю именно там. Достаточно прорешать 30-40 задачек, чтобы базовые скиллы ушли на уровень рефлексов и перестали парить мозг. Правда желательно решать это все с наставником.

    Косвенный бонус тут будет в том, что ты привыкнешь решать задачи на JavaScript. Я когда менял стек, поначалу мыслил на PHP, и подобный финт на кодварс позволил мне переформатировать мышление на JS. Вот мой профиль на кодварс как пруф: https://www.codewars.com/users/iCoderXXI

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

    Понять надо настолько глубоко, чтобы легко и просто, с юморком, рассказывать это любой первой встречной бабушке, да так, чтобы та всё поняла... Это вот прям залог успеха в JS, потому что все остальное держится на этих двух китах. В ютубе имеется курс Зоракса (Zorax) и JavaScript Weird Parts, оба про то же самое, первый на русском, второй на инглише. Кантор, безусловно, крут, но эти двое объясняют попроще и понятнее (имхо).

    После этого прокачиваемся в использовании встроенных методов JS, таких как map, reduce, includes, replace и пр. (на том же кодварс)

    После этого нужно прокачаться в ES6+, стрелочные функции, let/const, деструктурирование, рест оператор, классы, промисы, генераторы, async/await, декораторы - без этих продвинутых штук в современных фреймворках ловить нечего.

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

    Потом уже заостряемся на API форм, DOM, AJAX (fetch/axios), вебсокетах, Localstorage и пр.

    И вот только теперь можно переключаться на фреймворки. Проще всего освоить Vue (по слухам), наибольшим спросом пользуются React и Angular, для общего развития так же неплохо бы немного послушать про Ember.JS.

    React только на первый взгляд выглядит простым, на самом деле это только view-библиотека, а в любом нормальном SPA есть много чего еще кроме view, поэтому React всегда идет в компании Redux, Router, и еще целой толпы всего, что тоже придется осваивать, не только с точки зрения API, но и с точки зрения философии (а нахрена оно вообще сдалось?)

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

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

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

    Еще вроде большие компании вроде Яндекса устраивают летнее обучение, с последующим трудоустройством лучших кандидатов, но это не точно.

    Оптимистичный прогноз - 6-12 месяцев плотного фигачинга и ты в тренде.
    Ответ написан
  • C чего начать изучение JavaScript опытному верстальщику?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Знать как следует язык программирования, безусловно, штука весьма полезная и нужная.

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

    Поэтому окромя языка я бы настоятельно рекомендовал от души попрактиковаться в структурах данных, алгоритмах и паттернах. Тут, как говорится, нужно наработать минимум 1000 часов, чтобы навык ушел на уровень рефлексов и работал автоматически. А совершенствовать скиллы ты будешь всю оставшуюся жизнь, ибо нет предела совершенству.

    По части именно JavaScript вот этот курс отлично мне поставил мозги на место в своё время https://www.youtube.com/watch?v=bzuelEN1Kg8&list=P... прям аж до просветления.
    Ответ написан
  • Польза от codewars?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Когда решил что основным ЯП у меня теперь будет JS, надо было переформатировать мозги, для этого сотню-другую часов интенсивно что-то кодить, не важно что, важно чтобы на JS и в хорошем темпе.

    Тут, как раз, Кодварс подвернулся. Прокачался до 2.5 qyu и подзабросил, но эффект получил должный, теперь на php кодить не так комфортно (иногда совсем не так).

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

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

    в общем для меня кодварс оказался весьма приятным и эффективным способом привыкнуть к ЯП.
    Ответ написан
  • Как быстро погрузиться в react?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Проще всего научиться на практике. Я нашел несколько годных скринкастов и повторял 1 в 1 за ведущим. Вообще всегда так делал с новым языком.

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

    Одна проблема в том, что реакт бурно развивается, и огромное множество материалов по нему уже устарели, т.е. ты будешь учиться тому, что уже не актуально. Поэтому ищи материалы не старше года, в идеале не старше 6 месяцев.
    Ответ написан
  • Как бороться с прокрастинацией?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Прокрастинация, это когда штурвал перехватывает внутренняя макака.

    Макака, в отличии от человека разумного, эволюционировала миллионы лет, является очень энергоэффективной, поэтому чуть-что, мозг сразу врубает макаку.

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

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

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

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

    Ну а если уж совсем дело швах, то надо выпускать большое, страшное, мохнатое чудище, тогда макака бросает штурвал. Еще макака уходит на покой где-то часа в 3 ночи, так-что если досидеть, то отпускает и можно до утра поработать... Правда это вариант нестабильный.
    Ответ написан
  • Как учить что-то новое и быстро не забывать?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Я всегда учу только самый необходимый минимум, исходя из принципа Парето, что 20% усилий дают 80% результата. Зачастую этих 80% результата за глаза хватает для большинства задач.

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

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

    Так-что я рекомендовал бы каждый навык оттачивать в конкретном модуле, на практике, в разных обстоятельствах, тогда в голове уложатся принципы и примерное представление, где, если потребуется, быстро найти детали и нюансы...
    Ответ написан
  • Существует ли "карта программиста"? Что и за чем учить?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Нет одинаково эффективного пути для всех и каждого.

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

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

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

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

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

    На первых порах, тестирование будет занимать до 99% времени и сил. Заодно подтягивается синтаксис используемых языков (вообще не важно каких), вырабатывается внимательность, концентрация, тренируется память и пр.

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

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

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

    Обрати внимание, самое главное качество во всем этом многабукафф - упорство на грани фантастики. Любой, кто не дойдет до конца, не треснет себя по лбу в соты раз с воплем, так вот же она где, эта запятая, пропущена - сломается в самый неподходящий момент на боевом проекте...

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

    Ах да, обложись справочниками по любому инструменту и научись быстро вникать и подхватывать необходимый минимум. Обычно достаточно на 20% владеть инструментом, чтобы решать 80% задач.

    В любом случае я за критерий истины держу платежеспособный спрос.
    Ответ написан
  • Что умеет настоящий senior/lead developer кроме знания какого-то языка и его фреймворков?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Нужен разнообразный боевой опыт на десятках проектов, который заработаешь только по ходу практики. Все остальное - инструменты и декорации. Не так важно чем. Важно чтобы работало и не падало.

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

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

    В общем главное тут - напористое желание решать стопицот новых и неведомых проблем каждый день в штатном режиме, в порядке обыкновения.
    Ответ написан
  • Как развиваться начинающему web-разработчику?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd developer
    Я в начале 2000-х писал приложение для учета некоммунальных услуг ЖКХ для местного МУПа. Начинался этот проект как тестовое задание для приема на работу.

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

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

    Забегая вперед скажу, что автоматизация, в конце концов, удалась, из режима работы 3 человека по 8 часов в день 6 дней в неделю, за 6 месяцев после начала внедрения, вышли в режим 1 человек 2 часа в день 5 дней в неделю... Т.е. 3*8*6*4 = 576 человеко-часов превратилось в 2*5*4 = 40 ч/ч, КПД был увеличен в 14.4 раза.

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

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

    Далее я реализовывал эти пути как разумел и предоставлял тётушкам.

    И о чудо, обычно на этом этапе прорезался дар речи (тётушки, как все нормальные люди, обожают критиковать то, что по их мнению "не так"), и на меня начинал сыпаться поток весьма конкретных и ёмких ЦУ (ценных указаний), которые я подробно документировал и впоследствии претворял в жизнь.

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

    Первые месяцы они вели двойной учет, по старинке в своей огромной бухгалтерской книге, и в программе, и программу проверяли по книге. Через 2-3 месяца они убедились, что в программе "цифры" точнее, ошибки отлавливаются быстрее, меньшими усилиями, и стали уже свою книгу проверять по программе. Через 5-6 месяцев я написал им модуль расчета и распечатки месячного отчета, и они перестали вести свою книгу, просто печатали ее каждый месяц на огромном матричном принтере.

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

    Условно можно разделить основной функционал приложения на 2 фазы - ввод/редактирование/просмотр данных и построение отчетов/выборок. С отчетами и выборками тёмный лес, т.к. требования меняются непредсказуемым образом любое количество раз в году (по началу), а вот с вводом и редактированием данных в целом ситуация стабильная, тем более за предыдущие 3 версии я достаточно хорошо исследовал этот процесс.

    Ввод/редактирование данных осуществляется посредством форм, которые, в общем случае, повторяют структуру таблицы БД, за исключением случаев, когда присоединяются поля из справочников.

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

    Первейшая проблема программ на Clipper 5.x это банальное отсутствие таблиц БД, либо слетевшие индексы. Это первое, чем я озаботился. программа при запуске проверяет наличие или отсутствие таблиц и индексов, и чего не хватает - достраивает на лету. Таким образом можно потерять данные, но программа, все равно, работать будет. Чтобы это стало возможным, потребовалось в программе прописать структуры таблиц БД и индексов.

    Вторым этапом, дико устав копипастить на 95% совпадающий код для построения форм, а, потом, когда надо что-то поменять, добавить или исправить, шариться по тоннам на 95% идентичного кода в сотне мест, я решил прибиться к стану метапрограммирования.

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

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

    Причем генератор грамотно отрабатывал множественную вложенность, и каждый вызываемый справочник имел полный функционал CRU (Create, Read, Update), включая фильтрацию по столбцам и сортировку.

    Таким образом я создал мощный и гибкий генератор интерфейсов, а разработка CRU-части приложения сводилась к разработке описания структур таблиц, индексов и метаописания форм.

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

    Для реализации этого функционала пришлось пропатчить стандартный грид TBrowse (он применяется для просмотра таблиц).

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

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

    P.S.: когда я мигрировал в веб, через некоторое время я снова вынужден был пройти аналогичный путь, в результате которого родился простенький AJAX-фреймворк на стеке PHP+Smarty+DBSimple+jQuery. Сегодня я всеми силами стараюсь от него уйти, хотя для своих задач он достаточно хорош. Был опыт, когда на шареном хостинге за 5 баксов проект на этом фреймворке со скрипом но держал 30-40 тысяч уников в сутки (после ряда оптимизаций) и достаточно хорошо был защищен от топорного взлома через SQL-инъекции благодаря DBSimple...
    Ответ написан