Я зараз єдиний розробник / архітектор досить великого веб-додатка (стек ASP.NET MVC, приблизно 150 К + рядків коду), і кінець розробки вже на горизонті. Тому я починаю замислюватися над тим, що потрібно зробити для розгляду проекту, і я хочу переконатися, що я роблю правильно для кожного, хто має підтримувати проект у майбутньому.
Які речі слід пам’ятати, готуючись передати проект іншому розробнику чи команді розробників з обслуговування?
Відповіді:
ІМХО, якщо ви могли зробити лише одне, перш ніж передавати проект (прямо чи опосередковано), я б рекомендував вам двічі і втричі перевірити, чи він складається як-от з управління джерелами.
Не смійся, але я не можу сказати тобі, скільки разів я отримував "останню" інформацію від джерела управління, і це не вдалося зібрати, лише щоб потім з'ясувати, що я не "на старій скриньці Фреда", тому що, мабуть, код " компілює на стару скриньку Фреда ". У мене навіть колишній роботодавець негайно вийняв робочий стіл з мого куба і замінив його на «стару коробку Фреда», щоб я міг працювати над проектом, який я повинен був.
Як розширення вищенаведеної рекомендації, оскільки іноді отримання останнього не все необхідне для складання програми, я рекомендую створити README.txt і розмістити його в кореневому каталозі вашої програми та поставити це в керування джерелом. Цей документ README повинен містити перелік зовнішніх залежностей, які неможливо перевірити у контролі джерел (якщо такі існують), способи настройки бази даних та будь-які інші дивацтва щодо циклів компіляції, виконання або розгортання програми.
Все, що вище, а також за вищезазначеними двома пропозиціями, було б просто підтягнутим, але ІМХО вищевказані дві майже потрібні для будь-якого проекту, що перевищує "Hello World".
Редагувати:
На тему документації ...
Протягом багатьох років я писав і читав свою неабияку частку програмної документації для полегшення переходу розробника. Я б сказав, що такі документи рідко коштують паперу, на якому вони надруковані. Розробники (включаючи мене) рідко замислюються про важливі частини програми під час написання таких документів, ми лише схильні думати про останні останні пожежі, з якими ми зіткнулися. Окрім того, що ці документи, як правило, не охоплюють усіх важливих аспектів програмного забезпечення, вони також дуже швидко застарівають. Після того, як документ застаріє, майбутній розробник швидше за все не зважатиме на нього, замість того, щоб повернути його відповідно до реальності (думаю, що змінює вимоги).
Замість документації як такої, я рекомендую одиничні тести. Я знаю, що це, ймовірно, звучить по-старому, але нехай код робить документування для вас. Зламані одиничні тести важко ігнорувати (і простіше помітити), ніж документ Word. Крім того, англійська мова жахливо неточна для артикуляції тонших пунктів дизайну програмного забезпечення. Просто занадто багато способів інтерпретувати значення навіть найпростіших англійських речень, і це просто призводить до плутанини та / або помилок.
readmeфайлі. Якщо код збирається та працює, все налаштовано.
Саме тому коментарі не мають кодового запаху. Це також, чому ми повинні документувати наш код.
Ви повинні переконатися, що у вас є обгрунтована документація. Існують програми, які можуть генерувати документацію з коментарів залежно від формату коментарів та мови програмування.
Поміркуйте, яку інформацію ви хотіли б про бібліотеку або кодову базу, коли ви приймаєте її. Попросіть друга, який є програмістом, швидко оглянути і побачити, чи не помічають вони явних питань.
Удачі!
Переконайтесь, що ваш код збирається та упаковується в остаточній формі лише однією командою / клацанням.
Я не можу відповісти на відповідь. Які речі слід пам’ятати, готуючись здати проект? достатньо, тому мені доведеться записати це ще раз.
Я дуже вибагливий щодо цієї компіляції одним клацанням , тому що я вже вклав стільки часу, щоб зрозуміти, як насправді скласти або упакувати проект, що мені довелося виправити лише одну маленьку помилку. Я почав вводити невеликі сценарії пакетних / баш-програм у свої проекти, щоб упакувати остаточний ZIP, JAR або EAR.
На додаток до цього я додаю README.txt до кореневого каталогу, який описує загальний дизайн , складні частини та середовище проекту (з точки зору спілкування з іншими відділами чи особами).
Я намагаюся зберегти цей README.txt невеликим , тому що ніхто не читає 200+ сторінок документів із специфікацією, якщо все, що ви хочете зробити, - це виправити помилку, компілювати та упакувати її. Деталі впровадження задокументовані в одиничних тестах , тому немає необхідності записувати все це знову в книгу ...
Мій контрольний список передачі за замовчуванням:
Якщо щось зламається, я би це виправив перед здачею. Ніхто не змушує кого-небудь розпочати, а потім перевірити проект, створити та запустити день, коли ви отримаєте проект.