Карьера
Alexey Laptev
10 859

Как нанимать и управлять программистами уровня junior и middle, не теряя месяцев времени

Всем привет! Я Лаптев Алексей, основатель и главный разработчик сервиса бесплатной сквозной аналитики и коллтрекинга Utmstat, а также Telegram-канала про сквозную аналитику. Сегодня расскажу, как работать с программистами на примере внутреннего регламента Utmstat.

В закладки
Пасет котов

Для кого статья

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

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

Проблема на рынке

Лебедь, рак и щука​

Есть цепочка: бизнес — менеджер — программист, и она работает по принципу испорченного телефона.

Бизнес просто хочет сайт/сервис/приложение и поручает менеджеру сделать.

Менеджер по-своему понимает задачу, говорит ее программисту, при этом не может адекватно оценить решение от программиста.

Программист по-своему понимает задачу менеджера и просто пишет красивый код.

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

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

Дисклеймер

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

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

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

Как нанимать программистов

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

Что нужно спрашивать на собеседовании

1. Просим показать предыдущие проекты и оцениваем их сложность.

Если у вас интернет-магазин и там интернет-магазины — хорошо, если простенькие ленды — плохо. Опыта нет.

То есть смотрим, чтобы сложность предыдущих проектов была примерно как у вас.

2. Смотрим примеры кода.

Если все более-менее по стандартным паттернам — хорошо, если какой-то креатив и видно, что даже про MVC не слышал, — плохо.

3. Смотрим на рабочее окружение.

Если это бэкенд-программист, например PHP, то его рабочими инструментами должны быть Ubuntu/MacOS и PHPStorm. Это наиболее эффективная связка.

Если там Windows, noname-opensource-ide и удаленный сервер — это звоночек, но шанс еще есть.

4. Вспоминаем сложные моменты из проекта и просим предложить их решение.

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

Если словами сложно объяснить, можно попросить набросать схему компонентов в Google Draw. Писать код не нужно.

Чего не надо требовать

1. Писать код

У верстальщиков, конечно, можно спросить, но если программист на пальцах рассказал решение, то он и код напишет.

2. Требовать точные знания каких то команд и синтаксиса

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

3. Требовать знания алгоритмов и другой лютой теории

В 99% случаев программисту нужна арифметика на уровне (a+b)/2, поэтому если в задачи программиста явно не входит разработка логики с высшей математикой и каких-то быстрых алгоритмов повышенной надежности, то не надо спрашивать, как работает пузырковая сортировка и прочую ерунду.

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

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

Итого

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

Типы программистов на рынке

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

1. И так сойдет, лишь бы работало здесь и сейчас

У них нет цели сделать хорошо, разобраться. Пишут как умеют. Лишь бы платили.

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

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

2. Религиозный фанатик

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

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

Надо быть готовым к долгим холиварам в чатах на тему, как делать правильно и почему.

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

3. Нормальный программист

Моя любимая категория.

Тут нормальный баланс фанатизма и пофигизма, работа идет ровно.

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

О чем нужно рассказать в первый день

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

Поэтому на всякий случай нужно настроить на нужную волну.

Целью разработки является

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

Целью разработки не является

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

Вот так

Что нужно понимать программисту, особенно новичку

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

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

Ежедневные правила работы

Цели правил

  • Ускорить процесс разработки продукта.

  • Минимизировать бесполезное общение в чатах.

  • Минимизировать бесполезные телодвижения команды в целом.
  • Минимизировать бардак в коде.
  • Дать план решения типовых задач новичкам.

Подготовка к работе

  • Поставить промышленную IDE уровня PHPStorm от IDEA (да, платная), никаких опен-сорcных и noname/online редакторов и VIM’a.
  • Синхронизировать настройки статического анализатора кода и автоформатирования
  • Поставить сервис скриншотов «Яндекс.Диск» (Windows) или CloudApp (Mac), чтобы не возиться с файлами. Это сервисы наиболее удобные. Все скриншоты пересылаются в виде ссылок, а не по схеме: скачал файл → нашел → отправил в чат. Вот как это работает — https://cl.ly/1b2ab0576ca3.

  • Поставить десктопную версию чата — Slack или Telegram.

  • Религиозных фанатиков уровня «я только за опенсорс», «я использую только %softname%», которые категорически не хотят переходить на объективно более производительные инструменты, можно сразу просить на выход, на практике толку от них мало.

