BG Development


Страници: (6) [1] 2 3 ... последна »  ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> Стратегия за пренаписване на система
relax4o
Публикувано на: 06-11-2018, 20:35
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2152
Регистриран на: 04.04.07



Здравейте,

Във фирмата, в която работя(малко повече от 2 месеца) се опитваме да измислим стратегия за цялостното пренаписване на системата, която поддържаме докато пазим и клиентите щастливи с покриването на техните желания.
Системата е писана на PHP от човек, който си е нямал грам понятие от програмиране. Всичко е ужасно направено, всеки файл е с по над 6к реда, базата данни е структурирана така, че една таблица да има по 100 колони и всичко е заплетено ужасно.

Като цяло фирмата за която работя предлага 4 различни продукта(свързани са с покупко/продажба на апартаменти, отдаване под наем и т.н.) и всичките тези системи трябва да общуват помежду си. 2 са писани на PHP, другите 2 на ASP.NET.

Комуникацията е скалъпена по някакъв начин с фийдване през разни фтп-та и глупости, даже и аз изцяло не знам как работи.

Мислихме за рефакториране, но това няма как да се рефакторира. Ужасно трудно за трасиране и разбиране е кода.
Всичко уж трябва да е с идеята да е API, но не може и това да се нарече. Хвърчат разни exit-и насам-натам, коментарите са безсмислени - нищо не може да се разбере.
Остава да пренаписваме с идеята кое какво прави по сайта.
Проблема идва, че това няма да е работа за от днес до утре, а системата се използва постоянно, клиентите искат нови фичъри, искат подобрение на пърформънса, искат да се оправят бъгове, което отнема времето на всички.

Каква стратегия бихте взели вие за пренаписването на средно голяма, а може би и голяма система.
Както и как би било най-добре да се преструктурира(нормализира) базата данни без да се изгубят данни или да счупи каквото и да е?

Не знам дали пропускам нещо като информация, която би била от полза, но общо взето всичко е една плетеница. Ако добавиш нещо, не знаеш дали не чупиш друго.
Тестове няма, а и на този код няма и как да се напишат. Човека писал това си е мислил, че е използвал ООП, но всъщност е само спагети код набутан в клас.


--------------------
Бисери :D

QUOTE (oveRLuckEd)
Ползваш някоя нова версия на PHP, която е вече ооп ориентирана и заради това ти я изкарва тази грешка.


QUOTE (nbacool2)
Щом няма input полета, значи няма откъде да се направи SQL инжекция Very Happy
PM
Top
Golden Gega
Публикувано на: 06-11-2018, 20:47
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1077
Регистриран на: 04.06.10



Най-добрата стратегия е да си наемете човек с опит който да ви преведе през проекта. Ако това дето си писал е истина няма нищо смислено да направите сами.
PMEmail Poster
Top
relax4o
Публикувано на: 06-11-2018, 20:51
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2152
Регистриран на: 04.04.07



QUOTE (Golden Gega @ 06-11-2018, 20:47)
Най-добрата стратегия е да си наемете човек с опит който да ви преведе през проекта. Ако това дето си писал е истина няма нищо смислено да направите сами.

Ами за жалост това решение не мога да го взема аз, за това и сами търсим правилното решение, та вземем поне ние да станем "опитните". icon_lol.gif


--------------------
Бисери :D

QUOTE (oveRLuckEd)
Ползваш някоя нова версия на PHP, която е вече ооп ориентирана и заради това ти я изкарва тази грешка.


QUOTE (nbacool2)
Щом няма input полета, значи няма откъде да се направи SQL инжекция Very Happy
PM
Top
Golden Gega
Публикувано на: 06-11-2018, 21:25
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1077
Регистриран на: 04.06.10



Проблема е че не е достатъчно да се напише "ползвайте тази или онази стратегия" - много са подробностите и най-вече решенията които трябва да се взимат на база опит.
Ако сте решили да си трошите сами главите (което е похвално) аз бих подходил по следния начин:
Решавам че няма да създавам копие на системата, а ще я изградя наново. Това означава че изграждането на новата система трябва да догонва развиването на старата - т.е. в един момент старата трябва да спре да се развива.

За изграждането на новата система разделям проблема на три основни етапа:
- миграция на данни
- миграция на функционалност
- миграция на интерфейс
И при трите етапа подхода е еднакъв, затова и с цел да не стана досаден ще разгледам само миграцията на данни.

