Моя производительность в написании программ

[creative]

Maslov в сообщении #358789 писал(а):

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

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

[brimal]

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

А вот когда в рамках одного языка чувствуешь скбя свободно не лишне задуматься
о расширении языкового базиса. Но объять все невозможно. На этой стадии надо определяться: в какой области хочешь работать?

Но пока первая стадия не пройдена лучше не дергаться со сменой мест работы. Учить никто не будет. Мне очень понравился афоризм из одной книги, наиболее точно отражающий суть профессии:"Программисты несчастные люди. они очень увлечены
своей работой, но им не с кем поделиться. Т.к. даже их коллеги не разбираются в чужих программах." (Цитировал по памяти, но смысл думаю не переврал). Программирование это такая отрасль, где единственные учителя книги, примеры и трудолюбие.

[arseniiv]

brimal в сообщении #359158 писал(а):

Программирование это такая отрасль, где единственные учителя книги, примеры и трудолюбие.

Это ваше личное мнение. (Хотя, конечно, пока оно совпадает с моим опытом. Но мне уже не раз доводилось поучиться у людей на форумах.)

[Maslov]

creative в сообщении #359082 писал(а):

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

Практическое программирование в большинстве компаний, специализирующихся на разработке ПО, имеет весьма мало общего с решением учебных/олимпиадных задач. Это существенно менее романтическое занятие: проектирование/программирование пользовательских интерфейсов, работа с базами данных, сетевыми технологиями и т. п. И если Вы не в состоянии разобраться в постановке реальной задачи, спроектировать программную систему, состоящую из нескольких модулей/компонентов, запрограммировать всё это дело и отладить, то толку от Вашей способности переложить Ханойскую башню, уложившись в 13.5 минут и 21 строку исходного кода, мягко говоря, не вагон. Другими словами, решение учебных задач -- это практически всегда "программирование в малом", а реальные задачи -- это "программирование в большом".

Кроме этого, учебные задачи предполагают подход к решению, существенно отличающийся от практического программирования. Ну не пишут парсеры/интерпретаторы "на коленке": давным-давно разработаны стандартные средства и подходы. Поэтому в данном случае, на мой взгляд, для будущей практической деятельности существенно полезнее затратить некоторое время на изучение основ теории формальных грамматик и синтаксического анализа, а потом взять что-нибудь из стандартных средств (типа Flex/Bison, Antlr и т. п.) и решить задачу так, как это делается в реальности. Пусть даже это займет не 20 минут, а неделю, и программа будет не 43 строки, а 500.

И что Вы так привязались к этой скорости? Если Вы не можете в день написать больше 20 строк, то это, скорее всего, говорит о том, что Вы не знаете среды программирования, в которой работаете, и Вам приходится за каждой мелочью (открыть файл, выполнить SQL-запрос, вывести данные в сокет) лезть в Интернет или в help. Ну или Вы просто страдаете перфекционизмом :)

[Zealint]

Тов. Maslov всё правильно говорит. Так называемые промышленные программисты действительно должны знать современные технологии и идти в ногу со временем. Они должны программировать, а не решать задачи. Очень малая часть из них вообще должна что-то решать, кроме примитивных задач, необходимых при разработки ПО: написать цикл, написать SQL-запрос, написать html тэг, и т. д.

В научной сфере, где компьютер используется для вычислений, такие программисты не нужны.

С другой стороны, профессиональный олимпиадник далеко не всегда умеет писать ПО, поэтому на работу его сразу не возьмут, но ему гораздо проще научиться решать промышленные задачи. К сожалению, в науке такой человек тоже мало что может сделать - он не может решать сложнейшую задачу, над которой нужно думать больше 5 часов (длительность стандартной олимпиады). Однако я знаю места, где таких берут на работу без вопросов. Многих, конечно, выгоняют потом...

Но есть олимпиадники, успевающие брать золото на мировых чемпионатах и умеющие разрабатывать очень качественное ПО на десятки тысяч строк в одиночку. Лично знаю только одного.