Работа с GIT

  • Проект содержит две основные ветки — develop и master (продакшн) + задачи.
  • Каждый коммит содержит коммент в формате “#%номер задачи% — %что сделал%”.

  • Каждая задача в отдельной ветке.
  • По завершению, каждая задача проходит ревью кода и мержится в develop через pull request.

  • Каждый релиз в master теггируется кодом релиза, например r20191209.

Базовые принципы разработки

  • Твой красивый и каноничный код никому не нужен, «красивый» — код это следствие качественной работы, а не самоцель.

  • Твои длительные исследования никому не нужны, если не было на то явной задачи.

  • Лучший код — это его отсутствие. Постоянно задавай себе вопросы «Зачем?» и «Можно ли проще?».
  • Не надо заниматься программированием ради программирования.
  • Локальный разумный плохокод допустим, если есть ощутимая экономия времени и его можно причесать позже, без переписывания всей системы. Яркий пример — тесты.

  • Но плохоархитектура не допустима, она должна быть максимально продумана, чтобы нормально работать в условиях кривых локальных модулей и слабых разработчиков.
  • Держим статический анализатор кода зеленым.
  • Используем стандартное автоформатирование кода.
  • Каждая проблема на длинной дистанции должна решаться один раз (золотое правило).
  • В каждой проблеме нужно разбираться с точностью до строчки кода, никаких заверну в докер или переустановлю ОС/etc, авось пройдет. Пока нет ясной причины — нет и решения.
  • Каждую ошибку/проблему или значимое событие нужно логгировать в БД.

  • Важная функциональность должна быть покрыта тестами.

  • Тесты в релизной ветке должны работать.
  • Пиши стандартный код и используй возможности фреймворка на максимум, даже если это «не производительно».
  • Но при этом думай и закладывай возможность оптимизировать код под x1000 кратную нагрузку.
  • А еще думай, как твой код смотрится на фоне общего проекта — однотипно (хорошо) или жгучий креатив (плохо)?
  • Не занимайся преждевременной оптимизацией и не пиши низкоуровневый код без 100% уверенности, что это тут нужно, реальные узкие места покажет нагрузочный тест, вот тогда и будем усложнять. Если ты новичок — точно не пиши, без команды тимлида.
  • Не принимай решения, потому что кажется. Без метрик и чисел любые решения — пустая трата времени.

Что нужно иметь в виду в новом проекте

  • Не заниматься посторонними делами, если на это нет задачи — рефакторинг, исследования, переустановки. Все это приносит не пользу, а лишь финансовые и временные потери. Так как приходится корректировать планы релиза и работать сверхурочно, чтобы догнать план.
  • «Кривой код» может оказаться очень прямым, когда поймешь контекст использования.
  • Если код не в твоем стиле и он не нарушает грубо стандарты, это не значит, что он плохой.
  • Не правь чужой код, не понимая на 100%, что оно делает.

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

Работа с задачей

  • Должно быть 100% понимание смысла задачи.
  • В работе должна быть только одна задача или подзадача, фокусируйся, не распыляйся.
  • Делать ровно ту функциональность, что написана в задаче. Знаешь решение лучше? Сначала обсуди.
  • Все написанные модули покрывать тестами, как минимум проверкой, что модуль отвечает кодом 200 на типовые запросы и возвращает ожидаемый ответ.
  • Не заниматься рефакторингом и ненужными исследованиями в рамках задачи.
  • Не знаешь, как делать? Спроси.
  • Кривой код, хочешь рефакторить? Сначала спроси, потом исправляй.
  • Хочется глубоко исследовать тему на пару дней? Сначала спроси, потом исследуй
  • После выполнения задачи тесты должны работать.
  • После тебя сломались тесты? Немедленно исправляй.

