Советы про разработке среднего приложения

Это общая проблема управления чем угодно, не только написанием программ. Осознание - первый шаг, на нем многие валятся. Второй - обсуждение с заказчиком, причем можно даже от себя несколько фич предложить, чтобы он понял объем работы. Дальше это должно вылиться в ТЗ, а там уже ногами можно запинать.

ТЗ - это понятно, но, что делать когда интеграция приложения начинается с другим сторонним к примеру ? Дело не только в сложности, а именно в отслеживании всей работы и что с чем взаимодействует.

В ТЗ и контроль прописывают, и интеграцию.

отслеживании всей работы и что с чем взаимодействует

Вот это и писать в ТЗ, как отдельный пункт с выделением времени и финансирования. А еще неплохо бы получить требования на

небольшой плагин

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

Я так понял нужно по плану действий делать что-то типа документации

А как ты уследишь если там 20 полей с верификациями, проверками, взаимодействием с аяксом и так далее. Так это только одна форма !

Новое тз?

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

тебе не аяксы нужны, а vue.js. его придумали чтобы писать интерфейсы, а не трахаться с dom-деревом и css

Рано или поздно это происходит с любым приложением. В самом начале предполагается один набор фич, по мере разработки он меняется, затем он меняется радикально.

В итоге, уже через 3-5 лет, приложение становится legacy с кучей костылей, заплаток. Половина кода уже не используется, но настолько тесно переплетена с существующим, что выпилить её никогда не хватает сил и времени.

Способы бороться есть разные, но, по большому секрету, ни один не помогает.

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

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

Да примерно тоже самое, тут предлагают «новые-технологии» спасибо, но, нет. На счёт вот-вот долетим, да, есть такое, вот думаешь уже «допилил» а потом то тут, то там, что-то «вылетает». Так если в среднем это ещё решаемо, а если прикинуть где девелопишь не только ты

веб-интерфейс разрабатывать не проще чем классический. у него один плюс - это кроссплатформенность и все

Ещё живучесть. Попробуй скомпилить на современной системе какое-нибудь приложение на Qt4 — это сделать крайне проблематично, так как Qt4 из всех репов давно убрали, а собрать без туевой хучи патчей современными компиляторами и с современными библиотеками не получится. Не говоря уже о Qt3. А старые сайты продолжают работать на новых веб-движках.

Расскажи детальнее.

А так, например, почитай про ФФФ: https://bureau.ru/about/fff/ чтобы немного в суть менеджмента любого процесса погрузиться

1. Диалог с заказчиком. Составление ТЗ. Утверждение ТЗ с заказчиком. Получение аванса.

2. Торопливая реализация «демо» версии с минимальным функционалом. Демонстрация заказчику. Сбор изменившихся требований. Получение аванса

3. Продумывание архитектуры. Рефакторинг и перенос на архитектуру. Реализация основного функционала. Демонстрация заказчику. Сбор изменившихся требований. Получение аванса

4. Внедрение новых требований. Получение оставшейся оплаты. Заключение договора на дальнейшую поддержку.

Что такое архитекрута — станет понятно из первого попавшегося видео на ютубе.

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

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

Проблема возникла тогда, когда заказчик, начала просить, добавить то, добавить это

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

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

Надо писать юниттесты. Внес доработки, запустил тесты, смотришь какие упали и дальше думаешь что делать.

Дело в том что архитектура - это когда ты пишешь или проектируешь с ноля, тут да, можно как говорится всё подготовить. А когда к одному проекту, к той же CMS, нужно «допилить» другое «приложение» + ещё пересечения в некоторых местах прав и функционала, то, выстроить определённую архитектуру тут очень сложно.

веб-интерфейс разрабатывать не проще чем классический

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

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

Собственно для этого рефакторинг и нужен .

Стоит только начать: «пересечения» прав выносишь в одни классы/файлы, функционал (в зависимости от типа/актера/кейса) — в другие, работу с БД/файлами — в третьи, «допилку напильником» приложения — в четвертые. А старое, ставшее ненужным — безжалостно вырезаешь. Вот тебе уже и 33% архитектуры готово.

На следующих итерациях классы/файлы и их функционал еще не раз перетасуются. Идеально сразу не бывает.

Полистай классику, пообщайся с дипсикой/гопотой на эту тему, они шарят.

• Мартин - Чистая архитектура
• Ларман - Применение UML и шаблонов проектирования
• Фаулер - Рефакторинг улучшение существующего кода

