У нас по факту интерфейсы используются или чтобы скрыть общение между слоями приложения (напр. чтобы работа с SQL не торчала в домене), или если есть общепринятый в команде паттерн вроде вынесения кода проверки прав в декоратор (чтобы не захламлять логику). В остальных случаях можно жить без интерфейсов и использовать класс напрямую. Но есть в интерфейсах свой плюс, что они позволяют сосредоточиться на контракте при разработке взаимодействия компонентов, т.к. внимание не захламляется деталями реализации, но это слабый аргумент, т.к. IDE имеют для этого механизмы, плюс можно просто самому выписать список методов куда-то отдельно (например в draw.io)
Есть конкретный пример из недавнего - встроенный entity manager по скорости не вывозил - переписали на чистый SQL. При правильном разделении в таком случае затрагивается только инфраструктурный слой, слой приложения не меняется, т.к. интерфейсы остались те же. А, казалось бы, БД та же.
>Неужели лучше скролить файл с несколькими классами?
В крайности можно впадать при любом подходе. Если реализация небольшая и вмещается на пару экранов, то не вижу проблемы связный код в один файл положить. А иначе, конечно, лучше разделять.
Бывают чисто утилитные классы, которые нигде больше не нужны, например, чтобы между методами прокидывать несколько значений. Для таких случай придумали кортежи, но для большей типобезопасности и читаемости можно описать небольшую структурку - в том же файле, т.к. больше нигде не нужно. Смешения разных уровней нет, как и в моем примере с интерфейсом. Не знаю, по-моему так размазывание логики по микрофайлам бОльшая проблема, чем страх положить в один файл несколько классов (в языках, где это возможно). В первую очередь в приоритете читаемость и удобство навигации. Разделение на микрофайлы никак не защищает нас от смешивания разных уровни логики, скорее только скрывает реальные проблемы, т.к. при размазывании по файлам немного теряется общее понимание работы кода.
>Когда смотришь код по файлам пооекта ожидаешь где и что лежит, а тут опана, в контроллере еще какие-то классы лежат.
Есть и обратная ситуация - алгоритм оперирует вложенной иерархией объектов, где часть не имеет смысла без остального (какой-то агрегат, например, или алгоритмическая структура данных), а в итоге всё это размазано по 10 файлам, по которым приходится прыгать туда-сюда, чтобы понять, как это работает. Нужно смотреть по ситуации. Да, в контроллере сразу не придумать, зачем там могут быть лишние классы. Даже в той же Джаве были придуманы "вложенные классы", чтобы можно было несколько классов вложить в один файл, т.к. потребность есть. В Go я часто использую такой паттерн: например, есть сервис, он занимается чем-то своим, но где-то в одной из функций ему нужно делегировать работу в деталь реализации, которую я скрываю за интерфейсом, и если у этого интерфейса потребитель только один (этот единственный сервис, т.к. довольно специфичная одноразовая штука), то я кладу описание интерфейса в тот же файл, что и сервис. Не вижу, в чём тут дичь - сразу в одном месте видно что это такое, я не захламляю проект файлами для мелких интерфейсов, получается такая локализация в одном месте.
>При чтении того, чтобы складывать код нескольких классов в одни файлы, меня покоребило... не знаю на каком языке вы программируете, но это не нормально
Такая практика (1 класс = 1 файл) была популяризована Джавой (где это ограничение рантайма, т.к. исходный файл компилировался в файл типа .class 1-к-1), и было скопировано в PHP, C# и т.п., но по сути ничего плохого в этом нет, если у классов сильная связность и они всё равно меняются вместе. Подход "несколько структур в одном файле" поощряется в Go.
Таймтрекинг хорош для самодисциплины. Т.е. когда сам следишь за своим временем. В первую очередь нужно развивать культуру самодисциплины. Остальное от лукавого.
А как коммерческая компания может с уверенностью сказать, что заказчик находится в сговоре с организацией из санкционного списка, какие есть у неё для этого инструменты? Выглядит так, что проще вообще не иметь дела с российскими компаниями на всякий случай. Но и тут можно завести подставную компанию в каком-нибудь условном Казахстане.
А в чём причина, если не секрет? Британский заказчик? Немного удивляет их упёртость по поводу орфографии, когда все библиотеки и фреймворки используют условный colorize, а британцы упорно в соседнем методе пишут colourise, неконсистентность нисколько не смущает.
>А почему бы не сделать так, чтобы наше отечественное ПО применялось во всём мире
Качественное отечественное ПО обычно очень быстро становится неотечественным благодаря стараниям государства, т.к. в любой момент может прийти товарищ майор со всеми последствиями, и безопаснее всё оформить зарубежом.
>Но я подозреваю, что в нашей вертикали принятия решений про опенсорс либо не слышали, либо слышать не хотят
При регистрации в реестр отечественного ПО есть пункт о возможности использования заморских библиотек с опенсорсными лицензиями (вроде MIT/BSD, но не GPL). Не помню, чтобы видел регламент по проценту от общей кодовой базы. То есть, в принципе, есть возможность написать glue-код, связывающий опенсорсные библиотеки, и назвать это отечественным ПО. Мне кажется, большая часть софта в реестре так и работает :)
Просто на одном из сайтов ФБР решение о том, кому слать письмо и с каким содержанием, делалось внезапно client-side, поэтому автор просто подменил содержание запросов, и вуаля, любые письма с корректным DKIM от лица ФБР. Социальную инженерию можно устроить, но компрометации серверов/данных как таковой не было.
Мне, наоборот, использование термина "ручка" вместо более популярных аналогов намекает на то, что человек работал за всю карьеру примерно в одной компании (кто-то это рассматривает как "мало опыта") и поэтому даже не подозревает, что его могут не понять.
Про "ручку" впервые услышал пару лет назад от представителей Яндекса, и до сих пор режет слух. По-моему, это пошло от них, но не распространено повсеместно (в комментариях с докладов Яндекса часто можно увидеть вопросы вроде "про какие ручки он говорит"?). Обычно же эндпойнт, роут, я сам предпочитаю называть API-метод или REST-метод.
У нас по факту интерфейсы используются или чтобы скрыть общение между слоями приложения (напр. чтобы работа с SQL не торчала в домене), или если есть общепринятый в команде паттерн вроде вынесения кода проверки прав в декоратор (чтобы не захламлять логику). В остальных случаях можно жить без интерфейсов и использовать класс напрямую. Но есть в интерфейсах свой плюс, что они позволяют сосредоточиться на контракте при разработке взаимодействия компонентов, т.к. внимание не захламляется деталями реализации, но это слабый аргумент, т.к. IDE имеют для этого механизмы, плюс можно просто самому выписать список методов куда-то отдельно (например в draw.io)
Есть конкретный пример из недавнего - встроенный entity manager по скорости не вывозил - переписали на чистый SQL. При правильном разделении в таком случае затрагивается только инфраструктурный слой, слой приложения не меняется, т.к. интерфейсы остались те же. А, казалось бы, БД та же.
>Неужели лучше скролить файл с несколькими классами?
В крайности можно впадать при любом подходе. Если реализация небольшая и вмещается на пару экранов, то не вижу проблемы связный код в один файл положить. А иначе, конечно, лучше разделять.
Бывают чисто утилитные классы, которые нигде больше не нужны, например, чтобы между методами прокидывать несколько значений. Для таких случай придумали кортежи, но для большей типобезопасности и читаемости можно описать небольшую структурку - в том же файле, т.к. больше нигде не нужно. Смешения разных уровней нет, как и в моем примере с интерфейсом. Не знаю, по-моему так размазывание логики по микрофайлам бОльшая проблема, чем страх положить в один файл несколько классов (в языках, где это возможно). В первую очередь в приоритете читаемость и удобство навигации. Разделение на микрофайлы никак не защищает нас от смешивания разных уровни логики, скорее только скрывает реальные проблемы, т.к. при размазывании по файлам немного теряется общее понимание работы кода.
>Когда смотришь код по файлам пооекта ожидаешь где и что лежит, а тут опана, в контроллере еще какие-то классы лежат.
Есть и обратная ситуация - алгоритм оперирует вложенной иерархией объектов, где часть не имеет смысла без остального (какой-то агрегат, например, или алгоритмическая структура данных), а в итоге всё это размазано по 10 файлам, по которым приходится прыгать туда-сюда, чтобы понять, как это работает. Нужно смотреть по ситуации. Да, в контроллере сразу не придумать, зачем там могут быть лишние классы. Даже в той же Джаве были придуманы "вложенные классы", чтобы можно было несколько классов вложить в один файл, т.к. потребность есть. В Go я часто использую такой паттерн: например, есть сервис, он занимается чем-то своим, но где-то в одной из функций ему нужно делегировать работу в деталь реализации, которую я скрываю за интерфейсом, и если у этого интерфейса потребитель только один (этот единственный сервис, т.к. довольно специфичная одноразовая штука), то я кладу описание интерфейса в тот же файл, что и сервис. Не вижу, в чём тут дичь - сразу в одном месте видно что это такое, я не захламляю проект файлами для мелких интерфейсов, получается такая локализация в одном месте.
>При чтении того, чтобы складывать код нескольких классов в одни файлы, меня покоребило... не знаю на каком языке вы программируете, но это не нормально
Такая практика (1 класс = 1 файл) была популяризована Джавой (где это ограничение рантайма, т.к. исходный файл компилировался в файл типа .class 1-к-1), и было скопировано в PHP, C# и т.п., но по сути ничего плохого в этом нет, если у классов сильная связность и они всё равно меняются вместе. Подход "несколько структур в одном файле" поощряется в Go.
В unit-тестах меняется на in memory представление :)
Таймтрекинг хорош для самодисциплины. Т.е. когда сам следишь за своим временем. В первую очередь нужно развивать культуру самодисциплины. Остальное от лукавого.
А как коммерческая компания может с уверенностью сказать, что заказчик находится в сговоре с организацией из санкционного списка, какие есть у неё для этого инструменты? Выглядит так, что проще вообще не иметь дела с российскими компаниями на всякий случай. Но и тут можно завести подставную компанию в каком-нибудь условном Казахстане.
>В команде принята британская орфография.)
А в чём причина, если не секрет? Британский заказчик? Немного удивляет их упёртость по поводу орфографии, когда все библиотеки и фреймворки используют условный colorize, а британцы упорно в соседнем методе пишут colourise, неконсистентность нисколько не смущает.
>это проверят и банально не продадут
Это подразумевает, что все коммерческие сделки с российскими компаниями проверяются федеральным правительством перед их заключением. Неужели это так?
Меня всегда интересовало, что мешает делать покупки через подставную компанию? Как такие списки что-то решают?
>А почему бы не сделать так, чтобы наше отечественное ПО применялось во всём мире
Качественное отечественное ПО обычно очень быстро становится неотечественным благодаря стараниям государства, т.к. в любой момент может прийти товарищ майор со всеми последствиями, и безопаснее всё оформить зарубежом.
>Но я подозреваю, что в нашей вертикали принятия решений про опенсорс либо не слышали, либо слышать не хотят
При регистрации в реестр отечественного ПО есть пункт о возможности использования заморских библиотек с опенсорсными лицензиями (вроде MIT/BSD, но не GPL). Не помню, чтобы видел регламент по проценту от общей кодовой базы. То есть, в принципе, есть возможность написать glue-код, связывающий опенсорсные библиотеки, и назвать это отечественным ПО. Мне кажется, большая часть софта в реестре так и работает :)
На момент выхода этой новости на Хабре уже было как 8 часов известно, что никакого взлома не было: https://krebsonsecurity.com/2021/11/hoax-email-blast-abused-poor-coding-in-fbi-website/
Просто на одном из сайтов ФБР решение о том, кому слать письмо и с каким содержанием, делалось внезапно client-side, поэтому автор просто подменил содержание запросов, и вуаля, любые письма с корректным DKIM от лица ФБР. Социальную инженерию можно устроить, но компрометации серверов/данных как таковой не было.
Всё-таки англицизм хорош тем, что при чтении литературы на английском проще, когда на обоих языках примерно один термин, проще ориентироваться.
Не спорю, что термин более древний, чем пара лет -- просто я до этого особо не обращал внимание.
Вот ещё пример:
https://habr.com/ru/company/wrike/blog/475558/#comment_20878414
Опыт опыту рознь :)
Мне, наоборот, использование термина "ручка" вместо более популярных аналогов намекает на то, что человек работал за всю карьеру примерно в одной компании (кто-то это рассматривает как "мало опыта") и поэтому даже не подозревает, что его могут не понять.
Вот пример непонимания: https://habr.com/ru/company/yandex/blog/489048/comments/#comment_21316610
Про "ручку" впервые услышал пару лет назад от представителей Яндекса, и до сих пор режет слух. По-моему, это пошло от них, но не распространено повсеместно (в комментариях с докладов Яндекса часто можно увидеть вопросы вроде "про какие ручки он говорит"?). Обычно же эндпойнт, роут, я сам предпочитаю называть API-метод или REST-метод.