Який мінімальний підмножина найкращих / відомих практик розробки програмного забезпечення для сольного програміста? [зачинено]

Я досить самотній програміст у своїй роботі. Зазвичай я читав статті та публікації про

• Системи управління версіями
• Постійна інтеграція / доставка
• Методології розробки: Scrum, водоспад, V-Model, Agile, XP тощо.
• Управління програмними проектами

Але майже всі вони, здається, зосереджені на КОМАНДАХ. Я не команда, то який би був абсолютно мінімальний набір практик лише для одного програміста? Розглянемо наступні умови:

• У мене немає конфліктів з кодом інших людей.
• Мені не потрібно підтримувати файли / дерева каталогів, моє середовище розробки піклується про версію самостійно (розробка на основі зображень).
• Офіційних вимог немає, мої користувачі не знають, чого хочуть, і з цим все в порядку.
• Єдиний, хто міг би зацікавитись у наданні випуску чи документації, це я, в основному замовник хоче РЕЗУЛЬТАТИ і не піклується про методології програмного забезпечення тощо

На мою думку, я не хочу витрачати (занадто багато) часу та енергії на що-небудь, що безпосередньо не пов'язане з вимогами замовника. Будь-які рекомендації?

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

Якби я був на вашому становищі, я б рішуче застосував таке:

• Система контролю версій - Хоча ви можете подумати, що система розробки на основі зображень виконує завдання щодо регулярних резервних копій і чогось іншого, у вас є нульове приміщення для експериментальних функцій, де зазвичай використовується гілка . У вас також немає можливості зберегти важливу версію проекту ( тегування ). Якщо ви коли-небудь розширитеся лише за собою, розробники, які приєднаються, будуть думати, що вони перебувають у пеклі.
• Agile - Цей метод надзвичайно застосований для клієнтів, які не знають, чого хочуть. Рано чи пізно вони зрозуміють, що не хочуть витрачати гроші, щоб переслідувати хвіст - вони захочуть побачити прогрес.
• Інструмент управління проектами - це обов’язково. Дуже грізно бути здатним утримати все в голові, але цього не потрібно. Бути дисциплінованим та використовувати інструмент управління проектами (наприклад, Redmine ) дозволять вам розділити свої завдання та забезпечити легкий перегляд історії вашої роботи. Це буде дуже важливо, коли ви почнете заряджати за годину.

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

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

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

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

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

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

Для методологій - настійно рекомендую маніфест програмістів . Зазвичай це дає великі результати невеликим командам через нульові накладні витрати і не потрібно тримати в голові, як працює група J2EE-портлетів з підтримкою JSR-сумісного JSR-сумісного MVC рольової системи веб-служб CMS для веб-служб .