Има два варианта - единия е копирането на старата система, като се елиминира неизползваната част, дублираните данни и т.н. Това по ред обективни причини не е добре в случая.
Другия е изграждането на нова база данни и мапинга на данни. Кривия момент е че може да изпуснете функционалност/данни която има в оригиналната система (или пък да го направите по друг начин), и да го разберете на по-късен етап. Правилния подход е да изградите абстрактна база данни - или такава, която описва обектите максимално абстрактно. Например - ако става дума за система за недвижими имоти с точно определени потребители - брокери, администратори, наематели и т.н., то правилния начин за абстрактната база е да направите потребители и роли, като ролите са разширяеми, един потребител може да има повече от една роля и т.н. Тогава, ако на по-късен етап разберете че в старата система има някакъв вид потребители - да кажем собственик на апартаменти - то вие с минимални усилия да добавите нова роля.
Следва мапинга на данни - трябва да можете да експортирате данни от старата система и да ги импортирате в новата. Процеса трябва да бъде многократен и да бъде дирефенциален, т.е. да може да се импортират само тези данни които вече не присъстват или са променени. Този процес е лакмуса докъде сте успяли с изграждането на новата база.
По подобен начин се процедира с миграцията на функционалност и накрая с интерфейса.
Успех.
PMEmail Poster
Top
SuN
Публикувано на: 06-11-2018, 21:42
Quote Post


Group Icon
Име:
Група: Администратор
Ранг: Почетен член

Мнения: 7240
Регистриран на: 27.01.05



Ще оставя интересните въпроси на желаещите да споделят опит (много важни въпроси, на които не си отговорил), но за това:

QUOTE
Каква стратегия бихте взели вие за пренаписването на средно голяма, а може би и голяма система.

Бих искал повече пари веднага или поне твърда уговорка в кратки срокове (до 3 месеца) за повишение. Иначе не бих си мръднал пръста както правя в момента с един такъв проект. icon_smile.gif

П.п.
Сега гледах обяви на една фирма в метрото, която благодари на тая и оная роля на хора в екипа им, но принципно това е страшно неблагодарна работа. Нямаш ли моментално минимална изгода, която е поне двойно на това, което би искал винаги ще си прецакан.

Това мнение е било редактирано от SuN на 06-11-2018, 21:42


--------------------
Копирай лесно ударено и - ѝ Ѝ
Замърсяване на въздуха в София - http://aqicn.org/city/bulgaria/sofia/druzhba/
PMEmail Poster
Top
relax4o
Публикувано на: 06-11-2018, 22:05
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2152
Регистриран на: 04.04.07



Благодаря за отделеното време, @Golden Gega.

То отново ще е копие, така или иначе функционалността трябва да си остане + новите фичъри, които изискват потребителите.
Точно това се опитваме да анализираме, до кога ще можем да добавяме нови функционалности и същевременно да разработваме на ново системата.

Там малко се различаваме по мнение с Product Owner-а, но всеки гледа своето. Ние гледаме как да си улесним живота, те гледат да пазят клиенти, което е напълно разбираемо. Все пак те ни правят заплатите.

Project Manager-а има на идея да микросървизира всички системи. Оттам на идея имах да взимаме отделни части и да ги микросървизираме, като всеки микросървиз да си използва собствена база данни, т.е. само тези, с които трябва да работи.

Оттам се улеснява хем оправянето на базата данни, хем кода, но пък проблем става цялостната структура(архитектура).
Всичко ще се усложни доста и за нашия случай, може да доведе до overhead и да изгубим доста перформънс.

Друга идея беше, да изграждаме новата система плътно до текущата, но лично аз не бях съгласен, понеже ще стане още по-голяма плетеница.

Ще прочета още няколко пъти поста ти, да мога напълно да асимилирам идеята, която предлагаш.

Иначе да, за сега смятаме сами да си трошим главите. icon_lol.gif Ако започнат да напират(това им е хубавото за сега, че дават зор), тегля им чертата.

@SuN аз не изисквам някой да дойде да ни оправи всичко, а само за насоки. Дори статии, конференции, които са насочени в тази насока - всичко би било от полза за взимане на идеи.


--------------------
Бисери :D

QUOTE (oveRLuckEd)
Ползваш някоя нова версия на PHP, която е вече ооп ориентирана и заради това ти я изкарва тази грешка.


QUOTE (nbacool2)
Щом няма input полета, значи няма откъде да се направи SQL инжекция Very Happy
PM
Top
SuN
Публикувано на: 06-11-2018, 22:15
Quote Post


Group Icon
Име:
Група: Администратор
Ранг: Почетен член

Мнения: 7240
Регистриран на: 27.01.05



От колко човека су състои екипа? Какво е мнението на другите? Какъв е реалния обем код? (файлове с по 6к реда не е информативно, нито стряскащо)

QUOTE
Точно това се опитваме да анализираме, до кога ще можем да добавяме нови функционалности и същевременно да разработваме на ново системата.

Това е работа на отговорника на екипа ти и на ръководителя. От коментарите досега става ясно, че все пак достатъчно бързо ги правите за да ви стоят клиентите и да не поглеждат алтернативните.

Ти си от 2 месеца там (а и професионално стажът ти беше малък), а мислиш за някакви пренаписвания? Година-две или три устройва ли те като срок за малък проект с много участници или се надяваш на нещо по-бързо?


--------------------
Копирай лесно ударено и - ѝ Ѝ
Замърсяване на въздуха в София - http://aqicn.org/city/bulgaria/sofia/druzhba/
PMEmail Poster
Top
relax4o
Публикувано на: 06-11-2018, 22:43
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2152
Регистриран на: 04.04.07



Написал съм какво е мнението на другите, написал съм и от колко човека се състои екипа.
Задаваш въпроси, на които съм отговорил.

