tag:blogger.com,1999:blog-6846929136376245264.post4168115662226235279..comments2024-01-03T12:54:39.457+03:00Comments on Привычка не думать: Программисты-олимпиадникиИлья Весеннийhttp://www.blogger.com/profile/12075968879288943233noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-6846929136376245264.post-13091474371478250912013-11-06T10:43:45.686+04:002013-11-06T10:43:45.686+04:00миЛисекунды... ))миЛисекунды... ))Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-74584570712461506832009-09-01T09:22:54.412+04:002009-09-01T09:22:54.412+04:00Chikey, есть такой момент, что сильные олимпиадник...Chikey, есть такой момент, что сильные олимпиадники вынуждены знать большой набор специфических техник (быстрые вариации алгоритмов на специфических типах графов, например). Поэтому простой программист уверенно пролетит, если окажется на серьёзной олимпиаде. А вот программист с олимпиадным прошлым может себя показать неплохо (но, скорее всего, тоже призовых мест не получит, так как будет делать всё медленно - "набитость рук" на отдельные типы задач и постоянные тренировки имеют значение).Илья Весеннийhttps://www.blogger.com/profile/12075968879288943233noreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-35922760723793327742009-08-31T21:07:43.424+04:002009-08-31T21:07:43.424+04:00Ну ну. Вы говорите о школьниках?
Если да, то там н...Ну ну. Вы говорите о школьниках?<br />Если да, то там нет таких крутых задач, которые не сможет решить простой программист. Все задачи однотипные, так или иначе. Нет творчества.Chikeyhttps://www.blogger.com/profile/05535279154870262920noreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-63150152247369867142009-08-31T18:56:36.585+04:002009-08-31T18:56:36.585+04:00Проверка на граничные условия это то - что отличае...Проверка на граничные условия это то - что отличает быдлокод от промышленной разработки. Возможность обработать критические ситуации и не свалиться, а в некоторых случаях и продолжать управление процессом до перехода на ручное управление часто очень важна.Anonymoushttps://www.blogger.com/profile/09478705798209185267noreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-4484185822275923712009-08-31T02:49:29.853+04:002009-08-31T02:49:29.853+04:00Не так давно с удовольствием решил (не полностью, ...Не так давно с удовольствием решил (не полностью, но покатит!) такую задачу.<br /><br />Пишем мультиплеер Microsoft Train Simulator. Есть железнодорожная схема. И есть редактор - корявый, как непонятно что (нет даже выделения нескольких вершин, т.к. тяжело программируется и обломище). Выясняется, что мы где-то забыли какой-то светофорчик, и надо расширить схему. Как это сделать?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-53122978039759870762008-10-07T22:57:00.000+04:002008-10-07T22:57:00.000+04:00Nikita, спасибо за полезный комментарий!Nikita, спасибо за полезный комментарий!Илья Весеннийhttps://www.blogger.com/profile/12075968879288943233noreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-54231014688073718392008-09-27T21:11:00.000+04:002008-09-27T21:11:00.000+04:00Случайно заглянул и хочу добавить пару слов, будуч...Случайно заглянул и хочу добавить пару слов, будучи довольно успешным олимпиадником и одновременно (в последний год) 'промышленным' программистом.<BR/><BR/>Главная польза от олимпиад когда вы идете на работу, по моему мнению, умение писать код. Я слишком часто встречал людей у которых нахождение максимума из набора значений вызывает затруднения. О чем-то более серьезном можете вообще забыть. Эти люди нормальные программиста, у них может быть хороший опыт в ms access или верстке веб-сайтов, но для более серьезной работы вы никого из них не возьмете. Хотя у них и достаточно квалификации для большинства позиций, но если вы хотите роста, я думаю умение писать код будет совсем не лишним.<BR/><BR/>И по поводу понятности. Иногда олимпиады могут провоцировать появление нечитаемого кода, но в целом это не совсем верно. Если вы делаете код который не понимаете, вы убьете пол часа на его отладку. И чем сложнее задача, тем важнее понятность. Это необходимое условие если вы хотите добиться чего-то серьезного на олимпиадах. Даже у самых чемпионистых чемпионов код не работает сразу.<BR/>С другой стороны, конечно, олимпиады не дают software design опыта. Как правильно сказано, если у человека есть голова, он поймет что правила изменились и приспособиться к ним.Anonymoushttps://www.blogger.com/profile/08772451556345040720noreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-51778374976001033182008-09-23T15:54:00.000+04:002008-09-23T15:54:00.000+04:00Mark, спасибо за ссылку на Ронина - он выразил сут...Mark, спасибо за ссылку на Ронина - он выразил суть коротко и точно.<BR/><BR/>Что касается граничных условия, то я уже уточнил эту идею выше: нацеленность на решение <B>несущественной</B> и неразрешимой задачи может заметно помешать в удовлетворении заказчика (исполнении всего контракта). Надо понимать, что важно, а что несущественно, а не слепо следовать за несущественными показателями, называемыми заказчиком.<BR/><BR/>Bkonst, то, что Вы говорите, увы, не всегда достижимо. Очень часто заказчик сам не знает, чего хочет. Поэтому он не может сформулировать. И хоть какие-то уточнения надо вытягивать из него на протяжении всего контракта. И тут не важно, общаться будет программист или менеджер. Если заказчик не знает, то в любом случае придётся а) переделывать, б) игнорировать некоторые требования.<BR/><BR/>Безусловно, есть организации, где такого "бардака" не наблюдается. Но он очень много где есть. И это там считается нормой ("спецификой тематики").<BR/><BR/>Давайте не будем теоретизировать "как надо делать в идеале". Такие идеальные расклады типичны для маленьких и простых задач. В сложных проектах такой ясности почти не бывает (но я не исключаю, что где-то есть). Я говорю про то, с чем сталкивался сам в разных организациях, с чем сталкивались мои близкие друзья и хорошие знакомые в России, Франции и Канаде.Илья Весеннийhttps://www.blogger.com/profile/12075968879288943233noreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-16243912242344468902008-09-23T15:28:00.000+04:002008-09-23T15:28:00.000+04:00Типичная ситуация - заказчик требует удовлетворять...<I>Типичная ситуация - заказчик требует удовлетворять требованию, которое а) никто никогда не будет проверять, б) вообще невозможно проверить (такое бывает и это нормально).</I><BR/><BR/>Это уже ситуация, связанная с умением формулировать задачу (в том случае, если программист сам общается с заказчиком) или умением работы в команде (в том случае, если задача формулируется постановщиком). Естественно, олимпиады этому не учат.<BR/><BR/>Но! важно понимать разницу между такой ситуацией (которая, собственно, вызвана плохим управлением - т.е. вещью, находящейся за рамками полномочий "простого" программиста-кодера - и решаться должна, собственно, на другом уровне) и "граничными условиями", о которых мы говорили изначально.bkonsthttps://www.blogger.com/profile/03538058978623973298noreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-45531721700603691102008-09-23T15:01:00.000+04:002008-09-23T15:01:00.000+04:00Ну на то и нужны постановщики, чтоб формализироваь...Ну на то и нужны постановщики, чтоб формализироваь плохо формализированную задачу. Другой вопрос, что не везде они есть и не всегда адекватные, но вообще это не совсем программистская работа. <BR/><BR/>Ограничения - где-то критичны, где-то нет.<BR/><BR/>> Более того, олимпиадник старается проверять свою реализацию на различные граничные эффекты, а в настоящем мире это никому не надо <BR/>Сомнительное утверждение. Граничные эффекты имеют тенденцию рано или поздно проявляться. Только у олимпиадника как правило это обнаруживается сразу, а то что у пользователя оказывается испорчена работа за пол года - это выяснится через пол года.<BR/><BR/>> Это значит, что главное в реализации - понятность и модифицируемость. <BR/>Вот это правда.<BR/><BR/>> Но у олимпиадника другие привычки: для него понятность программы стоит на последнем месте (ведь её век очень короток - никто кроме него самого не будет читать этот код).<BR/>Называется неумение работать в команде. Да, это часто встречается.<BR/><BR/>Где-то я уже что-то подобное читал... Ах да<BR/>http://victorronin.com/2008/05/19/olimpiadnoe/<BR/>По-моему, гораздо больше похоже на правду.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-28640367815560630792008-09-23T14:50:00.000+04:002008-09-23T14:50:00.000+04:00Bkonst, я с Вами полностью согласен!Моя мысль сост...Bkonst, я с Вами полностью согласен!<BR/>Моя мысль состоит в том, что чрезмерная нацеленность на граничные эффекты - это не жизненный подход. На олимпиадах это работает, а в промышленных задачах - нет.<BR/><BR/>Безусловно, надо проверять корректность действий в критических ситуациях, стараться делать программу максимально надёжной. Но есть случаи, когда это невозможно. И это не должно смущать команду.<BR/><BR/>Типичная ситуация - заказчик требует удовлетворять требованию, которое а) никто никогда не будет проверять, б) вообще невозможно проверить (такое бывает и это нормально). Тогда исполнитель должен писать код, который <B>теоретически</B> соответствует этому требованию. И это <B>устраивает</B> заказчика.<BR/><BR/>Повторюсь: это часто бывает в крупных промышленных проектах и это нормально. Олимпиаднику трудно с этим смириться, он истязает себя попытками решить задачу, которую решить невозможно.<BR/><BR/>Но это не противоречит тому, что надо писать корректный и надёжный код. Надеюсь, сейчас я ясно выразил идею.Илья Весеннийhttps://www.blogger.com/profile/12075968879288943233noreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-14647226844789331952008-09-23T13:47:00.000+04:002008-09-23T13:47:00.000+04:00... и даже если число 1000000, 65535 или 13456 взя...... и даже если число 1000000, 65535 или 13456 взято из головы, необходима проверка того, что случится, если оно будет достигнуто. <BR/><BR/>Как минимум, надо убедиться, что программа не "упадёт" и не унесёт с собой данные клиента; как максимум - сделать так, чтобы программа сама могла решить эту проблему.<BR/><BR/>В реальности часть таких проверок выносится в "нижние" части архитектуры - скажем, прикладному приложению нет смысла самостоятельно обрабатывать конкретный случай выхода жесткого диска из строя. Тем не менее, (хорошее) приложение должно суметь хоть что-то сделать в ситуации "не могу сохранить файл" (выдернули флешку или дискету, пропала сеть или поломался жёсткий диск).bkonsthttps://www.blogger.com/profile/03538058978623973298noreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-48905781402891293882008-09-23T13:17:00.000+04:002008-09-23T13:17:00.000+04:00Bkonst, согласен с Вашим уточнением. Действительно...Bkonst, согласен с Вашим уточнением. Действительно, я слишком широко сформулировал о проверке граничных эффектов. Речь была о нацеленности на проверку именно "корявых" случаев. Например, если в олимпиадной задаче сказано, что некоторое N может быть от 1 до 10000000000, то олимпиадник проверит эти края. Но в реальной жизни число 10000000000 часто берётся из головы. И речь именно об этом: нет резона бороться за достижение фантазий, а надо обеспечивать истинную потребность клиента (поняв её предварительно). Я согласен, что пример какой-то вырожденный. Надо будет подумать над понятной иллюстрацией этой мысли...<BR/><BR/>Aamonster, было бы прекрасно, если бы отдельные люди занимались общением с заказчиком, однако Вы верно указали, что это "в идеале". В реальной жизни так почти никогда не получается :(Илья Весеннийhttps://www.blogger.com/profile/12075968879288943233noreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-59425116403271581372008-09-23T11:14:00.000+04:002008-09-23T11:14:00.000+04:001. Вообще-то в идеале постановкой задачи и пытками...1. Вообще-то в идеале постановкой задачи и пытками заказчика должны заниматься отдельные люди. Умеющие именно общаться с заказчиком и понимающие, как из него вытянуть, что же ему надо.<BR/><BR/>2. Насчет граничных эффектов - не забывайте: "пользователи это осьминоги... восемь кривых шаловливых рук, которые растут из жопы". А программист, напротив, имеет привычку проверять только свой use-case. Поэтому нужна проверка другим человеком - и с крайними случаями.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6846929136376245264.post-29198919487567843652008-09-23T11:01:00.000+04:002008-09-23T11:01:00.000+04:00Всё бы хорошо, да только пассаж про граничные эффе...Всё бы хорошо, да только пассаж про граничные эффекты неверен и вреден. <BR/><BR/>"Граничные эффекты" не просто нужно проверять, но важно проверять - к ним относятся и проблемы безопасности, и переполнения целых чисел, и корректная обработка дат, и масса других вещей. <BR/><BR/>Попробуйте прикинуть, насколько часто пользователи будут обращаться в техподдержку, даже если "граничный эффект" проявляется для каждого конкретного пользователя раз в год, но самих пользователей - несколько тысяч.bkonsthttps://www.blogger.com/profile/03538058978623973298noreply@blogger.com