Как быстро разобраться в чужом проекте?

Question

[raiboon]

Пришел на проект, другой программист уходит через две недели.
Можете порекомендовать план, как максимально эффективно использовать эти две недели, чтобы по максимуму вникнуть в код?
Доков особо нет. Что точно должно быть задокументировано?

Answer 1

[Рональд Макдональд]

Обратиться к программисту с просьбой всё рассказать.
Две недели - вполне достаточно для проекта средненького пошиба.

Ну или бежать, пушо вот это:

Доков особо нет.

Вместо тысячи слов говорит об уровне конторы и постановке работы отдела разработки.

Comments

[Василий Банников]

Ну и кидать в проект нового разраба, который должен заменить единственного, который уходит через две недели - тоже такое себе.

[Hemul GM]

Василий Банников, я б сказал так: "автору п***а"

[Василий Банников]

Hemul GM, да и работодателю с таким подходом тоже)

[Hemul GM]

Василий Банников, возможно, работодатель, тут жертва :D

Answer 2

[pavelsha]

Эти две недели "Живите вместе" с прежним разрабом.

1) Пусть расскажет архитектуру, надет все обрывки по постановке ТЗ и выполнению, детально их покажет и отсортирует.

2) Пройдите с ним по типовым кейсам поддержки / доработки. На второй неделе садитесь сами выполнять все заявки по системе, которые приходят на разраба (он чтобы был рядом как тьютор)

3) Фиксируй для себя сразу, что было не понятно. И спрашивай

4) Попробуй договориться (в идеале через руководство) или лично со старым разрабом, что можете обращаться к нему эпизодически за советом ближайшие несколько месяцев.

5) Пусть старожил расскажет бытовые / политические / экономические особенности этого работодателя.
У тебя идет испытательный срок? Прекрасно! В случае Пушного зверька на горизонте имеешь право уйти одним днем.

6) Если время позволяет и ресурс есть, то пусть аналитики или этот разраб (если он Алл-инклюзив) садаться и ночами пишут доки по системе. Со стороны работодателя будет корректно предложить за это премию / бонус / договор ГПХ после увольнения разраба.

Answer 3

[Saboteur]

Доков особо нет. Что точно должно быть задокументировано?

Все логины, пароли, хостинги, зависимости, версии использованного ПО и либ, структура БД, политика бэкапов.

А дальше все зависит от того, что нужно делать - если активно разрабатывать, то может и не стоит браться.

Если лениво поддерживать, то уведомив о рисках что проект неизвестный, можно неторопясь разбираться.

Answer 4

[Александр Прохорович]

Умение читать чужой код - чуть ли не первое, что спрашивают при трудоустройстве. В первую очередь изучите, как ПО должно работать с точки зрения пользователя, по пользовательским инструкциям (заодно уточнив, реально ли это сделано или только в планах). А дальше, если голова на плечах, можно и разобраться.

Comments

[pavelsha]

умение читать чужой код - это одно....
а вот умение не материться при этом и не уходить после чтения в состояние "херня какая-то - напишу свое с блекджеком и шлюхами" - несколько другое.

Иногда костыли и отступления от паттернов оправданы.

Здравый смысл при этом никто не отменял. Будь готов, что в старом проекте есть решения архитектурные / в UI / бизнес-процессе, который обеспечивпет ПО, класса "сделали так потому что у нас так принято". Свежий взгляд позволяет их заметить. А их отмена порой приводит к заметным улучшениям для большинства участников

[Александр Прохорович]

pavelsha, ну это же классика, материть предыдущего разработчика) Самое печальное, что часто совсем не остается времени и возможности после этого свежего взгляда исправить старые архитектурные косяки, потому что они слишком глубоко вплетены в код, и приходится и дальше тянуть их и еще больше городить костылей и велосипедов...
Да и отмена какого то на первый взгляд очевидного косяка иногда приводит не к улучшению для большинства, а к падению важного функционала. Здесь всегда нужно быть крайне осторожным.

[pavelsha]

Александр Прохорович, самые дорогое косяки обычно не в коде, а в бизнес-процессах или взаимодействии исполнителей.

Пример,
Есть процесс получения полномочий пользователя в ИТ-системе. В него решили встроить цепочку согласования: Руководитель сотрудника - Владелец роли - сотрудник ИБ. Касается это ВСЕХ полномочий. Начиная с тупого бесправного оператора. Маршрут жесткий.
Текущий результат: получение полномочий может занимать неделю или две и закончится ничем. Согласование виснет на каждом из этапов. Процесс замещения на случай комадировок/болезни/отпуска не отработан. Специалисты простаивают. Владельцы и линейные руководители нагружены доп деятельностью.

Костыль, который используют пользователи и поддержка: права предоставляются по письму вне процесса получения полномочий. Сотрудник ИБ раз в полгода фонтанирует инцидентами по ИБ, грозит депремированием, но все прикрывают нарушение процесса риском простоев.

Недорогое, очевидное, решение: Убрать из согласования Руководителя и сотрудника ИБ. подключать доп согласующих только в сложных случаях по требованию.
Кол-во кода для реализации стремиться к 0Кб.

[Александр Прохорович]

pavelsha, сотни таких историй могу рассказать, пара в свое время закончилась роспуском целых отделов, когда в рамках анализа процессов автоматизации выяснялось, что на самом деле всю работу отдела делает один человек, а остальные бездельничают.
Вообще, замечаю, что для многих организаций вопрос неиспользуемого по факту внедрения нового продукта очень болезненный, хотя по факту в большинстве случаев проблема в плохой подготовке к внедрению, плохом анализе процессов и т.д. Кстати, с руководителями таких компаний потом очень сложно общаться, им везде видится пустая трата денег на ИТ, так как предыдущие процессы автоматизации заканчивались пшиком.

p.s. И про доработки продукта, вылившиеся по факту в перестройку бизнес-процессов вместо написания кода, мне тоже есть что рассказать)