Зачем я опять выразил свое мнение? Хочу сказать, что нужно сначала определиться с целями, а потом думать кем быть и как к этому стремиться. Кому-то нужно решать ханойские башни за 3-4 минуты, кому-то не надо. Кому-то надо уметь думать над задачей до 3-4 лет подряд, кому-то лучше писать движок для форума на php, натягивать макет и продавать. Программирование бывает разным. Я условно делю его на олимпиадное, промышленное и научное. Эти классы почти не пересекаются. И не должны в современном Мире.

[Scholium]

Maslov писал(а):

Другими словами, решение учебных задач -- это практически всегда "программирование в малом", а реальные задачи -- это "программирование в большом".

Правильно подмечено. «Олимпиадное» и «прикладное» мышление отличает даже математиков теоретиков. Первые приспособились вскрывать орешки с жемчужинами, а вторые долбить гранит в скале, чтобы построить там свой собственный храм. Для программирования я бы еще добавил проблему концептуального мышления. Возьмем простой пример с клиентом базы данных. Подобных клиентов создано море, как для файл-серверных БД, так и для клиент-серверных. Только вот хороших практически нет, в отличие от серверов БД. Сервера (ядра) БД сейчас очень хороши и разного калибра. Таковым является, например, ядро файл-серверного Visual FoxPro или клиент-серверного SQL Server’a. Этот список можно продолжать неограниченно. А вот с клиентами ситуация явно похуже и явно не собирается улучшаться в сторону создания простых, удобных, эффективных, универсальных и т.д. и т.п. программ. Монстроподобных, не универсальных, с тяжеловесными понтами и «рюшечками» - сколько угодно, а действительно простых и удобных («идеальных») практически нет и не предвидится. Т.е. программисты не могут, не хотят или не знают как создать идеального клиента. Если народу интересно, мы можем эту тему развить, но для примера достаточно.

[creative]

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

Но я стремлюсь к другим направлениям в программировании. Самое приоритетное направление это системное/низкоуровневое программирование под ОС семейства *nix (в частном случае под ядро Linux), пока я ещё новичок и ассемблер (для начала IA-32) подтягиваю. Я знаю, что это сложно, но мне очень нравится это направление. И думаю там гораздо больше алгоритмов и нетривиальных задач.
Альтернативным направлением для себя я считаю разработку ядер пользовательских приложений, например, ядро игры или какого нибудь графического редактора. Поэтому понемногу осваиваю и C++ с его объектным подходом. В ядрах приложений тоже много нетривиальных задач и алгоритмов.

Вот поэтому меня беспокоит скорость решения задач, для которых у меня нет инструментов, то есть научится быстрее думать в новых условиях. Google и другие подобные компании рассматривают победителей олимпиад как претендентов. Например, Google Code Jam создан не просто как олимпиада, но и как способ найти лучших претендентов. Например, на сайте Google написано:

Цитата:

If you are interviewing for a software engineering or technical position, you may find it helpful to visit www.topcoder.com. Please launch the 'Arena' widget and go to the practice rooms where you can solve problems in the first and second division.

