Много обобщений на основе одного человека из одного банка... из пальца высосанные обобщения на всю страну. Ну такое.
Язык и технологии скорее всего не главная проблема. В легаси обычно главная проблема "как бы так починить вот тут, чтобы ничего не сломалось", или "если я тут исправлю, что я могу сломать и как это протестировать", или "есть ли на свете живой человек который еще помнить как это работает"...
Из собеседований, наблюдаю картину когда разработчик не знает других тестов, кроме юнит. Даже какой-нибудь файловый логер готовы все замокать и протестировать непонятно что.
Я думаю были кандидаты, у которых код был лучше поэтому вам и отказали. Когда есть несколько вариантов решения легче выбрать.
Вообще задание достаточно сложное, что сделать его прямо хорошо не затратив на это слишко много времени. Я бы первым делом погуглил как работают с "cron expression" библиотеки типа Quartz.
По коду:
если говорить про эффективность я бы его заточил на определенный сценарий, например "может быть долгое создание, но быстрый расчет даты"
очень сложный для понимания код, возможно стоило логику парсинга выделить в отдельный класс? с регулярными выражениями возможно этот код был бы проще для понимания
размер объекта сложно назвать оптимальным
алгоритм и структура данных не тривиальна, поэтому должна быть хорошо описана в комментарии к коду
методы расчета дат очень большие и сложные
в эксепшенах никакой информации о контексте ошибки, просто "Invalid character." не очень поможет пользователю понять что же не так
если корректировка времени сильно усложняет код (тем более вас не просили), то я бы не реализовывал это в рамках тестового задания, но написал бы список что можно еще улучшить
простите, но "schedule.cs", когда внутри Schedule, говорит о некоторой небрежности, так же как у другие мелкие недочеты как названия проекта...
юнит тесты которые проверяют внутреннее состояние? ну такое... может это индикатор того, что парсинг хорошо бы положить в отдельный файл?
бенчмарки я бы сделал отдельно на создание, отдельно на методы, ваш бенчмарк если честно не понятно чего намерит
Многие советы из категории "вредных" либо очевидных (что ToList() делать для Count() не нужно). Главное правило в оптимизациях: померить, найти узкое место, исправить, и повторить нужное количество раз. Обычно это доступ к данным и внешним сервисам...
Выдумывание нового подхода к реализации IDisposable напоминает старый анекдот о стандартах... лучше делать так как завещал дедушка Рихтер, тогда не надо будет над каждой реализацией ломать мозг и всем будет проще читать и понимать код.
Интересно на плавучей станции предумотрен случай когда станция может опракинутся, или просто иметь сильный крен. Я понимаю, что этого не может быть и все такое. Но все же, можно ли будет заглушить реактор в перевернутом состоянии, не вывалится ли все из него.
ох я тоже в свое время напарывался на это. если я правильно помню, у нас было сконфигурироание логирование в файл (это можно сделать в конфиге), и получалось что приложение из-за этого станавилось практически одно поточным, так как все потоки ждали лока под которым писалось в файл.
вообще МС рекомендует этот механизм для высокопроизводительного трейсинга, странно было получить такое «оправдание» от них.
Во всем нужен здравый смысл. Хороший код сам по себе мало интересен бизнесу. Нужно чтобы поставленные задачи решались, и продукт был нобходимого качества для пользователей… Банально да, но к пониманию этой банальности сам потратил не один год.
С практической точки зрения, в подобной ситуации поможет хороший тим/тех лид.
Вторая причина глубже. Эта штука пронизывает Россию. И нет, это даже не коррупция, а Тотальная Повсеместная Некомпетентность. Надо признать, что мы страна с подавляющим числом плохих специалистов.
Наблюдаю эту же картину в других странах, не что-то уникальное для России, мне кажется это некоторое стат распределение ). Причем, прособеседовав разработчиков из разных стран, могу сказать что ребята из России, Украины, Белорусии… в среднем сильно лучше.
Сижу я несколько лет назад на заседании российской академии образования. Умудренные и уважаемые люди обсуждают ФГОС (Федеральные государственные образовательные стандарты, то, что ребенок должен изучать в школе) по информатике. И всерьез обсуждают, что надо там оставить Паскаль как язык программирования.
Это если честно напоминает мне картину когда джуниор приходит в энтерпрайз проект и начинает учить «надо переписать все на модный фрейворк X», «надо захостить все кубере» и т.д. Он не задумывается что это даст бизнесу, сколько это ресурсов потребует, сколько человек поддержки нужно будет переучить, как это сделать без остановки бизнеса, и еще 100500 вопросов из реальной жизни.
В XPS 15 были очень ненадежными. У нас компания купила их порядка 30-40 шт и наверное с 10 были проблемы, у 4 из них аккум вздулся (типа известная проблема)… вообщем компания в итоге перешла на другие ноуты. А так ноут приятный.
оо недавно тоже проходил этот квест выбора ноута… требования были противоречивые)
в итоге взял ThinkPad X1 Gen3 i7 64GB 2xSDD, GeForce gtx 1050 ti. Flight симулятор идет)
доволен как слон. из редкого — легкий доступ к памяти и дискам и поддержка 2 ссд (+raid).
С такой автономностью, звучит как лучший на рынке ноутбук. Там можно будет винду запустить? :)
шикарный список!
молодцы! по факту лучша .net конференция в мире.
Много обобщений на основе одного человека из одного банка... из пальца высосанные обобщения на всю страну. Ну такое.
Язык и технологии скорее всего не главная проблема. В легаси обычно главная проблема "как бы так починить вот тут, чтобы ничего не сломалось", или "если я тут исправлю, что я могу сломать и как это протестировать", или "есть ли на свете живой человек который еще помнить как это работает"...
задача именно самописный логер, как удобная задача чтобы пописать немного кода и обудить кучу вопросов около этого.
это собеседование, оно ограничено по времени. мы обсуждаем вопросы дизайна, и тестирования, многопоточности на этом простом примере.
даже абстракный лог будет иметь код который пишет в файл, задача была на этом уровне.
Из собеседований, наблюдаю картину когда разработчик не знает других тестов, кроме юнит. Даже какой-нибудь файловый логер готовы все замокать и протестировать непонятно что.
Я думаю были кандидаты, у которых код был лучше поэтому вам и отказали. Когда есть несколько вариантов решения легче выбрать.
Вообще задание достаточно сложное, что сделать его прямо хорошо не затратив на это слишко много времени. Я бы первым делом погуглил как работают с "cron expression" библиотеки типа Quartz.
По коду:
если говорить про эффективность я бы его заточил на определенный сценарий, например "может быть долгое создание, но быстрый расчет даты"
очень сложный для понимания код, возможно стоило логику парсинга выделить в отдельный класс? с регулярными выражениями возможно этот код был бы проще для понимания
размер объекта сложно назвать оптимальным
алгоритм и структура данных не тривиальна, поэтому должна быть хорошо описана в комментарии к коду
методы расчета дат очень большие и сложные
в эксепшенах никакой информации о контексте ошибки, просто "Invalid character." не очень поможет пользователю понять что же не так
если корректировка времени сильно усложняет код (тем более вас не просили), то я бы не реализовывал это в рамках тестового задания, но написал бы список что можно еще улучшить
простите, но "schedule.cs", когда внутри Schedule, говорит о некоторой небрежности, так же как у другие мелкие недочеты как названия проекта...
юнит тесты которые проверяют внутреннее состояние? ну такое... может это индикатор того, что парсинг хорошо бы положить в отдельный файл?
бенчмарки я бы сделал отдельно на создание, отдельно на методы, ваш бенчмарк если честно не понятно чего намерит
забавно. надеюсь это не был болт на котором все держится )
Идея прикольная. Рисуете здорово!
Если рядом с винтом будет любая веревка/кабель то ее намотает на винт.
Многие советы из категории "вредных" либо очевидных (что ToList() делать для Count() не нужно). Главное правило в оптимизациях: померить, найти узкое место, исправить, и повторить нужное количество раз. Обычно это доступ к данным и внешним сервисам...
Выдумывание нового подхода к реализации IDisposable напоминает старый анекдот о стандартах... лучше делать так как завещал дедушка Рихтер, тогда не надо будет над каждой реализацией ломать мозг и всем будет проще читать и понимать код.
Спасибо за статью!
Интересно на плавучей станции предумотрен случай когда станция может опракинутся, или просто иметь сильный крен. Я понимаю, что этого не может быть и все такое. Но все же, можно ли будет заглушить реактор в перевернутом состоянии, не вывалится ли все из него.
вообще МС рекомендует этот механизм для высокопроизводительного трейсинга, странно было получить такое «оправдание» от них.
Как посмотреть на проект? Вы давайте в начале каждой статьи один абзац говорящий о том что за проект и где его найти, для тех то впервые видит.
С практической точки зрения, в подобной ситуации поможет хороший тим/тех лид.
а если серьезно, то сам попадал в такую ситуацию. простое решение работать в разных проектах, как правило это можно сделать не покидая компании.
Наблюдаю эту же картину в других странах, не что-то уникальное для России, мне кажется это некоторое стат распределение ). Причем, прособеседовав разработчиков из разных стран, могу сказать что ребята из России, Украины, Белорусии… в среднем сильно лучше.
Это если честно напоминает мне картину когда джуниор приходит в энтерпрайз проект и начинает учить «надо переписать все на модный фрейворк X», «надо захостить все кубере» и т.д. Он не задумывается что это даст бизнесу, сколько это ресурсов потребует, сколько человек поддержки нужно будет переучить, как это сделать без остановки бизнеса, и еще 100500 вопросов из реальной жизни.
здравомыслящегобизнес человека?в итоге взял ThinkPad X1 Gen3 i7 64GB 2xSDD, GeForce gtx 1050 ti. Flight симулятор идет)
доволен как слон. из редкого — легкий доступ к памяти и дискам и поддержка 2 ссд (+raid).