Чи, як правило, створення абсолютно нового програмного забезпечення є основною частиною більшості програм програмування? [зачинено]


63

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

У будь-якому випадку, думаючи про те, що я зробив, я вважаю, що менше, ніж 10% мого часу витрачається на "нову" роботу. Є такі речі, як "адаптувати цю існуючу систему до роботи в цьому новому середовищі", що, безумовно, вимагає багато планування, але власне кодування та "нові речі" зводиться до того, щоб в багатьох місцях у коді вносяться невеликі зміни. Так само і для невеликих запитів на функції - якщо я знаю, що робити, їх часто можна закінчити за годину, а якщо я цього не роблю, це просто багато читання коду та з'ясування того, що робити (що мене засмучує, бо я вчуся набагато краще, роблячи, а не читаючи).

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

Я помиляюся? Я точно описую більшість завдань програмування, чи більшість програмістів відчувають, що вони часто створюють нові речі?


11
@JamieTaylor У твоєму метафоричному розумінні виникає питання: чи типово завжди фіксувати чужу модель Лего і рідко створювати нову?
Калеб

22
@Joe, га! Отже, ви - хлопець, який виробляє всі ці! * # @ * &!% Застарілі системи, які ми маємо підтримувати назавжди ?! ;-P
Петер

14
@Joe, так, я дуже дякую Можливо, якщо ви зможете написати лише тест на більше одиниць, я буду повністю задоволений :-)
Péter Török

8
@Joe, це враховує стару приказку, яку я не знайшов особливо придатною - тобто дотепер: "завжди кодуйте так, ніби наступний хлопець, який перейняв ваш код, був небезпечним психопатом, який знав, де ви живете"; -)
Петер Тьорьк

11
@JonMcdonald Це не повинно бути гнітючим - жодна робота - це не всі троянди, а підтримка існуючої бази коду - це, можливо, найшвидший спосіб набути досвіду та вдосконалити свої навички інженера. Витрата часу на технічне обслуговування допоможе вам зрозуміти і уникнути всіх типових помилок, які призводять до неможливого коду в першу чергу, а також допоможе оцінити речі, які, інакше, напевно, не піклуються, такі як статичний аналіз коду та створення автоматизованих тестових одиниць.
Бен Коттрелл

Відповіді:


66

Велика робота з програмним забезпеченням - це обслуговування. Звичайно, жоден менеджер з найму не скаже вам це, але це, безумовно, так.


13
Це, мабуть, так, але технічне обслуговування все ще дуже важливе, і інколи може бути складним для інтелекту :)
joshin4colours

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

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

3
@omouse - іноді так, але іноді це просто виправлення кричущих помилок у реалізації, щоб відповідати оригінальній специфікації. Але ви маєте рацію - під рубрикою "обслуговування" висвітлюються різноманітні заходи.
Скотт С Вілсон

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

59

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

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

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


15
+1 за "ніхто, хто постійно працював над малими проектами" зеленого поля ", не може насправді претендувати на компетентність"
mattnz

1
Що таке "малий проект" зеленого поля "?
Печиво з рисової муки

@RiceFlourCookies: « Грінфілд» - це абсолютно новий термін для робочого ендевура. У цьому випадку проект починався з нуля.
Стівен Еверс

@RiceFlourCookies і хоча малий відносний, проекти, які може бути виконана однією людиною, можна вважати малими.
Скотт C Вілсон

23

Спадкові системи є успішними. Вони пережили початковий процес розробки, де 50% проектів провалилися (навіть після того, як успіх було переосмислено!). Вони пережили мінливе ділове середовище. Вони, ймовірно, пережили близько десяти пропозицій молодих наївних програмістів переписати все на Java або все, що було модним у той час. Їм пощастило, що будь-який департамент, компанія чи агентство, яке пропонувало програмне забезпечення, пережили різні скорочення бюджету, реорганізації, злиття тощо.

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

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


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

@marek це може бути і те і інше.
Ніколас

