У мене неправильне уявлення про інженерію програмного забезпечення? [зачинено]

У мене є питання, яке було порушено моєю останньою роботою (швидше стажисткою).

Просто, щоб поставити речі в контекст - мені 21 рік, і я закінчив 2-й курс університету, до цього я мав близько 2-річного досвіду роботи з системою адмін / QA, і в основному можу сказати, що я бачив, як відрізняються Діяли ІТ-сектори. Промайну вперед до теперішніх часів, і ось я займаюся стажуванням в одній з провідних науково-дослідних установ у Великобританії.

Що мені потрібно зробити, це створити деякі внутрішні інструменти за допомогою поєднання технологій - головним чином AWS / Java / Bash - ви отримаєте картинку. Все гаразд, я роблю свою роботу, Але я не задоволений. Чому це так - тому що, як очікується, я працюю в спеціальній справі. Тобто створюйте речі швидко, не витрачаючи часу на розробку. Мій керівник прямо заявив, що очікується, що ми будемо "мчати" через проблеми, коли вони виникають, а ми по суті. Як наслідок, виявилося, що речі треба було переробити і переробити, і вони все ще не є ідеальними. Що стосується тестування - зведіть його до мінімуму, доки він здається працює, тоді це нормально.

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

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

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

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

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

Перетворення програмного забезпечення на повторне використання та безпроблемне використання не є рушійною силою інженерії. Інженерія полягає в оптимальному вирішенні проблем реального світу в межах реальних обмежень . Більшість інженерів вважають за краще працювати на Ferrari - але вагон станції потребує стільки ж інженерії, а причина, що фургон не працює також (певним чином) через більш складні конструктивні обмеження, а не через гіршу техніку .

Коли ви говорите, що хочете зробити «хорошу роботу», а не «швидку роботу», це робить більшість інженерів, але іноді частиною того, що визначає добро, є те, наскільки швидко це зробити. Тож не правильно вважати "добрий" та "швидкий" як протилежний вибір. Або вважати, що ти робиш погану роботу, або просто "мавпа з кодом" за те, що робиш найкращу можливу роботу за доступний час.

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

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

Головною проблемою тут є те, що відсутність тестування зокрема може бути етично сумнівним, якщо інструменти мають важливе призначення. Якщо хтось не впевнений, що у програмного забезпечення є дефекти, оскільки обмежений мінімальним часом тестування, це означає, що НЕ ОДИН не несе відповідальності за робочий стан програмного забезпечення, і Atlas знижує плечима.

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

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

Чи не етично гарантувати, що програмне забезпечення для моделювання не має великих проблем з його прогнозами?

Вся проблема не в тому, що парникові гази прогрівають землю. Проблема полягає в тому, чи чистий результат ефекту зворотного зв'язку - це прискорене підвищення температури, яке після перевищення порогу більше не буде оборотним.

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

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

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

Ви не маєте неправильного уявлення про те, що таке інженерія програмного забезпечення. Однак вам не вистачає дуже важливого аспекту: це сфера послуг. Деякі з нас роблять роботу над продуктом роками, і проходять дизайн, а потім багато ітерацій, перш ніж це буде в v1. Іншим доводиться щось виробляти за 3 години. Це залежить від того, хто ти обслуговуєш і яка мета.

Якщо ви можете створити додаток за 3 години (або дні), що робить те, що потрібно зробити, навіщо витрачати більше часу на це, щоб розробити передній план? Ти просто витрачаєш гроші. Втрачання грошей - це взагалі не добра ідея ™.

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

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

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

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

Все, що сказано, все змінюється. Окремі компанії (в основному ті, для яких програмне забезпечення є їх основним бізнесом, і ті, хто працює над критично важливими для безпеки програмними засобами, такими як медична техніка), дотримуються дуже суворих технологічних процесів. Але загалом, так, я скажу вам, що зараз більшість комерційних програм є відносно неохайними. Зазвичай існує якийсь офіційний процес, але дотримання його суворо майже завжди займає заднє місце, щоб реагувати на вклад клієнта та інші комерційні тиски. Це насправді не "неохайність" сама по собі, це просто звичайна прагматична корисність. Хитрість полягає в тому, щоб знайти свою нішу і подивитися на роль з точки зору того, яку послугу вона надає, а не наскільки крутим є її "чисте програмування".

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

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

Іноді ти можеш зробити щось цінне, бути добрим . Як правило, це стосується програмного забезпечення, що обтягується термінами, як Adobe Photoshop. Дослідження вже проводилось років тому, і тепер питання полягає в тому, як додати список функцій, які бажають клієнти, таким чином, щоб не вводити помилок. Це питання архітектури, дизайну та тестування, тестування, тестування. Сам код - це те, що цінно, а не те, що ви дізнаєтеся з нього.

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

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

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

Ось моя порада, що ґрунтується на моєму досвіді, мені 20 років, і зараз я працюю у великій фінансовій установі у Великобританії. У мене були ті ж почуття, що і у вас кілька місяців тому. Я помітив, що це може бути пов'язано з природою робота, яку ви виконуєте.

Що я маю на увазі під цим, ви сказали:

«Що мені потрібно зробити, це створити деякі внутрішні інструменти, використовуючи поєднання технологій - головним чином AWS / Java / Bash»

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

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

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

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

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

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

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

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

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

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

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

Я думаю, що ваша ситуація все ще перебуває на шкалі реального світу, оскільки менше акцентується на якості. Ваші уподобання - на іншому кінці реального світу. Характеристики змінюються, переборюйте. Треба робити справи.

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