Алгоритм поиска причины ошибки

  • Запустить код, который генерирует ошибку.
  • Посмотреть ошибку и stack-trace.

  • Посмотреть внутренние логи приложения.
  • Загуглить текст ошибки.
  • Просмотреть всю цепочку методов до ошибки и понять, чего там не хватает.
  • На все про все не более 30 минут.
  • Если ответ не найден — задаем вопрос тим-лиду.

Алгоритм исправления ошибки

  • Воспроизвести и ясно понять причины.

  • Если это Exception, вызванный работой пользователя, — покрыть тестом.

  • Написать тест, воспроизводящий ошибку.
  • Исправить ошибку.
  • Убедиться, что тест заработал при правильном сценарии.
  • Важно: исправляем причину ошибки, а не бездумно подгоняем код, чтобы ошибки не было, добавляя isset, try и так далее.

Как задавать вопросы тимлиду по логике кода

  • Сначала думаем сами, но не более 10 минут, если мыслей никаких.

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

  • Спрашиваем, что непонятно, с указанием строки кода или стрелками на скриншоте.

Как задавать вопрос тимлиду по ошибкам

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

  • Спрашиваем, что не понятно — с указанием строки кода или стрелками на скриншоте.

Какие вопросы не нужно задавать тимлиду

  • «За жизнь» в рабочее время.

  • Размытые вопросы уровня «Как делать задачу?». Начни делать и спрашивай конкретику, что не понятно.

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

Обязанности разработчика

  • Проявлять интерес к проекту.

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

  • В случае пробелов в знаниях — срочно их восполнять, в том числе в нерабочее время.
  • Если нет задач — сигнализировать об этом.
  • Если что-то не понятно — спрашивать, но сначала думать самому по установленному плану.

Обязанности тимлида/продуктовнера

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

Завершение рабочего дня

  • Проставить актуальный статус выполненных задач.
  • Отметить время.
  • Тезисно написать, что сделано внутри задач.

Итого

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Alexey Laptev", "author_type": "self", "tags": [], "comments": 62, "likes": 19, "favorites": 164, "is_advertisement": false, "subsite_label": "hr", "id": 96386, "is_wide": false, "is_ugc": true, "date": "Mon, 09 Dec 2019 11:23:24 +0300", "is_special": false }
0
{ "id": 96386, "author_id": 223450, "diff_limit": 1000, "urls": {"diff":"\/comments\/96386\/get","add":"\/comments\/96386\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/96386"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199121, "last_count_and_date": null }
62 комментария
Популярные
По порядку
Написать комментарий...
14

Очень субъективная статья, особенно что касается windows и phpstorm. Слишком популярное мнение, далекое от истины. Напоминает: "обязательно должно быть высшее образование".

Ответить
–6

Ну вы можете ценой своего времени и денег доказать обратное.

Ответить
7

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

Ответить
–4

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

Все эти оптимизации процесса экономят время и уменьшают срок разработки.

Разумеется если ваш продакшн это винда или ios, там другие требования, например наличие макбука для разработки на ios.

Ответить
3

но IDE к этому не так сильно привязано, тем более в статье вы сами пишете правильные вещи про линтер, пул реквесты и тд. Я работал на проекте где языком разработки был golang, как минимум я знаю, что люди писали код в vscode, emacs, goland от JB, idea + плагин. Но какая разница в чем код пишется, если есть код ревью, настроен строгий линтер, который фейлит билд.

Ответить
–4

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

Ответить
0

Ну а phpstorm здесь причем?) Практически любую ide можно под себя сделать. Какой смысл в phpstorm не зная 90% настроек, потому что утонул? Если есть, допустим, vs code, который ты сам построил и знаешь каждую hot key? Сам я на пхпшторме сижу, только очень много людей вокруг себя вижу, которые и половины возможностей этой ide не знают, так и напрашивается вопрос: "А зачем им пхпшторм?!".

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