6к може да не е стряскащо за C++, но както казах, ние пишем на PHP. Представи си 6к оплетен код в един файл. Това няма проследяване. Един клас прави много неща, един метод прави много неща и не е просто да се щракне с пръсти и да се разделят.

Не аз мисля за пренаписванията. Ти нещо се сбърка обаче. От къде на къде аз ще решавам какво да правя с продукта.

Всичко това го размишляваме с екипа естествено и взимаме решения заедно. Идеята на темата ми беше относно насоки, а не някой да седне и да ми напише гайд стъпка по стъпка какво да правя.

Ами не ги правим бързо. Точно в момента се опитвам да добавя нов фичър и се занимавам вече 2ра или 3та седмица само с това и прогреса не е очарователен, просто защото цялата работа е микс от олигофрения.
Съпорта просто си върши добре работата да обяснява на клиентите.

Това, че стажа ми е малко, не значи, че не трябва да съм заинтересован относно това. Ако не ти се споделят насоки, недей. Никой не карам, просто исках да чуя и вашето мнение като професионалисти с "повече" стаж.



--------------------
Бисери :D

QUOTE (oveRLuckEd)
Ползваш някоя нова версия на PHP, която е вече ооп ориентирана и заради това ти я изкарва тази грешка.


QUOTE (nbacool2)
Щом няма input полета, значи няма откъде да се направи SQL инжекция Very Happy
PM
Top
Golden Gega
Публикувано на: 06-11-2018, 22:47
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1077
Регистриран на: 04.06.10



Микросървисите са нож с две остриета. В генерален план те са за да осигурят производителност на определена цена - и тази цена определено не е опростяване на каквото и да било.

В един случай от моята практика имах за задача да направя модул за офлайн търговия към голяма търговска система. Това означаваше че трябваше да заредя определени категории стоки в мобилното устройство, да реализирам продажби и тези продажби да се върнат в основната търговска система. Говорим за десктоп софтуер, доста консервативен, преди доста години, така че популярни днес решения като уеб сървиси не вършеха работа.
Имах два варианта пред себе си - първия, да разуча търговската система и да копирам структурата на базата й. Това означаваше обаче да разуча и как работи, което гарантираше много труд, който едва ли някой щеше да плати.
Затова избрах втория подход, и направих абстрактна търговска база. Това означава че декомпозирах максимално всички участници и процеси - вместо крайни клиенти, дилъри, продавачи, доставчици и т.н. сложих контрагенти, вместо продажби и покупки - сделки между контрагенти, вместо фактури, касови бележки и т.н. - документи по сделката и т.н.
Интерфейса с основната база реализирах с SQL заявки, които ми разписаха от екипа на търговската система. Импорта и експорта на данни от мобилката към системата стана изключително гладко, защото в мапинга на данни нямаше дупки - в моята абстрактна база бях предивидил всичко, дори партиди (които тогава в търговската система нямаше).
Допълнителното време което вложих се изплати многократно - и като време, и като нерви, и за голямо учудване на отсрещния екип (и донякъде и на мен) - и като липса на комуникация, четене на документация, спорове и дрязги и т.н.

Във вашия случай декомпозицията всички данни и процеси ще ви даде толкова много ползи, че ще е трудно да се изброят. Най-важната обаче е че миграцията на данни, оттам на функционалност, оттам и на интерфейс ще се изплати многократно на по-късен етап. Не забравяй че тези миграции ще се правят многократно - ще се наложи да тествате и сравнявате резултати и функционалност много пъти и в различни условия.

За да завърша - опитен човек ще ви трябва не за да ви наставлява как да си пишете кода или правите базите. Той ще ви трябва за да предвиди всички възможни пръчки по време на изграждане на новата система и стиковането й със старата, да ви ги каже отрано и да минимизира цената която ще платите. Ако успеете да го направите сами - ще повярвам че деградацията в младите програмистки среди не е пълна icon_twisted.gif
PMEmail Poster
Top
relax4o
Публикувано на: 07-11-2018, 00:35
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2152
Регистриран на: 04.04.07



Благодаря.

Всичко би се изплатило многократно. По цял ден се хващам за главата, да се чудя какъв ум е успял да измисли такава идиотщина.
Едно поне със сигурност е успял да постигне - затрудняване на бъдещи програмисти да се чудят какво, аджеба, се случва. icon_lol.gif

Най-готиното в нашата ситуация е, че той използва една таблица да съхранява всичко, което се случва и това го използва да изкарва резултати в UI-а. Един запис е възможно да породи още 10 дъщерни записа в същата таблица.
В момента тази таблица съхранява данни за поне 50 случая.






--------------------
Бисери :D

QUOTE (oveRLuckEd)
Ползваш някоя нова версия на PHP, която е вече ооп ориентирана и заради това ти я изкарва тази грешка.


QUOTE (nbacool2)
Щом няма input полета, значи няма откъде да се направи SQL инжекция Very Happy
PM
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (6) [1] 2 3 ... последна » Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2018 | BG Development | All Rights Reserved
RSS 2.0