если фреймворк с готовыми компонентами взять, то ты тоже ничего не кастомизируешь, но в отличии от шедевров на голом qt (не qml), оно хотя бы везде одинаково будет выглядеть

Фреймворки тоже не всегда годятся. Так как можно написать куда проще и без лишнего функционала.

набивай шишки сам

Всё верно, так и есть.

Не хеллоуворлды писать понятно просто на любом ЯП. А вот, например, когда тебе надо тупо поле с форматированным текстом сделать, то сразу выясняется, что веб на порядки проще и удобнее, чем Qt/GTK/WINAPI/WinForms и прочие GUI фреймворки.

Это называется опыт. Тут есть несколько подходов.

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

Тут надо учиться ограничивать хотелки заказчика. Понятно, что невозможно на 100% обговорить все требования до начала работ, неизбежно будут появляться изменения, но эти изменения должны приводить к переработкам разумного размера. Т.е. нужно сразу говорить, что составляем ТЗ, что вне ТЗ, делать не будем. Потом на изменения соглашаться, но уже с «сильной позиции», типа ты и так делаешь одолжение, ну и за счёт этого отклонять те изменения, которые сложно реализовывать.

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

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

В этом подходе велика вероятность получить провал. Если программист не справился, то результат будет нулевой. Если заказчик не справился с формулировкой ТЗ, то результат будет ненужным. При этом оплата ведётся сразу, т.е. велика вероятность потерять много денег.

Второй подход это гибкая разработка. Разработка осуществляется периодами в две недели, в конец каждого периода есть готовый продукт, в начале каждого периода происходит планирование. За период можно реализовывать какие-то фичи, проводить рефакторинг старого кода и тд. Важно лишь, чтобы постоянно был готовый, пусть и с ограниченным функционалом, продукт. И далее вместе с заказчиком двигаете процесс к тому результату, который заказчика устроит. Оплата тут ведётся поэтапно, например за каждый двухнедельный спринт, но и заказчик всегда видит текущий результат. В итоге этой разработки всегда получается отвратительный неподдерживаемый код, переполненный костылями, но с другой стороны заказчик получает какое-то решение.

Как минимум полезно прочитать

Очень утрировано. И оба варианта рассчитаны на то что заказчик бомжует, а разработчик, набравший безграмотных кадров по блату, которых даже бесполезно учить декомпозиции задачи, пытается выдоить из него как можно больше денег (с учётом их отсутствия у заказчика), обменяв их на продукт который будет заведомо ущербным, т.е. заказчик всё равно заплатит, но будет платить тем что у него осталось - терпением при использовании ужасного продукта. Что, впрочем, можно понять глядя на современное состояние айти и бизнеса в РФ.

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

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

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

Да так везде. Типичная команда - 2 разраба, 2 анальщицы, тестерша и менегерка. И 4-х этих баб можно смело выгнать. Тесты сами разработчики могут писать (TDD). Архитектора в команде нет, так как архитектуру тоже они придумывают, а не баба, которая все про бизнесы рассказывает, не зная даже чем дебет от кредита отличается…

Вообще есть два подхода: калька с западных бизнец-процессов (у нас в стране карго-культ всего западного и слепое копирование) и славянская система разработки, когда есть куча программистов, которые неизвестно чем заняты, каждый занимается чем ему в голову взбредет… Но итог тот же самый, что в первом случае (работающее, но неподдерживаемое говно) и достигается быстрее

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

P.S баб оставить.

Типичная команда - 2 разраба, 2 анальщицы, тестерша и менегерка. И 4-х этих баб можно смело выгнать.

Можно одну анальщицу оставить?

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

самое оптимальное количество - это 0, но прогрессивные херки хотя бы одну специалистку протащат, которая все равно в итоге отвалится, так как будет стрессовать без знаков сексуального внимания (а если они будут, то соя будет уже о харрасменте трындеть)

в какой-то момент начинаешь понимать, что уследить за всем, становиться достаточно сложно

Во первых, это не проблема и с этим не надо бороться. Лёгкость внесения изменений - это неоспоримое преимущество ПО.

Во вторых, этим естественно нужно управлять. Называется «управление изменениями». Проще всего завести что-то типа Jira, MantisBT или приватный GitHub, и обучить заказчика этим пользоваться, чтобы он сам работал со своими предложениями.

