Выскажу свое мнение: не очень понравился код из-за "раздутости". То есть методы очень большие по объему кода. Это затрудняет чтение и, как следствие, понимание кода. Вам бы реорганизовать его. Перенести некоторую логику в подклассы, либо отдельные методы.
Вообще по опыту выполнения тестовых могу сказать, что в большинстве не нужно учитывать именно тонкости реализации. Нужно, чтобы +/- работало и все.
Теперь перейдем к ответу, который Вы получили «отвратительно, халтурно». Тут все куда интереснее. Даже если код оставляет желать лучшего, то можно выразится более обтекаемыми выражениями. Человек потратил время, к этому нужно отнестись с уважением. Если такое обращение допускается на начальном этапе отношений, то что будет дальше?! Радуйтесь, что не попали к этому работодателю.
Видимо в скраме тоже нужна градация по уровням. Виктор из рассказа, например, джун сркам-мастер)
Так-то все правильно, но вот скрам как раз можно применять «частично», что собственно Иван и делал «по-колхозному». А почему нет? Взяли полезное, выбросили бесполезное. Такое сплошь и рядом. И пофигу, что «Это уже не скрам». А для чего же он нужен?! Чтобы бизнесу стало легче. А если в команде сплошь аутисты? Или никак команде не перестроить свое мышление уже полгода? Тогда уж лучше и не трогать, а работать по-старому. Иначе бизнесу станет тяжелее.
Скрам — штука хорошая, но если брать его и применять бездумно, то ничего хорошего не получится.
Боль чувствуется только тогда, когда человек находится в сознании. Она стимулирует особь найти способ избавления от боли, то есть вылечиться. Так что для того, чтобы выключить боль достаточно просто «отключить» сознание.
Был недавно под общим наркозом. Может звучит и странно, но мне понравилось — как будто неплохо поспал)
Для школьника, я бы даже сказал, впечатляет. Многие, работая по несколько лет по 8 часов, имеют меньше нывыков, чем этот парень. Да, все индивидуально, но парень однозначно молодец.
Операция сжатия/разжатия требовательна к ресурсам процессора. Поэтому я бы предложил зачитывать файл и паралелльно проводить упаковку/распаковку. Это ускорит производительность программы, хотя и повысит потребление ресурсов. Задание при этом усложнится (причём до уровня junior, а может и middle исполнителя), но при этом станет интереснее.
Да простят меня стажёры!)
Почитал мегатестовое и немного бы его изменил. В свое время решал похожее. Там нужно было наоборот многопоточное решение. Оно добавляло изюминку)… и заодно проверку знаний потоков.
Уж не ошибки ли архитектуры и организации работы пытается оправдывать автор.
Думаю автор описывает классический монолит и как бы намекает, что с ними нужно бороться. В любом случае я воспринимаю статью как метафору, которая говорит именно об этом. В жутком Legacy как раз монолит встречается чаще всего, а потом уже идут другие проблемы. И да — это ошибки архитектуры классического монолита)
Расскажите, пожалуйста, какие именно? Самим интересно.
Легенд не знаю, но попасть в Veeam достаточно трудно. Хотя компания с мировым именем и для такого уровня, видимо, так и должно быть. Опишу свой опыт. Я сам проходил собес в Veeam. Решил тестовое, но лиды завалили на тех.интервью, сказав «Приходите через годик.» На тот момент не искал работу, поэтому не сильно расстроился. Но через время присмотрелся к компании, да и в новостях проскочили, и подумал «а почему бы и нет?!». Решил отправить отклик, но фидбека вообще не получил. Никакого. Ладно бы написали: «Не подходите» или «Вы — в черном списке с прошлого интервью», но просто молчание.
В целом интервью и сама компания в лице лидов и HR с прошлого собеса оставили положительное впечатление. Успехов вам!
хм… вот смотрю на себя и думаю, что сначала работал как описано в «Вот откроешь свой бизнес, там и покомандуешь», то есть старался, вкладывался. А теперь мой принцип «Ты — начальник, я дурак»(наверно это этапы развития такие). Раньше было так: тратил нервы и силы, чтобы что-то доказать, но в итоге тебя все равно не услышат. А сейчас просто говоришь — «Я считаю лучше сделать так, потому-то и потому-то. Но в итоге решать тебе, начальник.» А дальше пускай руководитель либо делает по-моему, либо по-своему и, как правило, начинает расхлебывать. Может есть более конструктивная и выгодная всем сторонам тактика?! Или дело во мне? Объясняю не так?
Рад, что Вам оказались близки мои наблюдения:)
Спасибо за отсылку на материалы. Нужно будет ознакомиться. В личку может скинете также парочку материалов, которые посчитаете полезными?! А про системное мышление мне уже сказали. Не думал, что подобные вещи уже описывались, думал, что это только мой майндсет)
как это не предвидится?
В крупных компаниях уже давно придумали PDM системы
привет, Илья!
Сами PDM-системы, разумеется, есть. Да и я упомянул их. Но не видел я присутствия в них «оркестрирования». Есть, правда зачатки, но это далеко до оркестрирования. И, да, проектирование действительно идет сверху вниз, но не средствами PDM.
не говорил я такого. И, как мне казалось, я ясно дал понять во фразе «ТЗ может поменяться многократно», что я, напротив, допускаю пересмотр интерфейса и его перепроектирование. Я нисколько не возражаю против принципов Agile. Я очень даже за эти принципы и думаю, что они пригодились бы не только при разработке ПО. Тот же канбан пришел к нам из автомобилестроения.
Ну, видимо не получилось донести мысль. Попытаюсь донести мысль про интерфейсы по-другому. Представьте, что сидят на совещании несколько специалистов разных профилей. Каждый видит свою работу, но не работу другого. Они спроектировали механизм, но «сшить» его не могут, так как дали друг другу плохие «интерфейсы». Со временем они начинают «слышать» друг друга. У них появляется мышление, где начинают лучше продумываться «интерфейсы». Это своего рода точки соприкосновения инженеров. Именно им уделяется мало времени. А зря.
Я хотел бы чтобы Вы немного оторвались немного от разработки ПО. Есть же к примеру, инженер-конструктор, ему не дают готовую конструкцию — ему дают, к примеру ТЗ и габаритный чертеж. Вот это уже интерфейс. Ему нужно его реализовать.Может это грубо сказано, но в данном случае вышестоящий инженер как бы говорит «сделай это так, а это так, а в остальном мне все равно. Ты — специалист, ты и думай.» Если уйти от проектирования, то теплообменник физически тоже выглядит как реализация интерфейса: можно поставить теплообменник не одной, а другой фирмы, из другого материала и пр., а результат будет примерно тот же.
Пользователь же ОС работает с чем? С программным интерфейсом. Ему в большинстве случаев все равно какие алгоритмы лежат в работе ОС. Но, интерфейс — это то, что он видит, и вот тут ему уже не все равно. Касаемо теплосети — отдельно взятому цеху все-равно, что творится в остальной части теплосети, главное чтобы в теплообменник приходило что нужно. ТЗ может поменяться многократно, думаю Вы с этим тоже сталкивались. Это значит, что интерфейсу с самого начала уделили мало внимания.
весь код, который был дописан в исходные файлы, нужно вписывать туда заново
В моем случае все было не совсем так. Я использовал кодогенератор, который мог хранить в себе реализацию, то есть описал реализацию в IDE, отддебажил и скопипастил ее обратно в UML, дальше генерируй без опаски что-то потерять. Да, двойная работа, но лучшего не имеем, поэтому… Еще помогло, что помимо прочего он поддерживал реверс-инжиниринг. То есть, если соблюсти определенные формальности, то можно было получить UML из исходников. Но, правда, не все так просто было. Да и на некоторых порах было бы достаточно даже просто рыбы кода. Я вообще не лобирую использовать UML-кодогенераторы. Это мне они жизнь упростили, у других может быть негативный опыт. Да и посыл я делал другой — зачатки инструментов есть, но требуют развития.
А какой кодогенератор использовали Вы? Rational Rose как понимаю?
Выскажу свое мнение: не очень понравился код из-за "раздутости". То есть методы очень большие по объему кода. Это затрудняет чтение и, как следствие, понимание кода. Вам бы реорганизовать его. Перенести некоторую логику в подклассы, либо отдельные методы.
Вообще по опыту выполнения тестовых могу сказать, что в большинстве не нужно учитывать именно тонкости реализации. Нужно, чтобы +/- работало и все.
Теперь перейдем к ответу, который Вы получили «отвратительно, халтурно». Тут все куда интереснее. Даже если код оставляет желать лучшего, то можно выразится более обтекаемыми выражениями. Человек потратил время, к этому нужно отнестись с уважением. Если такое обращение допускается на начальном этапе отношений, то что будет дальше?! Радуйтесь, что не попали к этому работодателю.
Так-то все правильно, но вот скрам как раз можно применять «частично», что собственно Иван и делал «по-колхозному». А почему нет? Взяли полезное, выбросили бесполезное. Такое сплошь и рядом. И пофигу, что «Это уже не скрам». А для чего же он нужен?! Чтобы бизнесу стало легче. А если в команде сплошь аутисты? Или никак команде не перестроить свое мышление уже полгода? Тогда уж лучше и не трогать, а работать по-старому. Иначе бизнесу станет тяжелее.
Скрам — штука хорошая, но если брать его и применять бездумно, то ничего хорошего не получится.
Был недавно под общим наркозом. Может звучит и странно, но мне понравилось — как будто неплохо поспал)
Да простят меня стажёры!)
В целом интервью и сама компания в лице лидов и HR с прошлого собеса оставили положительное впечатление. Успехов вам!
Спасибо за отсылку на материалы. Нужно будет ознакомиться. В личку может скинете также парочку материалов, которые посчитаете полезными?! А про системное мышление мне уже сказали. Не думал, что подобные вещи уже описывались, думал, что это только мой майндсет)
Сами PDM-системы, разумеется, есть. Да и я упомянул их. Но не видел я присутствия в них «оркестрирования». Есть, правда зачатки, но это далеко до оркестрирования. И, да, проектирование действительно идет сверху вниз, но не средствами PDM.
Ну, видимо не получилось донести мысль. Попытаюсь донести мысль про интерфейсы по-другому. Представьте, что сидят на совещании несколько специалистов разных профилей. Каждый видит свою работу, но не работу другого. Они спроектировали механизм, но «сшить» его не могут, так как дали друг другу плохие «интерфейсы». Со временем они начинают «слышать» друг друга. У них появляется мышление, где начинают лучше продумываться «интерфейсы». Это своего рода точки соприкосновения инженеров. Именно им уделяется мало времени. А зря.
Пользователь же ОС работает с чем? С программным интерфейсом. Ему в большинстве случаев все равно какие алгоритмы лежат в работе ОС. Но, интерфейс — это то, что он видит, и вот тут ему уже не все равно. Касаемо теплосети — отдельно взятому цеху все-равно, что творится в остальной части теплосети, главное чтобы в теплообменник приходило что нужно. ТЗ может поменяться многократно, думаю Вы с этим тоже сталкивались. Это значит, что интерфейсу с самого начала уделили мало внимания.
А какой кодогенератор использовали Вы? Rational Rose как понимаю?