Здравствуйте, 0K, Вы писали:
0K>С опытом учишься видеть главное и не зацикливаешься на мелочах. Кстати, достичь сего "просветления" неплохо помогают грамотные вопросы.
0K>Предлагаю в этот топ скидывать такие списки с вопросами (не просто абы-какие вопросы, а вопросы выработанные в результате опыта). Меня больше интересуют вопросы по архитектуре приложений. Хотя не против мельком глянуть и на другие вопросы: по технологиям, по языкам и пр.
Ну к примеру — Все на интерфейсах vs иногда пожертвовать интерфейсами ради лучшей читаемости кода. Естественно для внутренних разработок.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Lloyd, Вы писали: L>>Т.е. вы можете просто-напросто взять и усложнить архитектуру и сделать разработку дороже, несмотря на то, что требования могут и не измениться? L>>Вы действительно счастливый человек. __>а вы можете сьесть тонну креветок? ах, вы ничего про это не говорили.
поэтому еще на этапе проектирования нужно абстрагироваться от всех рисковых вещей, которые могут измениться в будущем.
— это и есть усложнение функционала в угоду возможным изменениям в будущем, котое может и не наступить. У Спольски есть неплохая статья про архитектурных астронавтов, как раз об усложнятелях и абстрагателях.
__>вот и я тоже ничего про усложнение и удорожания вроде не писал. так что не выдумывайте всякую ерунду. если хотите мне возразить, приведите лучше пример изменения требований, когда рефакторинга не избежать простым более грамотным проектированием системы заранее.
Я сейчас в таком работаю. 4 года назад писался как простенький репорт в экселе. Сейчас — под 2 сотни пользователей по всему миру, отдельный сервер приложений для обсчетов, интеграция с хранилищем данных, из которого ежежневно выкачивается какое-то немерянное количество новых записей, каждый день под несколько миллионов записей со стороны пользователей.
Чтобы это предвидеть, надо как минимум быть Ностадамусом.
S>>А теперь-то понял, что незачем этого ламера Фаулера читать с его глупостями. __>дело в том, что рефакторинг звучит как умное слово и не считается чем-то постыдным, именно поэтому вопрос о рефакторинге позволяет реально выяснить, насколько хорошо дела в проекте с архитектурой.
Совершенно верно, но только связь, прямо противоположна той, которую вы обозначили несколькими постами ранее. Нет рефакторинга — код постепенно скатывается в сра*** га***.
__>копиписта, например, считается постыдной и на вопрос "как часто в твоей архитектуре ты используешь копипасту" многие предпочтут ответить "никогда" вне зависимости от реального положения дел,
Конечно, никогда, но не по той причини, что вы описали, а потому что вопрос — бредовый. Что вообще такое "копипаста в архитектуре"?
__>а рефакторинг звучит уже как что-то умное и люди не будут стараться приврать, чтобы выставить себя в лучшем свете
1. Не уловил связи между рефакторингом и копипастой.
2. Рефакторинг не звучит как что-то умное, слово как слово.
Здравствуйте, 0K, Вы писали:
0K>Предлагаю в этот топ скидывать такие списки с вопросами (не просто абы-какие вопросы, а вопросы выработанные в результате опыта). Меня больше интересуют вопросы по архитектуре приложений. Хотя не против мельком глянуть и на другие вопросы: по технологиям, по языкам и пр.
Если бы ко мне пришёл собеседоваться Будда Шакьямуни...
То я бы спросил его про strcspn.
Я ни разу не мучал этим вопросом реальных живых людей. Ни разу. Не потому что я мизантроп, не потому что я не верю в людей, а просто речь об уровне просветления -- я никогда не собеседовал людей на позиции где ТАКОЙ уровень вхождения в тонкости реально требовался бы.
Но раз вы хотите, давайте попробуем.
Итак, это открытый матч, вы можете пользоваться чем угодно, гуглом, головой и соседом, но попробуйте ответить содержательно:
-- что делает функция strcspn, зачем она нужна, что принимает-возвращает, каким пунктом стандарта C99 регламентируется, в каких случаях её использование даёт реальные преимущества (приведите пример кода, приведите альтернативные решения, покритикуйте)
-- как бы вы её реализовали, если бы разрабатывали стандартную библиотеку (запишите код на C)
-- оцените среднее число итераций, которое сделает написанный вами код по равномерно распределённым входным строкам (равномерно распределёнными считаем и строчки образцов тоже). Дайте верхние/нижние асимптотические оценки вашего кода по времени/памяти. Можно ли на них как-то поиграть, выигрывая одно за счёт другого? Какой ценой?
-- проанализировав среднее число итераций предложите оптимизацию этой функции по быстродействию в среднем случае. Сколько позволяет выиграть ваша оптимизация в среднем случае? Сравните реализацию этой функции как минимум в трёх известных вам реализациях стандартной библиотеки C, сравните с вашей реализацией, покритикуйте себя и других
-- обобщая, объясните зачем эта функция вообще включена в стандарт языка C
Здравствуйте, 0K, Вы писали:
0K>Предлагаю в этот топ скидывать такие списки с вопросами
У нас на физтехе когда я был студентом преподаватели говорили, что вопрос по билету на экзамене — это всего лишь предлог для интересной беседы
(по физике конечно).
Я считаю, что все тех-интервью должны строиться на этом принципе, пусть и немного юморном.
Здравствуйте, Tilir, Вы писали:
T>Итак, это открытый матч, вы можете пользоваться чем угодно, гуглом, головой и соседом, но попробуйте ответить содержательно:
T>-- что делает функция strcspn, зачем она нужна, что принимает-возвращает, каким пунктом стандарта C99 регламентируется, в каких случаях её использование даёт реальные преимущества (приведите пример кода, приведите альтернативные решения, покритикуйте)
Мягко говоря, очень станно видеть такой вопрос в ответе на пост, начинающийся со слов
С опытом учишься видеть главное и не зацикливаешься на мелочах.
Вы бы еще предложили спросить, сколько раз встречается артикль "the" в упомянутом стандарте.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Философ, Вы писали: Ф>>Частенько с начала проекта эта фича просто не предполагается. __>когда я написал ту игру iphone даже в проекте не было и портировать ее я вообще никуда не собирался
MV/MVC это уже классика, но сомневаюсь что к примеру компилятор C++ вы написали бы без рефакторинга.
Здравствуйте, Lloyd, Вы писали:
L>С опытом учишься видеть главное и не зацикливаешься на мелочах.
Просто я не согласен в этом с автором Мой опыт подсказывает, что по-настоящему с опытом начинаешь ценить и видеть мелочи и ньюансы. Между прочим вопрос сколько раз артикль the встречается в стандарте C99 кажется мне вполне нормальным Если дан final draft в формате pdf, можно спросить:
— какие библиотеки языка C человек знает (или может нагуглить) для разбора pdf-документов
— попросить сравнить две-три из них, аргументировать выбор подходящей
— попросить написать с использованием выбранной библиотеки код, который считает количество артиклей the в стандарте
— обсудить оптимизацию этого кода и его надёжность
Здравствуйте, UA, Вы писали: UA>Здравствуйте, __kot2, Вы писали: __>>Здравствуйте, Философ, Вы писали: Ф>>>Частенько с начала проекта эта фича просто не предполагается. __>>когда я написал ту игру iphone даже в проекте не было и портировать ее я вообще никуда не собирался UA>MV/MVC это уже классика, но сомневаюсь что к примеру компилятор C++ вы написали бы без рефакторинга.
то есть нельзя построить здание, скажем, МГУ не разломав его снова на части и не переделав посреди постройки?
L>- это и есть усложнение функционала в угоду возможным изменениям в будущем, котое может и не наступить. У Спольски есть неплохая статья про архитектурных астронавтов, как раз об усложнятелях и абстрагателях.
не читал но одобряю. воще видел когда при старте не проекта даже а некого отдельного функционала не очень то и большого в существующем проекте люди говорят "так щас посмотрим, какие патерны тут надо юзать" (и таки находят применение этим патернам, причем и гоф, и фаулер и еще что-нибудь из известного блога).
и все ж согласно и задумчиво кивают — как же мы без патернов, что ж это за архитектура то такая.
правда хорошо — скажешь, да давай сделаем просто вот так, потом если усложняться будет мона тут вот таким макаром будет додолбить. и все облегченно кивнут и спорить не будут (кроме совсем уж клиники), ну вот нашелся один лох, который патернов забоялся, ну шо ж, ответственность на нем в случае проблем — он нам не дал настоящую архтяктуру возвести. а там сделают и забудут.
__>сейчас я пишу один раз код, который слегка меняется во время тестирования, после этого фризится и я им могу лет пять-десять пользоваться не внося ни единого изменения.
а я вспомнил! вот это ваш обсолют, он достигнут и человеческая цивилизация теперь не нужна
Здравствуйте, MescalitoPeyot, Вы писали: MP>А что, в здании МГУ уже появилась психбольница, ядерный бункер и публичный дом? А у Садовничего в планах Евро-2012 на той же площадке?
все поете старую песню об "изменении требований"?
конечно, если бы строительство здания МГУ начали с расширения бытовки для рабочих, то после надстройки второго этажа нужно было бы рефакторить все — разбирать, делать нормальный фундамент и собирать обратно. возможно, некоторые бы так и сделали. дык флаг им в руки. хоть так могут что-то сделать, уже хорошо. таким людям вполне можно доверить строительство деревянных туалетов, но, конечно, от серьезных проектов их надо держать подальше. но ведь и туалеты кому-то надо строить.
T>-- что делает функция strcspn
... T>-- обобщая, объясните зачем эта функция вообще включена в стандарт языка C
Я бы также хотел заслушать ответ на последний вопрос (все остальные достаточно тривиальны и требуют немного времени на подумать и погуглить). Честно скажу, мне было лень, я только чутка голову включил, — и на мой вкус, окромя реализации чего-то подобного printf() cо строками форматирования, где есть РАЗНЫЕ placeholders, в мою включенную голову не приходит.
Я внесу всего один вопрос: ЗАЧЕМ? Вопрос применим в любом контексте, ответ на него дают весьма редко даже весьма просветленные личности. Обычно отвечать начинают на вопрос "почему?".
T>Просто я не согласен в этом с автором Мой опыт подсказывает, что по-настоящему с опытом начинаешь ценить и видеть мелочи и ньюансы.
Написание "ньюанс" — это почетная часть расстрельного списка типичных ошибок, но суть не в этом.
Я, кажется, понимаю вашу мысль: знание мелочей нужно затем, чтобы осознанно использовать язык программирования. Да, когда человек знает все тонкости, он, скорее всего, будет понимать, как именно работает написанный им код. Следовательно, не будет шаманских плясок с бубном, копипасты и индусятины ("а дай-ка я вот этот кусок вот сюда перенесу — вдруг заработает?").
К сожалению, вы сами блестяще иллюстрируете тот факт, что пользоваться языком (в данном случае русским) можно вполне успешно и не заморачиваясь знанием всех его тонкостей. Языки (и языки программирования в том числе) так устроены, что для пользования ими достаточно иметь привычку использования кое-каких конструкций языка. Привычка дает иллюзию понимания.
T>Между прочим(ЗПТ) вопрос(ЗПТ) сколько раз артикль the встречается в стандарте C99(ЗПТ) кажется мне вполне нормальным(ТЧК) Если дан final draft в формате pdf, можно спросить: T>- какие библиотеки языка C человек знает (или может нагуглить) для разбора pdf-документов
Как вам сейчас абсолютно бесполезно знание, сколько запятых вы пропустили, так и кандидату на должность программиста абсолютно бесполезно знание об именах этих библиотек. Вы ведь не используете знание правил русской пунктуации в своей работе? Вам они, скорее всего, и не интересны. Вот и кандидату вопрос о библиотеках странен и неинтересен, если он не планирует работать с парсингом PDF.
T>- попросить сравнить две-три из них, аргументировать выбор подходящей
Коронный вопрос: зачем?
Какие сведения о кандидате вы хотите получить, спрашивая его аргументацию в выборе среди незнакомых (скорее всего) ему библиотек? Является ли он поклонником или же противником опенсорса?
T>- попросить написать с использованием выбранной библиотеки код, который считает количество артиклей the в стандарте
Я не имею ничего против тестовых заданий, если они оправданы. Но вы должны понимать, что наличие тестового задания автоматически сужает число кандидатов, из которых вам придется выбирать. Да, явные остолопы отсеются, но и многие ценные кандидаты от вас отвернутся — кто-то по принципиальным соображениям, у кого-то просто не хватит времени. И чем менее полезным покажется ваше задание кандидату, тем меньше у него будет стимулов за него взяться.
В вашем случае тестовое задание имеет мало практической пользы. Кандидат должен очень хотеть у вас работать.
T>- обсудить оптимизацию этого кода и его надёжность
Если парсингом занимается библиотека, в основном коде будет, скорее всего, однопроходный цикл и счетчик. Вряд ли обсуждение стратегий оптимизации этого кода получится длинным.
Здравствуйте, keenn, Вы писали:
A>>Ну к примеру — Все на интерфейсах vs иногда пожертвовать интерфейсами ради лучшей читаемости кода. Естественно для внутренних разработок.
K>а какие интерфейсы имеются в виду, эти — interface IFace, class Book implements Readable, etc?
Ага, ими можно логику так запутать, что не разберешься.
