×Закрыть

«Досконалі» архітектурні рішення

Мої вітання!

Я збираю, на мою думку, цікаві архітектурні, і не тільки, рішення (feellikeagrownup.files.wordpress.com/2015/08/leonard.jpg), і хочу поділитись ними з вами, і почути подібні.

Цілі що я переслідую цим топіком: посміятись(не цинічно), можливо натовкнути на думку що не треба так робити, або зрозуміти що я в корінь не правий і треба відкрити півчанській і дивитись телевізор

Почнемо:
1. Давайте створимо клас з глобал константами, а потім не будем ними користуватись а будем хардкодити стрінгі — шоб всім було «легше» міняти їх

2. Слабо типізовані мови то холі грааль для девів — можна ж написати функцію котра один раз верне int якшо все ок, а якшо ерор то map вернем з деталями шо сталось, ну і ше може трошка навернутись з ексепшеном — песня

3. Убер розумний фронтенд — от нашо завжди ходити до бекенда і шось там просити, якшо ми знаєм архітекруту і можна на пряму з фронта постучати на третьопартійний сервіс авторизації, потім піти загрузити медіа на пряму на s3 бакет, а потім з токеном від auth сервісу сказати бекенду шо я вже зарегався вот токен вір мені на слово шо я тебе не напарюю, і вот тобі ссилкі на картінкі які я сам же загрузив в твою інфраструктуру без твоєї участі

4. Давайте проксювати всьо з бази даних на фронт — треба тобі того не треба, палимо половину структури і дані які ніколи фронту не треба(я вже писав як гарно на конфі ЕПАМ так робив)

5. Не риба не мясо база — а давайте візьмем релейшен базу даних і половину задизайним правельно(нормалізуєм), а потім вдруг рішимо шо кльово мати декілька колонок котрі мапи(в даному випадко це PostgreSQL спецефічно, JSON field) в які ми валим нові колонкі без міграцій

6. Давайте юзати орм, але дизайнити базу як будто я ООП класи пишу — en.wikipedia.org/...​tional_impedance_mismatch

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

оффтоп — сугубо моє субєктивне: багато хто в коментах накідує на гвинтокрила всякі удобрення про мій стиль, як на мене це дуже гарний показник як працює маркетинг і політика... що дуже сумно для мене

гвинтокрила

Иногда сначала лучше узнать значение слова, перед тем как его использовать

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

На любой вопрос даете любой ответ?
Вы создали унылую тему на форуме и ... сюрприз: она мало кому интересна.
Отличе между политиками и вами в том что политики могут аолучить выгоду из имиджа «сельского дурачка», а вы просто зарабатываете себе такой имидж.

я знаю різницю між гвинтокрилом і вентилятором — в цьому і була суть

ну якшо тема нікому, або більшості не цікава, то шо поробиш — я був не правий

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

А по людськи написати все оце -не можна було?

дуже філософське питання, робити можна все що завгодно;
я обрав саме такій шлях — я не політик шоб подобатись всім, або більшості

хардкодити стрінгі

В труси?

«гавнокод це теж інструмент, а досвдчений майстер знає, коли варто застосувати той чи інший інструмент»
З того, що мені вдалося побачити на різних проектах, все може бути «не так однозначно».
Дуже часто, можна помилитись, коли вважаєш щось гавнокодом чи гавноархітектурою, без розуміння контексту, історії та потреб бізнесу.
Якщо проект існує, працює, приносить бабло, а тут з’являється Д’артаньян, який нарікає все какою і поривається переписати, то кака не проект, а Д’артаньян.
Але це не відміняє того, що в 99% випадках на кожному проекті є помилки і погані рішення, які можна порефакторити/переписати.

тут з’являється Д’артаньян, який нарікає все какою і поривається переписати, то кака не проект, а Д’артаньян.

Переписувати часом потрібно, і коли хтось береться — то чом би й ні?

Якщо фігове рішення було згенероване не достатньо кваліфікованим працівником і може бути легко переписане — вперед!
Але якщо для переписування треба

розуміння контексту, історії та потреб бізнесу

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

1) Коли на одну історію зверху накладається ще 10, то в тій купі костилів нема сенсу розбиратись.
2) Якщо маєте тестування, і хтось хоче переписати швидко — ну нехай спробує, якщо результат пройде тести — випустите як бету, і зможете поті ще 5 років нові костилі втикать в чисту архітектуру.

Переписувати часом потрібно, і коли хтось береться — то чом би й ні?

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

погоджуюсь, є дуже веселий репозиторій, і книжка по цій темі — github.com/...​ogans/unmaintainable-code

але у мому випадку я взяв випадкі відірвані від контексту, бо одна з моїх цілей посміятись — позитивно без тикання в код від братів котрим платили за лінійку коду

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

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

я чесно кажучи бачу подібне добрим рішенням якшо це повністтю не залежна штука від бекенда, скажем цсс або картінкі з гугла, а якшо фронт спочатку позбирав інфу(токени з аус сервіса) а потім прокінув його на бекенд, бекенд перевірив знов такі через аус сервіс чи валідний токен — якось за багото тєлорухів, я це бачу шо фронт постучав до бекенда і бекенд вже знає шо тре форвардити до аус сервіса....

на рахунок не архітекнурні рішення — погоджуюсь, я не знаю як ліпшіше подібне назвати

ліпшіше

Моя хотіти вбивати! :)

я не знаю як ліпшіше подібне назвати

анти-паттерны при написании кода.

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

я би не сказав шо це антипатерни, антепатерн це шось шо зустрічається часто, скажем пагано названі змінні, а мій намір більше звернути увагу на більш ріткі випадкі — я би сказав шо архітектура/антипатерни для мене десь однаково звучить — в цьому конкретному випадку

Жесть какая-то. На каком языке Вы этот текст писали?

я не розумію, що конкретно не так з тим як я це написав?

шо вы коверкаете украинскей Язык. инцыклопидию ни читали чи шо?

мені дуже шкода що вам не подобається мій текст :(

Текст то може й годний, але ж стиль!

Дуже розвернута стаття про еволюцію кода на тривалих проектах www.laputan.org/mud
Стара підбірка антипатернів, з тим, як кожен з них долати ff.tu-sofia.bg/...​nd Projects in Crisis.pdf

Подписаться на комментарии