В одной большой функции разбитой на разделы комментариями...
Читая различные книги, различных авторитетных авторов (например того же дядюшки Боба "Чистый код") встречался с тем что необходимо избегать обильного комментирования кода. Если есть желание кусок кода "обернуть" комментарием то этот код самый верный кандидат на вынесение в отдельный метод или класс. Имя метода (класса) станет абстракцией/черным ящиком которая явно скажет что делает этот кусок кода.
Иначе код будет:
Захламлен обильными комментариями, что затрудняет чтение кода, к тому же хорошие комментарии тоже надо уметь писать.
Необходимо будет следить, чтобы комментарии соответствовали коду при рефакторинге, что дополнительная нагрузка для программиста.
Если профукать предыдущий пункт, то несоответствие комментария и кода создаёт намного большую нагрузку. Намного лучше если не будет комментария, чем если он возможно не будет соответствовать коду.
Методы/функции будут непомерно большими и сложно понимаемыми.
Я лично стараюсь вообще не писать коментарии, стараюсь чтобы код сам рассказал что происходит. Обычно если метод/функция действительно короткая, то в необходимости докстроки нет необходимости. Хотя конечно всегда есть исключения, и комментарии пишутся там, где кажутся уместными.
Автор добавил комментарии, чтобы читатель быстро вник в контекст. Обычная практика при написании статьи. Да и функция большая делающая много чего, что комментарии напрашиваются.
куче функций, передающих друг другу управление
Обычно все таки не нужно знать как метод достигает цели, мы смотрим на него как на черный ящик. Если все таки нужно знать реализацию, то опять же имя метода говорит, что должен сделать метод, код расскажет как он это делает. Опять вижу только удобство;
Первый вариант приводит к созданию 100500 копипащенных функций
обычно когда делишь на меньшие методы/классы/... то больше шансов, что не будет копипаста. Вопрос только в том как правильно декомпозировать. Но похоже мы вернулись к теме поднятой автором).
В крайнем случае надо пойти на чрезвычайные меры, включающие в себя захват инопланетных заложников и принуждение их к переговорам и репарациям.
Хороший план, через силу принудить сделать нас добрыми, нравственными, развитыми. По вашему плану исход будет один. Полное уничтожение человеческой цивилизации. Или инопланетяне не поймут наших методов установления дружбы. Или сами люди получив более высокие технологии гарантировано себя уничтожат. Метод получения этих знаний способствует этому.
Лучше уж предложение автора статьи. Я хоть и не понял в чем конкретно его предложение, но оно направлено на развитие лучших человеческих качеств: заботы о других людях, развитие человечества, кооперация над высокой долгосрочной целю направленный на развитие общества взамен краткосрочных направленных на корыстные (увеличение капитала, захват рынка и.т.д.).
А что из них более реально? Реально то, на что направлено наше внимание, что мы развиваем. Если достаточно людей возьмут курс на предложение автора (что бы это ни было:), это возможно. Осталось найти харизматичного лидера. То бишь второго Илона Маска.
Читал про большую геодезическую экспедицию во Франции, результатом которой было определение длины меридиана. А также определение новой меры длины 'метр'.
Насколько правильна моя информация по данной экспедиции?
Будет ли подобная статья и по этой экспедиции?
Конечно можно было бы прогуглить. Но охота проверить свои знания (предположения) у живого эксперта, а не скучного Гугла).
Все таки ответственность на мой взгляд это в первую очередь взять для самого себя обязательство решить задачу/вопрос/проблему. И только потом отвечать за результаты.
Ответственность это: я хочу (мне надо) решить этот вопрос самым лучшим образом. Тогда я буду молодец.
Нагрузка это: я должен закрыть этот вопрос, не то мне попадет.
Нагрузку можно запросто перевести в ответственность.
Или у вас хороший подбор кадров, что к вам не попадают такие. Или у вас такая хорошая корпоративная культура, что все ведут себя так. Или вы просто не видите что эти софт скиллы не у всех наблюдаются и развивать их довольно сложно и многие не считают нужным развивать софт скиллы, считая: я не идиот/мудак, значит все хорошо.
Автором предлагается какая никакая (на мой взгляд хорошая) методология. А не быть идиотом/мудаком навряд ли можно применить объективно в работе.
А я не согласен с вами). Софт скиллы это важно, как важны и хард скилы. Не отрицая важности того что справа, я считаю что важнее то что слева. Правда это относится к командам где практикуется аджайл. Почему?
Потому что продукт делают команды. Не архитектор, не синьор, не ещё какой либо супер... Именно команда. Если будет команда суперспециалистов, то есть вероятность что они не смогут придти к решению или оно будет принято не экологично, путем продавливания. Но если эту команду разбавить даже одним человеком с прокаченными софт скилами (это даже может и не программист), то он может создать атмосферу где эта команда может показать себя во всей красе. Само собой этому человеку должны быть даны соответствующие полномочия.
Вообще софт скилы действуют сразу на много факторов командной разработки, поэтому и ценятся. А если это будет опытный программист с хорошими софт скилами, то он будет очень ценнен для любой компании.
Ещё одна причина почему софт скилы ценнее. Их качать намного сложнее. Найти таких людей сложнее. Вырастить хорошего специалиста возможно за условно три года. А прокачать софт скилы с условного нуля до условного нормального уровня практически невозможно, намного вероятнее с условно нормального уровня прокачать до условно хорошего уровня и это тоже немногим (надеюсь ошибаюсь) людям дастся.
Разберём мой случай: "Чувствую, что рынок перегрет и лучше продать акции". Тут брокер чувствует что на рынке происходит. Например что другие брокеры взволнованы и все делают покупки (при этом он не видит всех брокеров, но атмосфера говорит что все так и происходит). Дальше мозг подключается и на основании имеющихся данных строит модель к чему это приведет. Он рассчитает, что нужно продавать, но чтобы собрать сливки с момента нужно поймать момент, когда нужно продавать. И останется ждать момента.
В этом случае интуиция подсказала что происходит в общем на рынке. Как ведут себя другие люди. При этом нет обьективной информации. Мы просто чувствуем это. А дальше уже мозг сделал выводы, прогнозы, и принял решение.
Разберём ваш случай. Охотник или хищник хочет сделать заключительный бросок и по предыдущим атакам у него есть модель, что и как может развиваться. При этом в момент атаки он видит как действует цель и вносит корректировки в свои действия. Все строится на вполне объективных данных. Таких как предыдущий опыт и данные поступающие в реальном времени . Здесь нет никакой интуиции, здесь вполне здравый рационализм.
Интуиция основана на способности считать поле, общую атмосферу и передать эту инфу в мозг. А дальше уже мозг примет решение.
Так как it-шники очень прагматично-логичный народ, то они все в мире захотят перевести в логичные обоснования которые позже можно перевести в нолики и единички).
Я к чему. Интуиция на мой взгляд не имеет ничего общего с тем какой опыт мы имеем. Проще говоря, это не связано с деятельностью мозга.
С чем это связано. С трансцендентным. Боюсь, если дальше буду продолжать, то это больше будет похоже на эзотерику, но все таки попробую), на примерах из жизни.
Были ли вы в церкови, мечети, синагоге? Если были, то чувствовали ли вы изменения (как будто там совсем другая атмосфера) как только переступили порог. Если да, то каким местом вы это чувствовали? Неужели мозгом?
Что то похожее, но совсем другое по вкусу можно почувствовать, если придти в высокозаряженный концерт, или спортивный матч. Там совсем другие энергии. И если вы чувствовали это, то опять же, навряд ли это вы чувствовали это мозгом. Хотя есть вероятность, что вы устроены по другому чем я и чувствуете это мозгом. Но все таки я думаю, мы разные экземпляры одного и того же класса. И интерфейсы, внутреннее устройство у нас одинаково).
То же самое можно сказать про атмосферу в коллективе, можно придти на собеседование и почувствовать что лучше здесь не работать.
И примеров этому много. Все что я привел, не имеет отношение к интуиции. Но это намного родственнее, чем то что вы описали. Основано оно на энергиях в нашем теле и в пространстве, которое мы можем ощущать или считать. Интуиция, это как раз способность считать общий контекст с пространства. "Чувствую, что рынок перегрет и лучше продать акции", сказал бы брокер с развитой интуицией. При этом он не перелопатил вагон данных, он просто почувствовал это.
Проще говоря, есть более тонкое энергетическое поле. Очень сложно уловить ее. Настроить свою антенну на эту волну. Особенно если твоя деятельность связана с точными науками (привет it-шникам), т.е. преобладает ментальное мышление. Антенна эта находится в районе груди. Поэтому есть ощущение, что чувствуешь сердцем. Не зря говорят: "Нутром (сердцем) чувствую", не слышал я чтобы говорили: "Мозгом чувствую:)"
Когда вы собрались написать эту статью. Откуда появилась энергия (ресурсы) на это? Часто мы это называем вдохновением, желанием. Я думаю, что это энергия которая как раз и "заставила" вас сесть за статью. А мозг уже определил структуру, обобщил опыт, построил теоретическую модель, привел доводы и т.д.
Ещё аналогия взятая из книги "Внутренняя инженерия" йога Садхгуру. Наше тело это железо, типа системного блока. Наш ум, разум, интеллект это софт. Инфу можно сохранить в винчестере. Комп (смартфон) без электричества груда "безжизненного" метала, пластика и кремния. Примерно то же самое, но намного сложнее и в нашем теле.)
Поддомены можно разделять и логически в монолите...
Да это так. Так как у нас пока модульный монолит, то мы рассматривали это именно так, а обращение сделать через фасады. Но потом решили все таки добавить шину и общение через него.
Наверное одна из проблем то, что мы не смогли вовремя остановиться. Вообще, в начале предполагалось разрабатывать только отделенный предметный слой, а в остальном думали использовать то, что предлагает NestJS.
Но когда начинаешь понимать прочитанные книги, то охота это применить и закрепить на практике. Действительно, за это время мы всей командой поняли, что скрывается за SOLID, о чем говорит DDD и многое другое поднятое в статье. Когда начинали над проектом, термин REST было незнакомым (по крайней мере для меня). А тут такое. И при этом развитие шло командное. Это меня радует не меньше.
Мне нравятся 4 причины использования микросервисов, которые озвучил Рихтер:
Я во всей статье старался исходить из того, что и как я понимал. Это сделано специально, чтобы если я что то понимаю не так, то чтобы мне ткнули на это.
Ни в коем случае не обижаюсь. Вы правы). То что продукт будет изменяться, переделываться. И наверняка будет чем то другим чем то, что я сейчас вижу в своем представлении.
Вы правы. Я во многих статьях читал, что mvp должен разрабатываться как можно проще, чтобы не жалко было выкинуть. Но. Мы решили пойти своим путем. Ну реально, мы же имеем право идти и развиваться как считаем нужным. Причину почему я написал и в статьях и в ответе на ваш комментарии в предыдущей статье.
С вами сложно не согласиться. Единственно, когда начинаешь с продаж, то хорошо бы чтобы продажники умели продавать. В нашем случае также. Мы просто хотели улучшить свою компетенцию как разработчики. В нашем случае, в нашем контексте, в наших планах развития это считалось наиболее важным.
Ни в коем случае не считаю, что наш путь правильный и всем надо так делать. Это глупо.
Но в тоже время нельзя следовать общепринятому, отбросив всю уникальность ситуации в конкретном твоем случае.
Чтобы ответить на этот вопрос, надо опять же начать немного с истории. Я в it пришел осознанно и надолго. Это написано в предыдущей статье. Даже если этот стартап не взлетит, то я продолжу этот путь и буду заниматься другими стартапами. В любом случае какую бы идею я не выдвигал, над реализацией будет работать команда разработки.
Иными словами мои идеи зависят от команды разработки. И основная боль для меня была, что она (я тоже нахожусь в команде разработки) была слабая, не хватало компетенции. Значит в долгосрочной перспективе эту задачу все равно решать. Я решил решать сперва эту проблему. Зато теперь, пройдя этот путь, я могу более уверенно смотреть над реальностью реализации продуктов своими силами. Хотя конечно же, нам еще учиться, учиться и учиться... и мы скорее всего все равно будем привлекать опытных специалистов. Но теперь это будет точечное решение проблем.
Проще говоря, я поставил в приоритет долгосрочные цели (иметь опытную команду разработки) в ущерб краткосрочным (реализация mvp).
Читая различные книги, различных авторитетных авторов (например того же дядюшки Боба "Чистый код") встречался с тем что необходимо избегать обильного комментирования кода. Если есть желание кусок кода "обернуть" комментарием то этот код самый верный кандидат на вынесение в отдельный метод или класс. Имя метода (класса) станет абстракцией/черным ящиком которая явно скажет что делает этот кусок кода.
Иначе код будет:
Захламлен обильными комментариями, что затрудняет чтение кода, к тому же хорошие комментарии тоже надо уметь писать.
Необходимо будет следить, чтобы комментарии соответствовали коду при рефакторинге, что дополнительная нагрузка для программиста.
Если профукать предыдущий пункт, то несоответствие комментария и кода создаёт намного большую нагрузку. Намного лучше если не будет комментария, чем если он возможно не будет соответствовать коду.
Методы/функции будут непомерно большими и сложно понимаемыми.
Я лично стараюсь вообще не писать коментарии, стараюсь чтобы код сам рассказал что происходит. Обычно если метод/функция действительно короткая, то в необходимости докстроки нет необходимости. Хотя конечно всегда есть исключения, и комментарии пишутся там, где кажутся уместными.
Автор добавил комментарии, чтобы читатель быстро вник в контекст. Обычная практика при написании статьи. Да и функция большая делающая много чего, что комментарии напрашиваются.
Обычно все таки не нужно знать как метод достигает цели, мы смотрим на него как на черный ящик. Если все таки нужно знать реализацию, то опять же имя метода говорит, что должен сделать метод, код расскажет как он это делает. Опять вижу только удобство;
обычно когда делишь на меньшие методы/классы/... то больше шансов, что не будет копипаста. Вопрос только в том как правильно декомпозировать. Но похоже мы вернулись к теме поднятой автором).
А кто целевая аудитория статьи? Кого убеждаем?
Хороший план, через силу принудить сделать нас добрыми, нравственными, развитыми. По вашему плану исход будет один. Полное уничтожение человеческой цивилизации. Или инопланетяне не поймут наших методов установления дружбы. Или сами люди получив более высокие технологии гарантировано себя уничтожат. Метод получения этих знаний способствует этому.
Лучше уж предложение автора статьи. Я хоть и не понял в чем конкретно его предложение, но оно направлено на развитие лучших человеческих качеств: заботы о других людях, развитие человечества, кооперация над высокой долгосрочной целю направленный на развитие общества взамен краткосрочных направленных на корыстные (увеличение капитала, захват рынка и.т.д.).
А что из них более реально? Реально то, на что направлено наше внимание, что мы развиваем. Если достаточно людей возьмут курс на предложение автора (что бы это ни было:), это возможно. Осталось найти харизматичного лидера. То бишь второго Илона Маска.
Мне как бывшему топографу изыскателю тоже зашла.
Читал про большую геодезическую экспедицию во Франции, результатом которой было определение длины меридиана. А также определение новой меры длины 'метр'.
Насколько правильна моя информация по данной экспедиции?
Будет ли подобная статья и по этой экспедиции?
Конечно можно было бы прогуглить. Но охота проверить свои знания (предположения) у живого эксперта, а не скучного Гугла).
Все таки ответственность на мой взгляд это в первую очередь взять для самого себя обязательство решить задачу/вопрос/проблему. И только потом отвечать за результаты.
Ответственность это: я хочу (мне надо) решить этот вопрос самым лучшим образом. Тогда я буду молодец.
Нагрузка это: я должен закрыть этот вопрос, не то мне попадет.
Нагрузку можно запросто перевести в ответственность.
Или у вас хороший подбор кадров, что к вам не попадают такие. Или у вас такая хорошая корпоративная культура, что все ведут себя так. Или вы просто не видите что эти софт скиллы не у всех наблюдаются и развивать их довольно сложно и многие не считают нужным развивать софт скиллы, считая: я не идиот/мудак, значит все хорошо.
Автором предлагается какая никакая (на мой взгляд хорошая) методология. А не быть идиотом/мудаком навряд ли можно применить объективно в работе.
Как же неудобно сказать про это…
А я не согласен с вами). Софт скиллы это важно, как важны и хард скилы. Не отрицая важности того что справа, я считаю что важнее то что слева. Правда это относится к командам где практикуется аджайл. Почему?
Потому что продукт делают команды. Не архитектор, не синьор, не ещё какой либо супер... Именно команда. Если будет команда суперспециалистов, то есть вероятность что они не смогут придти к решению или оно будет принято не экологично, путем продавливания. Но если эту команду разбавить даже одним человеком с прокаченными софт скилами (это даже может и не программист), то он может создать атмосферу где эта команда может показать себя во всей красе. Само собой этому человеку должны быть даны соответствующие полномочия.
Вообще софт скилы действуют сразу на много факторов командной разработки, поэтому и ценятся. А если это будет опытный программист с хорошими софт скилами, то он будет очень ценнен для любой компании.
Ещё одна причина почему софт скилы ценнее. Их качать намного сложнее. Найти таких людей сложнее. Вырастить хорошего специалиста возможно за условно три года. А прокачать софт скилы с условного нуля до условного нормального уровня практически невозможно, намного вероятнее с условно нормального уровня прокачать до условно хорошего уровня и это тоже немногим (надеюсь ошибаюсь) людям дастся.
Разберём мой случай: "Чувствую, что рынок перегрет и лучше продать акции". Тут брокер чувствует что на рынке происходит. Например что другие брокеры взволнованы и все делают покупки (при этом он не видит всех брокеров, но атмосфера говорит что все так и происходит). Дальше мозг подключается и на основании имеющихся данных строит модель к чему это приведет. Он рассчитает, что нужно продавать, но чтобы собрать сливки с момента нужно поймать момент, когда нужно продавать. И останется ждать момента.
В этом случае интуиция подсказала что происходит в общем на рынке. Как ведут себя другие люди. При этом нет обьективной информации. Мы просто чувствуем это. А дальше уже мозг сделал выводы, прогнозы, и принял решение.
Разберём ваш случай. Охотник или хищник хочет сделать заключительный бросок и по предыдущим атакам у него есть модель, что и как может развиваться. При этом в момент атаки он видит как действует цель и вносит корректировки в свои действия. Все строится на вполне объективных данных. Таких как предыдущий опыт и данные поступающие в реальном времени . Здесь нет никакой интуиции, здесь вполне здравый рационализм.
Интуиция основана на способности считать поле, общую атмосферу и передать эту инфу в мозг. А дальше уже мозг примет решение.
Так как it-шники очень прагматично-логичный народ, то они все в мире захотят перевести в логичные обоснования которые позже можно перевести в нолики и единички).
Я к чему. Интуиция на мой взгляд не имеет ничего общего с тем какой опыт мы имеем. Проще говоря, это не связано с деятельностью мозга.
С чем это связано. С трансцендентным. Боюсь, если дальше буду продолжать, то это больше будет похоже на эзотерику, но все таки попробую), на примерах из жизни.
Были ли вы в церкови, мечети, синагоге? Если были, то чувствовали ли вы изменения (как будто там совсем другая атмосфера) как только переступили порог. Если да, то каким местом вы это чувствовали? Неужели мозгом?
Что то похожее, но совсем другое по вкусу можно почувствовать, если придти в высокозаряженный концерт, или спортивный матч. Там совсем другие энергии. И если вы чувствовали это, то опять же, навряд ли это вы чувствовали это мозгом. Хотя есть вероятность, что вы устроены по другому чем я и чувствуете это мозгом. Но все таки я думаю, мы разные экземпляры одного и того же класса. И интерфейсы, внутреннее устройство у нас одинаково).
То же самое можно сказать про атмосферу в коллективе, можно придти на собеседование и почувствовать что лучше здесь не работать.
И примеров этому много. Все что я привел, не имеет отношение к интуиции. Но это намного родственнее, чем то что вы описали. Основано оно на энергиях в нашем теле и в пространстве, которое мы можем ощущать или считать. Интуиция, это как раз способность считать общий контекст с пространства. "Чувствую, что рынок перегрет и лучше продать акции", сказал бы брокер с развитой интуицией. При этом он не перелопатил вагон данных, он просто почувствовал это.
Проще говоря, есть более тонкое энергетическое поле. Очень сложно уловить ее. Настроить свою антенну на эту волну. Особенно если твоя деятельность связана с точными науками (привет it-шникам), т.е. преобладает ментальное мышление. Антенна эта находится в районе груди. Поэтому есть ощущение, что чувствуешь сердцем. Не зря говорят: "Нутром (сердцем) чувствую", не слышал я чтобы говорили: "Мозгом чувствую:)"
Когда вы собрались написать эту статью. Откуда появилась энергия (ресурсы) на это? Часто мы это называем вдохновением, желанием. Я думаю, что это энергия которая как раз и "заставила" вас сесть за статью. А мозг уже определил структуру, обобщил опыт, построил теоретическую модель, привел доводы и т.д.
Ещё аналогия взятая из книги "Внутренняя инженерия" йога Садхгуру. Наше тело это железо, типа системного блока. Наш ум, разум, интеллект это софт. Инфу можно сохранить в винчестере. Комп (смартфон) без электричества груда "безжизненного" метала, пластика и кремния. Примерно то же самое, но намного сложнее и в нашем теле.)
Как то так, но это конечно же ИМХО.)
У меня вопрос автору.
А делали ли вы выбор, согласно своей интуиции? Если да, то каким "органом" вы выбирали?
Да это так. Так как у нас пока модульный монолит, то мы рассматривали это именно так, а обращение сделать через фасады. Но потом решили все таки добавить шину и общение через него.
Наверное одна из проблем то, что мы не смогли вовремя остановиться. Вообще, в начале предполагалось разрабатывать только отделенный предметный слой, а в остальном думали использовать то, что предлагает NestJS.
Но когда начинаешь понимать прочитанные книги, то охота это применить и закрепить на практике. Действительно, за это время мы всей командой поняли, что скрывается за SOLID, о чем говорит DDD и многое другое поднятое в статье. Когда начинали над проектом, термин REST было незнакомым (по крайней мере для меня). А тут такое. И при этом развитие шло командное. Это меня радует не меньше.
Я во всей статье старался исходить из того, что и как я понимал. Это сделано специально, чтобы если я что то понимаю не так, то чтобы мне ткнули на это.
Ни в коем случае не обижаюсь. Вы правы). То что продукт будет изменяться, переделываться. И наверняка будет чем то другим чем то, что я сейчас вижу в своем представлении.
Вы правы. Я во многих статьях читал, что mvp должен разрабатываться как можно проще, чтобы не жалко было выкинуть. Но. Мы решили пойти своим путем. Ну реально, мы же имеем право идти и развиваться как считаем нужным. Причину почему я написал и в статьях и в ответе на ваш комментарии в предыдущей статье.
С вами сложно не согласиться. Единственно, когда начинаешь с продаж, то хорошо бы чтобы продажники умели продавать.
В нашем случае также. Мы просто хотели улучшить свою компетенцию как разработчики. В нашем случае, в нашем контексте, в наших планах развития это считалось наиболее важным.
Ни в коем случае не считаю, что наш путь правильный и всем надо так делать. Это глупо.
Но в тоже время нельзя следовать общепринятому, отбросив всю уникальность ситуации в конкретном твоем случае.
Вообще то, для некоторых договоренности на словах имеют больший вес, чем юридически закреплённые договоренности. И я не о криминальном мире.
Для некоторых, клятва на чем действительно ценном, тоже имеет больший вес, чем опять же юридические договоренности. Например "Клянусь детьми".
Чтобы ответить на этот вопрос, надо опять же начать немного с истории. Я в it пришел осознанно и надолго. Это написано в предыдущей статье. Даже если этот стартап не взлетит, то я продолжу этот путь и буду заниматься другими стартапами. В любом случае какую бы идею я не выдвигал, над реализацией будет работать команда разработки.
Иными словами мои идеи зависят от команды разработки. И основная боль для меня была, что она (я тоже нахожусь в команде разработки) была слабая, не хватало компетенции. Значит в долгосрочной перспективе эту задачу все равно решать. Я решил решать сперва эту проблему. Зато теперь, пройдя этот путь, я могу более уверенно смотреть над реальностью реализации продуктов своими силами. Хотя конечно же, нам еще учиться, учиться и учиться... и мы скорее всего все равно будем привлекать опытных специалистов. Но теперь это будет точечное решение проблем.
Проще говоря, я поставил в приоритет долгосрочные цели (иметь опытную команду разработки) в ущерб краткосрочным (реализация mvp).
Ок, спасибо. Не могу не согласиться с вашими доводами.
Я бы конечно не стал минусовать, а написал фидбек в виде коммента.
Интересно, что для читателей тут не к месту? За что минусы?
Не секрет, что нам встречаются в жизни моменты когда эмоции у тебя и у "оппонента" зашкаливают.
Хорошо бы нам учиться справляться с такими моментами.
Автор постарался поделиться своими инструментами.
Что не так?
Рад был бы услышать критику. Что не так?
Этим вы можете сильно мне помочь.)