Меньше всего меня интересует программирование проложений типа биллинга на очень высокоуровневых языках (типа C#) или веб-программирование небольших сайтов на PHP. Нет, я ничего не имею против этих языков, просто это мне не так интересно. Да, я знаю, что будучи системным программистом я буду получать меньше программиста на C#, но не вся же жизнь в деньгах, да и зарплата у системного программиста не нищебродская, поэтому лучше получать немного меньше (но не мало!), но работать на работе, которая действительно нравится.

Вопросы:

Учитывая вышеописанное, остаётся ли в силе Ваш тезис относительно бесполезности решения олимпиадных задач?
Поможет ли мне поиск и модификация open source программ с целью понять их структуру?

[Zealint]

Кто-то из классиков сказал, что задачи делятся на два типа: нерешённые и тривиальные. Первые ещё называют "задачами", а вторые просто "упражнениями". Мне такое разделение очень нравится.

Цитата:

гораздо больше алгоритмов и нетривиальных задач.

Больше всего таких задач (как мне кажется) в направлении "труднорешаемые задачи перечислительной комбинаторики". Там можно взять любую задачу, сформулировать условие так, что понятно школьнику, а потом решать несколько лет. Красота решения таких задач в том, что надо реально придумывать новый подход, настолько новый, чтобы он работал в миллионы раз быстрее старого, потом ещё доказывать, что решение правильное (сверять-то не с чем).

Цитата:

Вот поэтому меня беспокоит скорость решения задач, для которых у меня нет инструментов, то есть научится быстрее думать в новых условиях.

Для этого, очевидно, нужно создавать "новые условия". Решать типичные для программиста задачи с этой целью - не тот вариант. Нужно решать нетипичные задачи.

Если хотите быть системщиком, то тут скорее нужно разбираться в архитектуре ЭВМ, и уметь потом переписывать весь код с выходом нового процессора. На самом деле такие люди тоже нужны для написания ядра какой-нибудь вычислительной системы типа MKL.

[creative]

Zealint

Да, научные задачи программировать круче всего, но это пока вообще за горизонтом для меня, так как в математике я пока продвигаюсь очень медленно и на ближайшие годы мне с головой хватит той дискретной математики (точнее введение в неё), что описывается в книгах по алгоритмам. Так что в обозримом будущем для себя я пока не рассматриваю столь высокий уровень.

Zealint в сообщении #359339 писал(а):

Для этого, очевидно, нужно создавать "новые условия". Решать типичные для программиста задачи с этой целью - не тот вариант. Нужно решать нетипичные задачи.

Ну для меня пока простые олимпиадные задачи по программированию и есть новые условия

Zealint в сообщении #359339 писал(а):

Если хотите быть системщиком, то тут скорее нужно разбираться в архитектуре ЭВМ, и уметь потом переписывать весь код с выходом нового процессора. На самом деле такие люди тоже нужны для написания ядра какой-нибудь вычислительной системы типа MKL.

Именно низкоуровневая архитектура (организация памяти, уровни привелений и т.д.) меня и привлекает.

[Maslov]

creative в сообщении #359334 писал(а):

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

Алгоритмическое мышление пригодится везде, но кроме мышления, в любом программировании требуется ещё довольно большой объём весьма конкретных знаний и умений.

creative в сообщении #359334 писал(а):

Но я стремлюсь к другим направлениям в программировании. Самое приоритетное направление это системное/низкоуровневое программирование под ОС семейства *nix (в частном случае под ядро Linux), пока я ещё новичок и ассемблер (для начала IA-32) подтягиваю. Я знаю, что это сложно, но мне очень нравится это направление.

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

creative в сообщении #359334 писал(а):

И думаю там гораздо больше алгоритмов и нетривиальных задач.

Особенно не обольщайтесь. После того, как пропадает прелесть новизны (а это происходит довольно быстро), в любом программировании доля нетривиальных задач составляет процентов 5-10; всё остальное -- это обычная рутинная работа.

creative в сообщении #359334 писал(а):

Google и другие подобные компании рассматривают победителей олимпиад как претендентов. Например, Google Code Jam создан не просто как олимпиада, но и как способ найти лучших претендентов.

Google всех рассматривает как претендентов. Победа в какой-нибудь олимпиаде -- это несомненный плюс, но отнюдь не является необходимым или достаточным условием для получения работы.

creative в сообщении #359334 писал(а):

Учитывая вышеописанное, остаётся ли в силе Ваш тезис относительно бесполезности решения олимпиадных задач?

Я где-то писал о бесполезности? Решайте, если хотите. Только учтите, что решение таких задач даст Вам только весьма малую часть знаний и умений, необходимых в практической деятельности.

creative в сообщении #359334 писал(а):

Поможет ли мне поиск и модификация open source программ с целью понять их структуру?

Ну а почему нет? Если Вы собираетесь заниматься разработкой графических редакторов, то весьма полезно взять, например, Gimp и попытаться понять, как он работает.

[Scholium]

creative писал(а):

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

Что за глупости? Да, без алгоритмического мышления Вы шагу не ступите в программировании, хоть низкоуровневым, хоть высоко.

creative писал(а):

Но я стремлюсь к другим направлениям в программировании. Самое приоритетное направление это системное/низкоуровневое программирование под ОС семейства *nix (в частном случае под ядро Linux), пока я ещё новичок и ассемблер (для начала IA-32) подтягиваю. Я знаю, что это сложно, но мне очень нравится это направление. И думаю там гораздо больше алгоритмов и нетривиальных задач.

По поводу ассемблера. Не знаю как в Юниксоидах, но в Виндозе программировать на ассемблере одно удовольствие. Сложность собственно языка минимальна, но выразительность его максимальна. Аналогия – двоичная система, состоящая только из нулей и единиц. Общая структура – проще некуда, но закодировать в ней можно любую самую сложную информацию. Windows ассемблер хорош, например, тем, что учиться ему можно просто рассматривая бинарные коды exe-программ. Поверьте, реальные коды не сравнить с учебными. А получить ассемблерный код из бинарного можно очень просто. Для этого существует прекрасный инструмент выпускника мехмата МГУ Ильфака Гильфанова IdaPro v. 5.7, способный даже строить псевдокод (из практически любого бинарника) на уровне языка Си. Особенно здорово, если exe-шник или dll-ка имеют отладочные символы (что особенно характерно для мелкософтовских продуктов). Тогда декомпилированный код отличается от исходного разве что только отсутствием комментариев. Подобную технику использования ассемблера можно посмотреть в «Полная перекомпиляция программы write.exe или тестируем демо-версию IdaPro 5.6» и в «Полная перекомпиляция простых exe-программ или тестируем демо-версию IdaPro 5.7». Исследование даже таких простых программ дает столько нюансов программирования на ассемблере, о которых не прочтешь ни в каких книгах (впрочем, одно другому не мешает). Таким образом, это очень хороший способ обучаться реальному кодированию на ассемблере. Кстати, существует сайт, на котором представлен, в том числе си код, чуть ли не всей декомпилированой Виндозы (для эмуляции выполнения Win32 программ на Линуксоидах).

Совершено аналогично очень полезно обучаться высокоуровневому языку, изучая опен сорц. Только как и везде нужны собственные идеи даже для применения чужого продукта. Американцы, по-видимому, не зря говорят о «ползучем перетекании власти к профессионалам - технократам».

[creative]

Maslov, Scholium, Zealint

Спасибо, с этими моментами теперь всё более понятно.

Только что мне удалось сформулировать причины моей очень медленной разработки:

Сейчас я думал, что работа над текущей программой после 8 месяцев почти завершена как только я опять обнаружил серьёзную недоработку в ней. Три месяца назад я тоже думал, что закончил написание программы, как опять обнаружил серьёзную недоработку.
Проблема в том, что смотрю я на этот код, а через две недели обнаруживаю, что он вообще не годится, опять обнаруживаю серьёзные недостатки. И так каждый раз. Сейчас у меня уже паника Непонятно, как вообще завершить написание программы без серьёзных багов. Постоянно что-то новое вылезает.

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

[Joker_vD]

creative
Пишите спецификации, находите инварианты и верифицируйте написанное. Это очень муторно, но других способов нету.

[Maslov]

Joker_vD в сообщении #359450 писал(а):

Пишите спецификации, находите инварианты и верифицируйте написанное.

К сожалению, в реальных задачах формальная проверка правильности практически неприменима (кроме простейших случаев).

[creative]

Как быть тогда? Дело в том, что это модуль веб-сервера, документации к API практически нет, приходится самому смотреть исходники. Некоторые API сначала кажутся однозначными, а потом обнаруживаются нюансы их работы, которые сводят на нет их использование для моих целей.
И ещё по поводу автоматического тестирования, дело в том, что модуль работает вместе с сервером и статически протестировать его нет возможности. То есть я не могу запустить отдельную функцию модуля так сказать в оффлайне и дать ему тестовые данные на вход, так как большинство функций модуля принимают на вход инициализированные веб-сервером структуры. То есть единственная возможность тестировать работу модуля это в запущенном сервере, к которому я посылаю запросы.

И вот тут проблема! Например, сделав несколько запросов и посмотрев в debug_log я вижу, что всё работает как задуманно, а потом оказывается, что при определённой комбинации запросов или по прошествии времени как-то не так память высвободилась. Потом я изменяю часть кода, делаю более безопасной и конкретно эта проблема исчезает.

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

Потом смотрю на код, тестирую... вроде всё работает. Тестирую ещё, работает.... и т.д.

И опять через месяц я обнаруживаю, что нибудь новое, что раньше не замечал...

Конца этой разработки я не вижу (хотя бы убрать критические баги).