Як уникнути переписування частин програми


13

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

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

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

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


2
Яку парадигму програмування ви використовуєте? Процедурні, об’єктно-орієнтовані, функціональні, інші?
Tulains Córdova

2
Щоб уникнути перезаписів - розв'яжіть свою базу даних та свій прикладний рівень. Це не просте поняття, яке можна застосувати до того, як ви пишете код. Це складна концепція, яка робить ваш код простим і пристосованим.
StackOverFowl

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

3
Ін'єкція залежностей - ваш друг. Google це, і подивіться, як застосувати його до вашої мови / рамки. Це дозволить написати набагато більш модульний код, який повинен зменшити кількість коду, який потрібно переписати, коли зміниться вимога.
Вічний21

2
Хоча це може здатися, що багато перезаписів - це погана річ, але насправді важливо те, наскільки швидко ви можете відповісти на запити кінцевих користувачів. Хоча це залежить від складності проекту, я б сказав, що 1 день - це дуже хороший час проведення - ви повинні щось робити правильно! Насправді програмне забезпечення, яке бачить значні зміни, є хорошим знаком - це означає, що воно корисне і вдосконалюється. Програмне забезпечення, яке не було суттєво змінено роками, набагато складніше в обслуговуванні.
Джастін

Відповіді:


22

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

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

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

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

Коли вимоги зрозумілі, простіше приймати кращі рішення на стадії проектування.

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


3
Це. Ця відповідь є найкращим способом. Отримайте ці вимоги, перш ніж робити абсолютно все.
Rhys Johns

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

Ну, у мене було сильне відчуття, що проблема була в тій, яку я коментував, бо саме це сталося зі мною ще в перші дні, як розробник. Я миттєво переклав фрази в LOC або модулі, і коли мені довелося щось змінити, було для мене досить драматично. Рефактор над рефактором кожен день або тиждень. Навіть не робив усе можливе з SoC, SPR, поліморфізмом, ... Багато конфліктів, які я мав із змінами, були викликані моїм витоком загального бачення.
Лаїв

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

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

4

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

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

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


Гарна стаття, яку ви пов’язали.
SH7890

1
Гарна стаття дійсно! Я думаю, що це справа не в ОП, але я не міг більше погодитися з автором.
Лаїв

1
Я не думав, що це один для одного, але читав так, як це може бути один день. Сподіваємось, це допоможе ОП.
johnny

2

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

Користувальницький інтерфейс - це важкі речі, зазвичай 5 людей мають 15 різних поглядів. І структурування даних, і аналіз даних, і аналіз даних, як правило, змінюються на множення на коефіцієнт 10 :). Користувальницький інтерфейс - це мода, деякі комбінації - це круто, деякі - страшні або відсутні здоровий глузд.

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

Настільки проста відповідь, що немає такого поняття, як переписування не існує взагалі.


2

Ітеративний розвиток (який ви робили в основному, хоч одноденні ітерації) часто подібний. Ранні спроби рішень часто не впадають у межі, і, збираючи зворотний зв'язок, система переходить до рішення. Я запозичу рисунок 2.2 з інструкторського матеріалу Крейга Лармана для його книги " Застосування UML та дизайну" .

введіть тут опис зображення

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

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

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

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

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


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

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

1

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

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


1

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

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


-1

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

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

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

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