Как в промышленном программировании каталогизируются все функции, объекты и методы, которые есть в проекте?
Вот есть проект, его делает,например, 10-15 программистов.
В папке проекта примерно 500 файлов.
Ясно, что ни один человек не помнит наизусть, какие фичи где уже реализованы и как называются, чтобы не изобретать велосипед заново.
Плюс в проект приходят новые люди - как им объясняют структуру проекта (плакат во всю стену или что) ?
В готовой программе пользователю предоставляют help (например, в том MS Excel по функциям).
В серьезных конторах с правильным подходом к проектированию/программированию - каждый сам заносит свою функцию с описанием в некую локальную справочную систему или есть некие формы автоматизации этого процесса (типа что-то шерстит все файлы , а у файла в начале некая аннотация - так и составляется некий каталог и каждый программист перед изобретением велосипеда должен сначала там посмотреть, что уже есть из готового).
Вопрос родился, когда увидел список файлов "настоящего ынытрпрайз" проекта. Один из его разработчиков говорит, что никто ничего целиком не помнит конечно и естественно может изобретать велосипед по несколько раз - наплевать, лишь бы работало. Неужели это так ????
Секрет в том что память людей не постоянно и не важно о чем - коде Энтерпрайз проекта или запахе бабушкиной каши. Мы забываем все. В нормальных организациях есть документация (например, confluence), есть тексты (хотяб Unit), есть автоматизация (скрипты развертывания, Jenkins, .... ), есть репозитории с базовой информацией (README.md в git, хотябы), есть диаграммы (Visio, Lucidchart, ...) и много еще чего.
Ну и не забываем про документацию в коде и нормальные Фреймворк со стандартной структурой файлов
В нормальных организациях есть документация (например, confluence), есть тексты (хотяб Unit), есть автоматизация (скрипты развертывания, Jenkins, .... ), есть репозитории с базовой информацией (README.md в git, хотябы), есть диаграммы (Visio, Lucidchart, ...) и много еще чего.
из всего этого по делу "Confluence — тиражируемая вики-система для внутреннего использования организациями с целью создания единой базы знаний." - т.е. каждый программист сам должен вносить свои функции,объекты,методы с описанием в локальную wiki
есть тексты (хотяб Unit), есть автоматизация (скрипты развертывания, Jenkins, .... ), есть репозитории с базовой информацией (README.md в git, хотябы), есть диаграммы (Visio, Lucidchart, ...) и много еще чего.
Васе надо открывать окно по центру экрана - он написал свою функцию. Потом Пете понадобилось тоже самое и он снова написал свою функцию с таким же функционалом.
Вопрос: как тесты, скрипты развертывания, базовая информация в репозитории и "много еще чего" поможет Пете узнать, что такой функционал уже реализован Васей ?
Иван Шумов, спасибо, что отвечаете, но я не спрашивал про тестирование - чтоб тестировать надо знать о существовании тестируемой функции. Я спрашивал только про документирование создаваемого кода - сколько функций, объектов, методов уже создано и как ими пользоваться. Просто можете написать что используете в своей работе. Например, с Java.
Антон, я не программист, уже, поэтому не использую. Тесты это один из видов документации (хотя и вторичный, но не маловажный). О существовании функционала лучше всего узнавать на хайлевеле, а именно - в правильно структурированной документации, как, например, в Confluence или другой вики
Антон, каким вообще образом Вася и Петя решили делать одно и тоже? В любой дев-конторе должен быть хоть базовый таск менеджмент, который гарантирует, что Вася не будет делать то, что делает Петя и наоборот. Плюс в большинстве случаев все работают через гит, где под свои задачи есть свои бранчи, с логами и естественно коммитами. И даже если Вася с какого-то хрена подумает сделать то, что уже сделал Петя, при мерже будет вообще все-равно.
На счет сопровождения кода - очень часто как минимум используется авто-документирование типа doxygen или sphinx, например, дальше - кто как хочет. Единых решений нет, кто-то просто комментирует код, кто-то ридми-доки пишет, кто-то только на авто-документировании живет и не парится, везде по разному.
каким вообще образом Вася и Петя решили делать одно и тоже? В любой дев-конторе должен быть хоть базовый таск менеджмент, который гарантирует, что Вася не будет делать то, что делает Петя и наоборот.
Я не знаю насколько атомарно ставятся задачи в промышленном программировании - "инвертировать биты в байте" или "реализовать связь между ПЛК и РЗА по modbus по RS-485", но во втором случаем есть простор для велостроения.....
при мерже будет вообще все-равно.
речь не про мерж, а про жопочасы, потраченные на по сути одно и тоже разными людьми (бардак одним словом)
И даже если Вася с какого-то хрена подумает сделать то, что уже сделал Петя
Вася не специально это будет делать, а просто будет решать возникшую задачу, не зная, что она уже решалась Петей... и можно как минимум посмотреть его решение.... или взять целиком
очень часто как минимум используется авто-документирование типа doxygen или sphinx
вот это уже ближе к деталям....
Единых решений нет, кто-то просто комментирует код
этот комментарий другим людям в других модулях как-то виден? не пересматривать же все 500 файлов каждый раз наудачу...
Простой
Простой
Средний
Средний
Простой
Средний
