Англійська для розробників Ada

Ada використовується там, де неправильне слово в перегляді дизайну може бути таким же дорогим, як і неправильне слово в коді — системи безпеки в аерокосмічній, оборонній та залізничній галузях. Точний словник тут не є приємністю; це частина того, як ці команди демонструють аудиторам і сертифікаторам, що система була насправді правильно обґрунтована.

Ключовий словник

** Сильне типування / підтипи ** — підхід Ada до обробки навіть числово сумісних типів (наприклад, двох різних діапазонів цілих чисел) як окремих типів, які компілятор не буде безмовно перетворювати між собою, з підтипами, які додають обмеження діапазону на базовому типі. “Не просто перетворюйте це на Integer — декларуйте підтип з фактичним діапазоном, як Altitude_Feet range 0 .. 60000, щоб компілятор відкидав будь-яке значення за межами цього діапазону при присвоєнні, а не три функції вниз по течії.”

** Специфікація пакунка / тіло пакунка ** — розділення Ada публічного інтерфейсу блоку (спеціфікація) від його реалізації (тіло), вимагає компілятора як два окремих файли, схожі за духом на розділення заголовка/реалізації, але більш суворе. “Специфікація пакунка показує тільки ті операції, які клієнтський код насправді потребує — внутрішнє представлення стану знаходиться повністю в тілі пакунка, і виклики не можуть до нього дістатися.”

** Контракт (передумова / постумова) ** — формальні Pre і Post аспекти, приєднані до декларації підпрограми, перевірені під час виконання в більшості конфігурацій збирання і статично доводимі за допомогою інструментів, таких як SPARK, документуючи точно те, що функція вимагає і гарантує. “Додати Pre-аспект, що вимагає, щоб вхідний масив був непорожнім, і Post-аспект, що гарантує, що результат буде впорядкований — тепер контракт говорить про те, що коментар просто заперечував, і це фактично перевірено.”

** Задача (задачі Ada) ** — вбудований у Ada, одночасний блок рівня мови, приблизно аналогічний потоку, але визначений і синхронізований за допомогою мовних конструкцій, таких як зустрічі і захищені об’ єкти, а не бібліотеки. “Це не бібліотечна нитка — це завдання Ada, і дві задачі синхронізуються через rendezvous, що є конструкцією на рівні мови, а не чимось, що прикріплено до бібліотеки mutex.”

** SPARK subset ** — формально аналізований підмножина Ada, використовується для математичного доведення відсутності певних класів помилок виконання (наприклад, переповнення буфера або переповнення цілих чисел) до того, як код буде виконано, що є звичайним у роботах з найвищою гарантією безпеки. “Цей модуль написано у підмножини SPARK спеціально, щоб ми могли запустити інструменти формального доведення проти нього — це сильніша гарантія, ніж тестування, оскільки він перевіряє властивість для всіх можливих вхідних даних, а не тільки для тих, які ми тестували.”

Звичайні фрази

• Чи є це сирим цілим чином, чи має бути це правильно обмеженим підтипом?»
• Чи є ця операція в специфікації пакунка, чи існує вона тільки в тілі?
• «Чи має ця підпрограма до і після контракту, або ж вимога просто задокументована в коментарі?»
• Чи це одночасність, що обробляється з Ada tasking, або ми втручаємось в щось інше?»
• «Чи написано цей модуль у підмножини SPARK, чи в повній Ada, що не може бути формально доведено?»

Приклади висловлювань

Пояснення рішення щодо дизайну шрифтів під час перегляду:

• “Ми використовували підтип з явним діапазоном замість цілого числа, зокрема, щоб значення висоти, що знаходиться поза діапазоном, було виявлено компілятором або під час перевірки під час виконання, а не через три модулі пізніше, коли це призведе до фактичної помилки.” *

Обґрунтування контракту:

• “Я додав до цієї підпрограми контракт Pre і Post, оскільки вимога — що буфер повинен бути вже ініціалізований перед запуском — раніше була зазначена лише у коментарі, який ніхто не виконував.” *

Опис розробки одночасності: “Ці два компоненти спілкуються через Ada- завдання з зустріччю, а не спільною змінною за mutexem — це навмисний вибір, оскільки зустріч робить точку синхронізації явною в самому коді.”

Професійні поради

