Самый недооцененный инструмент программирования [закрыто]

У нас есть много отличных инструментов, которые очень помогают при программировании, таких как текстовые редакторы хороших программистов, IDE, отладчики, системы контроля версий и т. Д. Некоторые инструменты более или менее «должны» иметь инструменты для выполнения работы (например, компиляторы). ,

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

Какой инструмент программирования вы считаете самым недооцененным один? Мотивируйте свой ответ.

Резиновая утка. Да, действительно.

http://en.wikipedia.org/wiki/Rubber_duck_debugging

Отладка Резиновая утка , резиновый утенок и испытание резины Даки неформальные термины , используемые в разработке программного обеспечения для обозначения метода отладки кода. Название - отсылка к вероятной апокрифической истории, в которой неназванный опытный программист всегда держал бы резиновую утку за своим столом и отлаживал свой код, заставляя себя построчно объяснять это утке.

Чтобы использовать этот процесс, программист объясняет код неодушевлённому объекту, такому как резиновая утка, ожидая, что при достижении фрагмента неправильного кода и попытке объяснить его, программист заметит ошибку. При описании того, что должен делать код, и наблюдении за тем, что он на самом деле делает, любое несоответствие между этими двумя становится очевидным ...

Ручка и блокнот.

1. Работает без электричества.
2. Портативный.
3. Каракули в / в, когда скучно на совещаниях
4. Храните полезную информацию.
5. Если оно записано, люди придают ему больше значения.
6. Другие могут читать и учиться.

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

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

Хорошие инструменты XML жизненно важны - если вы работаете с файлами XML более десятка строк или несколько схем. Иногда вам нужно больше, чем просто подсветка основного синтаксиса, которую предоставляют другие редакторы. Также при работе с XML изучение XSL может быть очень полезным. Много раз я видел, что можно сделать с помощью простого XSL-преобразования, выполненного во многих строках кода приложения. Хотя, чтобы уточнить: я не предполагаю, что сам XML является «недооцененным инструментом программирования»; Я полагаю, что ценность хороших редакторов XML недооценивается из того, что я видел.

Регулярные выражения

Они просто так полезны. Они помогают при поиске в файлах журналов, разборе текста и т. Д. Они просто чрезвычайно полезны.

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

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

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

Google. Существует очень мало проблем, которые еще не были решены и задокументированы. Хорошо настроенный запрос Google может сэкономить много времени.

Самым недооцененным инструментом для поиска «узких мест» является Ctrl+ Cили кнопка «Пауза» в отладчике.

Проверьте для начала последний абзац этого поста , и этот пост , и этот пост .

Столько раз я вижу / слышу, как люди говорят: «Программа слишком медленная! Что я могу с этим поделать? Я пробовал профилировщик (если они это сделали), но я не понимаю, что он говорит. У кого-нибудь есть какие-то догадки? Помогите! " Ну, догадки только это. То, что я всегда делал, как и другие, - это запуск, прерывание и проверка стека вызовов. Если проблема действительно плохая, бинго , она прямо перед вами. Если проблема только легкая, вы делаете это несколько раз. Все, что можно обнаружить в более чем одном образце, которого вы можете избежать, является узким местом, которое вы можете исправить.

Да, это приманка, но это работает.

Какой тип инструмента программирования вы считаете наиболее недооцененным? Мотивируйте свой ответ.

Компилятор

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

Твой мозг. Другие инструменты не имели бы большого значения без него.

Старый добрый:

print

Иногда полезны отладчик, профилировщик или блок-схема UML. И иногда они сводят тебя с ума. Я всегда возвращаюсь к использованию операторов print (или trace, или NSLog, или what-have-you) просто для того, чтобы убедиться, что мой код делает то, что, я думаю, он делает, когда я думаю, что он делает это.

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

Ручка и доска.

Вы не можете победить низкую технологию, пытаясь что-то объяснить.

извед . Это как grep -r, но он предназначен для поиска через ваш исходный код.

Perl и другие скриптовые языки. Отлично подходит для задач, которые слишком сложны для инструментов с графическим интерфейсом, таких как Agent Ransack.

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

Поэтому, как правило, используйте хорошие инструменты (IDE / редактор) и узнайте, как использовать большинство функций, которые они предоставляют.

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

Используйте их, и вы легко перейдете к написанию корректного обслуживаемого кода, который соответствует принципу СУХОЙ и самодокументируется.

Модульное тестирование предлагает следующие преимущества:

• Разработчики становятся первыми клиентами кода. Чем быстрее обнаружена ошибка, тем дешевле ее исправить. Ошибки могут быть пойманы перед сборкой, установкой или развертыванием .
• Тестирование меняет вашу точку зрения на код. Дизайн понятен? Это обрабатывает угловые случаи?
• Эффект Хоторн улучшит качество, просто объявив, что команда публикует показатели качества / тестирования.
• Даже если тесты не включены в систему контроля версий, они могут стать отличным способом для изучения и изучения нового ландшафта.
• Высокая вероятность меньшего количества ошибок!

