Обратить внимание на непонятное.

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

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

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

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

От ТЗ до сдачи меньше двух месяцев. Работаем хорошо и быстро, заказывайте разработку

https://vk.com/@-124059206-sokratili-vremya-na-podgotovku-smety-s-1-nedeli-do-1-minuty

Важность базы

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

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

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

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

Конструктор, интеграции, тг бот и электронные сертификаты в кейсе
https://vk.com/@studio_alt-ne-vsya-tovarka-na-marketpleisah-internet-magazin-utro

А еще ребята делают крутые полотенца и однотонное белье

Первый факап

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

Спустя годы, я обучил и поработал с громадным числом таких же новичков и по опыту — похожего момента не избежать никому. Чего только не видел: десятки способов убить сервак при настройке там чего-то (rm -rf / на проде не видал, но chown -R user:user / был), десятки способов потерять данные (применение старого бэкапа вместо снятия текущего на прод базу как вам), десятки способов положить сайт (включая как заддосить самим себе бэкенд), и сотни менее критичных плохо сделанных задач. И вот после первых проблем и определяются будущие профи, а нежные снежинки отсеиваются. Ну а так как избежать фиаско не удастся никому, попробую дать совет как себя вести есликогда оно произойдет. Принципы эти помогали работать и двигаться дальше, что на старте пути, что со временем, когда факапы становились сложнее, проявлялись на большей дистанции и меньше зависели от внимательности и наличия бэкапов: плохие решения в выборе технологии или архитектуры, катастрофически недостаточные оценки задач, неверные приоритеты, найм не тех людей.

Итак:
Быстро поднятое не считается упавшим
Возможно вам повезло и все не так плохо, не паникуем и даем себе время на поиск идеального решения. Это время не должно быть большим, счет этого пункта буквально на минуты. Понимаем, что произошло и знаете ли вы 100% метод как вернуть все обратно. Важно, что в этом пункте мы сначала думаем, что случилось и знаем ли мы как это исправлять. Если осознали и действительно знаем - делаем. Если же в решении, всплывающем сходу, мы не уверены — не торопитесь и переходите к дальнейшим пунктам, всегда есть шанс сделать хуже.

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

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

Учимся на ошибках
В итоге даже самые дикие проблемы разрешаются. Важно сделать для себя разбор: что случилось, почему, что сделать чтоб этого избежать, чего не хватало, что делать на будущее? Ответив на эти вопросы себе, оформляем постмортем для клиента формата: проблема была в Х, причиной стала ошибка, чтоб этого больше не произошло мы сделаем Y, а также Z для страховки на случай подобного.
Конечно, неизбежность фейлов не значит, что не стоит их избегать заранее. Наоборот, опыт ошибок научит делать все, чтоб когда они случились — то не стали катастрофой.

Хороший программист

Услышал недавно в оживленном обсуждении опус, мол в России хороших программистов нету. И хоть обсуждать столь очевидно неверное заявление нет никакого смысла, однако оно натолкнуло на мысль, а как определять термин "хороший программист". Проще и правильнее судить по факту сделанного, успешным проектам не загнувшимся от техдолга и нагрузок, но успех проектов зависит не только от отдельно взятого кодера. Потому задумался, кто для меня "хороший программист" и попытался составить набор критериев, таких, чтобы можно было при найме понять, что программист — хороший, а новичкам узнать на что обратить внимание:

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

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

- Неплохо, человек пишет хороший код. Хватает ли этого? В коммерческой разработке нет. От этого кода зависят другие части проекта, и у любой задачи в реальном мире будет срок и бюджет. Потому хороший разработчик умеет в оценки задач и коммуникацию. Понятно, что ясновидящих не бывает, и всегда 100% давать верные сроки — навык уже не хороших, а исключительных разработчиков, но сообщать о том, что ситуация поменялась и ранее названные сроки нереалистичны — доступно каждому, хотя на деле далеко не каждый это делает. Потому навык отслеживать затрачиваемые ресурсы, и как можно заранее сообщать о том, что прогноз был неверен, и надо смещать объем/срок настолько-то — выделит вас среди ребят "будет, когда будет". Коммерческая разработка это командная игра, и кроме коммуникации по статусам и срокам, нужно уметь и критику принять, и о помощи попросить вовремя. Лучшие по результатам разработчики с которыми я работал всегда задавали в разы больше вопросов и делились проблемами с которыми сталкиваются, чем остальные.

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

0.1 + 0.2 != 0.3

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