8
Те, що щось виживає, не означає, що це оптимально або навіть добре. Це означає лише, що це "досить добре", що його ніхто ще не вигнав зі своєї бідності. Основна селективна сила в природі - конкуренція; коли конкуренції мало, ти можеш отримати кілька досить пустотливих організмів. Конкуренція теж працює в програмному забезпеченні, але внутрішні системи зазвичай не мають великої конкуренції. Результат полягає в тому, що внутрішні системи часто піддаються максимуму.
Калеб

@Caleb - Як правило, виживають системи, де розробники слухали користувачів і блокували вимоги. Як би погано не написано! Системи, де розробники намагаються відповідати останній схемі дизайну, впроваджуючи останні примхи та одержимістю їх відступу, не роблять це до першого випуску. Робочий код завжди перемагає гарний, сумісний з buzzword код.
Джеймс Андерсон

14

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

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

Також створити щось абсолютно нове - це багато роботи. Навіть у проекті Greenfield ви, мабуть, виберете ряд інструментів, які допоможуть вам: платформа, компілятор, фреймворки, бібліотеки тощо. Як тільки ви зробите ці рішення, ви наклали певні обмеження на свій проект. Це не означає, що ви більше не займаєтесь новою роботою, лише те, що «нове» тут є відносним терміном. Звідси не великий крок, щоб побачити додавання функції або модуля до вже існуючого проекту як "нового", навіть якщо ви не назвали це проектом Greenfield.


7
"чуже невдале починання" - застарілі системи - історії успіху дарвінів, невдалі проекти не підтримуються!
Джеймс Андерсон

2
@JamesAnderson Точка прийнята, але технічний успіх - не єдина вибіркова сила в екології програмного забезпечення. Хто не бачив напівфабрикату собаки проекту, який важливий для менеджерів, але вважається занадто далеко, щоб почати спочатку?
Калеб

6

Це залежить від того, яку роботу ви шукаєте.

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

Інакше я працював у технологічних компаніях, які потребували програмного забезпечення для підтримки своїх внутрішніх НДДКР або зовнішніх продуктів.

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

Мінус полягає в тому, що ви є частиною витрат, а не частиною товару. Тож у мене були проекти, консервовані, тому що "ми не займаємось програмним забезпеченням" / "програмне забезпечення не є основним бізнесом" = дивно, як компанії думають, що вони можуть продати верстат за 100 тис. К, не маючи програмного забезпечення для його управління!


Також мене дивує те, як компанії думають, що їм не потрібно спеціальне рішення їх власної проблеми, і що мільйон рядків з 278 стовпців кожен може легко та швидко маніпулювати в excel, а не db.
Спенсер Ратбун

@SpencerRathbun Що мене дивує ще більше, ніж це те, коли ви даєте їм оцінку для створення спеціального програмного забезпечення, вони негайно починають розпитувати вас і запитувати: "Чи не є їх безкоштовне програмне забезпечення з відкритим кодом, яке може безкоштовно надати нам функцію X?"
maple_shaft

7
@maple_shaft, що ще веселіше, коли вони кажуть "ми можемо придбати X за $ 10К, і це рішення загального призначення ідеально підійде до нашої нестандартної проблеми без встановлення! BTW ви будете відповідальні за її вставлення та роботу та всі проблеми / помилки з програмним забезпеченням, яке ми купили, - ви винні ".
Спенсер Ратбун

3
@SpencerRathbun Ви виграєте, це найгірша ситуація, в якій ви перебуваєте.
maple_shaft

5

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

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

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

Я працював в ІТ майже 22 роки з останніми 15 як розробник програмного забезпечення, і за весь цей час я створив лише близько 5 нових продуктів, більшу частину свого часу або підтримуючи ці продукти довгостроково, або підтримуючи чужі продукт. Кожен дав мені виклики та проблеми для вирішення, і до кожного з них ставилися не як до простого великого проекту, до якого я є лише частиною, але також як ВЕЛИЧИЙ ряд мікропроектів, які потрібно виконати.

Дивно, як маленька розумова гімнастика може повністю змінити ваше сприйняття та задоволення від щоденної роботи, яку ви виконуєте. ;-)


4

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