Генераторы кода

Генераторы кода могут создать большое количество эффективного и безошибочного кода из простого определения. Использование типов ORM наиболее очевидно для создания классов доступа к данным, но существует гораздо больше потенциальных применений.

Поддержка генерации кода, похоже, все еще находится в зачаточном состоянии как с точки зрения программиста, так и с точки зрения фреймворка, но я верю, что мы увидим это все больше и больше. В .NET вы можете начать заниматься с CodeDOM .

Я активно использую AgentRansack . Это огромная помощь в поиске тысяч файлов очень быстро. Это сэкономило мне так много времени, но я не знаю многих программистов, которые знают об этом или используют его.

Формальные методы.

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

Трудно переоценить их важность. Каждый цикл и каждое утверждение if начинаются как идея, которая требует своего рода «доказательства». Большинство программистов делают это доказательство большую часть времени в своих головах. Вы спрашиваете, что делает оператор if, и они могут четко и логично сформулировать, что это за варианты и почему они являются полными, последовательными и эксклюзивными.

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

Это просто алгебра (и исчисление) для кода. Ничего слишком сложного или сложного.

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

Ну, это Half Life 2 (вставьте свою любимую игру здесь). Если у меня есть проблема, которую я не могу решить, я просто ухожу и начинаю играть в свою любимую игру, и внезапно решение приходит мне на ум. Так что, честно говоря, это не игра или что-то в этом роде , а занятие чем-то другим . Я часто вижу, как люди сидят над проблемой часами, не решая ее, и все, что им нужно сделать, это отключить свой мозг на короткий период.

Переполнение стека - быстрая помощь эксперта, когда вы застряли

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

Я думаю, что это Блокнот / TextPad / простые программы редактирования текста. У всех есть время, когда им нужно быстрое исправление, которое не требует открытия IDE и требует только быстрого редактирования. И на всех компьютерах есть какая-то простая программа для редактирования текста.

Утверждает и хороший alwaysAssert() функция. ИМХО, они более важны, чем модульные тесты, потому что модульные тесты могут находить ошибки только в тех конкретных случаях, которые вы хотели протестировать. Если один и тот же программист пишет код и тесты, он / она, вероятно, пропустит одни и те же крайние случаи в обоих. Кроме того, иногда модульное тестирование нецелесообразно, поскольку среда, в которой функционирует компонент, и / или данные, с которыми он работает, слишком сложна, чтобы придумать надуманный тестовый пример.

Прелесть утверждений заключается в их способности документировать предположения и проверять их на необдуманных данных . Если какое-либо из этих предположений неверно, ваш код громко дает сбой, вместо того, чтобы «работать», но выдает слегка неверные результаты. Он также не подходит ближе к корню проблемы, чем без утверждений. На практике, если вы явно сформулируете достаточно предположений о куске кода, и все эти предположения верны, то код обычно является правильным.

Одна из распространенных претензий к утверждениям заключается в том, что их можно отключить. ИМХО, у каждого языка или стандартной библиотеки должна быть alwaysAssert()функция или грубый эквивалент, который делает то же самое, assertно не может быть отключен. Это можно использовать для проверки предположений в не критичных к производительности областях кода, где преимущества отключения утверждений незначительны.

Клавиша F1. - Полезно для программ, которые вы не знаете, и для программ, над которыми вы работаете. (Предполагая, что это большое приложение.)

Мощным средством отфильтровать проблемы было то, что пользователи сообщали об ошибках на основе их интерпретации того, как должно работать программное обеспечение. Конечно, возможно, что сам дизайн был ошибочным. Но это другая история.

Различные основные утилиты UNIX, но в первую очередь findи иногда grepили ed. Возможность находить вещи в глубоких гнездах файлов неоценима, особенно когда вы внезапно наследуете кодовую базу и должны ее исправить. Даже если указанный код хорошо документирован, вам, вероятно, придется охотиться, и глубокое понимание его findубивает.

Любопытство

Назовите это «Загадкой программирования». Что такое инструмент по сравнению с человеком, который владеет им? Желание узнать, как и почему что-то работает или не работает, расширяет знания больше, чем какой-либо конкретный инструмент, и это действительно за пределами программирования.

Ctrl + C    
Ctrl + V

Сохранено бесчисленное количество часов по всему миру!

Хвост

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

Примеры программ есть;

• хвост для Unix.
• хвост для Mac.
• BareTail для Windows.

Однажды я собрал генератор графа вызовов Perl. Это было чрезвычайно полезно, но сильно упало на непроцедурный код или подпрограммы вне файла.