Только не пытайтесь чрез него смотреть экраны. Особенно вёрстку. Это днище просто: 1) нет увеличения / уменьшения; 2) дикое мыло и артефакты сжатия; 3) это блин поделие само накладывает линейные градиенты сверху и снизу экрана, и ты видишь ни разу не то, что тебе показывает дизайнер
Плагин GitToolbox вообще делает blame автоматически для выделенной строки, помимо всего остального.
А ещё из полезных вещей, которыми почему-то никто не пользуется - Call Hierarchy и Analyze Data Flow to here. Но с первым нужно быть аккуратным и обязательно настроить частный scope на файлы и либы проекта, иначе упёршись в какой-нибудь Thread.run эта штука попытается просканировать весь maven и подвиснет вместе с IDEA
:) Вы не использовали shortcut XYZ 7851 раз. И 7852-й раз не использую, потому что я долго и со вкусом перед эти ковырялся мышкой в run configuration, и кликнуть чуть быстрее, чем опять уходить на клавиатуру
Вынужден отметить, что многие вышеприведённые советы... не вполне эффективны. КМК профессиональный разработчик должен делать всё, что только можно не отрываясь от клавиатуры. Так тупо быстрее, и думать не нужно - только понадобилось, а руки уже сделали. И IDEA это всё поддерживает - достаточно сходить в Help - Keyboard Shortcuts PDF, распечатать, повесить на стену и выучить всё. Тот же Select opened file - под Win Alt-F1 и далее либо Enter сразу, либо куда хочешь... Обратно в окно редактора из дерева проекта - Esc. Ну и так далее, переписывать весь PDF в комментарий к статье (да их там три PDF, по одному на каждую из основных ОС) - дело неблагодарное.
А вот совет который явно отсутствует - научится пользоваться bookmarks, как окном и разными списками заметок, так и установкой именованных по горячим клавишам. Потому что найдя что-то, нужно ещё запомнить где оно и зачем вообще искали. Открывать 100500 файлов и помнить визуально где какая вкладка - можно, но неэффективно. А в этих списках ещё и комментарии можно писать к строке - что имели в виду, когда искали.
Вы не поверите... Если немного учесть, что подключение к конкретной БД - настраиваемый параметр, то есть такая штука как Edit - Find - Search structurally. Там же и replace. Ну или регулярками по тексту, тоже так неплохо работает.
Присоединяюсь к просьбе. Ну очень интересно. Потому что как это бывает на бывшей 1/6 части суши - примерно понятно (дядя - тётя - сват - брат в начальниках али совладельцах). А вот как из рядовых разработчиков / аналитиков в крупной американской конторе в менеджмент попадают - непонятно. Даже термин специальный придуман и не на пустом месте - "Стеклянный потолок". В общем просим ещё главу - "От кеш-линий в кеш-flow" :)
Vaadin? Не то чтобы no-code, но концепцию "щас повесим на on-click бизнес-логику" позволяет реализовать замечательно. А так да... для того, чтобы это вот всё завелось, нужна рядышком ролевая модель и метаданные, какие поля в какой таблице что означают на бизнес-языке, и куда по какой связи ходить можно ... и при каких условиях... и кому... и где и как создавать новые записи. Была такая SugarCRM, которая этот концепт неплохо так развила
Как же SOLID ещё никто не помянул то... А оно ведь работает. Просто не на уровне именования переменных и функций, а на уровне микроархитектуры приложения. Ну возможности распиливания монолита на микросервисы потом, да. PS:
Говорящие имена переменных бесполезны
А что касается выразительности... Зависит от языка конечно, но вот в Java к примеру, не завезли перегрузку операторов и кое-какое наследование, через что адски неудобно делать типы. Т.е. классов с интерфейсами хоть залейся, а вот определить два несовместимых Double, один для градусов цельсия, второй для кельвинов - примерно никак. Ну или городить вычисления словами, а инициализацию через фабрику. А не, это из 2016. Теперь через билдер. Но если он будет порождаться фабрикой, так будет энтерпрайзней, всё равно в половине кода сделано так, а в половине, которая писалась при другом архитекторе, этак. И единственный способ поймать косяк на review - это таки да, говорящие имена. У нас на проекте, если имя локальной переменной не говорит, зачем она тут - MR тут же заворачивается на доработку. Плюс JavaDoc по стандартам, и дополнительно следим, чтобы там было написано ЗАЧЕМ этот параметр, а не что он есть. Иначе получается Сепулька сепулька; //ссылка на сепульку.
ваш код не читают от нечего делать, в качестве развлечения. Ну почти никто. В него смотрят обычно намереваясь обнаруживать и чинить баги. Я могу заверить, исходя из собственного опыта: намного важнее выразительности понимание алгоритма
Есть области, где это не работает. Ну нет описания алгоритма, вот вообще. Есть БТ + Функциональные требования. Есть толковый разработчик, который с утра наливает кофе, открывает тикет, читает, матерится на аналитиков, которые это писали, открывает исходник и начинает соображать, в какое вообще место в коде (который писали три команды за последние семь лет) это можно присрать. И как. По дороге выясняется, что на двадцатой странице БТ написано про семь параллельных линий, на тридцать второй про то, как они должны пересекаться. Ещё через пол-года другой разработчик что-то там унаследует, чтобы одна из линий была в форме котёнка. А ещё через год - выяснится, что всё должно быть совсем не так, потому что Госдума. И очередной новый разработчик, после двух недель на "изучение существующего решения", таки осознает, что алгоритма - нет. То, что написано в ТЗ №1 - вообще не соответствует кодовой базе, потому что были доработки XX и XY, а постановка задачи на фикс с котёнком потонула в переписке двух эффективных менеджеров и РП. Ни один из которых в данный момент в конторе уже не работает. И единственный источник истины - код, потому как стоит в проде и функциональный заказчик почти не ругается. И вот тут говорящие имена переменных, выразительная структура классов и паттерны проектирования где надо, описания зачем так и ссылки на тикеты (хотя в Java сейчас хорошо - есть плагин для IDEA, который умеет показать это для каждой строки прямо в коде) - становятся ключевым фактором сроков выкатки фич. А это уже про чистые деньги.
Большое спасибо за статью. Сейчас тоже в полный рост стоим перед выбором подсистемы кэширования. Пока в фаворе Ignite, собственно у нас на нём больше чем один проект уже, но в сторону Redis тоже посматриваем. Вы их случайно не сравнивали "углублённо"? А то про возможности в статье есть но текстом, а вот например результатов тестирования производительность / объём потребляемой памяти нет... А хочется... Потому что не хочется пилить этот стенд самим :)
Ходить и смотреть глазами я и сам могу :). Но время от времени хочется (и нужно) почитать "роман", особенно при анализе PR / MR, чтобы не держать контекст в голове
Нужно вообще запрещать вывод любых уведомлений на экран заблокированного телефона. Потому как уже есть реальные атаки, если правильно помню нужен только номер телефона жертвы и её же аппарат, на котором можно читать уведомления. Заблокированный годится.
О да! Особенно в связке с Lombok. Не далее как вчера - перестало собираться приложение. Ломбок не ломбочит, билдеры не найдены, 100 однотипных ошибок maven. Внятного сообщения об ошибке - нет. Стал разбираться, что менял. Оказалось - прибил одно поле, которое было явно прописано в mapper-е. В нём самом удалить забыл, это же просто аннотация со строковыми полями. MapStruct на этом предположительно молча падал, после чего не запускался следующий annotation processor. Нашёл только в логе ребилда в IDEA, по паттерну Unknown property .+ in result type, а там и догадался. Минус час жизни.
Всё хорошо в меру. Был у нас разработчик, который обожал разрезать имплементацию на минимальные кусочки, кусочки разложить по иерархиям, снабдить интерфейсами и припудрить Parameter Object, потому что иначе контекст вычислений не передать... И каждый раз, чтобы понять по логу что конкретно пошло не так, нужно было в голове всё это собирать. Потому что глядя на код программы - невозможно понять, при каких условиях какой кусочек кода будет использован. Там ещё и карта Command была до кучи, со строковыми ключами, если правильно помню. Я вот последнее время вообще начал мечтать, чтобы IDEA научилась на место вызова функции рендерить её код, чтобы можно было посмотреть весь контекст выполнения не прыгая по десяти файлам. Ну вроде как рефакторинг Extract method, только с точностью до наоборот, и только чтобы посмотреть. А в случае виртуальной функции - да, рендерить вот тот switch по необходимости
Виртуальные функции. В Java в явном виде их нет, но под капотом именно оно. Был где-то тест, где сравнивали с switch, последний работал ощутимо быстрее. Впрочем, зависит от того, в чём приложение проводит основное время. Где то и Optional имеет смысл выкидывать, потому что сравнение c null - чуть быстрее. Любой инструмент короче с умом применять нужно.
Ну вот я начну... Сделали сначала всё на классах. Не без иерархий на 5+ элементов, но там доменная модель не самая простая. 1С короче пытаемся написать, в своей предметной области естественно. Потом выяснилось, что один класс тащит две (три и больше) обязанностей. Но описывает один объект реального мира, просто с разных сторон. Можно конечно распилить на мелкие классы и каждый в свою таблицу. С учётом полиморфных ссылок на него из других сущностей - как раз появится эта связка в БД 1:1. Пока вот пытаемся выделять мелкие интерфейсы (и класс будет реализовывать несколько таких), а где нужно - использовать их в качестве параметров. Ну и куча мест, где класс должен реализовать строго один интерфейс, если он (класс) достаточно мелкий. А глобально получим некоторый бардак - ненавижу в параметрах функций классы и интерфейсы вперемешку. Поэтому наверно будем реализовать эту вашу... бест практис..., вот
И на одном номере телефона неожиданно могут оказаться пять человек (у которых он основной контактный) и две конторы, у которых он рабочий. Вполне себе кейс в кредитном антифроде
Только не пытайтесь чрез него смотреть экраны. Особенно вёрстку. Это днище просто: 1) нет увеличения / уменьшения; 2) дикое мыло и артефакты сжатия; 3) это блин поделие само накладывает линейные градиенты сверху и снизу экрана, и ты видишь ни разу не то, что тебе показывает дизайнер
Я бы добавил в аналоги Visio - yEd. Местами он реально удобнее даже
Будете перевыкладывать - проверьте вёрстку на Samsung Internet, который в телефоне Galaxy по умолчанию браузер.
Как оно на телефоне
Плагин GitToolbox вообще делает blame автоматически для выделенной строки, помимо всего остального.
А ещё из полезных вещей, которыми почему-то никто не пользуется - Call Hierarchy и Analyze Data Flow to here. Но с первым нужно быть аккуратным и обязательно настроить частный scope на файлы и либы проекта, иначе упёршись в какой-нибудь Thread.run эта штука попытается просканировать весь maven и подвиснет вместе с IDEA
:) Вы не использовали shortcut XYZ 7851 раз. И 7852-й раз не использую, потому что я долго и со вкусом перед эти ковырялся мышкой в run configuration, и кликнуть чуть быстрее, чем опять уходить на клавиатуру
Вынужден отметить, что многие вышеприведённые советы... не вполне эффективны. КМК профессиональный разработчик должен делать всё, что только можно не отрываясь от клавиатуры. Так тупо быстрее, и думать не нужно - только понадобилось, а руки уже сделали. И IDEA это всё поддерживает - достаточно сходить в Help - Keyboard Shortcuts PDF, распечатать, повесить на стену и выучить всё. Тот же Select opened file - под Win Alt-F1 и далее либо Enter сразу, либо куда хочешь... Обратно в окно редактора из дерева проекта - Esc. Ну и так далее, переписывать весь PDF в комментарий к статье (да их там три PDF, по одному на каждую из основных ОС) - дело неблагодарное.
А вот совет который явно отсутствует - научится пользоваться bookmarks, как окном и разными списками заметок, так и установкой именованных по горячим клавишам. Потому что найдя что-то, нужно ещё запомнить где оно и зачем вообще искали. Открывать 100500 файлов и помнить визуально где какая вкладка - можно, но неэффективно. А в этих списках ещё и комментарии можно писать к строке - что имели в виду, когда искали.
Вы не поверите... Если немного учесть, что подключение к конкретной БД - настраиваемый параметр, то есть такая штука как Edit - Find - Search structurally. Там же и replace. Ну или регулярками по тексту, тоже так неплохо работает.
Присоединяюсь к просьбе. Ну очень интересно. Потому что как это бывает на бывшей 1/6 части суши - примерно понятно (дядя - тётя - сват - брат в начальниках али совладельцах). А вот как из рядовых разработчиков / аналитиков в крупной американской конторе в менеджмент попадают - непонятно. Даже термин специальный придуман и не на пустом месте - "Стеклянный потолок".
В общем просим ещё главу - "От кеш-линий в кеш-flow" :)
Vaadin? Не то чтобы no-code, но концепцию "щас повесим на on-click бизнес-логику" позволяет реализовать замечательно. А так да... для того, чтобы это вот всё завелось, нужна рядышком ролевая модель и метаданные, какие поля в какой таблице что означают на бизнес-языке, и куда по какой связи ходить можно ... и при каких условиях... и кому... и где и как создавать новые записи. Была такая SugarCRM, которая этот концепт неплохо так развила
Как же SOLID ещё никто не помянул то... А оно ведь работает. Просто не на уровне именования переменных и функций, а на уровне микроархитектуры приложения. Ну возможности распиливания монолита на микросервисы потом, да.
PS:
А что касается выразительности... Зависит от языка конечно, но вот в Java к примеру, не завезли перегрузку операторов и кое-какое наследование, через что адски неудобно делать типы. Т.е. классов с интерфейсами хоть залейся, а вот определить два несовместимых Double, один для градусов цельсия, второй для кельвинов - примерно никак. Ну или городить вычисления словами, а инициализацию через фабрику. А не, это из 2016. Теперь через билдер. Но если он будет порождаться фабрикой, так будет энтерпрайзней, всё равно в половине кода сделано так, а в половине, которая писалась при другом архитекторе, этак. И единственный способ поймать косяк на review - это таки да, говорящие имена. У нас на проекте, если имя локальной переменной не говорит, зачем она тут - MR тут же заворачивается на доработку. Плюс JavaDoc по стандартам, и дополнительно следим, чтобы там было написано ЗАЧЕМ этот параметр, а не что он есть. Иначе получается
Сепулька сепулька; //ссылка на сепульку.Есть области, где это не работает. Ну нет описания алгоритма, вот вообще. Есть БТ + Функциональные требования. Есть толковый разработчик, который с утра наливает кофе, открывает тикет, читает, матерится на аналитиков, которые это писали, открывает исходник и начинает соображать, в какое вообще место в коде (который писали три команды за последние семь лет) это можно присрать. И как. По дороге выясняется, что на двадцатой странице БТ написано про семь параллельных линий, на тридцать второй про то, как они должны пересекаться. Ещё через пол-года другой разработчик что-то там унаследует, чтобы одна из линий была в форме котёнка. А ещё через год - выяснится, что всё должно быть совсем не так, потому что Госдума. И очередной новый разработчик, после двух недель на "изучение существующего решения", таки осознает, что алгоритма - нет. То, что написано в ТЗ №1 - вообще не соответствует кодовой базе, потому что были доработки XX и XY, а постановка задачи на фикс с котёнком потонула в переписке двух эффективных менеджеров и РП. Ни один из которых в данный момент в конторе уже не работает. И единственный источник истины - код, потому как стоит в проде и функциональный заказчик почти не ругается. И вот тут говорящие имена переменных, выразительная структура классов и паттерны проектирования где надо, описания зачем так и ссылки на тикеты (хотя в Java сейчас хорошо - есть плагин для IDEA, который умеет показать это для каждой строки прямо в коде) - становятся ключевым фактором сроков выкатки фич. А это уже про чистые деньги.
Большое спасибо за статью. Сейчас тоже в полный рост стоим перед выбором подсистемы кэширования. Пока в фаворе Ignite, собственно у нас на нём больше чем один проект уже, но в сторону Redis тоже посматриваем. Вы их случайно не сравнивали "углублённо"? А то про возможности в статье есть но текстом, а вот например результатов тестирования производительность / объём потребляемой памяти нет... А хочется... Потому что не хочется пилить этот стенд самим :)
Ходить и смотреть глазами я и сам могу :). Но время от времени хочется (и нужно) почитать "роман", особенно при анализе PR / MR, чтобы не держать контекст в голове
Две разные реализации под разные профили Spring?
Нужно вообще запрещать вывод любых уведомлений на экран заблокированного телефона. Потому как уже есть реальные атаки, если правильно помню нужен только номер телефона жертвы и её же аппарат, на котором можно читать уведомления. Заблокированный годится.
О да! Особенно в связке с Lombok. Не далее как вчера - перестало собираться приложение. Ломбок не ломбочит, билдеры не найдены, 100 однотипных ошибок maven. Внятного сообщения об ошибке - нет. Стал разбираться, что менял. Оказалось - прибил одно поле, которое было явно прописано в mapper-е. В нём самом удалить забыл, это же просто аннотация со строковыми полями. MapStruct на этом предположительно молча падал, после чего не запускался следующий annotation processor. Нашёл только в логе ребилда в IDEA, по паттерну
Unknown property .+ in result type, а там и догадался. Минус час жизни.Всё хорошо в меру. Был у нас разработчик, который обожал разрезать имплементацию на минимальные кусочки, кусочки разложить по иерархиям, снабдить интерфейсами и припудрить Parameter Object, потому что иначе контекст вычислений не передать... И каждый раз, чтобы понять по логу что конкретно пошло не так, нужно было в голове всё это собирать. Потому что глядя на код программы - невозможно понять, при каких условиях какой кусочек кода будет использован. Там ещё и карта Command была до кучи, со строковыми ключами, если правильно помню.
Я вот последнее время вообще начал мечтать, чтобы IDEA научилась на место вызова функции рендерить её код, чтобы можно было посмотреть весь контекст выполнения не прыгая по десяти файлам. Ну вроде как рефакторинг Extract method, только с точностью до наоборот, и только чтобы посмотреть. А в случае виртуальной функции - да, рендерить вот тот switch по необходимости
Виртуальные функции. В Java в явном виде их нет, но под капотом именно оно. Был где-то тест, где сравнивали с switch, последний работал ощутимо быстрее. Впрочем, зависит от того, в чём приложение проводит основное время. Где то и Optional имеет смысл выкидывать, потому что сравнение c null - чуть быстрее. Любой инструмент короче с умом применять нужно.
В Java класс без проблем замокировать. Кода нужно писать ровно одну аннотацию
Ну вот я начну... Сделали сначала всё на классах. Не без иерархий на 5+ элементов, но там доменная модель не самая простая. 1С короче пытаемся написать, в своей предметной области естественно. Потом выяснилось, что один класс тащит две (три и больше) обязанностей. Но описывает один объект реального мира, просто с разных сторон. Можно конечно распилить на мелкие классы и каждый в свою таблицу. С учётом полиморфных ссылок на него из других сущностей - как раз появится эта связка в БД 1:1. Пока вот пытаемся выделять мелкие интерфейсы (и класс будет реализовывать несколько таких), а где нужно - использовать их в качестве параметров. Ну и куча мест, где класс должен реализовать строго один интерфейс, если он (класс) достаточно мелкий. А глобально получим некоторый бардак - ненавижу в параметрах функций классы и интерфейсы вперемешку. Поэтому наверно будем реализовать эту вашу... бест практис..., вот
И на одном номере телефона неожиданно могут оказаться пять человек (у которых он основной контактный) и две конторы, у которых он рабочий. Вполне себе кейс в кредитном антифроде