В программировании мне известны две реально тривиальные, но сложные задачи:
- Программирование удобного календаря.
- Программирование красивой шкалы по осям на графике.
То есть они настолько хороши, что любую из них можно давать в качестве первой тестовой задачи пришедшему на работу сотруднику и через пару дней про него все будет понятно.
А какие еще есть в том же духе?
Comments
Тимур меня, помниться, потроллил программой, которая выводит
Тимур меня, помниться, потроллил программой, которая выводит собственный листинг собственными средствами. Читать файл с исходником -- неспортивно.
Утверждал, что задача решается минут за 20ть, если программер действительно хорошо знает тот язык на котором проделывает эту хохму.
У меня, конечно, не вышло. Но решение для C он действительно мне прислал минут за 20ть.
Это известная задача, но абсолютно "непрактическая" ("олимпи
Это известная задача, но абсолютно "непрактическая" ("олимпиадная"). Олимпиадных задач много.
А две перечисленные - сплошные достоинства
- не требуют специальных знаний
- практичны
- интуитивно понятны
- сразу видно, тестирует человек свои произведения или нет
- требует внимания к деталям, решение асимптотически улучшается. А первый вариант делается за полчаса.
Сплошные достоинства.
Если бы мне в текущей конфигурации работодателя дали задачу
Если бы мне в текущей конфигурации работодателя дали задачу 1, я бы послал. Потому что я - программист (архитектор уже), а не UI-дизайнер. И определить, что такое удобный календарь, может он, а не я. Собственно, это претензия к "интуитивно понятны" тредом выше - в требованиях такое недопустимо.
У меня в качестве подобной задачки одно время было написание ORM, но у них есть недостаток - за полчаса не сделаешь.
Одно из важнейших свойств сотрудника (в данном случае - прог
Одно из важнейших свойств сотрудника (в данном случае - программиста) - это затраты на коммуникацию с ним. То есть
- много ли надо сил, чтобы объяснить задачу
- поймет ли оно то что объясняли "правильно" (с точки зрения постановщика) или как-то еще
- много ли итераций нужно на уточнение (понимания) задачи.
Ну и так далее.
Ну то есть не можешь определить что такое "удобный" - давай уточнять требования. Считаешь что можешь, но принесешь в качестве решения календарь Майя в 17-ричной системе счисления ("задача не формализована - делал как хотел") - тоже зашибись. Задашь правильные вопросы - +5 в карму.
Задача же - определить возможность легкой коммуникации сотрудника и команды, на модельной (и интуитивно понятной, да!) задаче.
Если ты решаешь такую задачу, то да, в этом случае тест идеа
Если ты решаешь такую задачу, то да, в этом случае тест идеален.
Календарь (вебовский) я рисовал в жизни раза три. Оцифровку
Календарь (вебовский) я рисовал в жизни раза три. Оцифровку графиков - не помню. Помню что один раз это было в Рамблере и рисовал я эту оцифровку руками другого программиста (а я был, типа, начальником) и очень удивлялся, что ему приходится объяснять простейшие и очевиднейшие вещи.
На бегу - неправильно ответил. Да, конечно, начальник решае
На бегу - неправильно ответил.
Да, конечно, начальник решает именно такую задачу. Он заказал HR-у сотрудника, выбрали из N, взяли на работу, но теперь его или обтесать под коллектив или вышибить пока испытательный срок не кончился. Иначе же придется с ним жить.
редактор строки:)
редактор строки:)
В 21-веке - неактуально. К сожалению. Но тоже да.
В 21-веке - неактуально. К сожалению.
Но тоже да.
А что такое удобный календарь?
А что такое удобный календарь?
Каждый видел много НЕУДОБНЫХ календарей.
Каждый видел много НЕУДОБНЫХ календарей.
<q>А какие еще есть в том же духе?</q> Я, на самом деле, под
А какие еще есть в том же духе?
Я, на самом деле, подумал, что еще неплохая (не идеальная) задача в таком роде - это показать человеку на репозиторий(-и) кода, документов и задач, показать там же конкретный небольшой проектик и сказать "разберись до состояния "могу поддерживать", задавая минимум вопросов".
(заодно каждый раз проверяем, насколько хорошо описана задача в репозиториях)
http://sigrand.ru:8280/gitweb/?p=sigcam.git Разберётесь? Док
http://sigrand.ru:8280/gitweb/?p=sigcam.git
Разберётесь? Документации - почти никакой.
На вопросы отвечу, составлю FAQ.
Фиг знает. В любом случае, репозитория задач я что-то не виж
Фиг знает. В любом случае, репозитория задач я что-то не вижу, а это очень важно - привязка каждой конкретной строчки кода к задаче, в рамках которой она была реализована.
Ну вот, отмазались. Я вам не задачи предлагаю разобрать, а s
Ну вот, отмазались.
Я вам не задачи предлагаю разобрать, а software project.
Задача у него одна единственная.
Понимаете, мы в разном контексте. У меня вся работа связана
Понимаете, мы в разном контексте. У меня вся работа связана с корпоративными требованиями, постоянно меняющимися и плывущими. И мне в сотрудниках важно умение в каждый момент времени ответить, почему конкретный кусок кода ведет себя так, а не иначе. При этом большая часть кода, в принципе, с точки зрения программирования - тривиальна. Но каждый раз его править, чинить, рефакторить, не умея при этом его оттрассировать до задачи - смертельно опасно.
И эти требования - хорошо документированы, причем заказчик и
И эти требования - хорошо документированы, причем заказчик изменения этот документ видел и согласился с ним.
А, да, и когда увидел результат (котрый с точки зрения тести
А, да, и когда увидел результат (котрый с точки зрения тестировщика - соответствует требованиям) - в подавляющем количестве случаев соглашается, "да, это то что я хотел"?
Мы стремимся к тому, чтобы (а) требования видел заказчик изм
Мы стремимся к тому, чтобы (а) требования видел заказчик изменения и соглашался с ними и (б) эти требования содержали критерии done done.
Другое дело, что как бы не стремились, нам это удается не полностью. Но по крайней мере для кода мы стараемся иметь возможность сказать: мы это написали потому, что у нас была такая задача вот в такой формулировке.
А у нас корпорация крошечная, нам не до бюрократии. Обзадачи
А у нас корпорация крошечная, нам не до бюрократии.
Обзадачивая каждую строку кода, накладные расходы
съедят проект.
Я охотно допускаю, что есть софтверные проекты, где оверхед
Я охотно допускаю, что есть софтверные проекты, где оверхед на коммуникацию такой, что любой чих - документируют.
Но не надо делать вид, что это - достоинство. Это - недостаток т.к. лишний безумный оверхед на коммуникацию.
Да, часто этот недостаток - вынужденный (много народу, много тупых уродов, распределенная команда), но от этого он не становится достоинством.
Это не достоинство, это данность, обусловленная условиями ра
Это не достоинство, это данность, обусловленная условиями работы. Для LOB applications, сколько бы я их не видел и не писал, всегда получается так.
Для компонентов, для системного софта все, конечно же, совсем иначе. Но даже там сейчас приходится очень сильно закладываться на документирование - но не столько внутренностей, сколько поведенческого контракта. Просто поскольку этот контракт по сравнению с кодом невелик, получается, что оверхед на него невелик.
У меня есть полное ошушение, что в 37signals обходятся миним
У меня есть полное ошушение, что в 37signals обходятся минимумом оверхеда. Хотя Rework я только начал читать, потом плюнул.
Я пошел и прочитал большую часть Getting Real (их же). Им уд
Я пошел и прочитал большую часть Getting Real (их же). Им удается обходиться с минимумом оверхеда, потому что они не работают на заказ, они делают приложение, которое должно выйти на рынок, и завоевать там меньшую или большую долю. И в этом случае их подход (особенно в случае с вебом) работает хорошо. Но в случае с long-running projects, LOB applications и одним постоянным заказчиком, это может и не взлететь (и они сами об этом предупреждают).
Грубо говоря, ни в одном из их приложений нет проблемы "какие из форм, отображающих балансы по акциям, начнут считаться неверно, если я поменяю алгоритм в этой функции (и вообще, какого хрена он здесь написан именно так?)"
Да, с ростом команды или человеко-годов или специфики прилож
Да, с ростом команды или человеко-годов или специфики приложения (от правки кода баланс не должен меняться, даже если раньше считался неверно, или же это должно быть специально оговорено) - оверхед на коммуникации растет. Иногда до 100% времени и более.
Но это означает, что разработчик должен заниматься коммуникациями, а не основным делом.
Лично меня такое положение дел раздражает и смывшись из большой компании (даже если она 10 лет назад была маленькой) я испытываю чувство облегчения.
Вот именно для того, чтобы <i>разработчик</i> не занимался к
Вот именно для того, чтобы разработчик не занимался коммуникациями (ну или минимизировать это), и используются всякие технические средства. Которыми полезно уметь пользоваться.
(хотя навык, конечно, специфический)
Что быстрее - быстро обсудить задачу (при условии наличия вз
Что быстрее - быстро обсудить задачу (при условии наличия взаимопонимания) или формально описать ее при помощи клавиатуры (и других технических средств)? А при наличии телепатической связи (например, постановщик и исполнитель - вовсе один человек)?
Основное назначение формальных ТЗ, которое я встречал в жизни, - это прикрыть чью-то жопу. На практике происходит же следущее
- пишется ТЗ. Или заказчиком, или пишет исполнитель, потом согласует у заказчика
- потом по ТЗ нечто реализуется. И, для простоты, формально ему соответствует, не придерешься.
- после этого потребитель пытается это дело потребить и выясняется что он хотел не того, а того про что написал (или согласовал) - не хотел.
- и все начинают друг на друга валить: "вы ТЗ читали? подписали? формально соответствует? жрите что дают! или платите еще!"
Я даже согласен, что это - какое-то из наименьших зол и способа лучше (годного в ситуации, когда эксплуататоры валят на разработчиков и наоборот) - нет, когда все друг на друга валят, формальное документирование есть единственный способ хоть что-то зафиксировать.
Но играть в эти игры - хочу как можно меньше.
P.S. Ровно в эти минуты пишу мануал, который прочтет, в лучшем случае, два человека.
Вот все рассматривают задачу в контексте ее реализации (и оп
Вот все рассматривают задачу в контексте ее реализации (и описанных тобой взаимных пинков).
А описанная мной проблема возникает тогда, когда задача давно реализована, а теперь надо понять, какой код в системе ей соответствует. И наоборот, какой задаче соответствует вот этот код, и почему в нем изменилась логика.
Т.е., в твоем примере надо сначала обсудить, а потом результат зафиксировать, чтобы всякий, кто придет туда потом, понимал, что это и зачем.
Я понимаю о чем ты. Но я не вижу решения, которое бы мне нр
Я понимаю о чем ты.
Но я не вижу решения, которое бы мне нравилось: вроде и не документировать плохо (не по понятиям) и документировать - еще хуже т.к. "потом" в подавляющем количестве случаев не наступает.
<q>документировать - еще хуже т.к. "потом" в подавляющем кол
документировать - еще хуже т.к. "потом" в подавляющем количестве случаев не наступает.
Вот этого я не очень понял.
Какой смысл писать документацию (большую чем 3-строчное опис
Какой смысл писать документацию (большую чем 3-строчное описание коммита), которую никто не прочтет никогда?
Так прочтет же, в этом и дело. (собственно, разговор началс
Так прочтет же, в этом и дело.
(собственно, разговор начался с того, что считаю, что в навыках разработчика должно быть умение бэктрейса кода на требования)
Причем эта документация не всегда обязана быть радикально больше, чем трехстрочное описание коммита.
Если надо читать и ее нет - плохо. А если есть и не надо чи
Если надо читать и ее нет - плохо.
А если есть и не надо читать - тоже плохо, можно было бы полезным чем-то заняться.
А если есть, надо читать, но реальность не совпадает с написанным - вообще труба.
Вопрос - где у этой функции оптимум.
Ну вот мы его тут локально ищем. Для некоторых задач вполне
Ну вот мы его тут локально ищем. Для некоторых задач вполне удается что-то найти.
А я, в свою очередь, ищу его путем смены задач (или мест раб
А я, в свою очередь, ищу его путем смены задач (или мест работы), путем перебегания в сторону, где количество ненужного (на мой личный взгляд) оверхеда - минимально.
Задачки: HTTP (клиент или сервере) -- без доп библиотек, н
Задачки: HTTP (клиент или сервере) -- без доп библиотек, на сокетах.
Что нибудь веселое, с форками и пайпами (работу с фильтрои например)
Хотя это простые, а вы просили сложную.
Не катит Простая редакци пишетс слишком быстро, это не на п
Не катит
Простая редакци пишетс слишком быстро, это не на пару дней, полноценная - слишком долго, явного обоснования, что именно должно быть сделано за 2 дня - не просматривается
ну как вариант - простой и удобный автокликер
ну как вариант - простой и удобный автокликер
Осталось рассказать мне, что такое автокликер!
Осталось рассказать мне, что такое автокликер!
программа, которая будет кликать (имитировать нажатие мышки)
программа, которая будет кликать (имитировать нажатие мышки) куда надо и как надо.
Применение в повседневности только для каких-то рутинных задач, которые скриптовнием гораздо тяжелее решать или невозможно.
немного с дугова боку
я как-то пытался найти календарную сетку (генератор оной) в векторе... с настраиваемыми шрифтами, цветами... день искал ничего путного не нашёл, потом не выдержал и сам нарисовал под свои нужды.
и это при том что инет забит шаблонами для календарей.
Один из моих знакомых - у него студия технического дизайна -
Один из моих знакомых - у него студия технического дизайна - мучает кандидатов проектом логарифмической линейки или часов. А календарь - да, это и у нас задачка. При том, что оригинальность заказчиком не особо приветствуется обычно.
10 с гаком лет назад мне попалась задачка по работе: написат
10 с гаком лет назад мне попалась задачка по работе: написать полный аналог стандартного виндового file open dialog, чтоб только через dcom броузить тот самый через dcom контупер. Выглядит несложно, но написать-сделать... С тех пор ничем связанным с гуями не занимался, кстати, так что может и не столь уж ужасно всё.
Progress bar! Но если ее давать в качестве тестовой задачи,
Progress bar! Но если ее давать в качестве тестовой задачи, то больше новых сотрудников не будет
Но ведь откуда-то берутся программисты, которые пишут прогре
Но ведь откуда-то берутся программисты, которые пишут прогресс бары?
Пишут-то многие, а вот чтобы написали и он бы работал правил
Пишут-то многие, а вот чтобы написали и он бы работал правильно - я не видел.
Я вот не задумывался о потрохах. Но вот скажем в Мозилле или
Я вот не задумывался о потрохах. Но вот скажем в Мозилле или в мю-торренте - есть прогресс-бары и они не раздражают.
Значит искусство не утеряно!
Progress bar легко сделать для file download, он качается се
Progress bar легко сделать для file download, он качается себе и качается с одинаковой скоростью, поделили сколько скачали на размер да и все.
А вот если процесс неоднородный, вот тут и начинается
А, вот ты о чем. Ты хочешь, чтобы вызывающий говорил, скольк
А, вот ты о чем.
Ты хочешь, чтобы вызывающий говорил, сколько процентов работы он сделал, а progress бар показывал бы сколько минут осталось?
Нет! Меня волновал вопрос как нарисовать ровный зеленый прям
Нет! Меня волновал вопрос как нарисовать ровный зеленый прямоугольничек!
Я хочу чтобы бар двигался более-менее равномерно, пусть будут проценты, но проценты от времени, а не от количества вызванных функций или что там еще обычно в голову программистам приходит
Ну то есть ты хочешь предсказания времени завершения, так ил
Ну то есть ты хочешь предсказания времени завершения, так или иначе.
А зачем еще нужен прогресс-бар? :-)
А зачем еще нужен прогресс-бар? :-)
Чисто чтобы пользователя развлечь, для чего же еще. Ну и что
Чисто чтобы пользователя развлечь, для чего же еще. Ну и чтобы он видел "цифирки бегут - значит не зависло".
Ну то есть в простом случае, когда мы байты и файлы копируем - программа в силах дать какие-то очевидные метрики сколько работы сделано (причем сразу две!), а что делать в более сложном случае? Ну вот компиляция какая-нибудь, там есть метрика в файлах, но это очень неточное же приближение, а более точной у программы и нету.
Ну компиляция, ну и что - мы этот проект компилируем десять
Ну компиляция, ну и что - мы этот проект компилируем десять раз в день, уже даже я знаю, что после clean - полчаса, если один субпроект поменять - три минуты, два - пять минут и т.п. Или, скажем, мы копируем файлы и знаем что это примерно занимает X*количество + Y*размер.
Ну то есть это должен быть сложный программный комплекс, с х
Ну то есть это должен быть сложный программный комплекс, с хранением данных в облаке и ... какие там еще модные слова есть?
О да, сложный программный комплекс из 16 байт в файле проект
О да, сложный программный комплекс из 16 байт в файле проекта и 20 строчек кода чтобы их читать и записывать
Вообще-то нет, даже если мы говорим о компиляции (или о копи
Вообще-то нет, даже если мы говорим о компиляции (или о копировании файлов), метрик будет побольше, иначе предсказание будет сильно мазать как только какой-то неучтенный параметр (флаги компилятора, девайс с/на который копируем) меняется.
И предсказание упирается в возможность вызвавшей (прогресс-бар) программы сообщить правильные метрики, которых вообще-говоря может быть очень много. Ну и в адекватную модель (предсказывающий полином) этой самой программы в прогресс-баре.
Ну то есть примерно понятно как делать, но пользоваться таким прогресс-баром в реальной жизни будет невозможно, слишком много данных хочет.
"Песочные часы крутятся - значит не зависло". Если пользова
"Песочные часы крутятся - значит не зависло".
Если пользователь хочет развлечься - от может переключится в другое окно (с ЖЖ) или сходить на кухню за кофе.
Показать сколько файлов скомпилировано - это status-bar, а не progress-bar.
Если мы можем узнать общее количесто файлов в проекте в начале компиляции, тогда мы можем рисовать progress-bar, в файлах или секундах (посчитав сколько обработано за первые 10 секунд и потом корректируя).
Задача про progress-bar сводится к анализу архитектуры програмы - какие метрики у нас есть и что мы можем показать пользователю.
Просто удивительно, как много задач на интервью просят кандидата в генералы разобрать/собрать автомат, а кандидата в главные бухгалтеры - отсортировать по номиналу кучу мятых купюр.
Да-да, именно к анализу метрик в вызвавшей программе и ее "м
Да-да, именно к анализу метрик в вызвавшей программе и ее "модели". И не только самой программы, скажем отчет по SQL-базе будет вариться разное время в зависимости от загрузки сервера.
И скорее всего модель (т.е. полином куда коэффициенты после первых 10 секунд работы положил - и оценил время завершения) в разных случаях будет разная.
А про генерала и мятые купюры - это правильное замечание, но ведь и реальные дивизии класть на землю на "собеседовании" - тоже накладно.
Песочные часы - не. Нужно дать понять пользователю, что прог
Песочные часы - не. Нужно дать понять пользователю, что программа не вошла в бесконечный цикл.
Проблема бесконечных циклов решается поркой программистов на
Проблема бесконечных циклов решается поркой программистов на конюшне.
эта порка станет БЕСКОНЕЧНОЙ
эта порка станет БЕСКОНЕЧНОЙ
"Зачем тебе отладчик, зараза? Пиши сразу правильно!"
"Зачем тебе отладчик, зараза? Пиши сразу правильно!"
Удобный кредитный калькулятор.
Удобный кредитный калькулятор.
Репортер какой-нибудь. Выглядит наверняка просто: выбрать да
Репортер какой-нибудь.
Выглядит наверняка просто: выбрать данные из какой-нибудь существующей системы, как-нибудь перелопатить, сложить результат куда-нибудь, результат представить пользователю в (полу)статическом виде.
Без поставленного ТЗ даже не
Без поставленного ТЗ даже не возьмусь решать задачи. Есть формальные требования, они должны выполняться. Если требования ну уровне "сделайте мне удобно", то надо брать на работу телепатов. Много раз натыкался на заказчиков, которые сами не знают что хотят, а после того, как им сделаешь, как ты думаешь удобно, окажется, что не хватает перламутра на пуговицах, а ради этого приходится менять весь покрой. Потом окажется, что сроки затянуты, клиент недоволен. Дизайном UI должен заниматься кто-то другой, не программист. Иначе нафига нужны модели, шаблоны, стили?
Ну это означает, что вам не
Ну это означает, что вам не быть моим (к примеру) сотрудником, когда и если я буду их нанимать.
Потому что одно дело - за 5 минут на салфетке нарисовать (а еще лучше - "тут нужен календарь для того-то"), а другое дело - писать формальное ТЗ на календарь со всеми пограничными случаями ("показывать ли неделю следующего месяца, если текущий кончается в воскресенье"). При этом я, конечно, готов поставить задачу более точно, не просто "удобный календарь", а "календарь в поле ввода даты в форме запроса паспорта" (например).
То есть моя задача, как работодателя (или начальника) - на максимально ранней стадии (на собеседовании или испытательном сроке) отсечь (потенциальных) сотрудников, которые требуют слишком много затрат на управление. Пусть идут корпоративные системы писать.
Ну и ситуация "сам не знаю что хочу" - она нормальная, в реальной жизни так бывает всегда.
Можно решать задачу хорошо,
Можно решать задачу хорошо, когда знаешь точно, что именно надо сделать. У меня с интерфейсами всегда было плохо, когда мне приходилось их писать, поэтому, примерив задачу на себя, мне бы хотелось чётких требований. Ну, а что не быть мне твоим сотрудником, я это давно подозревал ;)
Постановка задачи на программирование удобного календаря тож
Постановка задачи на программирование удобного календаря тоже не самая плохая тестовая задача.
Post new comment