Добрый день, столкнулся с тем, что все проекты, которые ведутся у нас на фирме не имеют документации, что становится большой проблемой, а если к этому добавить, что над классом может трудиться более 5 человек - становится совсем грустно..))
Хотел узнать, как организовано документирование у Вас.
Спасибо.
Боюсь что это проблема не только вашей фирмы.
У нас тоже отсутствует какая-либо документацию и все понимамают что это плохо, но ничего не делается для улучшения ситуации.
Часто о новом функционале узнаешь когда уже напишешь свой велосипед.
Это проблема больших фирм, где отсутствует четкая иерархия 
По поводу документации, у меня только один совет исходя из практического опыта - максимально комментировать код, который пишешь. Комментировать так, чтобы понял человек, который придет после тебя.
У нас код в основном пишут субподрядчики, из обязательных условий - передача документации и кода с адекватными коментариями. Для своего тоже стараюсь следовать корпоративным правилам, благо время позволяет.
Да, был бы благодарен..
Я вот на эту ссылку наткнулся: http://techsahre.blogspot.ru/2011/01/apexdoc-salesforce-code-documentation.html
Добрый день, коллеги! Отдельный привет Диме, брестской команде респект!
По своему скромному опыту сужу: не в комментариях в коде дело. Например, вы опытный девелопер и вам дают проект. Конечно, же большинство из вас потянется посмотреть, пощупать существующую архитектуру и вот если ваши коллеги до этого не позаботились о достаточно полной документацией - потратите много времени на изучение "египетско-индуских манускриптов".
Например, я лично пользуюсь замечательным, но не идеальным, языком UML. Диаграммы классов, диаграммы состояний, диаграммы последовательности, компонентов и развертывания дадут вам больше преимущества, чем читать многотонную спеку, набранную 12 кегелем....
По этому поводу выдавил из себя стихотворение (немного не складно, но технологично):
(на мотив "С чего начинается Родина")
С чего начинается кодинг?
C открытия браузера IE,
С хорошей и старой IDE,
Устроившей многим тролинг?
С чего начинается кодинг?
А может с 3-ей версии магов
Или с QA - для поиска багов-
Эдакой продвинутый модинг?
С чего начинается кодинг?
Да, что мы все сверлим как дрель!
У опытных - с моделирования на UML
Вот с чего начинается кодинг.
На основе UML умелые архитекторы создают гибкие системы. Вообщем, кому интересно, могу посоветовать, где почитать и что почитать.
Art Vegas, привет! Добро пожаловать.
Про UML очень интересно! Сам несколько раз порывался его использовать в работе, да как-то объем информации отпугивал.
Было бы супер, если приведешь какой-нибудь практический пример, ну и конечно советуй где почитать :)
Для начала рекомендую с азов. Великого и ужасного Фаулера. Основы UML
http://a1308.ru/books/download/592
Книга живая, много лирики, не сухая. Я, вообще, не люблю сухую документацию.
(На корпоративном блоге стараюсь писать статьи в своеобразном стиле и как раз-таки по UML хочу сделать что-нибудь в стиле статеюшки.)
Если кто-то подается в бизнес-анналитики или архитекторы можем подисскутировать в отдельно топике.
Есть более свежий проект по генерации документации для салесфорса http://scox67.blogspot.co.il/2013/08/sf-apexdoc.html
Но он как и предыдущий реализован с оглядкой на яву. Поэтому личто я им не пользуюсь. Если у вас есть мысли и пожелания как бы сделали процесс генерации документации милости прошу. Сейчас уже реализован проект по парсингу апекс классов и в него можно будет добавить часть по генерации комментариев.
Добро пожаловать, wilder, на наш форум!
Я чувствую, вы многим нас сможете порадовать.
wilder, читая очередное твое сообщение, я понимаю, что к нам присоединился один из профессионалов мира Salesforce. Добро пожаловать. Может русское сообщество немного встряхнется с твоим появлением, потому что последнее время наблюдается некий спад интереса к этой теме.
Добро пожаловать!
Я думаю не будет наглостью попросить тебя рассказать немного о себе 
Про себя особенно нечего рассказывать. il.linkedin.com/in/salesforcedev401/
Проект начался почти 2 года назад, и задумывался он в первую очередь как помощь разработчику для автоматизации повседневных задач. Таких как хранение логинов и паролей от оргов. На сегодняшний день проект включает в себя очень большое число разных инструментов, начиная от классических (запуск кода, запуск SOQL/SOSL) до вполне экзотических (получение полной копии орга или генерация visual force page из стандартного лайаута). Так же в текущую версию интегрирован TimeSheet и SVN. Ну и по мелочи куча разных твиков salesforce.
wilder, вот это понимаю серьезная работа проделана!!!
Я думаю многим разработчиками будет полезны твои инструменты.
Есть ли возможность поделиться с сообществом твоими наработками, рассказать о твоих достижениях?
Я думаю было бы классно описать все подробнее с примерами и скриншотами.
(если есть такая возможность, то буду рад обсудить это напрямую)
ну тогда позволь, Дмитрий, мне немного рассказать о тебе, чтобы нашим коллегам стало понятно кто к нам присоединился.Дмитрий ломал Salesforce когда я еще про него не слышал. Когда много лет назад мне довелось начать карьеру Salesforce разработчиком Дмитрий был в числе гуру нашей фирмы. Он приложил руку к моему развитию в области SF и многим нестандартным подходам в работе с системой я научился именно у него. Сейчас Дмитрий продолжает свою карьеру уже за пределами солнечной Беларуси, но не забывает про нас Так что с удовольствием желаю Дмитрий успехов в работе и спасибо что присоединился к нам. Твоя помощь будет очень полезна русскому SF сообществу.
Как то не скоромно ты написал.
К сожалению поделиться не могу, так как это коммерческий проект. Но в планах создать тестовый орг на котором с некоторыми ограничениями можно будет поиграться с этими тиулами.
Копия всех метаданных включая кастомные поля в managed packages.
Для полной копии данных существуют другие утилиты, например dataloader, pentaho kettle и другие
можно ссылку на тот блог? удалось ли написать статью про UML?
Я поднял эту тему так как, как раз разбирался с комментирование кода, и вспомнил, что в этой теме писалось, что единственное реал-лайф решение проблемы с документированием - это как можно больше комментировать код.
Но в голову пришла мысль: таким подходом можно подробно описать проектную логику, выполнение которой реализовано непосредственно через АПЕКС. А SFDC тем и хорош для бизнеса, что так много логики можно покрыть через WFRules, WFActions, validations rules, фильтрах на лук-апах, формульных полях. Получается, что документации, описывающей работу кода, будет недостаточно, чтобы описать работу приложения...
С другой стороны, бизнес-аналитики дают нам UML схемы, описывающие бизнес процессы. Но опять таки - это описание бизнес процесс, а не того как именно работает приложение.
Есть над чем подумать.
