Найбільш занижений інструмент програмування [закрито]

У нас є багато чудових інструментів, які дуже допомагають при програмуванні, такі як хороші редактори тексту програмістів, 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. А іноді вони змушують вас з розуму. Мені завжди здається, що я використовую оператори друку (або сліди, або NSLog, або те, що у вас є) лише для того, щоб переконатися, що мій код робить те, що я думаю, що робить, коли я думаю, що це робить.

Звичайні старі сценарії ... незалежно від того, скільки мов наступного покоління ми розробляємо, ми все ще сильно покладаємось на сценарії, також більшість повсякденних завдань можна досягти, написавши кілька рядків сценаріїв.

Перо та дошка.

Ви не можете перемогти низькі технології, намагаючись щось пояснити.

ак . Це як grep -r, але він розроблений для пошуку через ваш вихідний код.

Perl та інші мови сценаріїв. Відмінно підходить для завдань, які є занадто складними для таких інструментів GUI, як агент Ransack.

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

Тож загалом використовуйте хороші інструменти (IDE / редактор) та навчіться отримувати максимум можливостей, які вони надають.

Наступне тестування приладів та TDD, щоб тримати код перевіряючим і запобігати страху перед рефакторингом.

Використовуйте ці, і ви легко перейдете до написання правильного коду, який відповідає ремонту, який відповідає принципу DRY та є самодокументальним.

Блок тестування пропонує наступні переваги:

• Розробники стають першими клієнтами коду. Чим швидше буде виявлена ​​помилка, тим дешевше її виправити. Помилки можуть бути схоплені перед збіркою, встановленням або розгортанням .
• Тестування змінює ваше уявлення про код. Чи чітка конструкція? Чи обробляє кутові корпуси?
• Ефект Хоторна покращить якість, просто оголосивши, що команда публікує показники якості / тестування.
• Навіть якщо тести не перевіряються на контроль джерел, вони можуть стати прекрасним способом вивчення та вивчення нового рельєфу.
• Висока ймовірність меншої кількості помилок!

Генератори коду

Генератори коду можуть створити велику кількість ефективного і без помилок коду з простого визначення. ОРМВикористання типів є найбільш очевидним для створення класів доступу до даних, але існує багато інших потенційних можливостей використання.

Підтримка створення коду, здається, все ще знаходиться в зародковому стані і з точки зору програміста, і з точки зору рамки, але я вважаю, що це щось, що ми побачимо все більше і більше. У .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, і чи можуть вони чітко і чітко сформулювати - що таке вибір і чому вибір є повним, послідовним та виключним.

Але деякі, здається, здогадуються випадковим чином. Їм потрібна більша допомога, і формальні методи можуть бути видом допомоги, яка їм потрібна.

Це просто алгебра (і числення) для коду. Нічого занадто складного чи витонченого.

Фізичні моделі дизайну, такі як залишення стільця для швидкої пробіжки на сонячному світлі та свіжому повітрі, підтримують наш мозок на найвищому рівні.

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

Переповнення стека - швидка допомога фахівців, коли ви застрягли

питання та відповіді для професійних та ентузіастів-програмістів. Він побудований та керований вами як частина мережі Stack Exchange сайтів Q&A. З вашою допомогою ми працюємо разом, щоб створити бібліотеку детальних відповідей на кожне питання щодо програмування ...

Я думаю, що це Notepad / TextPad / прості програми для редагування тексту. У кожного є час, коли їм потрібно швидко виправити, що не потребує відкриття IDE та потребує лише швидкого редагування. І на всіх комп’ютерах є якась проста програма редагування тексту.

Твердження і добро alwaysAssert() функція. ІМХО це важливіше, ніж одиничні тести, оскільки одиничні тести можуть виявляти помилки лише у конкретних випадках, які ви думали перевірити. Якщо той же програміст пише код і тести, він / вона, ймовірно, пропустить однакові крайові випадки в обох. Крім того, іноді тестування одиниць недоцільно, оскільки середовище, в якому функціонує компонент та / або дані, над якими він працює, є надто складним, щоб придумати надуманий тест.

Краса тверджень полягає в їх здатності документувати припущення та перевіряти їх на неоднозначних даних . Якщо будь-яке з цих припущень є неправильним, ваш код не працює голосно, замість того, щоб "працювати", але створюючи невірні неправильні результати. Він також не підходить до коріння проблеми, ніж без тверджень. На практиці, якщо ви явно заявляєте достатню кількість припущень щодо фрагмента коду, і всі ці припущення є правильними, код зазвичай є правильним.

Один із загальних зусиль щодо тверджень - це те, що їх можна вимкнути. IMHO у кожній мові або стандартній бібліотеці має бути alwaysAssert()функція або грубо еквівалент, що робить те саме, що, assertале не може бути вимкнено. Це може бути використано для перевірки припущень у критичних областях коду, які не мають ефективності, де переваги відключення відхилень незначні.

Клавіша F1. - Корисно для програм, яких ви не знаєте, і для програм, над якими ви працюєте. (Припустимо, що це велика програма.)

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

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

Цікавість

Назвіть це "Загадка програмування". Що таке інструмент порівняно з людиною, яка ним володіє? Бажання знати, як і чому щось працює чи не працює, розширює свої знання більше, ніж будь-який конкретний інструмент, і це дійсно поза програмою.

Ctrl + C    
Ctrl + V

Збережено незліченну кількість годин у всьому світі!

Хвіст

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

Прикладами програм є;

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

Я співав один раз генератор графіків викликів Perl. Це було надзвичайно корисно, але важко потрапило на непроцедурний код або підпрограми, що не входять у файл.