• Типовий обмежений ** підтип ** над голим базовим типом, коли значення має відомий діапазон — це одна з головних причин, чому команди обирають Ada для роботи, яка має критичне значення для безпеки, тому використовуйте її послідовно, а не тільки там, де це зручно.
• Тримайте специфікацію пакунка мінімальною і розглядайте її як справжній контракт під переглядом — переглядачі повинні мати змогу зрозуміти публічну поведінку пакунка лише з однієї специфікації, без читання тіла.
• Написати ** До і Після контракти ** для будь- якої підпрограми, вимоги якої мають значення для правильності — контракт буде перевірено і буде можливо його перевірити, якщо коментар, який стверджує те саме, не є ні одним, ні іншим.
• Використовувати конструкції Ada tasking замість використання зовнішніх бібліотек одночасності під час роботи з Ada — розробка завдань є частиною специфікації мови і саме таку інформацію очікують побачити переглядачі і сертифікатори.
• Зарезервуйте SPARK підмножину для модулів з найвищою гарантією, де формальний доказ вартий додаткової дисципліни — це сильніша гарантія, ніж тестування, але це не безкоштовно, тому застосовуйте його там, де справді потрібна гарантія.

Практичні вправи

1. Пояснити, чому обмежений підтип безпечніший, ніж голий тип Integer у Ada.
2. Описати різницю між специфікацією пакунка і тілом пакунка.
3. Напишіть речення, яке обґрунтовує використання перед- і післяконтрактів у підпрограмі, яка має критичне значення для безпеки.

Основні праці: «Англійська мова в англомовних країнах

Основний словник Ada – такі терміни як «контракт», «задача», «виняток» і «критична безпека» – є життєво важливим. Однак, просто знати ці слова недостатньо, коли співпрацювати з колегами, писати документацію або брати участь в обговореннях про якість коду. Професійна англійська сильно покладається на * нюанс * - тонкі відмінності у фразування, які можуть кардинально змінити значення і вплинути на те, як ваші ідеї приймаються. Цей розділ зосереджений на розв’ язанні унікальних проблем, з якими стикаються люди, для яких англійська мова не є рідною, працюючи в середовищі розробки Ada, особливо при поширенні технічних концепцій в різноманітній команді.

Одним з найчастіших каменів спотикання є конструктивне висловлювання незгоду. Пряме твердження на кшталт «Це неправильно» може бути неймовірно дратуючим і негайно оборонним. Замість цього, розгляньте формулювання, яке фокусується на впливі коду або пропонує альтернативний підхід. Наприклад, замість того, щоб сказати «Це не відповідає вимогам», більш дипломатичним підходом буде: «Я бачу, як ця реалізація розглядає [конкретну точку], але я переживаю, що вона може ненавмисно ввести [потенційну проблему]. Можливо, ми могли б дослідити [альтернативне рішення], щоб забезпечити повне дотримання?” Аналогічно, коли ви отримуєте коментар перегляду коду – часто доставлений як коротка записка, наприклад, «Це потребує переробки» – розгляньте можливість відповіді з більш детальною інформацією: «Дякую за позначення цього. Я розумію занепокоєння щодо читабельності та підтримки. Я перегляну код, щоб включити [конкретну пропозицію] на основі вашого відгуку. » Ключовим є перехід від твердження що не так до пояснення чому це проблема і запропонування рішення.

Іншою областю, де обережна фраза є критичним є в PR описах. Короткий технічний опис, наприклад, « Виправлено ваду », не є достатнім для більших змін. Заголовок PR повинен чітко повідомляти про обсяг роботи і її переваги. Краще було б вказати: « Впроваджено покращене оброблення помилок для мережевих запитів з метою поліпшення стійкості системи ». Цей варіант надає вам можливість побачити контекст і дозволить переглядачам швидко оцінити вплив зміни. Крім того, використання точних дієслів - “реалізовано”, “рефакторизовано”, “перевірено” - демонструє чітке розуміння виконаної роботи.

Нарешті, пам’ятайте, що активне слухання так само важливо, як і чітке мовлення. Не бійтеся прохання про пояснення, якщо ви щось не розумієте. Просте питання на кшталт «Чи можете ви розібратися, що ви маєте на увазі під «оптимальною продуктивністю» в цьому контексті?» може запобігти нерозумінням і продемонструвати справжнє бажання навчатися.

# Example: Using `gcov` to analyze code coverage
gcov -b -e my_program.exe *.c

Ця команда, за допомогою інструменту gcov (зазвичай доступного у системах Linux), створює звіт, у якому буде показано відсоток рядків, які було перевірено для кожного файла .c у поточній теки. Це практичний приклад того, як технічний словник - “код покриття”, “тестування”, “лінії” - використовуються в реальних сценаріях розробки, особливо при обговоренні забезпечення якості і забезпечення ретельного тестування. Вивід можна обговорити з колегами, щоб визначити області, які потребують подальшої уваги або поліпшення тестових наборів.