• Notepad ++ - перенос текста в одну строку

    k12th
    @k12th
    console.log(`You're pulling my leg, right?`);
    Edit —> Line operations —> Join lines
    Ответ написан
    Комментировать
  • Нужны ли знания серверов?

    opium
    @opium
    Просто люблю качественно работать
    Они все заказывают админов
    Вы не поверите все крупные компании нанимают уборщиц которые имеют доступ ко всем помещениям этих компаний
    Ответ написан
    2 комментария
  • Меньше стек технологий, больше шанс устроиться на удаленную работу?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Сколько видел вакансий - везде стопицот непохожих требований, а когда доходит до собеседований и тестовых заданий, то всплывает еще стопицот сюрпризов.

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

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

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

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

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

    С 2015 года я положил глаз на full-stack JavaScript и потихоньку развиваюсь в данном направлении. Тренды таковы, что все больше вакансий и прочих предложений будут так или иначе именно в эту сторону. Одно меня печалит, пока что рынок фронтенда держит angular 1.x, но, думаю, это временно.
    Ответ написан
    3 комментария
  • Меньше стек технологий, больше шанс устроиться на удаленную работу?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Меньше стек технологий, больше шанс устроиться на удаленную работу?

    Вовсе. Шанс устроиться на работу определяется качеством знаний И умением себя преподнести, а не маленьким стеком технологий.

    Понимаю, что со временем разработчик "обрастает" знаниями и навыками, описанными выше, но на начальном уровне зачем такое?

    Рынок юниоров перегрет. Найти самую первую работу "за еду" - это уже хорошо. Вначале ваша цель должна быть опыт. А дальше цена ваших услуг с точки зрения работодателя будет на прямую зависеть от качества ваших знаний и опыта.
    Приведу пример. N лет назад общаясь с коллегами возник вопрос: кто в скольких проектах участвовал? На тот момент у меня накопилось около 15 (тогда я был твердым мидлом), у моего коллеги более 300 (слабенький юниор). Возник резонный вопрос: "что так?". Оказалось его проекты в основном сайты-визитки и роста на них (как специалиста) не было.

    Подскажите, от какого программиста(ЯП) требуется минимум технологий на начальном уровне, чтобы устроиться на работу?

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

    Учишь "ЯП" -> "технология1", "технология2", "технология3" -> проходишь собеседование -> Profit!!!

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

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

    Wolfnsex
    @Wolfnsex Куратор тега PHP
    Если не хочешь быть первым - не вставай в очередь!
    Фреймворков в целом, которые достигли должного уровня популярности и народного признания - не так уж много (если говорить о PHP-фреймворках).

    Для начинающего, с целью понять сущность MVC, "пощупать" некоторые аспекты фреймворка, такие например, как загрузка библиотек и пр. подобности, я бы порекомендовал Вам CodeIgniter. Отличная документация, довольно много людей, кто сможет Вам ответить на возникающие вопросы, есть документация на русском. А так же, минимальное количество "лишнего" из коробки, например, шаблонизаторов (которые Вы можете самостоятельно подключить, если очень хочется).

    После этого фреймворка, промежуточным, можно было бы считать Kohana, но, он что-то то "умирает", то снова "воскресает"... С документацией на него, по моему, всё так же плохо (читай "не очень хорошо") как и всегда... но, по нему есть несколько неплохих видео-уроков.

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

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

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

    P.S. Я понимаю, что Вы спрашивали "какой фреймворк учить первым?", а не какие они бывают вообще. Но, дабы предостеречь Вам от вопросов типа "какой фреймворк учить вторым?" или "почему Symfony в роли первого фреймворка так тяжело изучать?" и массы прочих подобных - озвучил одни из самых популярных фреймворков в мире веб-разработок в ракурсе PHP.
    Ответ написан
    1 комментарий
  • Существует ли "карта программиста"? Что и за чем учить?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Я в начале 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...
    Ответ написан
    1 комментарий
  • Что нужно знать php разработчику для изучения фреймворка? Ваше мнение?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    За любым фреймворком лежит опыт и мировоззрение его разработчиков. У любого фреймворка есть глубинная философия, его смысл, для чего он создан, какие проблемы решает, в каком контексте. Не смотря на то, что, казалось бы, разные фреймворки решают набор примерно одних и тех же проблем, делают они это очень по разному.

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

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

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

    И вот тут, чтобы действительно справляться, необходимо ПОНИМАТЬ, как это работает, почему так а не иначе, и как с помощью этого решать поставленные задачи. Если чего-то не хватает, или оно работает не так как надо, а это весьма частые явления, то ПОНИМАНИЕ процессов дает свободу РЕШАТЬ эти тупиковые, казалось бы, вопросы.

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

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

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

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

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

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

    Сейчас же я взял паузу, и намерен полностью мигрировать с PHP на JavaScript. При всей моей любви и уважении к PHP, в нем определенные вещи даются слишком большими усилиями, так-что игра не стоит свечей.
    Ответ написан
    1 комментарий
  • Стоит ли начинать заниматься программированием в 30+ если до этого не программировал?

    opium
    @opium
    Просто люблю качественно работать
    Вы так говорите как будто в 30 лет у вас нет рук и ног и вывалился глаз.
    Берите и делайте и меньше задавайте глупых вопросов на тостере.
    Ответ написан
    5 комментариев
  • Возможные варианты приложения для портфолио Junior Android Developer?

    Вот это смотрел? Можешь усложнить приложения и добавить какие-нибудь фичи. Если тебе нужны именно идеи, товот большой список. Или здесь на тостере. Смотри что тебе по силам.
    Ну а вообще, все зависит от канторы, в которую хочешь устроиться. Где сойдет хорошая теория + простенький tcp-чатик, а где-то могут спросить более сложные программы и тонкости архитектуры.
    Ответ написан
    2 комментария
  • Как понять суть программирования (подробнее в содержании)?

    @gatoazul
    Откройте среду Scratch и погоняйте кота в разные стороны экрана. Так вы быстро поймете, что такое программирование и нужно ли оно вам.
    Ответ написан
    Комментировать
  • Какие существуют способы защиты стилей CSS?

    opium
    @opium
    Просто люблю качественно работать
    мне кажется мания величия затмила ваш мозг глупейшими проблемами, вместо того чтобы код красиво оформить и выкладывать на гитхаб и делиться им, вы решили его зачем то прятать, просто задумайтесь, что хорошего вы сделали в жизни и почему не выкладываете его на гитхаб?
    Ответ написан
    11 комментариев
  • Как отучить стажёра от говнокода?

    @Slonoed
    Нормально, нормально. Это пройдет.
    Сейчас просто у него период эйфории — ух ты, я программы умею писать!
    Сам таким был вначале.
    Просто пока выбрасывайте весь его код.
    Надо мягко пока показывать правильный (свой) код
    и обсуждать с ним его.
    Ответ написан
    Комментировать
  • Как отучить стажёра от говнокода?

    @Alexznadr
    (Есть шанс, что вы взяли «не того» стажера. Судя по вашим комментариям выше я понял что опыт в программировании у него 0. И дело не в наличии/отсутсвии «опыта работы», а в том, что человек которому интересно этим заниматься — часто пишет программы «для себя». «Сильный интерес» — это одно из главных слагаемых успеха, а самостоятельно написанные хобби-программы — как раз признак наличия интереса.)

    Как с ним работать (особенно хорошо если сроков жестких нет)
    Cформулировать задание (желательно связанное с программированием, а не с изменением width:200px на wiidth 300px в css файле) (скорей всего на первых порах оно будет связано с процедурным программированием), попросить подумать над решением и (т.к. опыт 0) и записать его своими словами на листе бумаги/в текстовом файле в виде словесного описания алгоритма.
    Как будет готов — вы просматриваете что он придумал. В этот момент вы сможете увидеть места в которых он пытается реализовать билиотечные функции и для этих мест посоветуете ему ознакомиться с соответсвующей документацией. Кроме того если в этот момент вы видите что получается ерунда, можно или наводящими вопросами подвести его к правильной мысли. Или если вопрос достаточно сложен — предложить свой вараинт и спросить что он по этому поводу думает: достоинства-недостатки-что-лучше.
    Как только оно алгоритм скорректирован — ему останется просто, пользуясь словарём, перевести с одного языка на другой.

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

    ООП. Если вы уверены что у вас правильное ООП и оно вам действительно нужно, то «когда придёт время», то предварительно пусть ознакомится с принципами SOLID и основами UML (диаграммы классов, объектов, последовательностей) — этом поможет вам обсуждать архитектурные решения. А дальше тоже самое: формулируется задание. Он его обдумывает, рассазывает как решил делать декомпозицию и почему. Вы предлагаете свой вариант. Всё это обсуждается опираясь на принципы SOLID.

    Вот примерно так. Не позволяем себе высокомерия и фразочек вроде «чему вас только в институте учат» и «ну кто так пишет», не забываем хвалить когда он всё делает правильно.

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

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

    А если конструктивно, то долбить, долбить и долбить, как правильно писать код. Парное программирование, код ревью и прочее. Повторение — мать учения.
    Ну и книги какие-то вручить. Например, классический Code Complete.

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

    Nordvind
    @Nordvind
    Интересная практика. Не думал, что в стажеры берут человека, абсолютно не знакомого с программированием. Вместе с тем, что уже было высказано, советую дать почитать собственно статьи про говнокод (на лурке неплохая) и посмотреть презентацию А.Солнцева «WTF Code» http://www.devclub.eu/2010/08/13/video-wtf-code/.
    Объясните, что код надо не только писать, но и сопровождать, в конце концов.
    Ответ написан
    Комментировать
  • Как отучить стажёра от говнокода?

    @warbinox
    я думаю ничего не нужно вообще делать, пусть пишет полсотни строк вместо одной, главное чтобы задача решалась, а со временем придет и опыт и лень :) приободрите, включите в проект, только поддерживать эту часть оставьте его же, когда придет время что-то исправлять или дополнять, он сам все поймет.
    а идеального кода не существует, кто сказал что вашу задачу в 1 строку нельзя решить за половину? или вообще переписать этот кусок чтобы ее не было? вариантов масса, дайте человеку думать самому и решать :)
    Ответ написан
    2 комментария
  • Как отучить стажёра от говнокода?

    @nldr
    Если стажер работает меньше 3-х месяцев, то у вас отличный стажер.
    Главное уметь решать задачи. А как это делать эффективнее придет с опытом. Я например очень страдаю от того, что вместо решений в лоб, те же 4 часа сижу и думаю как написать за 5 минут в 1 строчку.
    Ответ написан
    1 комментарий
  • Как отучить стажёра от говнокода?

    Я думаю, что регулярки он не понял, из-за того, что ето совсем другая для него вселенная. Ведь посмотрите на это реально, он новичёк, он хотел справиться с задачей => хорошо! НО!!! Если бы вы ему дали «лёгкий» мануал по автоматам и гарматикам, он бы понял, что такое preg_функции. К сожалению я думаю, что preg_функции нельзя хотеть от новичков сразу, там надо немного вникнуть в проблему. ;-)
    Да и вообще, я в ВУЗе автоматы 2 года подряд сдавал, так что знаю, что это за хрень.
    Может он себя плохо чувствует, давление, итд?.. Обясните ему, что у него много времени, и что програмированние, это 60% поиска, 30% мозговой активности и 10 написания кода… Я думаю, что главное, чтобы старался!
    Ответ написан
    5 комментариев