Что ты смотришь сначала: код или дизайн?

Если вы только что познакомились с новым проектом, что вы в первую очередь ищете, чтобы понять, как он работает?

Вы ищете дизайн в первую очередь? Если есть дизайн, что вы ищете в нем? Диаграммы классов или схемы развертывания или диаграммы последовательности или что-то еще?

Или вы идете прямо к коду? Если да, то как вы понимаете, как взаимодействуют разные слои?

Я начинаю с кода. Отдельные проектные документы, если таковые имеются, с большой вероятностью могут быть ошибочными или ошибочными. Итак, я начинаю с попытки проследить некоторый простой поток через код; если это веб-приложение, это может быть, например, запрос или последовательность запросов. Как только я это сделаю, у меня будет своего рода скелет, на котором можно больше понимать. Затем я мог бы вернуться и прочитать проекты или другую документацию, но в этот момент у меня есть что-то конкретное, чтобы связать их и проверить их, чтобы я мог обнаружить ложную информацию. Или я мог бы просто продолжить чтение кода или тестовые случаи и т. Д.

Я бы начал с более высокого уровня. Если есть какая-либо пользовательская документация - руководство пользователя или руководство. В противном случае взгляните на спецификацию требований, чтобы у вас было представление о том, что должно делать программное обеспечение. Я хотел бы взглянуть на дизайн и попытаться сопоставить его с файлами кода. Надеюсь, они каким-то разумным образом структурированы в папки. Затем я выбрал бы часть проекта и пошел в файлы, чтобы следить за ходом кода, не слишком погружаясь в мелкие детали.

Я начинаю с настройки системы разработчиков. Я использую документированную процедуру. Это позволяет кошке из сумки узнать, насколько документация синхронизирована с реальностью.

Это также говорит мне, каковы зависимости. Это имеет значение

Теперь, когда у меня есть настройки для разработчиков (и я размечаю установочный документ по мере исправления), я создаю версию. Я заканчиваю тем, что задавал вопросы на протяжении всего этого этапа.

Сейчас он построен, я делаю вводное упражнение из руководства пользователя. Это говорит мне о том, что на самом деле делает система.

Теперь у меня есть частичная подсказка о системе, я читаю проектную документацию, в которую теперь я верю пропорционально тому, насколько ошибочными были документы.

Как только я доберусь до реальной поведенческой документации, я могу начать изучать код и видеть, что там на самом деле. Они никогда не выстраиваются в очередь, но теперь я знаю, во что верить.

Затем я смотрю на вывод IDE для комментариев "todo" и "fixme". Такие вещи, как «исправить в версии 2.0», также являются подсказками.

Так что все дело в изучении правдивости, и, как отмечают люди, отдельные проектные документы редко бывают актуальными или правильными, но они действительно говорят вам, что люди думали в определенный момент времени. И, конечно, этих людей, вероятно, нет рядом, чтобы допросить.

Я предпочитаю начать с дизайна, чтобы получить общее представление о проекте и попытаться понять некоторые его ключевые особенности и / или структуру, прежде чем углубляться в детали.

Всегда дизайн. С кодом стоит пройти этапы настройки разработчика (проверить исходный код, создать проект, внести любые необходимые изменения в конфигурацию), но нет смысла пытаться узнать структуру приложения из его кода. Это говорит только о том, что это за структура, а не о том, почему она есть, или о том, что другие разработчики думают о ее достоинствах и недостатках . Те, что вы узнаете из диаграмм доски и чатов с разработчиками.

Для сложного программного обеспечения я бы подошел к нему примерно так, как если бы это был новый проект разработки. Начните с больших идей - видения, контекста, масштаба, заинтересованных сторон. Прочитайте некоторую пользовательскую документацию и получите представление о том, как она используется. Пройдите обучение пользователя с помощью программного обеспечения, если это возможно (или применимо). Затем начните изучать требования и проектную документацию, чтобы понять, как она работает на высоком уровне. Поговорите с дизайнерами, если они все еще рядом. Посмотрите на архитектуру системы в разных ракурсах. Оттуда начните копаться в основной функциональности и посмотрите на некоторый код, возвращаясь к требованиям и дизайну по мере необходимости. Когда вы посмотрите на код, запустите программное обеспечение, чтобы увидеть его в действии. Все это время собирайте сводную документацию для дальнейшего использования - у вас есть Cliffs Notes. Разветвитесь, пока у вас не будет достаточно хорошего представления о том, как все это работает и сочетается, но сконцентрируйтесь на тех частях, с которыми вы будете работать. К настоящему времени у вас есть общее представление о всей системе или, по крайней мере, об отдельных ее частях.

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

Вы должны работать вперед и назад между самим кодом и любыми проектными документами.

• Вы можете начать с кода или дизайна, и это не имеет большого значения. Читайте код до тех пор, пока вы не почувствуете себя по-настоящему сбитым с толку, а затем посмотрите документацию по дизайну. Или прочитайте документацию по дизайну, чтобы получить общее представление, а затем посмотрите на код, чтобы увидеть, как он выглядит. Повторяйте почти до бесконечности, пока вы работаете с кодом.

• Имейте в виду, что документы по оформлению почти всегда устарели и во многом неверны. Однако, если вы помните эти моменты, устаревшие документы все же помогут вам понять мысли автора в какой-то момент в прошлом. Многие из проблем и проблем высокого уровня будут по-прежнему актуальными, и вы, скорее всего, сможете быстрее понять, как код попал туда, где он есть, если вы даже датируете картину того, где автор первоначально думал, что он собирается идти.

• Работая над кодом и дизайном, создайте свои собственные документы, которые описывают ваше понимание кода сегодня. Может быть, эти документы представляют собой простой эскиз или два, может быть, они написаны в вики, может быть, они что-то еще. Не делайте их слишком сложными: никаких документов на 30 страниц. Просто изложите свои идеи, что значительно прояснит ваше мышление.

