Ползвате ли концепции от DDD, на какви леъри разделяте проекта, ползвате ли SOLID принципи (като dependency inversion) и абстракции, или я карате по-просто?
Как решавате какъв да е дизайна на ОО системите ви
Дон Реба даже не знам какво ми говориш, честно
То ти не пишеше ли на C графични и low level неща? Там едва ли ги има тия истории.
Но при разните ентърпрайс проекти с OOP езици има разни архитектурни патърни, принципи и лигавщини.
realinformatik Дон Реба даже не знам какво ми говориш, честно
То ти не пишеше ли на C графични и low level неща? Там едва ли ги има тия истории.
Но при разните ентърпрайс проекти с OOP езици има разни архитектурни патърни, принципи и лигавщини.
Бегай бе - тва са гейщини. Ако знае CQRS и да "дебъгва в production" друго не му требва. 🙄
То ти не пишеше ли на C графични и low level неща? Там едва ли ги има тия истории.
пиша на С++ сякви неща
На тоя форум целта му е друга - да срещнеш умни хора и идиоти, понякога и микс между двете, да се понапсувате и въобще да разпуснеш, какви архитектури, какви патерни
realinformatik Ползвате ли концепции от DDD, на какви леъри разделяте проекта, ползвате ли SOLID принципи (като dependency inversion) и абстракции, или я карате по-просто?
Аз я карам по-просто.
Както е казал Баце (важи и за класовете дето пиша):
"Аз съм прост и вие сте прости и затова се разбираме!"
П.П. Ама дейба - ся съм у 2 проекта (и подобно на гуруто с 15k заплата у форума, бачкам у мега-миелеардна корпорация), Azure хуйни, Machine Learning, уу аа, ама май за SOLID не а чували. Некви класове от 1200+ реда, но пък за сметка на тва дължината на реда трябва да е максимум 120 символа (иначе ти връщат PR). 😏 "Добри практики, брат!"
Един от многото realinformatik Ползвате ли концепции от DDD, на какви леъри разделяте проекта, ползвате ли SOLID принципи (като dependency inversion) и абстракции, или я карате по-просто?
Аз я карам по-просто.
Както е казал Баце (важи и за класовете дето пиша):
"Аз съм прост и вие сте прости и затова се разбираме!"
П.П. Ама дейба - ся съм у 2 проекта (и подобно на гуруто с 15k заплата у форума, бачкам у мега-миелеардна корпорация), Azure хуйни, Machine Learning, уу аа, ама май за SOLID не а чували. Некви класове от 1200+ реда, но пък за сметка на тва дължината на реда трябва да е максимум 120 символа (иначе ти връщат PR). 😏 "Добри практики, брат!"
Какво стана с Гуруто? Той нали беше предприемач. Уж големи успехи. Пък сега на заплата.
pesho.konia Един от многото realinformatik Ползвате ли концепции от DDD, на какви леъри разделяте проекта, ползвате ли SOLID принципи (като dependency inversion) и абстракции, или я карате по-просто?
Аз я карам по-просто.
Както е казал Баце (важи и за класовете дето пиша):
"Аз съм прост и вие сте прости и затова се разбираме!"
П.П. Ама дейба - ся съм у 2 проекта (и подобно на гуруто с 15k заплата у форума, бачкам у мега-миелеардна корпорация), Azure хуйни, Machine Learning, уу аа, ама май за SOLID не а чували. Некви класове от 1200+ реда, но пък за сметка на тва дължината на реда трябва да е максимум 120 символа (иначе ти връщат PR). 😏 "Добри практики, брат!"
Какво стана с Гуруто? Той нали беше предприемач. Уж големи успехи. Пък сега на заплата.
Помага на пациенти у форума. Като всеки истински успешен човек. 😄 И все пак аз преподавам на студенти в ТУ-София... немам право да го храня за това...
Най-разумно на този етап ми се струва ако е тийм да си харесат някой готов хубав оупън сорс и да следват неговия шаблон. Аз най-вече се занимавах с .НЕТ преди да започна нацяло само инфраструктура / cloud. Майкрософт имат хубави примери вече публикувани. Взимаш един или няколко готови, взимаш им конвенциите и това е божия закон по отношение на правила и основна структура. Защото иначе има много спорове и нищо не може да се свърши. Един иска service layer, друг иска repository pattern, трети CQRS, четвърти DAL кръщавал, а не repository, някой искал и CQRS и Serice layer, защото иначе се повтаря един и същ код, това pattern, онова anti-pattern. По цял ден може да се спори и лийда и архитекта само да трябва да успокояват. Ако може да се намери нещо добро да се следва, сигурно е най-добре и да има доказателства, защо така или иначе.
pesho.konia Най-разумно на този етап ми се струва ако е тийм да си харесат някой готов хубав оупън сорс и да следват неговия шаблон. Аз най-вече се занимавах с .НЕТ преди да започна нацяло само инфраструктура / cloud. Майкрософт имат хубави примери вече публикувани. Взимаш един или няколко готови, взимаш им конвенциите и това е божия закон по отношение на правила и основна структура. Защото иначе има много спорове и нищо не може да се свърши. Един иска service layer, друг иска repository pattern, трети CQRS, четвърти DAL кръщавал, а не repository, някой искал и CQRS и Serice layer, защото иначе се повтаря един и същ код, това pattern, онова anti-pattern. По цял ден може да се спори и лийда и архитекта само да трябва да успокояват. Ако може да се намери нещо добро да се следва, сигурно е най-добре и да има доказателства, защо така или иначе.
Тук добре описваш, и точно по време на тея спорове излизат рогите на всички. И реално никой не е съвършено прав, че неговото е най-доброто, но за сметка на това си показва характеропатиите. Е Дърти Хари още цъка ADO.NET със сторнати процедури все едно сме 2003-та и му през канадската ливада какво мислим ние.
pesho.konia Най-разумно на този етап ми се струва ако е тийм да си харесат някой готов хубав оупън сорс и да следват неговия шаблон. Аз най-вече се занимавах с .НЕТ преди да започна нацяло само инфраструктура / cloud. Майкрософт имат хубави примери вече публикувани. Взимаш един или няколко готови, взимаш им конвенциите и това е божия закон по отношение на правила и основна структура. Защото иначе има много спорове и нищо не може да се свърши. Един иска service layer, друг иска repository pattern, трети CQRS, четвърти DAL кръщавал, а не repository, някой искал и CQRS и Serice layer, защото иначе се повтаря един и същ код, това pattern, онова anti-pattern. По цял ден може да се спори и лийда и архитекта само да трябва да успокояват. Ако може да се намери нещо добро да се следва, сигурно е най-добре и да има доказателства, защо така или иначе.
👍 👆 100% True Story!
Ама много хора дето казваш, почват да си теглят към техната камбанария.
Най-якото е кат внедряваш системи дето ще се използват в неколко чуждестранни офиса. Всеки офис със своите legal и др. глупости, но мани тва - всеки си ползва негови tool-чета, процеси и др. и вместо да вземат да седнат да се разберат като хора, некои фирми правят интеграция на системите с още 30 random проекта и tool-a.
Добре, че големите кур-порации са го яли тоя и правя глобални политики, дет верно мое да изглеждат "тъпи" на локално ниво, но алтернативата е "много по-тъпа". 😔
Много от тия принципи се занимават с повече абстракция и encapsulation, с цел да се скрият/decouple-нат компонентите или имплементациите едни от други (например dependency inversion principle). И така софтуера да е "софт", да може да се променя по-лесно.
Но на практика рядко се налагат големи промени, или една имплементация да се смени с друга или да има повече от една.
И хората почват да виждат тия абстракции като губене на време и спират да ги ползват. И накрая има само двете крайности - или напразно абстракнат код, или прост и couple-нат код.
Т.е. хората искат сляпо да копират принципите и принципите да им казват какво да правят, вместо да формират някакъв Principle for choosing principles.
Да, някои мислят, че базата данни трябва да е само сторидж и абсолютно никаква логика или даже да няма joins. Някакъв ORM отгоре само. Други виждат предимствата на joins и даже на stored procedures. Всъщност аз до последно бях в лагера на това да има повече в базата данни, защото да се оптимизирват тези ORM-и е ужасно сложно, а stored procedures примерно са много бързи. Но напоследък нацяло се занимавам само с cloud и не съм програмист даже, макар че ми липсва малко. Сега има и много други решения, които са по-cloud native. Но добре е да има някакви политически решения преди да се започне още, за да се избегнат конфликтите.
По принцип design patterns учат, че има неща, които искаш да предпазваш от промени, а други неща, които искаш да е лесно да променяш. И вече хората в тийма трябва да решат кое е кое в техния си бизнес. Абстракция за мен е важно нещо. Дори в cloud-a е полезно да се мисли за всяко нещо дори и човек като клиент на друго и всеки компонент да не се налага да знае повече отколкото трябва, за да му е лесна и ясна задачата. Много често в бизнеса даже хората са също просто част от софтуерната машина и същите правила важат за тях.
realinformatik Много от тия принципи се занимават с повече абстракция и encapsulation, с цел да се скрият/decouple-нат компонентите или имплементациите едни от други (например dependency inversion principle). И така софтуера да е "софт", да може да се променя по-лесно.
Но на практика рядко се налагат големи промени, или една имплементация да се смени с друга или да има повече от една.
И хората почват да виждат тия абстракции като губене на време и спират да ги ползват. И накрая има само двете крайности - или напразно абстракнат код, или прост и couple-нат код.
Т.е. хората искат сляпо да копират принципите и принципите да им казват какво да правят, вместо да формират някакъв Principle for choosing principles.
"Но на практика рядко се налагат големи промени" - зависи в коя област ти е практиката, едно е да правиш собствен продукт дори с форкнати версии за отделни клиенти, едно е да правиш софтуер по поръчка. В последния случай промяната идва от великия принцип "ама аз си го представях по-иначе", тогава е важно колко и каква гъвкавост си заложил за да може промяната (ако има и доколкото има) да влияе по-малко на крайната цена.
От друга страна гъвкавостта и колко струва е зависима от способностите (и предпочитанията) на екипа или поне на по-ключовите фигури в него, от това колко убедителен си да се заложи в началото и съответно да се убие част от скороста в името на крайния резултат и т.н. и т.н. Уникални неща се случват когато например се формира мултифирмен екип с много бабанки, тогава освен всичко друго е необходим много зен, дипломация и коварство за да се получи някакъв баланс.
В това отношение много помага да участваш в БГ форуми, те са един вид sandbox за меки умения, научаваш няколко основни момента които иначе ги няма в книгите за PM-и а са основни за работния процес, тренират се базови принципи при общуване с нискоинтелигентни съвкупности от клетки, вяра и непоклатима надежда за съществуването макар и в малки количеста на разумни същества и т.н.
pesho.konia Един от многото realinformatik Ползвате ли концепции от DDD, на какви леъри разделяте проекта, ползвате ли SOLID принципи (като dependency inversion) и абстракции, или я карате по-просто?
Аз я карам по-просто.
Както е казал Баце (важи и за класовете дето пиша):
"Аз съм прост и вие сте прости и затова се разбираме!"
П.П. Ама дейба - ся съм у 2 проекта (и подобно на гуруто с 15k заплата у форума, бачкам у мега-миелеардна корпорация), Azure хуйни, Machine Learning, уу аа, ама май за SOLID не а чували. Некви класове от 1200+ реда, но пък за сметка на тва дължината на реда трябва да е максимум 120 символа (иначе ти връщат PR). 😏 "Добри практики, брат!"
Какво стана с Гуруто? Той нали беше предприемач. Уж големи успехи. Пък сега на заплата.
Гуруто си е милионер отдавна. Един от многото не го знае, тука в тоя форум не се е вясвал изобщо, той говори за Стюи.
bobyb pesho.konia Един от многото realinformatik Ползвате ли концепции от DDD, на какви леъри разделяте проекта, ползвате ли SOLID принципи (като dependency inversion) и абстракции, или я карате по-просто?
Аз я карам по-просто.
Както е казал Баце (важи и за класовете дето пиша):
"Аз съм прост и вие сте прости и затова се разбираме!"
П.П. Ама дейба - ся съм у 2 проекта (и подобно на гуруто с 15k заплата у форума, бачкам у мега-миелеардна корпорация), Azure хуйни, Machine Learning, уу аа, ама май за SOLID не а чували. Некви класове от 1200+ реда, но пък за сметка на тва дължината на реда трябва да е максимум 120 символа (иначе ти връщат PR). 😏 "Добри практики, брат!"
Какво стана с Гуруто? Той нали беше предприемач. Уж големи успехи. Пък сега на заплата.
Гуруто си е милионер отдавна. Един от многото не го знае, тука в тоя форум не се е вясвал изобщо, той говори за Стюи.
Ааа, аз се чудих дали е същия Гуру. Ясно.