​Kanban

Еще одна популярная методология Agile — это канбан. В отличие от скрама канбан фокусируется не на спринтах, а на задачах.
Главная составляющая — доска с разделами todo, develop, test, deploy и дальше по вкусу. Задачи могут подкидываться и меняться каждый день, а оценка таски по времени не так важна, потому что не нужно рассчитывать сколько задач будет выполнено за спринт.

Таким образом Kanban еще более гибок, чем Scrum. Мне понравилось сравнение: скрам — это автобус, который берет таски только на остановках, а канбан — это маршрутка, которую останавливают где угодно.

​Почему твой pet проект обречен на провал?

Сколько ты начинал проектов? А сколько из них закончил? Лично у меня идей было сильно больше, чем результативных проектов. А почему?

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

— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно... — сказала Алиса.
— Тогда все равно, куда и идти.

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

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

Стратегия, четкая цель и расписанный план — залог того, что ты получишь первый результат раньше, чем забьешь на свой проект.

PHP, JS, паттерны, клиенты фриланса и прочая садомазахия — меня зовут Саша и я стараюсь простым языком объяснить сложные вещи. Все в плюсе: я структурирую свои знания, ты поднимашь свой прайс.

Вот посты, которые особенно сильно греют мне душу:

♦️Про синдром самозванца
♦️Клиент не шарит. И это — нормально.
♦️Баги с запахом бензина.

В общем, я fullstack laravel+vue, ко мне можно на ты, и я рад тебя тут видеть!)

👇Голосуй как давно в IT и рассказывай, на чем прогаешь👇

Неявные приколы 🤡

"Почему так?!?" — кричат джуны. "без понятия, юзай ===" — отвечают сеньеры.

На самом деле собаку опять зарыли в спецификации. При нестрогом сравнении js сначала пытается привести все к одному типу. В случае [] == 0.  Пустой массив сначала преобразовывается в строку, получается "", строка уже преобразовывается к Number, на выходе 0 == 0.

При сравнении [] == "\t" массив тоже преобразовывается в строку. Слева строка, справа строка: "" == "\t", тип один, но контент в строках разный — не равно. Вот и выходит, что
"" != "\t", "\t" != "0" и т.д. При этом, если любое выражение привести к Number — все будет 0

Кстати смайл относится не к js, а к тем, кто юзает нестрогое сравнение. Сам такой))

Небольшой оффтоп: мне интересно, как можно было переименовать твиттер, но оставить иконку скворечника, твиты вместо постов и т.д. Будет ли это вообще переделываться?

Дом, прокрастинация и котики — моя борьба за время

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

Сейчас мое спасение — душ и секундомер. Но, кажется, нужно будет искать что-то новое.

1. Секундомер — мне платят за часы, поэтому тикающий секундомер напрямую давит на мою совесть и не дает отвлекаться

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

А где вам легче работать? дома или в офисе?

​Скилл, деньги и поменяйте цвет к кнопочки, пожалуйста

Я начинал работу с верстки, работая параллельно курьером в яндексе еде (всем говорю, что работал в яндексе). Денег платили, что там, что там одинаково мало, но я был уверен, что верстка — временно, я выучу кучу крутых фреймворков, стану сеньером-помидором и буду получать 300к/наносек.

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

Почему?

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

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

Нужно ваше мнение!

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

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

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

​Долгострой выжмет соки из тебя и твоего заказчика

У меня недавно было 2 огромных проекта от разных заказчиков.

Первый — что-то типа CRM для строительной компании заказчика, допустим, Эдуарда. Так вот фантазии Эдуарда можно позавидовать — всё новые и новые фичи залетали в ТЗ намного быстрее, чем я успевал их реализовать. Я в принципе тоже был не против. Больше работы — больше денег. С деньгами правда были проблемы — постоянно приходилось торговаться и спорить, объяснять цены и сроки, которые двигались вместе с увеличивающимся ТЗ. Да и в принципе недовольство заказчика нарастало — деньги-то в проект вкладываются, а выхлопа нет.

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

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

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