Итак начнем с простого: арифметика чисел с плавающей точкой. В теории мемасы о том, что js странный и смотрите ха-ха-ха 0.1+0.2 выдает 0.30000000000000004 видали многие. Однако на деле из новичков учитывают этот факт — единицы. И еще меньше знает, что такая особенность далеко не только у js. Попробуйте python — получите тоже самое. Попробуйте php — может показаться, что все ок, но он вас обманывает.

echo 0.1+0.2;

выдаст вам 0.3, но попробуйте

var_dump(0.1+0.2 == 0.3);

или

echo json_encode(0.1+0.2);

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

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

Решение тут простое, точнее даже два. Для начала убедитесь, что вам действительно нужны числа с плавающей точкой. Например во всех случаях когда речь о деньгах — скорее всего их можно вполне хранить в int считая не число рублей, а число копеек. Тоесть, нужно хранить не цену 100.00 рублей, а целочисленное 10000 копеек. И ставите точку там где нужно только при итоговом выводе результатов. Ну, а если вам все же позарез надо хранить и считать во float — то во всех языках есть готовые инструменты для точных вычислений с ними. Обратите внимание на BigNumber в случае js или на функции bcmath в случае php

ChatGPT и программирование

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

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

НО: все это делается и применяется отлично, при условии, что применяющий сделал бы это и без ИИ, хоть и дольше. Если это так — все прекрасно. Когда человек пользующийся ИИ знает тему сам — он правильнее формулирует запросы, а самое главное — может проверить результат на адекватность и поправить если где-то проскочил какой-то кусок лютой дичи. На практике же местами сталкиваюсь с ситуациями, когда например целый день кодер, столкнувшийся совсем не со своей темой, творил какую то херню не в ту сторону "потому что чатгпт мне так сказал". Да и если например менеджер без достаточной технической базы, увидев что несколько раз ИИ отдавал ему разбивки с оценками такие же как проверенный кодер начнет не валидируя рассылать эти оценки как истину, то достаточно быстро пообещаем кому-нибудь то чего даже близко не можем обеспечить — а это критично.

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

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

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

Итак первое с чем надо разобраться, наш самый главный друг в вопросах времени, вносящий необходимое постоянство — unix timestamp. Таймстамп — количество секунд прошедших с момента времени, когда 1 января 1970 года часы в Гринвиче показали 00:00. Не с того момента когда часы в вашем регионе показали полночь, а когда они показали полночь именно в Гринвиче. А так как этот момент был одновременно для всего земного шара, то и таймстамп в один момент времени по всей Земле — одинаковый. Тоесть если человек в Москве у которого часы показывают 8 часов, и человек во Владивостоке у которого в этот же момент часы показывают 15 получат текущий таймстамп — то они получат одинаковые числа, несмотря на разное время "на стене".

Получить таймстамп можно в любом ЯП:

new Date().getTime()

в js — он правда вернет кол-во миллисекунд, тоесть в 1000 раз больше значение, чем например

time()

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

"Время на стене" же постоянно у всех разное. Причем на это влияют не только более менее понятные географические часовые пояса, но еще и местные законы и договоренности людей. Где-то есть переход на летнее время, где-то нету. Где-то люди договорились, что их время будет по другому часовому поясу, а потом могут передоговориться и вернуть назад (привет Новосибирск). Короче полная неразбериха. В общем случае ко времени на стене указывают его смещение относительно Гринвича, например UTC+3 — тоесть мол время на 3 часа больше, чем в этот же момент в Гринвиче. Но обозначенные выше ситуации создают кучу примеров когда у человека в течение времени смещение может сменяться — что крайне неудобно. Пытаться переводить время записанное со смещением во время в других местах иногда даже неразрешимая задача. Например если в регионе есть переход на летнее время, то когда часы переводят назад (например с 3 на 2), возникает ситуация когда к примеру время 2:30 наступает дважды. Хранением всех этих нюансов таймзон и переводов времени занимается tz database поддерживаемая и наполняемая волонтерами и поставляемая в операционные системы. Но это особо и не важно, сохранять локальное время в любом случае не стоит, ведь есть путь намного проще.

Фишка в том, что если нам нужно сохранить какой то момент времени (время создания записи в бд, или момент времени в который надо выполнить задачу) — используйте timestamp. Для него вам не надо спрашивать из какого часового пояса к вам обращается клиент. При том таймстамп когда вы его отдадите на фронтенд, каждый клиент может 100% перевести в его локальное время, простейшей функцией

new Date(1710178886146)

к примеру для js. Так бэк будет не заморачиваться и отдавать всем клиентам инфу в одном и том же формате, а фронтенды сами отобразят результат в своем локальном времени.