Ответить
–1

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

Ответить
14

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

Ответить
0

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

Ответить
–2

Всех всегда стандартизируют. Только нормальные люди таких стандартизаторов сразу посылают

Ответить
2

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

Ответить
0

Я вам советую сначала понять чем команда отличается от стада

Ответить
0

Разумеется тем, что там можно все рабочее время тратить на переустановки ОС и обсуждение какое IDE использовать сегодня.

Ответить
0

Уже теплее

Ответить
0

На галерах проще

Ответить
1

Никогда еще Штирлиц не был так близок к провалу

Ответить
8

Поставить промышленную IDE уровня PHPStorm от IDEA (да, платная), никаких опен-сорcных и noname/online редакторов и VIM’a
@
Религиозных фанатиков уровня «я только за опенсорс», «я использую только %softname%», которые категорически не хотят переходить на объективно более производительные инструменты, можно сразу просить на выход, на практике толку от них мало

Ответить
0

А сможете внятно аргументировать, чем PHPStorm превосходит например Eclipse PDT ?

Ответить
5

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

Ответить
0

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

Ответить
4

плохокод

какой политкорректный термин применительно к своему коду :D

Ответить
1

В 99% случаев программисту нужна арифметика на уровне (a+b)/2, поэтому если в задачи программиста явно не входит разработка логики с высшей математикой и каких-то быстрых алгоритмов повышенной надежности, то не надо спрашивать, как работает пузырковая сортировка и прочую ерунду.

Так бы сразу и написал - "Как нанимать и управлять веб-макаками видов infans и adolescens".

Ответить
1

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

Ответить
0

Это ты же троллишь так, да? Арифметика?

Ответить
1

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

Поэтому я не тролю.

Ответить
0

Вроде здраво, про базовые нужные вещи, но даже нет упоминания Trello/Scrum. Почему?

Ответить
2

Это уже мелочи

Ответить
0

А я в винде, а сервер на Open Server. Особых проблем в стандартной связке PHP+XML+MySQL не заметил. Дополнения работают без особых проблем.

По поводу PHPStrom - очень тяжёлая и вязкая среда. Иной раз проще запустить N++ и поправить строчку, чем в течение трёх-пяти минут (в зависимости от объёма проекта на i3/8GB) запускать PHPStorm и что-то делать. Коммит сделать - секундное дело.

Если честно, то я бы с удовольствием подучился всему этому. Раньше был помощник в виде сеньора, но потом там резкий скачок и попросту не стало время. Помощь была лишь в том, что кидали актуальные задачи, которыми занимался в свободное время. Там есть где логикой позаниматься, освежить то, что подзабыл (чем не пользовался давно) с разбором после.

Ответить
1

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

Ответить
1

Полезно! :)

Ответить
0

Шторм сейчас умеет делать половину работы за программиста
и ускорять разработку раза в два. Так что очень рекомендую овладеть инструментом)

Ответить
0

Мне бы хотелось научить его и второй половине. :) У меня объём небольшой, поэтому глубоко не лезу.

Ответить
1

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

Поиск переменных и рефакторинг - маст хев.

Удаленная отладка с xdebug - маст хев.

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

База, ремоут сервак - и все это в одном месте! Продукт незаменим. Плюс во многих компаниях это де-факто стандарт и выдадут именно его. И пхпшторм как твои пальцы, а ты пианист - нужно понимать как и где тюнить его, тогда рояль заиграет. Не знаю почему все жалуются на его прожорливость - i7+32gb dd4 нынче не очень дорогие, даже в ноутбуках. Этого не только на него хватит, этого хватит на вообще все, кмк.

Я тоже долго сидел на сборке OpenServer, т.к. проста в установке и подключению доменов, но переехал на докер. Потому что:

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

б) OS не заставляет задумываться о том, как это все работает и конфигурируется. Как ставить нгинкс, как подружить его с пхп, как поставить базу, как прокинуть порты нестандартные, включить https и куда заливать сертификат. Просто когда с этим столкнетесь - впадете в ступор.

