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

35

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

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

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

tools developer-tools

— Анто
источник

3

Наши мозги? - -

— Труфа

Хорошо, кто хочет добавить запись в Лисп? * усмехается *

— Марк C

70

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

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

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

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

— Andiaz
источник

6

Я делаю это все время с моим мужем. Как парень из службы технической поддержки, обладающий лишь небольшим количеством навыков программирования, он понимает примерно 60% того, что я говорю, но заставляет меня объяснять 40%, которые я тоже не понимаю. Количество случаев, когда это работает, действительно впечатляет.

— Этель Эванс

1

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

— Берин Лорич

57

Я попробовал, но моя резиновая утка не могла сосредоточиться на проблеме. Где я могу найти квалифицированного резинового утка с неподдельным интересом к программированию?

— Steve314

3

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

— Ларс Вирзениус

1

@Steve: над этим работают японские исследователи, но я не думаю, что они где-то рядом: youtube.com/watch?v=3g-yrjh58ms

— Рей Миясака,

42

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

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

— Спарки
источник

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

— oosterwal

3

Русские использовали карандаш.

— Работа

@ Джоб Ха, я все еще использую бутылку чернил! (... Ну, только для каллиграфии, но все же. :))

— Mateen Ulhaq

А как насчет планшетных ПК?

— Матеин Улхак

1

@Job: ... и водка!

— Спойк

38

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

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

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

— FrustratedWithFormsDesigner
источник

1

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

— Майк Данлавей

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

— Anto

23

+1 для профилирования, +1 для инструментов сравнения, -1 для инструментов XML. Некоторые люди, сталкиваясь с проблемой, думают: «Я знаю, я буду использовать XML».

<Problem:Worsening>  <Problem:TimeDescription>Now</Problem:TimeDescription>  <Problem:Posessive>they have</Problem:Posessive>  <Problem:Quantity>many, many</Problem:Quantity>  <Problem:WorseningDescription>more problems</Problem:WorseningDescription></ProblemWorsening>

— Мейсон Уилер

2

@ Мейсон: милый XML.

— Майк Данлавей

10

@ Мейсон Уилер: Я не предлагал XML в качестве инструмента для решения проблем, я предложил Good XML Tools - когда вам нужно работать с XML, убедитесь, что у вас есть редактор / инструмент, который очень хорош в этом. Что-то, что может выполнять запросы Xpath, проверку схемы, преобразование, сравнение значений со структурой (я полагаю, специальный вид diff) и т. Д. Простые редакторы с подсветкой просто не могут обрезать, когда что-то запутано - они часто запутывают хуже (кстати мне нравится твой код XML;)).

— FrustratedWithFormsDesigner

37

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

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

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

— barrem23
источник

8

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

— Anto

10

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

— Steve314

4

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

— JasonTrue

4

Хм, почему-то у меня всегда было впечатление, что регулярное выражение было далеко не недооценено. Слишком часто я вижу людей, пытающихся найти регулярное выражение, когда достаточно простого цикла split / for или когда регулярные выражения просто не являются ответом (например, анализ xml / html).

— МАК

Я видел оба явления: Regex? Это нечитаемое / медленное / вставное уничижительное слово здесь и «Каков лучший способ разобрать (вставить совершенно нерегулярную грамматику) с одним регулярным выражением?»

— JasonTrue

24

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

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

— Doug T.
источник

Хорошие товарищи по команде никогда не могут быть переоценены. Большинство программного и аппаратного обеспечения может.

— анонимный тип

19

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

— Адам Кроссленд
источник

13

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

— FrustratedWithFormsDesigner

12

Извините, но Google недооценили? По крайней мере, Google переоценивают :)

— eestein

2

Знаю, знаю! Но я полагаю, что вы будете согласны с тем, что я недооцениваю обоснование того, что оно недооценено: по крайней мере, 75% вопросов, задаваемых в StackOverflow, легко поддаются ответственности в Google, да? Понятно, что это до некоторой степени недооценивается, если многие люди не используют его. Если мое обоснование неверно, я удалю свой ответ.

— Адам Кроссленд

3

@ Adam Crossland: 75% добрые. Я думаю, что это выше, чем это.

— S.Lott

1

@adam @ s.lott, так что я думаю, дело в том, что Google не используется должным образом. С этим я согласен. Так много вопросов можно было бы ответить (не нужно спрашивать), если бы люди знали, как правильно Google. С уважением.