Це насправді не «технічне обслуговування». Наприклад, щойно випущена версія VMWare 8, це головне оновлення їх основного продукту. Я підозрюю, що мало хто з розробників, які зробили цю роботу, був там, коли був написаний перший рядок коду для VMWare. Вони побудували своє основне оновлення на коді, написаному хлопцями, які давно перейшли.

У бета-версії робочого місця виникає питання про те, як працює 20% персональна система проектів Google .

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

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


2

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

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


2

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

Моєю першою роботою була фірма з програмного забезпечення бухгалтерського обліку, основним продуктом якої була система ERP, яка конкурувала приблизно на тому ж рівні, що і Great Plains або Peachtree (як ви перейшли до неї з QuickBooks, або вбік, коли вам набридла затуманена схема GP чи все інше ви думали, що не так з PT, ви взагалі вийшли з рівня в пакет, як SAP). Ця робота складала 99,99% технічного обслуговування, визначалася як виправлення помилок та додавання "дрібних речей", не змінюючи принципово способу роботи програмного забезпечення або того, що воно може робити. Я покинув компанію, коли генеральний директор хотів зробити перепис сторінки на одну сторінку, що було б круто, за винятком того, що він наполягав на декількох конструктивних особливостях, які мають чіткі антидіаграми, такі як внутрішня платформа (що дозволяє високу ступінь налаштування програми, в основному даючи замовнику скинутий VS Designer,

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

Моя нинішня робота повертається до внутрішньої розробки для охоронної компанії, яка використовує відеомоніторинг та аудіо зворотній зв'язок для забезпечення перевірки сигналу тривоги та інших послуг "віртуальної охорони". Це поле швидко росте і все ще розвивається; нове обладнання постійно виходить на ринок, підписуються нові клієнти, які хочуть, щоб ми робили нові речі, а наявна продукція вже не відповідає адаптації регламентів UL та Уряду. 99% цієї роботи - це "інтеграція"; написання нового програмного забезпечення, яке раніше не існувало, щоб зробити один новий, але вже існуючий предмет обладнання або програмне забезпечення працювати з іншим, ймовірно, старшим попереднім обладнанням або програмним забезпеченням, щоб ми могли робити нові речі з обома.


1

Я б сказав, що це дуже залежить від характеру вашої ролі.

Я є частиною невеликої команди і, як такий, повинен підтримувати і підтримувати все, що я створюю.

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

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


1
  1. Це залежить від небезпеки для вашої посади: ;-)

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

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

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

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

Не багато хто робить це правильно, тому ми повинні підтримувати їх код і відшліфувати його до належного стану. ;-)

Хороша новина - якщо ви перебуваєте в компанії досить довго, ви можете впливати на те, як пишеться новий код :-)


1

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

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


1

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

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

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


0

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

За чотири роки, які я працював у своїй компанії, я б сказав, що 70-80% мого часу витрачається на створення чогось нового. Ймовірно, 50-60% цього витрачається на великі проекти, що є абсолютно новим кодом, тоді як решта цього часу витрачається на вдосконалення поточної функціональності.

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


0

Я працював майже три роки як єдиний розробник у компанії, яка використовувала QuickBooks та Excel і більше нічого, коли я починала. Тепер у нас є додаток Windows Forms , налаштування SharePoint , SQL Server + Reports, надбудова Excel та надбудова Outlook.

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

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


Режим обслуговування відбувся давно ... Вам зараз потрібні інструменти, які допоможуть вам.

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

Ну, ви не відповідаєте на поставлене запитання.

0

Деякі великі організації, такі як компанія, в якій я працюю, мають політику виведення з експлуатації програмного забезпечення через декілька років, можливо, тому, що мова розробки, на якій він був написаний, більше не використовується (Delphi хтось?), Або платформа замінюється (Windows XP) або нормативні вимоги цього вимагають. Наприклад, дворівневі програми, які спілкуються безпосередньо з базою даних, зараз виводяться з експлуатації на користь трьохрівневих, які використовують Kerberized з'єднання для більшої безпеки.

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

Очікуйте 5-7-річного циклу заміни для такого типу речей. Наприклад, до 2020 року, я очікую, що програмне забезпечення WPF (клієнт) / Java (сервер), про яке я зараз пишу, буде старим технологією і його замінить щось нове.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.