Это зависит от типа приложения. Если это приложение, ориентированное на данные, я обычно начинаю с проектирования базы данных. Если у него есть пользовательский интерфейс, который вы можете запустить (или хороший дизайн экрана), он также может дать вам хорошее представление о том, что приложение делает очень быстро (я говорю здесь всего несколько часов). После этого я начинаю копаться в коде, и это будет иметь больше смысла, потому что я знаю, что делает приложение.

Я начну с конструкторской документации. В частности, спецификация, в которой указывается цель рассматриваемой вещи.

Если возможно, тогда я просматриваю заметки по проектированию и документацию, чтобы получить общее представление о том, как это было сделано, процесс мышления, стиль и характер заинтересованных лиц.

Если возможно, я тогда поговорю с людьми, которые работали над этим - что это делает? Как? Почему? Где похоронены тела?

Среди разработчиков существует тенденция прыгать в код: «Позвольте мне показать вам этот код». Это хорошо для них, но имеет тенденцию угонять мои потребности - то есть понять высокий уровень, который дает контекст для вещей низкого уровня.

Он использует огромное количество умственных способностей, чтобы взглянуть на небольшие кусочки кода вне контекста и понять что-либо значимое. Поэтому, если это возможно, то, чтобы разработчики говорили о ПРИНЦИПЕ, структуре, единицах, модулях, все это приводит к пониманию задачи.

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

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

Все это говорит - когда нет ни доко, ни людей, а только кода - тогда для этого нет ничего, кроме как посмотреть на код.

В этом случае я обычно не пытаюсь понять это медленным глубоким чтением, я делаю быстрый проход, просматривая все. Иногда это просто открыть файлы и сидеть с нажатием клавиши вниз страницы. Вы можете получить удивительную оценку большой картины, просто делая это. (И в некоторых случаях я даже выполняю строковые дампы исполняемых файлов и тралю их в поисках сигнатур и шаблонов. Это было удивительно плодотворно за последние 20 с лишним лет.)

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

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

Я всегда стараюсь повысить ценность того, на что смотрю; написание тестов, очистка кода, рефакторинг больших (более 20 строк) функций.

Я считаю, что создание документации само по себе не добавляет никакой реальной ценности коду, поскольку оно никогда не взаимодействует с кодом.

ну что такое "дизайн"? README? диаграмма uml? вы можете сделать дизайн документа на полпути (и большинство делают), вы не можете писать код на полпути

любой дизайн просто будет мнением , тогда как код является фактом

Я буду ссылаться на вторичные документы только тогда, когда не могу понять смысл кода

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

Затем я смотрю на README, TODO и Changelog разработчика. Если я не понимаю, почему было написано программное обеспечение, как оно было написано и куда оно идет ... Я не использую его.

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

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

Более конкретно, мой подход «сначала дизайн» таков:

Я начинаю с модели de domain, если она есть, если ее нет, я строю хотя бы базовую модель (хорошей отправной точкой является модель данных). Он определяет «глоссарий» приложения и отношения между объектами (классами).

Это изображения "какие объекты обрабатываются" приложением.

Затем я ищу модель варианта использования, чтобы выяснить, «какие процессы выполняются» приложением, хотя я предпочитаю карту процессов, если она одна, которая показывает последовательности процессов.

После этого у меня должна быть хорошая картинка приложения, и тогда я могу приступить к разработке изменений.

Кстати, ответ выше в контексте бизнес-приложений.

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

Наконец, вы получите то, что является безоговорочным представлением о том, что делает программа, законченную головоломку. Документация может быть неполной или неточной, но код никогда не лжет. Все это вы можете сделать, не понимая, что делает каждый отдельный метод. Не каждый может узнать о проекте таким образом, но если вы будете делать это часто, вам будет легче, не говоря уже о том, что вы можете получить суть приложения среднего размера за пару часов обучения. Хотя, полагаю, все сводится к предпочтениям.

1. Функциональное назначение приложения
2. Функциональная сфера применения и поток приложения и его связь с другой системой заказчика.

После того, как я вижу код самого критического модуля / точки приложения: увидев код, я могу проверить правильность дизайна.

Пример:

Вы должны работать в управлении приложениями веб-приложения о финансовой отчетности.

1. Я спрашиваю и читаю документацию о цели: какие данные нужно сообщать? Кто использует это приложение?
2. Каковы связанные системы? Есть ли какой-нибудь срок для получения или отправки данных кому-либо? Если эта система не работает, какие другие приложения повреждены или остановлены, какие другие отделы повреждены?

После того, как я прочел код сообщения, начальное и конечное приложения (для вероятной блокировки в дБ), мастер-процесс создания данных, о которых нужно сообщить и т. Д. И т. Д. (Например, в хранилище газа главный процесс о расчет запаса газа в зоне хранения клиентов с подачей и закачкой; вторичный процесс - это расчет по этим данным, предварительно рассчитанным)

Ни кода, ни дизайна. Мне нравится общаться с заинтересованными сторонами и конечными пользователями и узнавать, как это работает с их точки зрения. Как только я смогу создать из них картину, я быстро взгляну на технический дизайн и затем на код.

Сначала я пойду с дизайном, а затем буду писать код. Это очень важно, потому что все проекты разные. Вам нужно выработать план и высокий уровень рабочего процесса от А до Я, прежде чем вы сможете начать работать над кодами одновременно. Каждое принятое решение должно быть задокументировано, чтобы другие команды (или вы), которые занимаются разработкой кодов, знали последние обновления и то, что было подтверждено.

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

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

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

Там нет правильного ответа для каждой ситуации!