andrzejn: (Curious)
[personal profile] andrzejn
[livejournal.com profile] asena просит привести примеры ситуаций из ваших областей деятельности, которые не требуют специальных знаний, а только общей базовой подготовки и сообразительности. Я подумал и подобрал общие вопросы из программирования, которые мы обычно задаём кандидатам на собеседованиях перед тем, как перейти к вопросам по конкретным технологиям.

Но по-моему, они всё равно требуют специальных знаний и опыта. Те, которые ничего не требуют - они не выше начальный классов информатики в школе, это не серьёзно...

1. У нас есть сложная форма ввода: сотни полей и специальные правила на каждом из них (если юзер поставил галочку здесь, показать ему ещё вот эту секцию; если выбрал из списка вот это значение, то автоматически заполнить вот эти поля; вот эти числа просуммировать, сравнить вот с этим полем, и если выйдет больше, то показать ошибку и не дать сохранять; и так далее). Компьютер у нас быстрый, но проверок много, все проверки для всех полей формы занимают в сумме около 0.1 секунды. Какой из вариантов реализации выбрать:

а) сделать сотни маленьких процедурок, чтобы при изменении любого поля отрабатывали только те проверки, на которые это поле влияет;

б) сделать одну большую процедуру со всеми сотнями проверок и вызывать её при изменении любого поля (всякий раз перепроверяя сотни полей, которые не изменялись)?

2. У нас есть автоматический регулятор (допустим, реактора). Есть десяток входных параметров: температура, давление, уровень радиации и так далее. Есть десяток управляющих воздействий: поднимать-опускать стержни, доливать-спускать воду, выпускать пар и так далее. Есть оптимум - один набор входных значений, который означает, что реактор работает идеально. Есть допуски - область значений "оптимум плюс-минус дельта", когда реактор в этой области - всё тоже в порядке. Есть алгоритм управления: на любое состояние на входе мы можем совершить действия, которые приведут реактор в оптимум. Мы живём в реальном мире: параметры реактора постоянно изменяются, и нам постоянно нужно возвращать его в норму. Какой вариант реализации выбрать:

а) при любом отклонении от оптимума немедленно возвращать реактор в оптимум;

б) при выходе параметров из зоны допуска возвращать их в зону допуска, а пока реактор "плавает" туда-сюда в этой зоне - ничего не делать, хотя точно в оптимуме реактор и не будет практически никогда.

3. Вы исправляете баг в программе. В процессе исполнения вы замечаете в исходниках ещё пять похожих по реализации мест, а также два сомнительных алгоритма в соседних модулях. Юзеры и тестеры на те места не жаловались, вроде бы всё работает, да и вы сами не уверены, что там есть ошибки - просто подозреваете. Как действовать:

а) исправив свой баг, пойти и внимательно перепроверить сомнительные места (времени у вас достаточно, спешки нет);

б) записать подозрения для позднейшей проверки и заняться следующим багом из списка;

в) ничего не делать, пока юзеры и тестеры не пожалуются?

4. Программа делает параллельно много вещей (рисует мультик, сортирует файлы на диске, обновляет информацию в базе, реагирует на нажатия клавиш и так далее), то есть в ней запущено множество параллельных процессов. Есть ресурсы, к которым несколько процессов не должны обращаться одновременно (нельзя одновременно перекладывать два разных файла, нельзя одновременно связываться с сетью, нельзя двоим одновременно проверять клавиатуру...). Для этого применяют блокировки: когда один процесс занимает критический ресурс, другие процессы, которые тоже хотят этот ресурс, ждут в очереди. Критических участков у нас четыре: диск, сеть, клавиатура и соединение с базой данных. Процессов у нас десяток, они проскакивают критические участки быстро, поэтому длинные очереди нигде не скапливаются, юзер задержек не замечает. Какой из вариантов реализации выбрать:

а) сделать по одной блокировке на каждый критический ресурс (когда один процесс занимает диск, это нисколько не мешает другому обращаться к сети);

б) сделать одну общую блокировку на все случаи жизни (один процесс занимает диск - и на это время остальные не могут работать ни с базой, ни с клавиатурой...)?

