|
Я это делаю Персональное меню Голосование Клуппы Yato ![]() Деньги, но неинтересная работа и невозможность уделить время семье Интересная работа, возможность саморазвиваться, но нищенский заработок Ваш возраст (не обязательно) Почему? (не обязательно) Голосование закрыто. Поиск по сайту Реклама Статистика |
Часто в программировании одну и ту же задачу можно решить большим количеством разных способов. Когда разные способы очевидны, возникает выбор. При выборе часто задаются вопросом «какой вариант - „правильный“?» Таким образом, «правильная программа» - это термин. Приведённые ниже свойства «правильной программы» следует проверять как для всей программы, так и для любых её фрагментов.
Юрий Попов, popoff.donetsk.ua Смотрите также
Что считать ошибкой?
Обработка ошибок программистами и обработка сообщений об ошибках программами Последняя модификация: 06.08.06 02:22 Обсуждение статьи в форуме 27.07.07 17:52 Aleksey Статья в целом неплохая. Однако существует ряд всяких «но»Например в разделе 1 написано Что касается пункта 3, то на него следует наложить определенные рамки 05.08.07 23:18 popoff Aleksey, Когда я говорил об уменьшении количества входных и выходных данных, я имел в виду не то, что что нужно жертвовать эффективностью во имя простоты, а то, что часто встречаешь программы, в которых несколько независимых между собой задач решаются одной общей функцией и в результате эта функция принимает на вход данные по каждой из задач и возвращает результат по всем задачам. В этой функции сначала решается кусочек первой задачи, потом кусочек второй, потом кусочек третьей, потом снова кусочек первой, а потом снова кусочек третьей. Это вместо того, чтобы сделать три функции, которые решают каждая свою задачу. Когда видишь вот такой алгоритм, состоящий фактически из переплетения нескольких алгоритмов - начинаешь думать одновременно о всех (в данном примере) трёх задачах, которые он решает. Нужно, правда, учитывать, что для начинающих программистов не очевидно, решает ли их алгоритм одну общую задачу или несколько независимых задач. Они наваяли код и думают, что это - самый простой способ. Чтобы понять, что задач решается несколько, нужно иметь опыт. Здесь вопрос в алгоритмизации; в том, чтобы программист понимал, какие задачи и как он решает. Программисты, которые ваяли приведённый в предыдущем абзаце пример, убеждены, что они решали цельную, не делимую на части задачу. Вопрос в п.1 - не о начинающих программистах, которым «понять будет достаточно сложно» чужой алгоритм сортировки. А о тех программистах, которые способны придумать десять собственных способов и выбрать среди них лучший. Дополнительно, по поводу простоты, замечу, что очень многие программисты стремятся повысить эффективность (часто даже не задумываясь над тем, по каким именно критериям) за счёт чаще всего - усложнения кода. При этом единицы удосужатся провести экспериментальные исследования. В большинстве же случаев реально получается так, что придуманные этими программистами фишки для повышения эффективности - только снижают эту самую эффективность. К п.1 могу добавить, что иногда имеет смыл упростить саму задачу. Возможно даже, упростить за счёт эффективности. Ломается обычно лифт, а не лестница. Хотя, конечно, никто же не спорит, что лифт удобнее лестницы. Вот только как Вы будете выбираться из здания, если лестницы не предусмотрены, а свет выключился из-за пожара? В Вашем примере с быстрой сортировкой, сортировка пузырьком - лучше, потому что она понятнее. Этот самый начинающий программист получит более правильную программу, если будет использовать более понятный ему алгоритм. А если он будет использовать метод быстрой сортировки, до конца в него не вникнув, то ошибок не избежать. Но вопрос этот не нужно сводить к личным способностям и наличию/отсутствию лени каждого отдельного программиста. В действительности в методе пузырька нет ничего хитромудрого, в отличие от тех алгоритмов, которые явно можно упростить и, поэтому, назвать неправильными по критерию чрезмерной сложности. П.3 - написано же: «эвристика». Когда я придумывал ту эвристику, я думал не о тех редких случаях многомегабайтных исходников, написанных профессионалами, о которых говорили Вы, а о тех чуть ли ни ежедневно встречающихся мне программках в несколько строк, в которых без комментариев даже автор разобраться не может. Если какая-то часть исходников «винды» - не читабельная из-за отсутствия комментариев, то это совсем не является доказательством того, что другие сложные нечитабельные программы - правильные. Вы привели в качестве примера винду, скорее всего, из-за того, что она не просто большая, она - огромная; чтобы внести туда какие-то изменения и правки, нужно поднять огромное количество людей; необходимость приведения исходников винды в читабельный вид - практически нулевая, потому что она и так работает. У Вас нет автоматических тестов для модулей винды, поэтому, внося изменения в исходники винды Вы не можете быть уверены, что после Ваших изменений она останется работоспособной. Я же в своём примере говорил о случаях, когда программист задумывается о правильности программы и готов для повышения правильности прилагать усилия. Я убеждён, что любой нечитабельный исходник можно рефракторить и привести к читабельному виду, не вводя туда комментарии. 02.09.19 18:03 Kolesik Хорошие программисты сейчас очень востребованы, учитывая что сейчас любое предприятие все свои записи и документы ведет в электронном виде, то такая профессия как программист очень даже хорошая. Вот совсем недавно сам изучал эту тему, нашел в просторах интернета советы https://blog.ithillel.ua/articles/10-sovetov-kak-vybrat-kursy-programmirovaniya-vadуm-drumov как выбрать курсы программирования. Вадим Друмов очень хорошо там все описывает. Просмотреть все комментарии в режиме форума. Всего комментариев: 4
|