Comments 36
Это я так понял Style Guide
У нас в Idea за основу были импортированы Google Style, и немного измененные под наши нужды
https://github.com/google/styleguide
Простенький стайлгайд это совсем не архитектура.
Архитектура это что-то вроде правил:
Сделали прием файлов от пользователей? Сливайте их в максимально надежную и максимально безразмерную трубу. s3 оптимальный вариант. Не забудьте подумать про максимальные размеры файлов и нагрузку. ООМы это реальность, потоковая обработка немного сложнее зато надежнее.
По клику пользователя делайте минимум вещей. Если можно не ходить во внешний сервис не ходите. Если можно обойтись одним походом в sql базу, а все остальное сделать асинхронно потом то так и делайте. Всегда помните что любой внешний сервис иногда ломается и подумайте что делать в этом случае.
Вас будут спамить в любой метод который это в теории позволяет. Все что позволяет сделать запись которую увидит другой пользователь подходит для спама. Защититесь от всех самых невероятных вариантов заранее.
Клиенты любят писать скрипты к вашему АПИ. Иногда они пишут плохие скрипты. Выдать 1000 рпс с одного компа можно вообще без проблем. Подумайте и защититесь заранее.
И тому подобное. И это только про внешние взаимодействия. Не касаясь архитектуры кода вообще.
Из архитектуры кода мое любимое: Любой вечный таймаут рано или поздно окажется на самом деле вечным. Даже если этого не может быть вообще никогда. Сделайте разумное время ожидания везде. И напишите хоть какой-нибудь обработчик на случай если оно вышло.
Тот момент, когда комментарий гораздо лучше статьи :)
Сейчас модно везде ставить слово "архитектура". Это такой новый "менеджер". Заходите в кафе, а там архитектор обслуживания проводит вас к столику и резюмирует ваши требования архитектору кофе.
А кто ещё кроме вас это знает?
Сеньоры и лиды точно знают. На то они и сеньоры с лидами.
Остальным пару раз в месяц устраиваем что-то вроде маленьких внутренним митапов и рассказываем всякое-разное. Писать это бесполезно. Это надо понять, а не прочитать. В виде рассказа с примерами из рабочего кода достаточно эффективно выходит. В виде текста абсолютно неэффективно, я пробовал.
Ну, у фронтенд-приложения тоже может быть архитектура, разве нет?
Речь, конечно, не о стиле написания кода и модификаторах доступа. А о том, как мы управляем общим состоянием, как осуществляется работа с api, как выполняется логирование и мониторинг. Как переиспользовать код между несколькими проектами, в конце концов.
Организацию кода по файлам и директориям, в принципе, тоже сюда можно отнести.
Маленькое резюмирование: "думай" (как сделать проще, оптимальнее, гибче и безопаснее).
Спасибо за статью — очень информативно. Однако по прочтении вашей статьи меня осталась пара вопросов, ответы на которые я не нашел в статье. Не могли бы вы ответить на них дополнительно?
1.
Для меня как менеджера, безусловно, эти профиты были на порядок выше, чем затраты на создание и поддержку гайда.Я понял про ваши выгоды. Но есть ли от такого режима работы какая-то выгода для разработчиков? Вы же, как хороший менеджер, вряд ли им позволите «большую часть времени заниматься именно тем, чем и должен заниматься каждый хороший менеджер, а именно своими делами, например просмотром хабра или ютуба» (то, в чем, по вашим словам, состояла часть вашей выгоды)?
2.
вы можете брать сотрудника на уровень ниже на все позиции Junior,Middle,Senior, Lead. Главное чтобы у кандидата было желание обучаться, остальному он научится сам по гайдам. Я считаю, что это особенно важно для аутсорс компаний, для которых критично нанимать слабых разработчиков, а выдавать за сильных. С гайдами их слабые разрабы через 3-4 месяца работы сильно вырастут.Я правильно вас понял, что таким образом вы фактически снижаете зарплаты своих разработчиков? Причем — не на 3-4 месяца, которые им понадобятся, чтобы вырасти, а на больший срок: потому как они вырастут только в проекции на нужды вашей фирмы, и ценность их на рынке труда, где нужды бывают сильно разные, от этого не повысится?
Отвечу с позиции разработчика, к автору отношения не имею:
Выгода в таком стайлгайде для разработчиков в том, что даже если он и требует лишних телодвижений вначале, он спасает от вырванных волос в будущем. Я тут работал с одним "джуном" (перешел из аналитиков), так вот у нас постоянно были споры вида:
— Ты делаешь неправильно, надо вот так.
— Ну работает же.
— Да, но это не поддерживаемо и не расширяемо.
— Ну ведь работает.
Пример для реакта — мы используем material-ui
Стили там можно делать так:
1) <div style={{flex: 1}} />
2) <Box flex=1 />
3) useStyles(theme => ({box: {flex: 1}})) + <div className={classes.box}/>
4) styled('div')({flex: 1})
Так вот он мешает все 3 подхода в абсолютно рандомном порядке и без оглядки. Есть конструкции вида <Box flex=1 className={classes.box} style={{...}}/>
Работает же, круто. Я бы очень хотел стайлгайд который бы мне позволял без всяких споров говорить, почему так делать не стоит.
Или вот мы давным давно договорились, что хендлеры в параметрах мы называем onX. onAddButton, onEditButton. Недавно смотрю — конечно он сделал />
В общем, стиль, нейминг, архитектура — беру всё.
Да, вы правы. Гайд помогает достигнуть единый подход в разработке и отрабатывать возражения умников, если вам пришлось их ревьюить
Выгода в таком стайлгайде для разработчиков в том, что даже если он и требует лишних телодвижений вначале, он спасает от вырванных волос в будущем.
Вот именно выгоды — той самой, что измеряется в деньгах — я и не увидел: разрботчику ведь деньги платят за потраченное на работу время, не так ли? А если так, то какая ему разница, пишет ли лично он код быстро или, из-за плохого смежника, медленно.
Так чего же ради волосы-то рвать?
PS Не, про эстетическое чувство я в курсе, но в деньгах оно не измряется. А мой вопрос был чисто про деньги.
выгоды для лида, что ему меньше тратить своего времени на прокачку людей, объяснение что и как и отработку возражений при ревью. Каждый разраб нужен чтобы развивать бизнес, чем быстрее, тем лучше. Гайд ускоряет этот процесс.
выгоды для лида,
В выгодах для менеджера я и не сомневался. Я интересовался чисто про выгоды рядового наемного разработчика. Я их не вижу. Может, вы мне их способны показать?
Каждый разраб нужен чтобы развивать бизнес.
Но нужно ли это, если чисто объективно, самому разработчику? Меня, как человека, вооруженного с ранней юности учением Маркса-Энгельса-Ленина о классовой борьбе, учили, что материальные интересы пролетария-разработчика и каписталиста-предпринимателя находятсяв непримиримом противоречии. И по жизни это тоже так — потому что распределение дохода между зарплатой и прибылью есть игра с нулевой суммой.
Вы согласны с этим?
PS Вспомнил цитату на обсуждаемую тему.
«Карась любит, чтобы его жарили в сметане». Это знают все — кроме карасей. Их даже и не спрашивали — не только насчет сметаны, но и любят ли они поджариваться вообще. Такова сила мнения.
К. Прутков-инженер. Мысль № 12.
PS Не, про эстетическое чувство я в курсе, но в деньгах оно не измряется. А мой вопрос был чисто про деньги.
Вы как-будто спрашиваете, зачем мастерам на каком-нибудь производстве держать инструменты в порядке и чистоте. Типа для них нет прямой денежной выгоды работать чуть медленнее в чистоте и порядке, нежели по уши в масле, грязи и нечистотах, (впоследствии тратя на поиск инструмента по нескольку часов).
Но это абсолютно теоретическая и даже социопатическая позиция, мне кажется всем очевидно, что мастера если не посходят с ума, то точно будут недовольны.
Даже в таком случае можно найти 2 денежных плюса:
1) Дело не только в эстетике — будет меньше выгорания, меньше денег уйдет на психотерапевта
2) При отсутствии кодстайла проект будет разрабатываться медленее, загнется и умрет.
Если вам нужна прямая денежная выгода для рабочих прямо сейчас — то её нет, но, как я уже сказал — это позиция абсолютно впоротого социопата.
1) выгода для разрабов в том, что у них есть готовое решение как поступать в большинстве кейсов им не нужно ломать голову что и как делать, также при ревью им придется меньше переделывать.
2) денег никто не понижает. просто вы сможете быстрей джуна вырости до мидла.
1) выгода для разрабов в том, что у них есть готовое решение как поступать в большинстве кейсов им не нужно ломать голову что и как делать, также при ревью им придется меньше переделывать.Выгоды для разработчиков не вижу (я об этом уже писал в другом ответе, чуть выше): разработчикам платят не сдельно, а повременно, поэтому им объективно без разницы, сколько кейсов они решили, и их интересам совсем не противоречит в оплачиваемое время поломать голову, вместо того, чтобы ломать свои руки об клавиатуру и наживать себе туннельно-запястный синдром.
Вы согласны?
2) денег никто не понижает. просто вы сможете быстрей джуна вырости до мидла.Использование джуна вместо мидла на одной и той же позиции очевидно позволяет изначально снизить для этой позиции зарплату. Это, в общем-то, справедливо — но есть нюанс, именно про который я и спрашивал: когда джун вырастет до мидла, то будет ли ему увеличена компенсация до уровня того же самого мидла? Учитывая, что вырастает джун скорее всего только в том направлении, которое требуется фирме и никуда более (потому что гайды), я сомневаюсь, что такой специально выращенный «одомашенный» мидл будет столь же конкурентоспособен на рынке труда, как и выросший в естественной среде. А потому я сомневаюсь, что бизнес (в лице менеджера) согласится платить ему «по рынку» для его «грейда»: никаких объективных причин я для этого не вижу.
Вы можете развеять мои сомнения?
1) Выгода для разрабов что у них меньше стресса при совместной работе. Также после их код ревью им меньше переделывать.
2) Откройте свою веб студию где программисты будут просто будут сидеть, а вы им будите платить за просиженное время. У вас точно будет успех.
3) Бизнес платит по рынку, если программист на рынке стоит дороже, но получает меньше, то он может просто поменять работу.
2) Ещё раз: проблемы бизнеса наемного работника не волнуют.
3) Да, но я как раз писал о том, что такая, как вы предлягаете, схема «роста» порождает неликвидного на рынке работника (своего рода employer lock). То есть все разговоры про «возможность роста» в этой схеме — обман.
А эти гайды в итоге лежат в виде вордовских файлов в папке, да? Какую-то систему типа вики или bookstack не делали?
Большую часть описанного в статье я бы заменил на автоматизированные проверки.
Хотите OnPush? Используйте prefer-on-push-component-change-detection .
Модификаторы доступа? explicit-member-accessibility .
Боритесь с null? Включите все strict настройки для компилятора (TS и Angular)
Что-то специфическое для проекта? Напишите тест или свое правило для eslint. Для случаев попроще можно обойтись правилом no-restricted-syntax (там очень гибкий синтаксис селекторов, можно много наворотить).
И приправить официальным styleguide от Angular, в котором уже многие рекомендации расписаны (обычно, в более легкочитаемом виде, чем свой README файлик)
Супер, кто еще кроме вас знает что так можно?
В этом и прелесть автоматизации. Главное, чтобы про это знали pre-commit хуки и CI pipeline.
А знакомиться с документацией Ангуляра и RxJS посылаем всех новоприбывших - потому что а как еще? Ридми этому не замена.
Нет, ну понятно, что всегда есть что-то, что не автоматизируешь, и что специфичто для проекта. Это описываем в ридми.
Моя мысль в том, что в первую очередь стараемся автоматизировать все, что можно - гораздо более эффективно, чем записывать в текстовый файл и надеяться, что все всё будут помнить потом.
Описание и автоматизация дополняют друг друга, а не противоречат. У вас люди знают какие именно проверки вы в строили в си? Или пишут вам с вопросом почему папйп не прошёл? Обязательно нужно расписать кратко какие проверки в си, чтобы люди знали это до пуша.
Это же не черный ящик с "прошло / не прошло" на выходе. Видно, на каком шаге ошибка, в чем она заключается.
Полностью согласен, что описание и автоматизация дополняют друг друга.
Как я решил проблему плохого кода с помощью architecture guide