P.S. Спасибо за ответы в предыдущем посте! Если честно, не ожидал, что так много человек заинтересуется)

Не надо так — Магические числа

Одной из самых распространенных bad practices в JS, да и вообще в программировании — это числа в коде, которые взялись неоткуда и значат непонятно что.

Возьмем пример со скриншота — только сатане и автору известно, что значат эти 1, 3 и 5. А через месяц известно будет вообще только Сатане, ибо автора уже повесят за такой кодинг.

Ну и в дополнение представь, что ты решил поменять код успеха с 1 на 200 а статус проверяется в проекте 242 раза — неприятно.

Короче, код статуса, процент НДС, часы рабочей недели и т.д. — все выносим в константы, чтобы не было стыдно свой код на гит заливать.

P.S. Думаю сделать badPractices постоянной рубрикой, поставь 🫡 если интересно

#badPractices

Валидатор, уходи!

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

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

1. В реальности валидатор не гарантирует кроссбразуерность.
2. Валидатор не гарантирует хороший UX
3. Не гарантирует даже корректное отображение сайта
4. Гарантирует нервный тик
5. Даже главная страница хабра показывает 65 ошибок

Так что давайте все дружно! Валидатор, уходи!

Ненавижу программирование! А нет, ненавижу проект.

Достал меня один проект — идет туго, делать неинтересно, даже начал думать, что программировать надоело, но переключился на свой проект туду листа (77 голосов, вы вообще дикие 🫡). Мне сразу жить захотелось! Развиваться и делать!

Проекты, которые тебе не нравятся и достали — реально истощают. Видел коллег, которые выгорели и больше не хотят прогать из-за проектов, которые стоят поперек горла.

В общем, делайте, что по кайфу, а что не по кайфу не делайте 😎 Ну хоть иногда..

Не надо так — глобальные переменные

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

1. Конфликты с другими глобальными переменными. Это рано или поздно случится, поверь.
2. Отладка — пойди  найди в файле на пару тысяч строк что с твоей переменное произошло и кто ей воспользовался.
3. Модульность. Опять же, найди в большом файле все строки, которые имеют отношение к твоей переменной и попробуй их выделить в модуль — будет весело

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

P.S. Всем спасибо! Очевидно, рубрике быть 🫡

#badPractices

Дебаггер в DevTools

Вроде как штука многим известная, но мало кто её использует. Но ведь js — не приговор, можно прогать как в нормальных других ЯП

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

Чтобы войти в дебаггер нужно либо щелкнув на вкладку debugger, либо через консоль, нажав на имя и строку ошибки/лога

use strict — надо, Федя, надо

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

use strict приводит нас к стандарту ES5, но что конкретно это значит?

1. Нет замалчиванию проблем. Больше нельзя будет случайно создать глобальную переменную myVar = 10, нельзя будет добавить повторяющиеся параметры в функцию function badFunc(a, a) {...} и т.д.
2. Минорная оптимизация производительности. Улучшение скорости работы — не главная фича строгого режима, но если это ничего не стоит...
3. Исправления безопасности. Некоторые методы (типа caller) стали приватными, запретили присваивать значения свойствам, предназначенным для чтения

А если с этим кодом еще кто-то работать будет... Лучше поставить "use strict"; чтоб потом креститься на код не пришлось

​Велосипеды мои любимые

Для меня одна из самых трудных частей в работе — это не изобретать велосипед. Всегда было легче потратить 5 часов на то чтобы написать какой-то функционал самому, чем потратить час на то чтобы разобраться в библиотеке. Я до сих пор себя заставляю использовать готовые решения, а не писать все с нуля.

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

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

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

​Про синдром самозванца

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

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

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

В общем, не бойся показаться дураком и не заставляй других чувствовать себя дураками, Love&Peace

Первые заказы, как испытание на прочность

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

Но я мальчик, который выжил, у меня получилось! Помимо того, что я спамил по 20 заявок в день, я брался за все заказы. Даже если не знал, как их делать (я почти никогда не знал). Главное получить заказ, а там уже google, stackoverflow, а теперь еще и chatGpt — прорвемся. По другому опыт не получится заработать.

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