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

У меня недавно было 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, а я на требуемом стеке делал лишь небольшой учебный проект. Заявку в принципе было посылать нестрашно, потому что я не верил, что получу такой крутой заказ. Но... я работаю с этим заказчиком до сих пор.

ГитМен — этому проекту нужен новый герой

Это история о том, как я чуть не потерял целый день работы 🤡

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

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

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

Собственно говоря, тогда я и понял, что знать git pull & git push недостаточно

​Фиаско, не смог выполнить заказ

В дополнение к посту о первых заказах. Один раз у меня все-таки не получилось выполнить работу. Заказ был сделать что-то в древней CMS Joomla. Я тогда с коллегой сидел несколько дней безвылазно, но для нас это был просто темный лес по сравнению с wp — ничего не получалось сделать.

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

В общем, проблема была решена и дипломатично, я предложил ему компенсацию за беспокойство в размере 10% от стоимости заказа 500р, лол.

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

P.S. по картинке — кто понял, тот понял 🧐

Нормально объяснить можно?

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

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

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

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

P.S. Накидайте реакций, если интересно посмотреть на несколько выдержек с курса 🔥

​🔥70 реакций, ребят, вы вообще дикие, выкладываю 🫡

Поймать баг и не умереть — git bisect

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

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

1. git bisect start — запускаем поиск!
2. git bisect bad — говорим, что текущий коммит "плохой", содержит баг
3. git bisect good <commit hash> — Указываем, какой коммит точно является хорошим.
4. Все, область поиска обозначена. Теперь git bisect перекинет тебя в коммит посередине — между хорошим и плохим. Ручками, или с помощью юнит тестов проверяем, есть в этом коммите искомый баг и говорим результат гиту с помощью git bisect good/bad. Таким образом ты сузил область поиска в 2 раза.
5-inf. Повторять предыдущий шаг, пока область поиска не сузится до одного-единственного коммита.

Кроме того, git bisect залезет даже в смерженные ветки, если окажется, что баг спрятался в них.

P.S. Как же тяжело урезать статью до поста — все время хочется добавить больше полезности и примеров

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

Так нужен матан-то?

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

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

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

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

На подумать — у меня есть знакомый программист, который не шарит за математику настолько, что я объяснял ему, как работают проценты. Так вот, за 7 лет в it он освоил только одну древнюю CMS.

Вспоминаю сейчас, как я все-таки взял себя в руки и разобрался с гитом

Ощущение было, будто заново ходить научился.

1. Меня перестало бесить переключение между тасками, потому что можно не комментить недописанный код, а просто переключиться на другую ветку.
2. Когда всплывал какой-то древний баг — я перестал логировать каждую строчку в 20 файлах ,пытаясь понять, что пошло не так, а просто ипользовал bisect
3. Начал сам разбираться в своем и чужом коде — коммиты с четким описанием по утвержденной структуре, ветки под таски - все это очень здорово помогает не устроить из кода бардак + по истории легко отследить зачем и кем код был написан.
4. Работа с командой! Для меня было открытием, что если нормально выстроить управление репозиторием — можно спокойно и без путаницы работать даже над большим проектом.

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

P.S. На фото я, когда преисполнился в познании гита

Переработки, как способ ничего не сделать

Берешь больше работы -> не успеваешь -> работаешь больше -> устаешь -> не успеваешь еще больше -> работаешь еще больше.

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

Но вот не получается так. Не работает. Чтобы работать эффективно — у тебя должны быть силы. Чтобы у тебя были силы — ты должен отдыхать.

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

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

Программисты, которые не пользуются гитом — вы кто?

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

Буквально в этом году на проект пригласили фронтенда: много кейсов в портфолио, более или менее приятный код, да и вообще с человек знаком, пускай и шапочно — знаю, что человек в it несколько лет как минимум. В общем, кажется, все ок. Созваниваемся, показываю тонкости проекта. кидаю ему ссылку на репозиторий, а мне в ответ неуверенное: "а, у вас на гите все... я с ним не сталкивался, мне что-то скачать нужно?"

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

Я понимаю, как можно не помнить флаги reset, понимаю, как можно не знать о Git LFS, но как можно умудриться за несколько лет работы обойти git целиком — не понимаю

​Тру прогеры кодят на линуксе

Так? Так ведь?

Я с линуксом познакомился в период, когда на то чтобы окружить себя атрибутами программиста я тратил сильно больше сил, чем на сам кодинг. Я прочитал, что настоящие жостики сидят на Arch — поэтому 3 дня сидел с туториалами и терминалом, чтобы накатить наконец этот гребаный трушный линукс. Потом я прочитал, что реальные хакеры пользуются Vim, а все IDE для слабаков — слабаков, которые не могут найти выход из Vim. После этого я, конечно, всем подряд доказывал, что это очень удобно и если у тебя стоит винда — ты вообще не программист. Хорошо, что тогда мне не попалась никакая статья о веганстве.

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

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

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

P.S. Ниже архивное фото, 2018год — я жестко гуглю, как войти в терминал в линуксе