Во время работы над каким то большим проектом львиную долю времени отнимает рутинная работа и очень мало — написание нового кода. А уж разработка алгоритма, решающего какую-то сложную и нетривиальную задачу (проектирование) — просто как манна небесная.
Это касается больших фирм и яндекса в частности. Для малоопытных разработчиков такой вариант программирования вполне нормальный, потому что другого они еще не знают. Но для тех кто уже поработал в интересных и нетривиальных проектах, это ужасный даунгрейд.
Отдаю должное тем интервьюверам, которые на собеседовании рассказывают — чем предстоит заниматся, какие отношения между отделами, какие подходы используются при разработке. В больших фирмах это редкость (имел опыт только с мейлру, в начала коментариев есть похожий опыт с Вами).
В больших фирмах считают что они дают тебе работу и ты им должен до конца дней, поэтому на собеседованиях такое отношение.
В фирмах поменьше с тобой общаются на равных, и предлагают тебе сотрудничество.
Мне кажется они не разработчиков ищут а натаскивают интервьюверов. С таким колличеством желающих копаться с легасикоде крупной компании можно организовывать платные тренинги для интервьюверов.
Друзья, зачет минусуете? (смайлик) Вы же помните о чем написано в книгах о паттернах. В них почти все паттерны для управления сложностью кодом и упрощение модификации и поддержки — это все для людей а не для машин! Нас учат писать код для людей!
на конференциях рассказывают, что с ростом посещаемости были сильно поражены тому, как сильно удалось расширяться не за счет введения в строй новых серверов, а за счет переписывания кода с учетом работы GC.
Это самая большая ошибка программирования. Написание кода не для людей а для машин. Поэтому мы до сих пор все всегда пишем с нуля, потому что существующий код неозможно поддерживать или портировать.
Страутруп писал вроде, что инструменты заставляют нас писать код под эти инструменты. Самый простой пример это прекомпилед хедерс. Только подумайте, мы меняем код только для того чтобы он быстрее собирался! В глобальном смысле это и ведет к тому хаусу что мы сейчас имеем в программировании.
Вот нифига ж себе. Как вы это себе представляете? У вас программа тормозит и жрёт память, как не в себя, заказчик «рвёт и мечет», а вы ему так с вызовом так говорите «это проблема создателей GC»? Будете оптимизировать как миленький.
Не буду, это ошибка проектирования а не оптимизации. Необходимо перепроектирование системы.
Ну смотрите. Я например слышал что все x86 машины давно уже суперскалярные. Весь x86 код транслируется в совсем другие инструкции и выполняется совсем по другому. Все оптимизация что мы делаем на асемблере, актуальны для x86, но не актуальны под реальные процессоры. И я даже слышал что процессор может переименовывать регистры. И что процессор это виртуальная машина, которая имеет внутри микропрограмму и ее можно апгрейдить. Но я не могу уронить процессор, не могу!
Я даже не интересовался как это сделать. Я пишу на шарпе и приблизительно знаю как работает GC основаный на поколениях. И я не буду никогда оптимизировать свой код для GC. Это проблема создателей GC. Я пишу для тех кто будет мой код поддерживать.
Такой подход к собеседованиям напоминает подход из анегдота про милицию. Берут либо сильных либо умных. Мне кажется он найдет или специалиста или человека у которого всегда падает джава машина.
Там помоему весь сыр бор из за естественой реализации наличия у файла двух имен, чтобы можно было использовать и в новых системах и в старых где длинна файла это 8+3
Т.е. разборки не из за какого то супер уникального варианта оптимизаций или другого хитрого алгоритма.
Если есть сервисы которые уже предоставляют для внутрених нужд схожую частную функциональность, то можно использовать эти сервисы для проброса в некоторых слоях.
Можно юзать в одностороннем порядке существующие сервисы, например, для уточнения данных.
Можно написать полностью независимую ветку.
Можно, например, снабжать объекты скрытыми частными интерфейсами и реализовывать внутри объекта (через композицию), но доступ все равно делать через вип сервис.
Главная задача не ломать\захламлять существующие интерфейсы и возможность удаления функциональности без изменений существующих объектов.
По поводу дублирования кода, то у нас он не дублировался. Сервисы были тривиальными и написать даже целую цепочку сервисов было нормально.
habrahabr.ru/post/205980/#comment_7098360
Это касается больших фирм и яндекса в частности. Для малоопытных разработчиков такой вариант программирования вполне нормальный, потому что другого они еще не знают. Но для тех кто уже поработал в интересных и нетривиальных проектах, это ужасный даунгрейд.
Отдаю должное тем интервьюверам, которые на собеседовании рассказывают — чем предстоит заниматся, какие отношения между отделами, какие подходы используются при разработке. В больших фирмах это редкость (имел опыт только с мейлру, в начала коментариев есть похожий опыт с Вами).
В больших фирмах считают что они дают тебе работу и ты им должен до конца дней, поэтому на собеседованиях такое отношение.
В фирмах поменьше с тобой общаются на равных, и предлагают тебе сотрудничество.
Это самая большая ошибка программирования. Написание кода не для людей а для машин. Поэтому мы до сих пор все всегда пишем с нуля, потому что существующий код неозможно поддерживать или портировать.
Страутруп писал вроде, что инструменты заставляют нас писать код под эти инструменты. Самый простой пример это прекомпилед хедерс. Только подумайте, мы меняем код только для того чтобы он быстрее собирался! В глобальном смысле это и ведет к тому хаусу что мы сейчас имеем в программировании.
Не буду, это ошибка проектирования а не оптимизации. Необходимо перепроектирование системы.
Я даже не интересовался как это сделать. Я пишу на шарпе и приблизительно знаю как работает GC основаный на поколениях. И я не буду никогда оптимизировать свой код для GC. Это проблема создателей GC. Я пишу для тех кто будет мой код поддерживать.
Т.е. разборки не из за какого то супер уникального варианта оптимизаций или другого хитрого алгоритма.
Если есть сервисы которые уже предоставляют для внутрених нужд схожую частную функциональность, то можно использовать эти сервисы для проброса в некоторых слоях.
Можно юзать в одностороннем порядке существующие сервисы, например, для уточнения данных.
Можно написать полностью независимую ветку.
Можно, например, снабжать объекты скрытыми частными интерфейсами и реализовывать внутри объекта (через композицию), но доступ все равно делать через вип сервис.
Главная задача не ломать\захламлять существующие интерфейсы и возможность удаления функциональности без изменений существующих объектов.
По поводу дублирования кода, то у нас он не дублировался. Сервисы были тривиальными и написать даже целую цепочку сервисов было нормально.