Попытки же сделать статичное ТЗ до начала проекта обычно бесполезны и подходят только для начальной оценки и планирования.

Знаешь, когда-то я в одной компании был, там адекватно был бизнес процесс поставлен. А потом я учился на доп квалификации и меня на конференцию отправили. Послушать про продукт и разработку в «известной отечественной компании», сразу скажу что она известна только в своей нише, т.е. не яндекс и майлрушечка. И вот у них все те проблемы что тут описаны, а мне они дикими казались. Особенно позорно выглядело когда у них софт на презентации упал и они в поте лица перед инвесторами бегали за тимлидом, чтоб он его хоть как-то заставил работать. Тут дело не в копировании и карго культе или импортозамещении, а в том, что в первом случае главный челик имел непосредственное отношение к разработке и айти бизнесу. А во втором случае богатая бизнесвумен решила в айти зайти. Т.е. деньги есть, а желания у неё самой и понимания что нужно не хватает.

Баб борщ варить оставить. Согласен.

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

У qt плохо с обратной совместимостью? Так же как у питона? Я правда не знаю.

Хосспаде, какое же ты быдло.

А старые сайты продолжают работать на новых веб-движках.

Если бы.

для него может старые - это статика с танцующей гифкой кота… а так да: у того же ie была несовместимое js api, а повсеместно-распространенные технологиии типа flash, на которых были сделаны целые сайты удалены отовсюду. были еще silverlight, браузерная ява, activex… а 3d-игры в браузере запускали через plugin unity

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

Не замечал такого. Например, Федора 42 вышла месяц назад - имеется полный набор версий Qt, начиная с 3-й - qt3, qt4, qt5, qt6. Причем все эти версии можно установить одновременно, без конфликтов!
Сейчас у меня установлены qt3-devel, qt5-devel и qt6. Qt3 программы прекрасно компилятся современными компиляторами g++ 14 и 15 версии (правда куча варнингов идет на qt инклюды). Полученные бинарники работают с современными библиотеками. Собственно, так я проверяю исправления и добавления функционала. Затем компилю в виртуалке под древний Линукс и отправляю на объект внедрения (это разные технологические АРМы АСУТП).

А что на счёт тестов ?

Я вообще никогда к ним не прибегал, хоть и писал не мало кода.

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

Общественный консенсус - тесты нужны.

1. Тесты показывают, что код вообще хоть как-то работает. Ты проверяешь, а кто-то не проверяет.

2. Хорошее тестовое покрытие позволяет уверенно рефакторить код. Без тестов ты всегда боишься, что что-то забыл и теперь приложение с багом. Эта боязнь сильно мешает рефакторингу. А без рефакторинга качество кодовой базы будет падать.

3. Юнит-тесты являются дополнительной документацией к тому, как использовать твой код.

4. Тесты могут являться первым пользователем какого-либо API. Это может позволить понять, насколько это API адекватное.

5. Test-Driven Development тоже любопытная штука (разработка кода в цикле «тесты, код, рефакторинг»).

Конечно у тестов есть минусы:

1. Написание тестов занимает, собственно, время. А время - деньги.

2. При изменении кода может потребоваться изменение тестов. Т.е. тесты усложняют поддержку кода в будущем (но и одновременно упрощают за счёт факторов, перечисленных выше).

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

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

Поэтому при написании тестов нужно придерживаться определённого баланса. Какого именно - никто не скажет, тут уже всё на ощущениях и опыте.

Без тестов ты всегда боишься

обезьяны храбрые, они не боятся

Ну а так всё правильно, правда ты ещё одну штуку забыл, кто будет писать тесты для тестов, потому как в тестах я тоже видел ошибки, когда тестировали немного не то что надо тестировать или немного не так. Чтоб на пальцах объяснить, то можно проверять является ли фигура треугольником по наличии 3 вершин. Почти всегда будет правильно, конечно ровно до тех пор, пока 2 или более вершин не будут одной точкой.

Документацию надо писать, вот прямо ещё до появления кода, желательно техническую.

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

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

К сожалению, в отличие от тестов, документация не ломается, когда код меняется и перестаёт ей соответствовать. Сейчас требования к софту меняются ежедневно, код должен меняться многократно за день (смотрим, например, крупные компании - у них только количество деплоев может достигать тысячи в день). Надеяться, что документация будет успевать за изменениями кода…

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

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

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

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

А не надо менять код до смены документации.