Заметки с тегом «Программирование»

Ребята из MoscowPython выложили видео моего доклада о том, как мы в ГдеМатериале поддерживаем качество кода:

Это — заметка для программистов. Если вы менеджер — почитайте версию для менеджеров.

Многие ребята, выбирая инструменты для нового проекта, начинают строить длинные таблицы, сравнивая фичи. Серьёзно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.

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

А вот если вы начинаете коммерческий проект, то смотреть нужно совсем в другую сторону. Фичи — это состояние проекта сейчас. Подумайте лучше о том, каким будет ваш фреймворк потом. Удержит ли он комьюнити в ближайшую пару лет? Успеет ли за быстроизменяющейся средой? Будет ли адекватным предложение на рынке труда?

Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends. И да, если вы выбираете фреймворк для фронтенда, то берите любой — всё равно протухнет через год.

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

Я использую MacBook Pro 14". Когда я работаю дома, ноутбук подключён к монитору Apple Studio Display. Я не использую два дисплея, поэтому ноутбук работает Clamshell mode. Единственное исключение — стримы: для них я открываю на ноутбуке Open Broadcaster Software.

В качестве органов управления я использую Happy Hacking Keyboard и Magic Trackpad. Мои пальцы не могут изогнуться, чтобы воспользоваться странной клавишей, которую засовывают в русских раскладках между левым шифтом и z, поэтому я всегда покупаю американские клавиатуры, их ещё называют ANSI.

Полный список железок:

• MacBook Pro 14" 2022, Apple M4 Max, 36Gb RAM
• Монитор Apple Studio Display на кронштейне Ergotron LX Desk Monitor Arm
• Клавиатура Happy Hacking Keyboard Pro Hybrid Type-S
• Внешний тачпад Magic Trackpad 2
• Веб-камера Razer Kiyo Pro
• Микрофон Shure SM7B со штангой Blue Compass
• Микрофонный предусилитель Art Tube PAC
• Звуковая карта Focusrite Clarett+ 2Pre
• Наушники Sony MDR-7506, колонки KRK Rockit G5
• Регулируемый стол на опоре Shapdesk U4.

Софт

Я не люблю IDE, и в роли редактора кода использую neovim. Долгое время я сидел в Visual Studio Code, но конце 2021 года я устал бороться с увеличивающимся количеством скрепышей фич, плюнул и перешёл на neovim в терминале kitty:

Плагинов neovim год от года становится всё меньше. Сейчас остались только 3 значимых плагина:

• fzf для быстрого открытия файлов
• nerdcommenter, чтобы быстро комментировать куски кода
• autosave, чтобы пореже делать :w

В качестве оболочки я использую прекрасный fish. Как интерфейс для LLM — opencode. Если хотите так же — посмотрите на мои файлы конфигурации на гитхабе.

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

Посмотрите на историю серверной инфраструктуры: 20 лет назад были большие железные серверы. Сисадмины с важным видом настраивали RAID, патчили FreeBSD и выдавали программистам права доступа. Потом появились виртуальные машины — теперь, чтобы выкатить софт, стало не нужно думать про RAID-массивы и FreeBSD: нажал кнопочку и получил работающую машину.

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

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

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

В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такая резка фич, ещё до продакт-менеджера.

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

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

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