в) с докером деплой и работа на любой ОС вообще перестают быть проблемой.

Ответить
0

Подружить-то всё - не проблема. ;) Я в этом варюсь.
А вот по остальному - спасибо. Часть используется, часть ещё нет

Ответить
0

подружите три проекта, где зависимости перебивают друг друга. А интерпретатор у вас 7.4. А тут легаси-калище пришло на 5.4 :)

Ответить
0

Вы шутите? 4.4!
ЗЫ: как я замумукался тогда с самописной CMS... ошибку убрал, дорвей нашёл - убрал. И послал в известном направлении )))

Ответить
0

Удаленная отладка с xdebug - маст хев.

А сможете внятно аргументировать, чем xdebug превосходит например ZendDebugger ?

Ответить
0

Для профессиональной разработки нужно профессиональное железо и ничего не будет вязким. Иначе вместо задач будете заниматься не пойми чем.

Ответить
0

Уточните что за профессиональное железо, если на iMac эта связка запускается не быстрее?

Ответить
0

i7/16gb/ssd и более

Ответить
0

25% выигрыша по скорости. Проверял. Благо оборудование разное у меня тут под руками имеется. Хотя писать - да, удобнее в PHPStorm, но в последних ревизиях они фризов добавили знатно. :)

Ответить
0

В целом никаких проблем ни у кого, но вы уже в зоне риска )

Будете заниматься не задачами, а тестами noname редакторов, ведь шторм тормозит.

Ответить
0

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

Ответить
–1

Не понимаю о чем вы, тут задачи не раздают

Ответить
0

А жаль :)

Ответить
0

Странно как-то, у меня i3-8100, 16gb, SSD - запускается секунд 10 максимум (при первом открытии, если дополнительные окна с проектами то секунды 2-3). Да и запускать приходится не часто, комп почти всегда включен или в режиме ожидания

Ответить
0

"Типы программистов на рынке
Прежде чем перейдем к правилам, надо понять, для кого и почему они написаны.

1. И так сойдет, лишь бы работало здесь и сейчас

У них нет цели сделать хорошо, разобраться. Пишут как умеют. Лишь бы платили."

Не растолкуете, что именно подразумевается, типа сайта на бесплатном/платном конструкторе, еще и с кучей плагинов-костылей, когда программист то и не нужен совсем?

Ответить
1

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

Ответить
0

А если хочется сделать рефакторинг, не из-за того что просто хочется, а из-за того что КПД добавления фич уменьшился настолько, что проще почти с нуля все написать. 

Какой тогда приоритет у такого рефакторинга по сравнению с новыми задачами?

Ответить
1

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

Ответить
0

 Если там Windows, noname-opensource-ide и удаленный сервер - это звоночек, но шанс еще есть. 

Сижу на Windows, Ubuntu из под Docker. Лучше уточнить в таком ключе: разработчик должен базово уметь работать со средой, в которой будет хоститься.
К тому же, если речь про бэкендера на C#, там без Windows не то. IIS, все дела.

Ответить
–1

Да

Ответить
0

(удалено)

Ответить
0

 Поставить промышленную IDE уровня PHPStorm от IDEA (да, платная)

А сможете внятно аргументировать, чем PHPStorm (всегда платный) превосходит например (иногда бесплатный) Zend Studio?

Ответить
0

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

Ответить
0

За что на вим то так :(

Ответить
0

потому что :q!

Ответить
0

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

Ответить
0

Согласен

Ответить
0

Не хватает еще обязанностей работодателя, чтобы картина сложилась целостная))))

Ответить
–2

Интересная статья! Я новичок. У меня винда. PHP Storm кушает много оперативы и моему компу сложно)))) Использую Netbeans

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } }, { "id": 20, "label": "Кнопка в сайдбаре", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cgxmr", "p2": "gnwc" } } } ] { "page_type": "default" }