Я програміст з 1-річним досвідом, нещодавно зрозумів, що рідко запускаю проект правильно (більшість мого побічного проекту), як правило, цикл проекту іде як

1. Почніть з кількох випадків використання
2. Почніть кодування
3. Зрозумійте кілька речей, з якими я не впорався, і не вписується в поточну базу коду.
4. Перепишіть більшу частину коду

і це може піти кілька разів

Тож мої запитання є

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

Цикл, який ви описуєте, є нормальним. Спосіб вдосконалення речей - не уникнути цього циклу, а впорядкувати його. Перший крок - це прийняти:

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

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

1. Почніть з кількох випадків використання
2. Почніть кодування
3. Зрозумійте кілька речей, з якими я не впорався, і не вписується в поточну базу коду.
4. Перепишіть більшу частину коду

Це насправді чудова відправна точка. Ось як я підійшов би до цього:

1. Почніть з кількох випадків використання

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

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

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

2. Почніть кодування.

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

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

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

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

3. Зустрічайте проблеми або недоліки в дизайні.

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

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

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

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

4. Перепишіть частину коду

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

5. Тест

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

6. Вчіться

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

Деякі приклади:

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

Будьте спритними

Що ви рухаєтесь до цього стилю, це стиль роботи, відомий як Agile. Agile - це не методологія, це сімейство методологій, що включає цілий набір речей (Scrum, XP, Kanban, якщо назвати декілька), але все, що у них є спільне, - це ідея, що все змінюється, і ми як розробники програмного забезпечення ми слід планувати пристосовуватися до змін, а не уникати або ігнорувати їх. Деякі її основні принципи - зокрема, ті, що стосуються вашої ситуації - такі:

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

Це нормально.

Можна скористатися одним із двох підходів:

1. Ласкаво просимо змінити

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

2. Уникайте змін

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

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

Розробка програмного забезпечення була описана як низка суттєво "злих" проблем .

Хорст Ріттель та Мелвін Веббер визначали "злу" проблему як проблему, яку можна чітко визначити лише шляхом її вирішення або розв'язання її частини *. Цей парадокс, по суті, означає, що вам доведеться один раз «вирішити» проблему, щоб чітко її визначити, а потім знову вирішити, щоб створити рішення, яке працює. Цей процес десятиліттями був материнством і яблучним пирогом у розробці програмного забезпечення

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

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

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

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

1. Так, це звичайно, за винятком, можливо, частини "перепишіть більшу частину коду". Ви ніколи не отримаєте всіх вимог з самого початку, тому важливо добре впоратися зі змінами. Ось в чому полягає концепція "кодового ремонту". Звичайно, це також допомагає витратити трохи більше часу на отримання вимог та дизайну.
2. По-перше, подумайте, які зміни вимагалися в минулих проектах і як ви могли передбачити їх або підготуватися до них краще. На початку проекту подумайте детальніше про випадки використання. Зробіть деякий абстрактний дизайн (які основні компоненти коду та як вони спілкуються, які їх API), перш ніж почати впроваджувати. Найголовніше, намагайтеся тримати код максимально простим і легким для зміни, читайте про такі поняття, як SOLID, DRY, KISS та YAGNI.

Чи поширена така практика, або це означає, що я не компетентний?

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

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

Як я можу вдосконалити себе в цьому аспекті?

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

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

• Чи одна корисна річ.
• Це правильно
• Робить це з достатньою продуктивністю.

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

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

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

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

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

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

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

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

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

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

4. Якщо ви працюєте в рамках, витрачайте час, якщо зможете зекономити, щоб розглянути, як зробити справи з нуля. Наприклад, ви можете легко зібрати запит із повідомленням, відкрити сокет і видати GET або POST-запит вручну. Якщо вам подобається, ви можете вручну проаналізувати XML-повідомлення. Що б ви не робили, питання, які ви генеруєте, та відповіді, які ви знайдете, підвищуватимуть ваші навички. Звичайно, ви можете вибрати, які типи основних питань є важливими або цікавими. Я б врахував це особистим розвитком, і не сподіваюся витратити багато на цілодобовий час.

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

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

Я хотів би додати кілька покажчиків

1) Мені особисто було неймовірно корисно починати з візуалізації речей. Намалюйте поля, стрілки, лінії ... Неважливо, якою мовою моделювання ви не користуєтесь. В першу чергу ви робите це ДЛЯ ВАС. Це повинно допомогти вашому потоку думок.

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

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

4) Цей процес поступового навчання ніколи не припиняється (і не повинен)! Ви озирніться через 10 років і посміхніться.

Сподіваюся, це допомагає крихітній шматочок і удачі!