В настоящее время я являюсь единственным разработчиком / архитектором довольно большого веб-приложения (стек ASP.NET MVC, примерно 150 000+ строк кода), и конец разработки находится на горизонте. Таким образом, я начинаю думать о том, что нужно сделать для передачи проекта, и я хочу убедиться, что я делаю правильные вещи для тех, кто должен поддерживать проект в будущем.
О чем следует помнить при подготовке к передаче проекта другому разработчику или команде разработчиков обслуживания?
Ответы:
ИМХО, если бы вы могли сделать только одну вещь перед передачей вашего проекта (прямо или косвенно), я бы порекомендовал вам дважды и трижды проверить, что он компилируется как есть из системы контроля версий.
Не смеюсь, но я не могу сказать вам, сколько раз я получал «последние» из системы контроля версий, и она не компилировалась, но позже узнала, что я не была «на старой коробке Фреда», потому что, очевидно, код «только компилирует на старой коробке Фреда ". У меня даже был прежний работодатель, который быстро удалил мой рабочий стол из моего куба и заменил его «старой коробкой Фреда», чтобы я мог работать над проектом, который должен был.
В качестве расширения приведенной выше рекомендации, поскольку иногда получение последних версий - это не все, что необходимо для компиляции приложения, я рекомендую вам создать файл README.txt, поместить его в корневой каталог приложения и поместить его в систему управления версиями. Этот документ README должен содержать список внешних зависимостей, которые не могут быть включены в систему контроля версий (если таковые имеются), как настроить базу данных, и любые другие странности в циклах компиляции, выполнения или развертывания приложения.
Все, что выходит за рамки вышеупомянутых двух предложений, было бы просто подливкой, но ИМХО вышеупомянутые два почти необходимы для любого проекта, большего чем «Hello World».
РЕДАКТИРОВАТЬ:
По теме документации ...
На протяжении многих лет я писал и читал свою значительную часть документации по программному обеспечению с целью облегчить переход разработчика. Я бы сказал, что такие документы редко стоят той бумаги, на которой они напечатаны. При написании таких документов разработчики (включая меня) редко думают о важных частях приложения, мы склонны думать только о самых последних пожарах, с которыми мы боролись. Помимо того, что эти документы не охватывают все важные аспекты программного обеспечения, они также ОЧЕНЬ быстро устаревают. Когда документ устарел, будущий разработчик, скорее всего, полностью его проигнорирует, вместо того, чтобы привести его в соответствие с реальностью (подумайте об изменении требований).
Вместо документации как таковой, я рекомендую юнит-тесты. Я знаю, что на данный момент это звучит устарело, но пусть код сделает документацию за вас. Сломанные модульные тесты трудно игнорировать (и их легче обнаружить), чем документ Word. Кроме того, английский язык ужасно неточен для формулировки тонкостей разработки программного обеспечения. Существует просто слишком много способов интерпретировать значение даже самых простых английских предложений, и это просто приводит к путанице и / или ошибкам.
readmeфайле. Если код компилируется и запускается, все готово.
Именно поэтому комментарии не являются запахом кода. Вот почему мы должны документировать наш код.
Вы должны убедиться, что у вас есть надежная документация. Существуют программы, которые могут генерировать документацию из комментариев в зависимости от формата комментариев и языка программирования.
Подумайте, какую информацию вы хотели бы получить о библиотеке или кодовой базе при ее использовании. Попросите друга, который является программистом, быстро взглянуть и выяснить, заметили ли они какие-либо очевидные вопросы.
Удачи!
Убедитесь, что ваш код компилируется и упаковывается в окончательную форму всего одной командой / кликом.
Я не могу высказать свой ответ. О чем следует помнить при подготовке к сдаче проекта? достаточно, поэтому я должен записать это снова.
Я очень придирчив к этой компиляции в один клик , потому что я уже потратил столько времени на то, чтобы выяснить, как на самом деле скомпилировать или упаковать проект, что мне нужно было исправить только одну маленькую ошибку. Я начал добавлять небольшие скрипты batch / bash в свои проекты, чтобы упаковать окончательный ZIP, JAR или EAR.
В дополнение к этому я добавляю README.txt в корневой каталог, который описывает общий дизайн , сложные части и среду проекта (с точки зрения связи с другими отделами или лицами).
Я стараюсь держать этот файл README.txt небольшим , потому что никто не читает более 200 страниц документов спецификации, если все, что вам нужно, это исправить ошибку, скомпилировать и упаковать ее. Детали реализации документированы в модульных тестах , поэтому нет необходимости снова записывать все это в книге ...
Мой контрольный список передачи по умолчанию:
Если что-то сломалось, я бы починил это перед сдачей. Ничто не заставляет кого-то начинать с начала, а затем проверять проект, строить и запускать его в тот же день, когда вы его получили.