— Eestein

16

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

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

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

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

— Майк Данлавей
источник

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

— Кристоф Провост

@Kristof: Соблазнительно так думать, и есть проблемы, с которыми он не может справиться, и есть случаи, когда сэмплы получить нелегко, но профилировщики тоже не могут обработать эти случаи, за исключением определенного вида, такого как Zoom и даже тогда они на самом деле не лучше в смысле того, чтобы привести вас прямо к проблеме.

— Майк Данлавей

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

— Майк Данлавей

14

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

Компилятор

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

— Кевин
источник

3

@Kevin: и я бы добавил способы написания кода, чтобы компилятор действительно проверял вас (для языков со статической типизацией). Большинство разработчиков используют готовые типы (такие как string) для представления любого вида информации, где они могут определять простые, но несовместимые типы для несвязанных данных ... и иметь компилятор, который они не испортили при передаче аргументов.

— Матье М.

@Matthieu M Это тоже хороший момент. Многие люди забывают о простых способах помочь вам.

— kemiller2002

3

Каждое предупреждение компилятора является ценным подарком. Не игнорируйте их! Проси добавку! -Рувер должен быть обязательным.

— Кристоф Провост

@Kristof: -pedantic -Wall -Wextra -Werror... хотя тогда может быть трудно что-либо построить: p

— Matthieu M.

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

— kizzx2

10

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

— jnevelson
источник

4

Я сделал мой в основном неработоспособным в некоторых случаях.

— Дэвид Торнли

3

"более или менее забыто": -S

5

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

— Jnevelson

2

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

— asoundmove

1

Некоторые комментарии заставили меня изменить свое мнение, +1 :)

— Anto

10

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

print

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

— JRW
источник

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

— Билли ONEAL

8

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

— Гаурав Сегал
источник

1

Смотри .. Я бы не согласился с этим. Да, скрипты могут автоматизировать некоторые задачи. Но часто их берут далеко за пределы смысла, до такой степени, что они просто становятся большой спагетти.

— Билли Онил

1

Правда, на большие скрипты смотреть ужасно, и для этого можно использовать perl или python. Хотя они все еще хороши в выполнении небольших работ.

— Гаурав Сегал

@ Билли Используйте Python. Проблема со спагетти решена :)

— Эван Плейс

7

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

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

— Andy Lowry
источник

3

Дублирующийся ответ - programmers.stackexchange.com/questions/57148/…

— ChrisF

Может быть дублированный ответ, но он заслужил мой отдельный голос за доску.

— Карсон Майерс

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

— Энди Лоури

6

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

— Peter Mortensen
источник

5

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

— Кевин Клайн
источник

1

Я не уверен, что они недооценены ...

— Анто

3

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

— Ладья

@Rook: Я не уверен, как язык с более чем 100 операторами можно считать «простым». Полезно, возможно. Но не "просто".

— Билли ОНил

@ Билли - Простой не исключает мощный. Я считаю калькуляторы простыми. Я не знаю, что делает половина из 300 моих функций, но это не уменьшает ее простоту.

— Ладья

4

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

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

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

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

— стихарь
источник

4

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

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

— Майкл Пасха
источник

4

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

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

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

— конрад
источник

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

— Захарий К

3

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

— JakeRadakovich
источник

3

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

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, и они могут четко и логично сформулировать, что это за варианты и почему они являются полными, последовательными и эксклюзивными.

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

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

— С. Лотт
источник

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

— Дэвид Торнли

3

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

— Джо Крайслер
источник

3

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

— Адам Арольд
источник

3

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

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

— комара
источник

+1, но больше не стоит недооценивать

— MAK

4

может быть, даже переоценен, или, по крайней мере, чрезмерно

— Anto

3

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

— Peter Mortensen
источник

2

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

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

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

— димча
источник

Согласовано. Но, к сожалению, простые, но эффективные инструменты, подобные этому, часто недооцениваются.

— Питер Мортенсен

2

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

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

— Джереми Эдвардс
источник

2

Оба недооценены, а также недооценены.

— анонимный тип

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

— тыкай

2

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

— Кодзиро
источник

2

Любопытство

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

— Томас
источник

2

Ctrl + C    
Ctrl + V

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

— gAMBOOKa
источник

1

Хвост

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

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

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

— утверждение
источник

Mac OS X - это система UNIX. Не нужно упоминать об этом отдельно.

— правостороннее

0

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

— Пол Натан
источник