K>Я, честно говоря, вообще никогда не попадал в ситуацию, когда техническое решение продавливается сверху. Среди адекватных людей всегда все обсуждается и аргументы выслушиваются независимо от должности. Я могу себе конечно теоретически представить заядлого фаната какой-нибудь технологии, который никого слушать не хочет, но от таких людей по-моему проще избавиться.
Я встречал и не раз.
Примеры:
— программа, в которой объектное дерево (довольно разветвлённое и сложное) не строится при загрузке, а имитируется своя база данных, из которой все объекты строятся на лету при необходимости. Аргумент руководства: если строить дерево зависимостей, то сложнее поддерживать его в целостном состоянии.
— REST сервер, где объекты идентифицируются не по уникальному ID, а косвенно (имя, доп. признаки и т.п.). Аргумент: для пользователя неудобно использовать ничего не значащие целые числа.
— Необходимо забабахать отчётную систему на базе существующей DB. Пользователи пользуются другой DB, более новой. Руководство принимает решение вносить изменения, нивелирующие разницу между DB1 и DB2 на клиенте, силами людей, которые не имеют доступа и знаний ни по DB1 ни по DB2, но зато знают хорошо клиента-сервера.
И такие ужасы довольно распространены.
Все будет Украина!
Re[8]: о собеседованиям .Net: Эксмо, ATH , Dentsu Aegis Network
M>Тебе повезло, наверное. Я почти пол года отработал с начальником у которого "прожим — лучший способ решения вопроса" и "если задача все же не решается, то нужно надавить сильнее". Формально мы, конечно обсуждали решения задач, но по принципу "будем обсуждать, пока не примем мое решение". Ну, а если решение приняли не совсем "его" (главный инженер помешал), то в процессе реализации он попросит его изменить, на более правильное. Ах, да, если решение не заработает — виноват всегда исполнитель. А если скажешь, что его решение в определенных условиях не работает или есть решение проще, то, однозначно, заденешь самолюбие со всеми вытекающими...
Здесь какое то двоевластие в компании Такого не встречал.
Бывало что присылали задачу для реализации без необходимости в обсуждении, но в таком случае вся ответственность на постановщике задачи.
Re: о собеседованиям .Net: Эксмо, ATH , Dentsu Aegis Network, Mary Kay, Касперск
Здравствуйте, binarystack, Вы писали:
B>Сложно понять, какая база является достаточной. В плане алгоритмов, конечно печально, я только с самыми примитивными знаком, но этим вопросом занимаюсь. B>Архитектуру нужно вкачивать,как я считаю, на реальном проекте с более опытными коллегами. B>Базовые паттерны и современные подходы я знаю, но вот с ddd пока руки не дошли поиграться. B>Я все это писал к тому, что собеседования показывают какие-то пробелы в знаниях,
...интервьюеров. Все эти алгоритмы (сортировки, разумеется, все остальные неканоничны), паттерны, тестовые задания, TDD, DDD и прочий BDSM -- вещи хорошие, но в последнее время превратились в индикатор пещерности дознавателей, которые выуживают эти вопросы в интернетах. Что же тогда спрашивать на интервью? Допустим, перед вами задача узнать, владеет ли некто русским языком. Вы будете спрашивать про склонения-спряжения?
B>но все равно есть какой-то фундамент, B>который нужно развивать, на данный момент я развиваю только в свободное время, хочу и на работе, уверен, B>что такие места есть, и не везде нужно данные из базы на фронт выводить и делать примитивные интеграции.
Везде. В широком смысле. Это и есть суть программирования: взять данные в точке А и передать их в точку Б.
Re[2]: о собеседованиям .Net: Эксмо, ATH , Dentsu Aegis Network, Mary Kay, Каспе
Здравствуйте, Artem Korneev, Вы писали:
AK>Здравствуйте, binarystack, Вы писали:
B>>Я после этого прочитал книгу про Оптимизации производительности приложений .Net
AK>Какую?
Такого не встречал.
