Дело в том, что почти всегда над проектом я работаю в одиночку. Проекты разной величины, ну скажем самые большие занимают год-полтора.
Так вот суть в чем. Я понимаю, что уже сто лет как напридумывали всяких редмайнов, джир и фабрикаторов, со скрам бордами через плечо.
НО! Заказчик пишет — я хочу такую то фичу, она должна свистеть, а сзади у нее должен быть красненький мотор. Он уложился в три строки. И вроде с виду
все понятно, думаешь, тю, легкотня на пару дней. НО! Начинаешь писать код, разбивать его на классы, потом на свойства, методы. Доходя до реализации,
которых, далеко углубляешься в дебри кода, соблюдение этих солид принципов и прочьего, что вчерашняя легкотня, превращается в монстрообразное мессиво
которое практически выходит из под контроля.
А выходит из под контроля почему? Потому что держать в голове его не удается. Например у меня 200 файлов с классами, в них в общей сложности 2000 методов и свойств,
а человек, насколько я знаю может держать в голове до 9 сущностей. ОК, в IDE все перед глазами и хоткеями можно перейти к нужному месту этого монстра.
НО! Заказчик говорит, а я хочу еще вот такую зелененькую свистелку сбоку.
В общем, чтобы не растекаться мыслью по древу, перейду к вопросу. У вас есть монстр, у вас есть задача. Между ними — пропасть реализации. Как удержать в голове и реализовать все микрозадачи?
Обычный процесс кодинга идет примерно так (по себе сужу). Вам надо создать класс (в нужной папке), создать в нем свойства, затем связать это с UI, потом поправить класс Settings, чтобы он учитывал внесенные изменения, в другом классе создать объект, перейти в нужный метод итд. В общем случае, мы постоянно прыгаем по коду. Огромному неуправляемому. И как проще сделать, чтобы эти прыжки были более продуктивными и не напрягали весь мозг.
Вот мой пример, что для этого делаю я. У меня есть мультизадача, или сверхзадача, которую обозначил заказчик (хотите менеджер). Разумеется я разбиваю ее на более мелкие подзадачи. И далее, исходя из них я начинаю кодить. Но тут и приходиться запинаться все время. Прыг в UI, прыг в конфиги, прыг в класс модели, прыг в класс view-модели,
назад в UI. И этот процесс цикличен. Между этими прыжками, можно потерять какую-либо деталь и вообще улететь в космос, размышляя о бытие.
Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?
p.s. сейчас мне представляется эта картинка из фильмов про хакеров, когда хакер бешено кодит и за 62 секунды у него получается прога. А еще, часто
на слуху в IT-блогах проскальзывает "состояние потока". Что это за состояние, когда тебе надо контролить уйму деталей? Писать все в один файл как emacs.c?
Здравствуйте, licedey, Вы писали:
L>Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?
Раньше писал в обычный текстовый файл — то есть да, блокнот.
Сейчас использую Org-mode — по сути те же самые текстовые файлы, но с минимальной структурой: иерархичеными пунктами, гиперссылками (в том числе и на конкретный кусок файла, в том числе и на файлы на удалённой машине через несколько ssh-туннелей), изображениями, интерактивными кусками кода на разных языках.
Здравствуйте, licedey, Вы писали:
L>Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?
Старый добрый принцип "слона едят по кусочкам". Разбиваем любую фичу на микрофичи (максимум на полдня работы каждая, обычно меньше) таким образом, чтобы по завершению каждой у нас был рабочий код. Рабочий — это не в смысле полностью функциональный, это в смысле всё, что доступно пользователю, является рабочим или прикрыто заглушкой. На микрофичу заводится отдельный тикет (подтикет, если ваш issue tracker такое умеет), дальше всё как обычно.
Конкретный способ разбиения зависит от команды, опыта разработчика, архитектуры и тыды и тыпы и подбирается по ходу дела, с третьей-пятой попытки обычно выстраивается рабочая схема. Оформляем по ней чеклист — готово.
Если разбиение систематически не получается — ну, вот вы и узнали, что такое технический долг
И да, пара сотен файлов — ни о чём. Разумеется, если у вас вменяемая система именования и IDE, которая умеет в моментальный глобальный поиск по произвольной части имени.
L>А еще, часто на слуху в IT-блогах проскальзывает "состояние потока".
Состояние, когда удаётся удерживать в кратковременной памяти все детали по текущей задаче. Переоценено, т.к при должном уровне опыта переключение с контекста на контекст не представляет особой проблемы. Особенно если прокачать скилл "отвечать угу/ага/давай позже, не вслушиваясь в вопрос"
Здравствуйте, licedey, Вы писали:
L>...Начинаешь писать код, разбивать его на классы, потом на свойства, методы. Доходя до реализации, L>которых, далеко углубляешься в дебри кода, соблюдение этих солид принципов и прочьего, что вчерашняя легкотня, превращается в монстрообразное мессиво L>которое практически выходит из под контроля.
L>А выходит из под контроля почему? Потому что держать в голове его не удается. Например у меня 200 файлов с классами, в них в общей сложности 2000 методов и свойств, L>а человек, насколько я знаю может держать в голове до 9 сущностей. ОК....
Все эти SOLID придумали не для религиозных ритуалов — это методы борьбы со сложностью. Нужно абсолютно точно понимать что значит каждая буква в это аббревиатуре, и зачем всё это, потому что иначе вместо уменьшения сложности ты получишь её увеличение.
L>..., в IDE все перед глазами и хоткеями можно перейти к нужному месту этого монстра...
Не нужно, не надо всё перед глазами — всё в твой мозг всё равно не влезет. Вместо этого стой системы так, чтобы всю систему ты мог схематически изобразить семью фигурами структурной схеме (каждый квадратик или кружочек на схеме — какая-то подсистема). Далее строй так, чтобы каждая подсистема могла быть изображена семью фигурками на плоскости и т.д. При таком подходе массивы каких-нибудь элементов должны представлять из себя отдельную фигурку: массив виртуальных машин в клауде, массив хранилищ данных, массив схем в БД, массив элементов данных.... После этого не допускай бардака, чтобы искать не приходилось. Т.е. нельзя допускать, например, чтобы элементы UI оказались среди элементов данных.
Соблюдая эти принципы ты избежишь излишней сложности: на каждом шаге тебе придётся оперировать небольшим множеством сущностей. Это намного, НАМНОГО лучше, чем когда перед глазами абсолютно всё одновременно.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Далее строй так, чтобы каждая подсистема могла быть изображена семью фигурками на плоскости и т.д.
Вот я бы не стал рекомендовать ничего подобного, т.к в большинстве случаев подобные хитрые схемы вырождаются в слепой карго-культ в стиле трёх сигм или ещё какой мутотени.
Подсмотрите опыт у профессий, где импровизация идёт вперемешку с типовыми процедурами и цена ошибки действительно высока — буквально везде safety checklist / SOP (Standard Operating Procedures). Для сложных задач — наборы SOP с изолированным контекстом (т.е. знать что-либо про остальные SOPы не требуется, всё содержится в самом списке).
P.S: не забываем, что чеклист — это не инструкция, а шпаргалка в стиле "чего тут можно сделать".
Здравствуйте, licedey, Вы писали:
L>А выходит из под контроля почему?
Потому, что фичи нужные заказчику размазаны по коду. Они не обязательно существуют в виде класса, метода и его части, но могут включать в себя куски в одних и тех же или разных файлах. Именно поэтому нужен функционал по CRUD, который позволяет выделять и объединять разные куски кода для выполнения этих операций. Это абсолютно тоже самое, что и SQL DML в базах данных или REST в сети, только для кода.
Как-то писал уже про модифицируемость кода и отсечение целей, хотя по хорошему данные о выделениях должны храниться вне кода. На самом деле это чисто программная проблема, ведь выделение это по сути положение и размер, а файл однозначно идентифицируется с помощью хеш-сумм. Группы выделений в файлах как раз и будут составлять необходимую фичу. Подобный функционал не встречал ни в редмайне, ни в какой-нибудь IDE, следовательно при всей своей навороченности программ фундаментальные проблемы программистов так и не решены.
Здравствуйте, velkin, Вы писали:
V>Подобный функционал не встречал ни в редмайне, ни в какой-нибудь IDE, следовательно при всей своей навороченности программ фундаментальные проблемы программистов так и не решены.
Blame в svn/git/... + интеграция с issue-трекером?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Философ, Вы писали:
Ф>>Далее строй так, чтобы каждая подсистема могла быть изображена семью фигурками на плоскости и т.д. S>Вот я бы не стал рекомендовать ничего подобного, т.к в большинстве случаев подобные хитрые схемы вырождаются в слепой карго-культ в стиле трёх сигм или ещё какой мутотени.
К сожалению твоя общая рекомендация "есть слона по кусочкам" часто приводит к тому, что каждый кусочек слона связан с миллиардом других кусочков слона, и даже просто добраться до кусочка 1ACE8 составляет проблему, не говоря уже о том, чтобы его поправить так, чтобы весь слон при этом не рассыпался. Моя основная мысль заключалась в том, что нужно оперировать разумным кол-вом кусочков за раз. А этого можно добиться только иерархическим проектированием этого самого слона.
S>Подсмотрите опыт у профессий, где импровизация идёт вперемешку с типовыми процедурами и цена ошибки действительно высока — буквально везде safety checklist / SOP (Standard Operating Procedures). Для сложных задач — наборы SOP с изолированным контекстом (т.е. знать что-либо про остальные SOPы не требуется, всё содержится в самом списке).
Такие чек-листы писались чьей-то кровью. Там каждый пункт — чья-то инвалидность или жизнь. Сомневаюсь, что ТС готов составить такой списочек. Так что тут больше подходят инженерные подход, типа проектирования сверху вниз.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sinix, Вы писали:
V>>Подобный функционал не встречал ни в редмайне, ни в какой-нибудь IDE, следовательно при всей своей навороченности программ фундаментальные проблемы программистов так и не решены. S>Blame в svn/git/... + интеграция с issue-трекером?
У меня все проекты в гите, да и с тем же редмайном знаком, более того, всё это связано вместе. Потому и говорю, что проблему "прыжков по коду" это не решает. Предположим есть фича 342 "ляляляляля ляляля ляляляля ляляляляляля". И мне нужна по коду операция Read в CRUD, она же Select в базах данных и так далее. Вот так фича 342 выглядит в файлах:
То есть при нажатии на фичу нужно открыть файлы где она находится и выделить нужный код. Более того, фича может пересекаться с другими фичами, отсюда нельзя накладывать ограничения на пересечения выделений кода с другими фичами, что в принипе упрощает дело по созданию такой программы.
А теперь представим, что такой информации нет. Вопрос, откуда программист возьмёт знания о том, что фича 342 "ляляляляля ляляля ляляляля ляляляляляля" заложена именно в этих строчках кода. Конечно, можно проанализировать код и догадаться, но это опять же говорит о том, что часть информации о разработке была потеряна.
Ф>К сожалению твоя общая рекомендация "есть слона по кусочкам" часто приводит к тому, что каждый кусочек слона связан с миллиардом других кусочков слона,
Есть такое дело, но это скорее к процессу разработки в целом вопросы, а не к проблеме топикстартера. Я ж не зря писал про "зависиот от команды/проекта/etc" Для наших проектов великолепно работает примерно такое комбо:
1. Нужен устоявшийся процесс разработки с микроитерациями
2. Обязательно использовать проектирование по реальным сценариям использования.
3. Не пренебрегать разделением ответственностей.
4. Следить за техническим долгом.
Если всё это выполнено — дальше никаких проблем. Если нет — требуйте замены слона, этот поломался.
Про разделение ответственностей при проектировании недавно расписывал, тынц
. В первой ссылке есть пара реальных топиков-примеров, чтоб было понятно, о чём речь.
Ф>и даже просто добраться до кусочка 1ACE8 составляет проблему, не говоря уже о том, чтобы его поправить так, чтобы весь слон при этом не рассыпался.
Ну, мне рабочий проект в таком состоянии не попадался (нерабочих было сколько угодно, но мы их сначала воскрешали, а затем уже лепили фичи), так что как быть с таким зомби — идей никаких.
S>>Подсмотрите опыт у профессий, где импровизация идёт вперемешку с типовыми процедурами и цена ошибки действительно высока — буквально везде safety checklist / SOP (Standard Operating Procedures). Ф>Такие чек-листы писались чьей-то кровью. Там каждый пункт — чья-то инвалидность или жизнь. Сомневаюсь, что ТС готов составить такой списочек. Так что тут больше подходят инженерные подход, типа проектирования сверху вниз.
+1. Тут необязательно дословно перенимать, идею уж точно можно позаимствовать. Если речь про разработку типовых вещей, как у топикстартера, то можно и без крови обойтись. Просто расписать текстом что делается прямо в процессе работы и ужать до 5-10 пунктов.
Здорово упрощает работу, т.к. в каждый отдельный момент времени в голове можно держать только часть задачи и сразу выбрасывать эту часть при переходе к следующему пункту. Не надо скакать обратно в проверках "что забыл" — уменьшается пространство состояний — меньше стресс. Анекдот про "мы меееедленно спустимся с горы" в действии
Здравствуйте, velkin, Вы писали:
V>А теперь представим, что такой информации нет. Вопрос, откуда программист возьмёт знания о том, что фича 342 "ляляляляля ляляля ляляляля ляляляляляля" заложена именно в этих строчках кода. Конечно, можно проанализировать код и догадаться, но это опять же говорит о том, что часть информации о разработке была потеряна.
Да отлично оно работает. Главное не забывать указывать номер коммита в issue tracker, по хронике потом восстановить кто, куда и чего труда не составляет.
Ну и не смешивать в одном коммите/куске кода несколько ответственностей, чтобы правки по несвязанным задачам не перезатирали друг друга.
Здравствуйте, Sinix, Вы писали: S>Здравствуйте, licedey, Вы писали: L>>Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как? S>Старый добрый принцип "слона едят по кусочкам". Разбиваем любую фичу на микрофичи (максимум на полдня работы каждая, обычно меньше) таким образом, чтобы по завершению каждой у нас был рабочий код. Рабочий — это не в смысле полностью функциональный, это в смысле всё, что доступно пользователю, является рабочим или прикрыто заглушкой. На микрофичу заводится отдельный тикет (подтикет, если ваш issue tracker такое умеет), дальше всё как обычно.
Слона то я съедаю на завтрак, обед и ужин. Я больше хотел узнать про инструменты. Выше Евгений привел пример одного. Я еще пользуюсь Help&Manual, что структурировать инфу, составлять свой knowledgebase.
Вы посмотрите сколько людей стонут в разделе Работа
кхм
(голосом Жириновского)
, что они не могут справится с этой махиной которая досталась им от прошлого пейсателя.
Из ваших слов, решение — issue tracker, остальное решит мозг?
Здравствуйте, Sinix, Вы писали:
S>Да отлично оно работает. Главное не забывать указывать номер коммита в issue tracker, по хронике потом восстановить кто, куда и чего труда не составляет. S>Ну и не смешивать в одном коммите/куске кода несколько ответственностей, чтобы правки по несвязанным задачам не перезатирали друг друга.
Дело не в коммитах и уж тем более не в том кто и что записал, ведь именно так и начинался топик:
Дело в том, что почти всегда над проектом я работаю в одиночку.
Потому и написал не конкретный код, а что-то вроде "ляляляляляля", так как это нельзя проанализировать, а нужно заранее знать указанное автором кода. Проектирование архитектуры программы, рефакторинг, её тестирование, документирование, не говоря уже о кодировании, а так же многое другое лишь частные случаи мыслительной деятельности конкретного программиста. Если посмотреть на топик далее:
Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть.
Так и выходит, что в итоге надо или помнить, или писать заметки. Но заметки тоже могут быть более развитыми. К примеру, я говорю о том, что сама система заметок плохо развита, так как не имеет прямой привязки к коду. Даже имея заметки, но не имея конкретного указания на код, и уж тем более возможности открыть весь связанный код вместе, получаем систему в которой программист вынужден использовать сравнение. Всё как по учебнику логики, только с отвлечением на лишние мозговые операции. А потом идёт синтез, куски кода сливаются вместе и для их разбора снова нужен анализ и сравнение.
Я к тому, что смысл не в том, чтобы разложить весь функционал по полочкам, то есть пространствам имён, классам, методам и тому подобным механизмам конкретного языка, которых в другом языке может и не быть. Вопрос в более эффективном анализе и синтезе, а так же сохранении результатов не только у себя в голове, но и на внешнем материальном носителе. Не помню в какой книге читал, но взять тот же опенсорс, казалось бы есть код, его можно прочитать и понять, а может быть откомпилировать и запустить. Однако в большинстве случаев теряется существенная часть процесса разработки, так как программисты редко описывают почему они приняли то или иное решение.
Здравствуйте, licedey, Вы писали:
L>В общем, чтобы не растекаться мыслью по древу, перейду к вопросу. У вас есть монстр, у вас есть задача. Между ними — пропасть реализации. Как удержать в голове и реализовать все микрозадачи? L>Обычный процесс кодинга идет примерно так (по себе сужу). Вам надо создать класс (в нужной папке), создать в нем свойства, затем связать это с UI, потом поправить класс Settings, чтобы он учитывал внесенные изменения, в другом классе создать объект, перейти в нужный метод итд. В общем случае, мы постоянно прыгаем по коду. Огромному неуправляемому. И как проще сделать, чтобы эти прыжки были более продуктивными и не напрягали весь мозг.
Если это твой индивидуальный проект, то ты можешь сам определять архитектуру.
Ну и организуй архитектуру так, чтобы прыжков было не очень много.
Я делаю так — у меня есть движок, гуи, и настройки.
Все три сущности размазаны по десятку файлов.
Но в каждый момент нужно работать только с одним сишником и одним хедером (итого — два) .
В смысле для движка два, для ГУИ два и для настроек два (всего одномоментно шесть).
Я работаю в Линуксе в KDE. У меня есть виртуальные экраны.
Движок на одном экране, ГУИ на втором, настройки на третьем, на четвёртом — отладчик.
Собственно всё, в человеческий максимум — 10 объектов я уложился.
Здравствуйте, alpha21264, Вы писали: A>Здравствуйте, licedey, Вы писали: A>Если это твой индивидуальный проект, то ты можешь сам определять архитектуру. A>Ну и организуй архитектуру так, чтобы прыжков было не очень много. A>Я делаю так — у меня есть движок, гуи, и настройки. A>Все три сущности размазаны по десятку файлов. A>Но в каждый момент нужно работать только с одним сишником и одним хедером (итого — два) . A>В смысле для движка два, для ГУИ два и для настроек два (всего одномоментно шесть). A>Я работаю в Линуксе в KDE. У меня есть виртуальные экраны. A>Движок на одном экране, ГУИ на втором, настройки на третьем, на четвёртом — отладчик. A>Собственно всё, в человеческий максимум — 10 объектов я уложился.
С мониторами — хорошая идея, думаю. Хотя не каждый может позволить себе, ну в силу площади рабочего места хотя бы. Я к тому и вел, чтобы меньше "скакать" — какой инструмент на данный момент лучший?
Чего вообще хочется идеального в вакууме. У меня есть класс модели и форма, для простоты. Я пишу класс — а форма сама строится, пусть криво, лучше потом поправить. Или наоборот, я рисую форму, а класс модели под нее уже готов. Совсем конкретно — сейчас навеяло меня WinForms на эту затею. Ранее WPF. Да и ASP.NET MVC, хоть и scaffold'ит что-то, но верстку все равно надо самому делать. Ближе всего к моей хотелке — конечно скафолдинг в MVC. В руби на рельсах тоже так можно. Но не покидает ощущение, что мы можем взять "перо" -> расчертить доску (блочный layout сделать) -> врисовать туда же пером контролы и приписать им метки. Все. На выходе у нас отверстанный (пусть частично) UI, у нас модель и у нас viewModel. А такие вещи, как settings, logs, exception handling, должны драгнгробом или кликом добавлятся в этот условный холст. Причем сеттинги и логи, тоже привязаны к нарисованной модели.
Есть такая странная технология как Lightswitch. Вот она как то, что-то близкое. Но все одно шаблон, интерфейс хауноу.
Oсторожно холивар
Не холивара ради, но UI на плюсах — у меня просто психика не выдерживает. Хоть Qt, хоть MFC, WinApi — все один сплошной геморой. И в том же духе Mac-ориентированные swift/objc.
Создавать вручную UI, кодом, узревая как поправил метку через 5 минут компиляции — не, за такое больше не берусь.
Здравствуйте, licedey, Вы писали:
L>Вы посмотрите сколько людей стонут в разделе Работа
Ну тут как — кто-то стонет, кто-то делает. Все обязанности распределены, все довольны
L>Из ваших слов, решение — issue tracker, остальное решит мозг?
В первую очередь — отсутствие бардака в проекте, мозг уже в довесок. Ну и плюс issue tracker и нормальная IDE, разумеется, которая умеет находить зависимости/места использования/текст в прямом эфире. Ничего сверх этого обычно не требуется.
Здравствуйте, velkin, Вы писали:
V>Дело не в коммитах и уж тем более не в том кто и что записал, ведь именно так и начинался топик:
Дело в том, что почти всегда над проектом я работаю в одиночку.
А какая разница? Это ж не повод разводить в проекте неразбериху до такой степени, чтоб рутинные действия начинали создавать проблемы. Как по мне, наоборот, "индивидуальные" проекты должны обкладываться всеми мыслимыми и немыслимыми подстраховками, ибо больше надеяться не на кого.
V>Потому и написал не конкретный код, а что-то вроде "ляляляляляля", так как это нельзя проанализировать, а нужно заранее знать указанное автором кода.
Бардак, без обид. Если без помощи человека из существующих артефактов (кода, тестов, документации и чтотамещё) нельзя восстановить что, зачем и куда, то код у нас неподдерживаемый. Для кого либо кроме автора ценности он представляет не больше, чем розеттский камень. Ну, т.е. только в плане занимательных историй на ночь.
V>Так и выходит, что в итоге надо или помнить, или писать заметки.
Угу, документацию по проекту надо вести. Систематически.
Если есть проблемы с сложностью проекта — обязательно с фиксацией в issue-трекере. Иначе потом концов не найти и проблемы тихо копятся, пока проект не загнётся под своим же весом.
V>Даже имея заметки, но не имея конкретного указания на код, и уж тем более возможности открыть весь связанный код вместе, получаем систему в которой программист вынужден использовать сравнение. А поиском зависимостей, хотя бы в виде find all references — никак?
V> Вопрос в более эффективном анализе и синтезе, а так же сохранении результатов не только у себя в голове, но и на внешнем материальном носителе.
Не вопрос — на выходе получится DSL-нотация, которая понимает все возможности вашего языка, но читается лучше и умеет синхронизироваться с кодом. Как по мне, сделать такую штуку на пару порядков сложнее, чем найти инструмент, который умеет строить граф зависимостей.
V> Не помню в какой книге читал, но взять тот же опенсорс, казалось бы есть код, его можно прочитать и понять, а может быть откомпилировать и запустить. Однако в большинстве случаев теряется существенная часть процесса разработки, так как программисты редко описывают почему они приняли то или иное решение.
L>Как удержать в голове и реализовать все микрозадачи?
А Никак. L>И как проще сделать, чтобы эти прыжки были более продуктивными и не напрягали весь мозг.
Никак.
У тебя прыжки не потому что код или инструменты, код и прыжки всего лишь отражают модель твоего мышления
Здравствуйте, licedey, Вы писали:
L>Дело в том, что почти всегда над проектом я работаю в одиночку. Проекты разной величины, ну скажем самые большие занимают год-полтора. L>Так вот суть в чем. Я понимаю, что уже сто лет как напридумывали всяких редмайнов, джир и фабрикаторов, со скрам бордами через плечо. L>НО! Заказчик пишет — я хочу такую то фичу, она должна свистеть, а сзади у нее должен быть красненький мотор. Он уложился в три строки. И вроде с виду L>все понятно, думаешь, тю, легкотня на пару дней. НО! Начинаешь писать код, разбивать его на классы, потом на свойства, методы. Доходя до реализации, L>которых, далеко углубляешься в дебри кода, соблюдение этих солид принципов и прочьего, что вчерашняя легкотня, превращается в монстрообразное мессиво L>которое практически выходит из под контроля.
...
Большой проект, 40 мегабайт в EAR, только половина — на внешние библиотеки. На Java. Писали десятки людей из не одной конторы десяток лет. Сотни тысяч обращений и загрузок данных (в основном XML, не часто бинарные файлы) в день в течении 2 недель в начале квартала. Не магазин. Слежу за всем один плюс подключается ещё человек, если затрагивается БД (слава разуму!).
И смысл [уже] был утерян. Изначально. Даже документации нет. Никакой! При передаче декомпилировали исходники, какая тут документация? И суть — рассыпается поневоле на отдельные кусочки. Это — да.
Мозг постепенно запоминает всю эту гущу. Мелкие ошибки устранены, но применением крупных, не адекватных усилий.
Теперь о главном.
Если заказчику и основному потребителю этого чуда что-то нужно изменить или добавить, то он пишет ТЗ! Оно практически всегда описывает проблему достаточно точно. Иногда даже не нужно звонить и уточнять. Похоже, это единственный путь реально бороться с расплыванием по древу мыслей заказчика и его фрейдистскими желаниями. которые неудержимы.
Суть метода ТЗ — упорядочивание мыслей заказчика и понимание им главной мысли — всё суета (Vanitas vanitatum et omnia vanitas).
Здравствуйте, licedey, Вы писали:
l> Так вот суть в чем. Я понимаю, что уже сто лет как напридумывали всяких редмайнов, джир и фабрикаторов, со скрам бордами через плечо. l> НО! Заказчик пишет — я хочу такую то фичу, она должна свистеть, а сзади у нее должен быть красненький мотор. Он уложился в три строки. И вроде с виду
Я как фанат ещё упомяну тесты (разных уровней Unit, Integration, Func, Perf, etc). Тесты тоже неплохой инструмент управления сложностью. Каждый тест по сути небольшая исполняемая программка, и вместо написания огромного сложного приложения ты пишешь сотни маленьких и простых. А собирать сложную конструкцию из простых и ожидаемо работающих деталей — проще.
Мало того, сами тесты служат документаций. Если непонятно что делает конкретная строчка|метод — всегда можно посмотреть как она протестирована.
Ещё наличие тестов заставляет использовать правильную архитектуру. Например, явное отделение API который можно легко тестировать и UI, который общается с человеками (понятное дело, что это больше подходит для более менее сложных приложений, где помимо UI есть хоть какая-то логика).
Ещё — регрессия. Когда будешь окрашивать новую свистелку в зелёный цвет ты не перекрасишь случайно свой красненький мотор.
А поиском зависимостей, хотя бы в виде find all references — никак?