5. Мы пишем программу: большую (команда менее чем из десятка человек не справится) и нужную (миллионы людей будут годами пользоваться этой программой, так что непременно будут новые версии, с исправлениями и доработками). Многие алгоритмы в программе можно сделать разными способами. Какой вариант реализации предпочтительнее:

а) выбирать самые быстрые, экономные по памяти и безупречные по результатам алгоритмы - но они будут большими, сложными для понимания и требовать много времени даже у хороших программистов (у нас хватает хороших программистов, денег и времени);

б) выбирать простые и очевидные для программистов реализации - но они притормаживают заметно для пользователя, отъедают лишние десятки мегабайт памяти, требуют не самого дохлого сетевого канала (ничего фатального, всё работает, у юзеров хватает ресурсов - но задержки, моргания картинки и косметические глюки слегка раздражают)?

Upd.: Добавил правильные ответы.

Date: Saturday, 12 September 2009 08:40 (UTC)
From: [identity profile] gds.livejournal.com
давайте я попробую.

1. в среднем случае -- одну большую, иначе будет сложно уследить, какая мелкая процедура что меняет. Если же имеем гарантии того, что мелкие процедуры обращаются точно к разным элементам (например, не показывают/скрывают один и тот же блок гуи), то можно и их использовать. А в идеале -- строгая разбивка на три секции: 1. взять свойства элементов, влияющих на поведение формы, 2. из них посредством простейших и очевиднейших средств получить результаты, влияющие на свойства подконтрольных элементов, 3. на основании значений из п.2 изменить свойства подконтрольных элементов.

2. зависит от кучи других условий. Например, насколько страшен выход из зоны допуска, насколько быстро он возвращается в зону допуска и насколько хорошо, если реактор точно в оптимуме.
Если когда выход из зоны допуска не страшен, возврат оттуда быстрый и гарантированный, и оптимальные условия по качеству не отличаются от условий в зоне допуска, только тогда можно допускать вариант "б", и он тогда будет гораздо лучше кучи мелких шевелений по варианту "а".

3. если спешки точно нет -- разобраться, отрефакторить нафиг. Но это сферический случай в вакууме. В среднем случае -- комбинация всех вариантов: посмотреть, к чему максимально плохому приведёт баг, если к серьёзным вещам -- разобраться и ниипёт, если нет -- записать подозрительное место, возможные симптомы проявления бага и жить дальше, обращая внимание на свежие баги. Если осмысленно и приемлемо, поставить отладочную печать при входе в подозрительный кусок, чтобы по ней судить о том, мог ли баг быть вызван им.

4. зависит от сложности алгоритмов. К сожалению, блокировки не композиционируются, из-за чего бывают дедлоки. Если очевидно, что с композиционируемостью проблем не будет, лучше делать "одна блокировка на один ресурс". Если вероятны проблемы -- "одна блокировка на все случаи жизни" (лучше, если пару тредов подождут подольше, нежели всё зависнет нафиг). Если есть возможность и удобные средства для работы с message passing, то использовать именно их вместо дебильных блокировок.

5. выбирать модульную архитектуру. А в ней сначала реализовать тупейшие и очевиднейшие алгоритмы (вплоть до возвращения константы в качестве хеша значения), а затем, когда профайлер скажет, переделывать нужные куски. Впрочем, если программистов и времени хватает, то обучить всех модульной архитектуре, и пусть себе пишут хорошие чёрные ящики с хорошими юнит-тестами. Но в идеале -- комбинацию этих подходов, чтобы программисты и пользователи видели результат (хоть и не оптимальный), и чтобы процесс улучшения модулей реально улучшал программу в целом.

Date: Saturday, 12 September 2009 11:48 (UTC)
From: [identity profile] nasse.livejournal.com
Очень понравился ответ на вопрос 5.

Profile

andrzejn: (Default)
Андрій Новосьолов

June 2025

M T W T F S S
      1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16171819202122
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Monday, 16 June 2025 11:59
Powered by Dreamwidth Studios
OSZAR »