ФАКУЛТЕТ или КУРС за ДОБАР ПРОГРАМЕР?

[jamajka]

Правам муабет за проект кој е почнат некаде 2005, и се имаат сменето богзнае колку програмери, последниот човек кој што им работел напуштил и мислам дека не се во контакт.

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

Верувај, со истата мисла тргнале девелоперите во 2005... важно ми е да знам што бара клиентот. Ама од 2005 до денеска, се измениле можда буквално сите вработени во таа фирма, а во зависност од браншата и по неколку пати се направила ротација... Истото се десило и во компанијата која го развивала софтверот.. во меѓувреме, се смениле барањата, се размрдале приоритетите и дошле некои нови неочекувани моменти и све тоа било правено од девелопери попут тебе кои можеби врска немале која е големата слика на проектот, ниту пак знаеле кои се почетните барања... и све завршило како што завршило...

Доколку не се воспостават правила на игра и доколку тие правила стриктно не се следат и контролираат... па макар тие биле и сосема погрешни, долготраен успешен проект нема да може да опстои сам по себе...

Замисли си штои бил SugarCRM во 2005 кои техники на развој користел и каква била визијата тогаш, со тоа што е денеска визијата и какви се денешните очекувања... Тоа што порака ти дава??? Незнам за тебе, ама мене ми дава порака дека продуктите во IT секторот се доста краткотрајни, и без разлика колку да вложуваш во нивна скалабилност, на крајот секако ќе застарат...Некои функционалности како knowledge base или како некакви модули, можеш да искористиш... Но робустен продукт во целина... тешко.

Тие луѓе што инвестирале 15 години во тој развој на тој продукт, преминале којзнае какви све нервози и заебанции, инвестирале многу пари и очигледно се очајни да го доведат во ред... Не им е пријатен звукот кога слушаат дека треба сета таа инвестиција да ја фрлат во ѓубре, а особено не им е пријатен звукот кога слушаат дека не знаат што сакаат...

Многу е лесно за тебе да кажеш не бива од ова ништо, дајте одпочеток да го почнеме... вистинската работа е да се снајдеш во тој калабалак.... Според мене, еден од условите за да некој стане сениор програмер, е да се снајде во таков некој код и генерално во таква некоја ситуација. Што ми вредиш ти како сениор, ако јас неможам да те искористам во некоја таква ситуација (во која што и си), која реално ми носи клиент, со кој би можел да ја зголемам соработката??? Што да пишам во твоите способности, кога те продавам ?? „Овој е програмер е многу добар али само кога почиња од почеток“ ???

Затоа мене не ми е многу важно дали програмерот ги знае дизајн патерните, и некои банални работи попут тернари оператор.. Мене ми е битно како девелоперот се справува со стрес и каков пристап има до проблемите... Многу повеќе ќе ми заврши јуниор, кој под стрес се осеќа како дома и има добар аналитички пристап, одколку филозоф, кој ќе ми кажува колку е срање проектот на којшто работам, како јас да сум малоумен и да не го гледам тоа...

 

[zmej gorjanin]

Верувај, со истата мисла тргнале девелоперите во 2005... важно ми е да знам што бара клиентот. Ама од 2005 до денеска, се измениле можда буквално сите вработени во таа фирма, а во зависност од браншата и по неколку пати се направила ротација... Истото се десило и во компанијата која го развивала софтверот.. во меѓувреме, се смениле барањата, се размрдале приоритетите и дошле некои нови неочекувани моменти и све тоа било правено од девелопери попут тебе кои можеби врска немале која е големата слика на проектот, ниту пак знаеле кои се почетните барања... и све завршило како што завршило...

Доколку не се воспостават правила на игра и доколку тие правила стриктно не се следат и контролираат... па макар тие биле и сосема погрешни, долготраен успешен проект нема да може да опстои сам по себе...

Замисли си штои бил SugarCRM во 2005 кои техники на развој користел и каква била визијата тогаш, со тоа што е денеска визијата и какви се денешните очекувања... Тоа што порака ти дава??? Незнам за тебе, ама мене ми дава порака дека продуктите во IT секторот се доста краткотрајни, и без разлика колку да вложуваш во нивна скалабилност, на крајот секако ќе застарат...Некои функционалности како knowledge base или како некакви модули, можеш да искористиш... Но робустен продукт во целина... тешко.

Тие луѓе што инвестирале 15 години во тој развој на тој продукт, преминале којзнае какви све нервози и заебанции, инвестирале многу пари и очигледно се очајни да го доведат во ред... Не им е пријатен звукот кога слушаат дека треба сета таа инвестиција да ја фрлат во ѓубре, а особено не им е пријатен звукот кога слушаат дека не знаат што сакаат...

Многу е лесно за тебе да кажеш не бива од ова ништо, дајте одпочеток да го почнеме... вистинската работа е да се снајдеш во тој калабалак.... Според мене, еден од условите за да некој стане сениор програмер, е да се снајде во таков некој код и генерално во таква некоја ситуација. Што ми вредиш ти како сениор, ако јас неможам да те искористам во некоја таква ситуација (во која што и си), која реално ми носи клиент, со кој би можел да ја зголемам соработката??? Што да пишам во твоите способности, кога те продавам ?? „Овој е програмер е многу добар али само кога почиња од почеток“ ???

Затоа мене не ми е многу важно дали програмерот ги знае дизајн патерните, и некои банални работи попут тернари оператор.. Мене ми е битно како девелоперот се справува со стрес и каков пристап има до проблемите... Многу повеќе ќе ми заврши јуниор, кој под стрес се осеќа како дома и има добар аналитички пристап, одколку филозоф, кој ќе ми кажува колку е срање проектот на којшто работам, како јас да сум малоумен и да не го гледам тоа...

Sugar CRM не верувам да постоел тогаш, и да постоел бил во некоја демо верзија, веројатно подоцна го имаат усвоено. Проектот го датирам според античкиот код кој што на некои места е пишуван, веројатно уште пред php да стане објектно ориентиран јазик.

Тие луѓе што инвестирале толку време и пари самите побараа ново решение ради заебанциите и нервозите низ кои поминале/поминуваат. Проблемот настанува кога им поставуваш прашања за некои делови од апликацијата да речеме калкулација на цени или попусти за некои производи и не можеш да добиеш одговор, а ти викаат цената треба волку да изнесува. Викни си го аналитичниот џуниор да се справува у такви ситуации.

За да напишеш добар код не мора да почнеш од нула и можеш да го направиш во повеќе фази, иако на клиентите најчесто им е битно само да работи функционлноста и не сакаат да плаќаат за code refinement. Исто ко што не те лажам дека најчесто проекти кои стигаат кај нас у фирма се почнати, удриле во ѕид, девелоперите си киднале и ти ги носат тебе да ги оправаш, некогаш се оправаат, некогаш не. Друго, повеќе од пола од работниов век ко девелопер го поминав у фиксање багови и препишување на претходно избагиран код така да паметни мисли од тебе на таа тема не верувам дека ми фалат. Трето, почетната фаза и сетирањето на проектот е една од покомплексните фази каде лесно можеш да тргнеш во погрешна насока така да не знам што мислеше со тоа овој знае само од почеток да работи.

И за крај ти се побиваш себе си кога од една страна викаш да се постават правила на игра, значи да се биде конзистентен, и од друга страна викаш мене не ми е битно девелоперот да ги знае правилата на игра, битно е само да се снаоѓа кога баговите и итните реквести ќе се појават, иако непочитување на правилата на игра и баговите се во тесна корелација.

 

[jamajka]

Sugar CRM не верувам да постоел тогаш, и да постоел бил во некоја демо верзија, веројатно подоцна го имаат усвоено. Проектот го датирам според античкиот код кој што на некои места е пишуван, веројатно уште пред php да стане објектно ориентиран јазик.

Незнам кога е почнат SugarCRM, а не е ни важно... важно е дека методите, приоритетите и потребите драстично се смениле од тогаш...

Тие луѓе што инвестирале толку време и пари самите побараа ново решение ради заебанциите и нервозите низ кои поминале/поминуваат. Проблемот настанува кога им поставуваш прашања за некои делови од апликацијата да речеме калкулација на цени или попусти за некои производи и не можеш да добиеш одговор, а ти викаат цената треба волку да изнесува. Викни си го аналитичниот џуниор да се справува у такви ситуации.

Сигурно повеќе ќе ми помогне во позитивен брејнсторминг со некој јуниор, одколку патетични забелешки на некој арогантен сениор, кој ќе ми објаснува како не треба да биде reverse engineering е решението... Све тоа е некако направено и има некакви правила, ако пробаш да видиш барем дел од тие правила, можеби ќе им помогнеш да воспостават бизнис логика. Ајде сега да парафразирам... Као на пример супер маркет да држи цена на некој производ, а да не знае како дошла таа цена... Што се случува побогу таму? Пресметките сигурно не се формули од квантна физика...

За да напишеш добар код не мора да почнеш од нула и можеш да го направиш во повеќе фази, иако на клиентите најчесто им е битно само да работи функционлноста и не сакаат да плаќаат за code refinement.

Најголемите факапи е што QA се однесува само на функциналноста, а не и на кодот. Немораш да почнеш од нула за да имаш добар код, но добар код е субјективна категорија.... за некој добар код е едно, за некој е друго... Е сега ти доаѓа проект, со добар код од тип А, но пошто ти не го сметаш тоа за добар код, правиш функционалност со добар код Б.... Иде трет девелопер и прави добар код Ц.... Замисли добиваме апликација со целосно добар код, меѓутоа кодот во разни модули не е конзистентен.

Под добар код се подразбира, определуваш правило А... И сите го следат тоа правило, тоа правило не смее да го кршиш, без разлика колку ти субјективно мислиш дека правилото А има недостатоци... тие недостатоци има начин како да ги пријавиш и да понудиш целосно решение на истите, што би значело целосен ретрограден рефакторинг на даденото правило....

Исто ко што не те лажам дека најчесто проекти кои стигаат кај нас у фирма се почнати, удриле во ѕид, девелоперите си киднале и ти ги носат тебе да ги оправаш, некогаш се оправаат, некогаш не. Друго, повеќе од пола од работниов век ко девелопер го поминав у фиксање багови и препишување на претходно избагиран код така да паметни мисли од тебе на таа тема не верувам дека ми фалат. Трето, почетната фаза и сетирањето на проектот е една од покомплексните фази каде лесно можеш да тргнеш во погрешна насока така да не знам што мислеше со тоа овој знае само од почеток да работи.

Не е само кај тебе у фирма, јас мислам дека тоа е случај во сите фирми.. така да скоро секој еден девелопер го поминал тој пат помалце или повеќе.. И тоа што го кажав „овој знае само почеток да работи“ беше баш во контекст дека претежно проектите со кои работат девелоперите се веќе почнати ... еве ај можеби претерувам, но мислам дека над 95% од луѓето во Македонија работат на проекти што ги почнале други луѓе ...

А иначе, почнување на еден сериозен софтвер е доста покомплексна работа од само да го сетираш проектот, освен ако не мислеше само на програмерскиот дел...

И за крај ти се побиваш себе си кога од една страна викаш да се постават правила на игра, значи да се биде конзистентен, и од друга страна викаш мене не ми е битно девелоперот да ги знае правилата на игра, битно е само да се снаоѓа кога баговите и итните реквести ќе се појават, иако непочитување на правилата на игра и баговите се во тесна корелација.

Пак ќе ти кажам, секој проект има свои правила на игра, тој што има секако... Значи прочитај убаво, мене не ми е битно девелоперот што го примам на работа, да ги знае општите правила на игра... туку ми е битно да ги следи правилата на игра, етаблирани во дадениот проект... Кои не ретко се сосема спротивни од општите.

Па така и во твојот случај(гледано од очите на клиентот), каква корист има на пример клиентот од тоа што ти ги знаеш патерните, кога не можеш reverse engineering да направиш на функционалноста за цените...

Но пак да не бидам погрешно разбран, патерните се добро помошно средство. Но зошто би морале да бидат во прашање за интевју??? Патерните се нешто што секој може да ги научи и да не ги знае... А работа под стрес не може секој да поднесе.. Добра аналитичка логика нема секој... Затоа викам Мене не ми е важно познавањето на патерните, претпотавувам дека ги знае, а и да не ги знае ќе ги научи, кога ќе му требаат. Што ќе му правам на некој програмер што ги знае патерните, а паѓа у несвест под стрес, и нема никакви аналитички способности???

И да те прашам, си се нашол некад во ситуација да форсираш патерн, без потреба...

 

[zmej gorjanin]

Незнам кога е почнат SugarCRM, а не е ни важно... важно е дека методите, приоритетите и потребите драстично се смениле од тогаш...


Сигурно повеќе ќе ми помогне во позитивен брејнсторминг со некој јуниор, одколку патетични забелешки на некој арогантен сениор, кој ќе ми објаснува како не треба да биде reverse engineering е решението... Све тоа е некако направено и има некакви правила, ако пробаш да видиш барем дел од тие правила, можеби ќе им помогнеш да воспостават бизнис логика. Ајде сега да парафразирам... Као на пример супер маркет да држи цена на некој производ, а да не знае како дошла таа цена... Што се случува побогу таму? Пресметките сигурно не се формули од квантна физика...


Најголемите факапи е што QA се однесува само на функциналноста, а не и на кодот. Немораш да почнеш од нула за да имаш добар код, но добар код е субјективна категорија.... за некој добар код е едно, за некој е друго... Е сега ти доаѓа проект, со добар код од тип А, но пошто ти не го сметаш тоа за добар код, правиш функционалност со добар код Б.... Иде трет девелопер и прави добар код Ц.... Замисли добиваме апликација со целосно добар код, меѓутоа кодот во разни модули не е конзистентен.

Под добар код се подразбира, определуваш правило А... И сите го следат тоа правило, тоа правило не смее да го кршиш, без разлика колку ти субјективно мислиш дека правилото А има недостатоци... тие недостатоци има начин како да ги пријавиш и да понудиш целосно решение на истите, што би значело целосен ретрограден рефакторинг на даденото правило....



Не е само кај тебе у фирма, јас мислам дека тоа е случај во сите фирми.. така да скоро секој еден девелопер го поминал тој пат помалце или повеќе.. И тоа што го кажав „овој знае само почеток да работи“ беше баш во контекст дека претежно проектите со кои работат девелоперите се веќе почнати ... еве ај можеби претерувам, но мислам дека над 95% од луѓето во Македонија работат на проекти што ги почнале други луѓе ...

А иначе, почнување на еден сериозен софтвер е доста покомплексна работа од само да го сетираш проектот, освен ако не мислеше само на програмерскиот дел...



Пак ќе ти кажам, секој проект има свои правила на игра, тој што има секако... Значи прочитај убаво, мене не ми е битно девелоперот што го примам на работа, да ги знае општите правила на игра... туку ми е битно да ги следи правилата на игра, етаблирани во дадениот проект... Кои не ретко се сосема спротивни од општите.

Па така и во твојот случај(гледано од очите на клиентот), каква корист има на пример клиентот од тоа што ти ги знаеш патерните, кога не можеш reverse engineering да направиш на функционалноста за цените...

Но пак да не бидам погрешно разбран, патерните се добро помошно средство. Но зошто би морале да бидат во прашање за интевју??? Патерните се нешто што секој може да ги научи и да не ги знае... А работа под стрес не може секој да поднесе.. Добра аналитичка логика нема секој... Затоа викам Мене не ми е важно познавањето на патерните, претпотавувам дека ги знае, а и да не ги знае ќе ги научи, кога ќе му требаат. Што ќе му правам на некој програмер што ги знае патерните, а паѓа у несвест под стрес, и нема никакви аналитички способности???

И да те прашам, си се нашол некад во ситуација да форсираш патерн, без потреба...

Тоа беше само еден упростен пример со цените а веројатно и си видел уплеткан код, ќе имплементираш нови калкулации и ќе ги смениш цените на милион други места каде не би требало да се сменат, цени за кои ти треба фидбек од еден куп sales people кои во моментов не се достапни.

Да напишеш подобар код подразбира и да не ти биде цел проект начукан во еден фајл по можност, кои правила во фајлови со по неколку илјади линии код? Ако структурирање на кодот на начин на кој што мене би ми било полесно да го одржувам понатаму е правење паметен не знам како очекуваш да те сфатам сериозно.

Клиентот може нема никаква корист и од рефакторирање но на мене ми се олеснува доста работата.

Ај наврати се на првата твоја реплика кога те прашав дали човек со 10 години искуство во девелопмент е нормално да те гледа чудно кога го прашуваш за концепти од OOP?

Постоеле ситуации кога ми било ќеиф и сум имал време да имплементирам, еве неодамна праев фајл аплоудер за аплоуд на фајлови на s3 и преку ftp па користев еден вид на фактори патерн иако веројатно побрзо ќе го направев да цепав процедурален код. Некогаш ме мрзи и се нема време па се оди quick and dirty, што не значи дека подоцна нема да го отворам пак и средам тој код.

Голем фан сум на репозитори патерн, особено кога работам со ларавел и има шанси проектот да порасне доста, а со тоа да порасне и бројот на квериња кои треба да се напишат. Вака имам 7 - 8 квериња во една репозитори класа кои ги повикувам низ сите контролери што значи осетно сум го намалил бројот на линии код.

 

[jamajka]

Тоа беше само еден упростен пример со цените а веројатно и си видел уплеткан код, ќе имплементираш нови калкулации и ќе ги смениш цените на милион други места каде не би требало да се сменат, цени за кои ти треба фидбек од еден куп sales people кои во моментов не се достапни.

Не мислев конкретно за додавање функционалност, туку за „незнаат што сакаат“. ОК, да речеме дека така грубо можеме да го опишеме фактот ... Муабетот ми е треба да им помогнеме да знаат. Да видите како е тоа имплементирано и полека со нив или со бизнис аналисти да дојдете до некаков заклучок за цените (или било што)... Ако ништо друго за новото решение, да знаат што сакаат нели. Но најчесто не е „незнаат што сакаат“ проблемот, туку знаењето е раштркано, со доста спротивставени страни и мислења, поготово кај ентерпрајс клиенти, таму има многу суета ... еве дури и да ја најдеш целосната функционалност можеби ќе се соочиш со коментари од типот „па тоа е тотално погрешно, не смее така“ ...

Но можеби гледам малку од повисоко на проблемот и затоа се разидуваме во некои мислења.

Да напишеш подобар код подразбира и да не ти биде цел проект начукан во еден фајл по можност, кои правила во фајлови со по неколку илјади линии код? Ако структурирање на кодот на начин на кој што мене би ми било полесно да го одржувам понатаму е правење паметен не знам како очекуваш да те сфатам сериозно.

Ако веќе е усран проектот, што и да напишеш тој останува да е усран, се додека не се направи целосен рефакторинг.. зборот ми беше нема да помогнеш да престане да биде усран проектот, ако постојано повторуваш дека е усран

Иначе мислев на ова, ако за еден проект има конвенција, за која ти сметаш дека не е добра и си ги тераш нештата по свое, за да тебе ти биде поедноставно оддржувањето.. Тоа е тотално погрешен пристап, од причина што ти на тој проект си пролазник... тој после тебе ќе се соочи со твојот код, ќе му стрчи, нема да е ист со останатиот ...

Клиентот може нема никаква корист и од рефакторирање но на мене ми се олеснува доста работата.

Рефактурирање на една апликација не се прави на добра воља, туку за тоа треба да се плати.
А ако мислеше на рефакторинг во развој за било каква оптимизација, тоа е нормална работа и дел од секој девелопмент. Некогаш не можеш да предвидиш или пак немаш време да ги направиш нештата како што треба, но тоа не значи дека, како што кажа, не се навратиш на тој код и го конципираш согласно принципите на твојата работа или конвецијата на проектот..

Ај наврати се на првата твоја реплика кога те прашав дали човек со 10 години искуство во девелопмент е нормално да те гледа чудно кога го прашуваш за концепти од OOP?

Незнам, не го поставувам јас тоа прашање, и да не ги знае патерните ќе ги научи кога ќе му затреба... Апсолутно не ми е важно, можда грешам, незнам ама тоа е мој став.

Постоеле ситуации кога ми било ќеиф и сум имал време да имплементирам, еве неодамна праев фајл аплоудер за аплоуд на фајлови на s3 и преку ftp па користев еден вид на фактори патерн иако веројатно побрзо ќе го направев да цепав процедурален код. Некогаш ме мрзи и се нема време па се оди quick and dirty, што не значи дека подоцна нема да го отворам пак и средам тој код.

Голем фан сум на репозитори патерн, особено кога работам со ларавел и има шанси проектот да порасне доста, а со тоа да порасне и бројот на квериња кои треба да се напишат. Вака имам 7 - 8 квериња во една репозитори класа кои ги повикувам низ сите контролери што значи осетно сум го намалил бројот на линии код.

Те прашав дали си имал моменти што ги викаат over engineering... пошто пази дизајн патерните не се начин на работа, туку се повеќе скици...

 

[Lester Freamon]

Во големи компании кои ви ја даваат работата се менуваат луѓе како чорапи, ако не во самата компанија тогаш меѓу сектори интерно. Пример еден го развивал/одржувал, друг продолжил, па трет и тн.. Најголем проблем во овие ситуации, а и во програмерските компании е недостаток на документација или и да ја има најчесто документацијата е некомплетна.
Каков и да е кодот, ако секој сегмент е објаснет детално, ќе му го најдете крајот. Лани ми падна една грдосија од софтвер, купена скоро 1м евра со 3 години поддршка од вендорот. Арно ама завршуваат тие 3 години и тие бараат еден куп пари за поддршка на годишно ниво и паѓа одлука да го одржуваме самите. Софтверот десктоп+веб, едновремено врзан со уште 7 други апликации, составен од 4 бази (2xrdbms на оракл, 1 sde esri, 1 ODBMS Mssql), кодот куцан во се можно ( html, css, javascript, php, c#, python) а се на се документација од 2 пдф документи едниот 70 страни за gui- то, другиот 60тина страни со опис на 10% од функционалностите и модулите. Фирмата што го продава го купила од Источна Европа како стартап софтвер од фирма која веќе не постои, па го прошириле и прилагодиле за нас. Во меѓувреме фирмава што го продава од 16 души вклучени на проектов сменила откако се завршил 14души,само 2ца еден сениор еден тогаш џуниор се останати, а на наша страна како купци сменети 70% од луѓето (и преговори и тие што биле вклучени во имплементација со другите системи). Ниту има човек за консултација, ниту да прашаш.
Што би правеле со ваков систем? Ми падна парето мене и уште на 2ца колеги да си ја чукаме главата, нема интерес ни за плаќање support на вендорот ни пак за одново друг софтвер, некој лапнал бонус дека направил нешто и ела сега оправи го. Засега е крпење, нешто што успеавме и прекуцавме од ново, ама се нема шанса, со години е развивам, а што е најтрагично на локален јазик оставале коментари полјаците.

 

[jamajka]

Во големи компании кои ви ја даваат работата се менуваат луѓе како чорапи, ако не во самата компанија тогаш меѓу сектори интерно. Пример еден го развивал/одржувал, друг продолжил, па трет и тн.. Најголем проблем во овие ситуации, а и во програмерските компании е недостаток на документација или и да ја има најчесто документацијата е некомплетна.
Каков и да е кодот, ако секој сегмент е објаснет детално, ќе му го најдете крајот. Лани ми падна една грдосија од софтвер, купена скоро 1м евра со 3 години поддршка од вендорот. Арно ама завршуваат тие 3 години и тие бараат еден куп пари за поддршка на годишно ниво и паѓа одлука да го одржуваме самите. Софтверот десктоп+веб, едновремено врзан со уште 7 други апликации, составен од 4 бази (2xrdbms на оракл, 1 sde esri, 1 ODBMS Mssql), кодот куцан во се можно ( html, css, javascript, php, c#, python) а се на се документација од 2 пдф документи едниот 70 страни за gui- то, другиот 60тина страни со опис на 10% од функционалностите и модулите. Фирмата што го продава го купила од Источна Европа како стартап софтвер од фирма која веќе не постои, па го прошириле и прилагодиле за нас. Во меѓувреме фирмава што го продава од 16 души вклучени на проектов сменила откако се завршил 14души,само 2ца еден сениор еден тогаш џуниор се останати, а на наша страна како купци сменети 70% од луѓето (и преговори и тие што биле вклучени во имплементација со другите системи). Ниту има човек за консултација, ниту да прашаш.
Што би правеле со ваков систем? Ми падна парето мене и уште на 2ца колеги да си ја чукаме главата, нема интерес ни за плаќање support на вендорот ни пак за одново друг софтвер, некој лапнал бонус дека направил нешто и ела сега оправи го. Засега е крпење, нешто што успеавме и прекуцавме од ново, ама се нема шанса, со години е развивам, а што е најтрагично на локален јазик оставале коментари полјаците.

Тоа е нешто слично како што го збореше претходниот колега.. А верувам вакви приказни има многу... што се однесува до имплементацијата, ако нема добра документиција, дури и да е имплементација добра па ќе се соочиме со потешкотии... Но мора да сме свесни, дека генезата на еден таков голем проект е доста комплексна за да може да остане со добра имплементација (добрата имплемтација кај големите проекти градени со години е повеќе исклучок).. Причините се како што кажав претходно разни, промена на кадрите, промена на технологиите, промена на приоритетите, неочекувани промени и така натаму...

Е сега што би правеле со таков систем... претпоставувам, пошто сте корисници на софтверот, не сте ИТ компанија и имате инхаус ИТ одел.. Тоа што би ми текнало сега на брзина е, да контактирате со некои од стариот кадар и од кај вас и од кај продавачите и да ги најмите како консултанти... Или да најдете друг вендор или искусни консултанти кои би се нафатиле да пробаат да го направат системот одржлив со ваша помош... Но пред се и во двете опции тоа од вас 3јца ќе значи да продолжите да си ја чукате главата уште долго време, пошто можеби најголемиот дел од работата ќе морате да ја направите вие. Јас тоа би го нарекол интересен предизвик

 

[zmej gorjanin]

Не мислев конкретно за додавање функционалност, туку за „незнаат што сакаат“. ОК, да речеме дека така грубо можеме да го опишеме фактот ... Муабетот ми е треба да им помогнеме да знаат. Да видите како е тоа имплементирано и полека со нив или со бизнис аналисти да дојдете до некаков заклучок за цените (или било што)... Ако ништо друго за новото решение, да знаат што сакаат нели. Но најчесто не е „незнаат што сакаат“ проблемот, туку знаењето е раштркано, со доста спротивставени страни и мислења, поготово кај ентерпрајс клиенти, таму има многу суета ... еве дури и да ја најдеш целосната функционалност можеби ќе се соочиш со коментари од типот „па тоа е тотално погрешно, не смее така“ ...

Но можеби гледам малку од повисоко на проблемот и затоа се разидуваме во некои мислења.


Ако веќе е усран проектот, што и да напишеш тој останува да е усран, се додека не се направи целосен рефакторинг.. зборот ми беше нема да помогнеш да престане да биде усран проектот, ако постојано повторуваш дека е усран

Иначе мислев на ова, ако за еден проект има конвенција, за која ти сметаш дека не е добра и си ги тераш нештата по свое, за да тебе ти биде поедноставно оддржувањето.. Тоа е тотално погрешен пристап, од причина што ти на тој проект си пролазник... тој после тебе ќе се соочи со твојот код, ќе му стрчи, нема да е ист со останатиот ...


Рефактурирање на една апликација не се прави на добра воља, туку за тоа треба да се плати.
А ако мислеше на рефакторинг во развој за било каква оптимизација, тоа е нормална работа и дел од секој девелопмент. Некогаш не можеш да предвидиш или пак немаш време да ги направиш нештата како што треба, но тоа не значи дека, како што кажа, не се навратиш на тој код и го конципираш согласно принципите на твојата работа или конвецијата на проектот..


Незнам, не го поставувам јас тоа прашање, и да не ги знае патерните ќе ги научи кога ќе му затреба... Апсолутно не ми е важно, можда грешам, незнам ама тоа е мој став.


Те прашав дали си имал моменти што ги викаат over engineering... пошто пази дизајн патерните не се начин на работа, туку се повеќе скици...

Ти мене ме заебаваш или што? Еве кажавме дека се работи за огромна апликација, во таа апликација имаш толку многу код кој можеби не се користи и само останува нафрлан по фајловите по функции, можеби некогаш се користел, некој не се замарал и го оставал така, а имаш илјадници фајлови, каде една функција повикува друга функција во друг фајл, работите одат во бескрај. Не е апликацијата за супермаркет каде можам да ја прашам продавачката за цени туку имаш стотици - илјадници sales people и resalers од кои треба да добијам фидбек а во контакт сум само со еден човек кој исто нема многу време да ти објаснува туку само да отвори тикет и набрзина да ти го објасни ишјуто на кое треба да се работи, исто ко што и ја не работам само на еден проект и имам неограничено време и трето не сум ја тој што треба да им кажува на што треба да се работи, тие отвараат ишјуа и за тоа што отвараат за тоа си плаќаат, односно ја за тоа репортирам време. Така да не ти останува ништо друго освен да си легнеш на брашното и да си продужиш со девелопмент ко што е до сега и да си пишуваш посебна логика за секое ново барање ако веќе не можеш да реискористиш веќе постоечки код, што е многу погрешен пристап и е одличен пример како кодот се претвора во чудовиште односно што се случува кога не поштуваш СОЛИД.

Да, можеби кога ќе ги собереш сите тие луѓе на едно место (што е невозможна работа пошто софтверот се користи во повеќе земји) и да седнете едно месец до два да се замарате и разглобувате што е што можеби и ќе успееш во тоа што ти го викаш, само тоа е нереална ситуација пошто не постои волја од нивна страна и ко што кажа и самиот секој проект си има свој end of life поради икс причини, да земеш да мигрираш толку голем а стар код сигурно ќе искршиш нешто и ќе направиш проблеми, плус што и на сервер ќе треба да инсталираш се од ново. Не дека не може да се направи, се е возможно ако клиентот е спремен да плати. Само во таков случај времето поминато во мигрирање на код е скоро исто со тоа да земеш да напишеш нова робустна апликација.

Пак тресеш глупости, нормално дека имаш конвенции и правила, секогаш кога работиш во некоја платформа, фрејмворк, цмс, црм имаш правила, во самата платформа се втемелени тие патерните за кои ти тврдиш дека се глупости и не мора да се знаат. Ја зборам за кодот кој е пишуван за компанијава и е ужасен.

Прашањето не било воопшто за патерни туку примена на интерфејси (иако интерфејси се абстракции кои се во самата срж на некои патерни и со тоа што ќе ја опишеш примената на интерфејсите веќе си објаснил еден патерн), што да очекуваш од човек кој не знае што е интерфејс?

Патерни се само фенси име за добро структуиран и модуларен код, не знам што мислиш дека правам барам усран код и викам аха еве тука патерн ќе искористам. Да, некогаш одам бај да бук ако видам дека ситуацијата ми дозволува, она што ја правам е гледам да напишам код кој ќе го изолирам во една посебна целина која се вика класа која ќе се грижи само за логиката според која сум и дал име. Гледам да направам separation of concerns and responsibilities пошто лично мене ми е многу полесно да работам така.

 

[jamajka]

Ти мене ме заебаваш или што? Еве кажавме дека се работи за огромна апликација, во таа апликација имаш толку многу код кој можеби не се користи и само останува нафрлан по фајловите по функции, можеби некогаш се користел, некој не се замарал и го оставал така, а имаш илјадници фајлови, каде една функција повикува друга функција во друг фајл, работите одат во бескрај. Не е апликацијата за супермаркет каде можам да ја прашам продавачката за цени туку имаш стотици - илјадници sales people и resalers од кои треба да добијам фидбек а во контакт сум само со еден човек кој исто нема многу време да ти објаснува туку само да отвори тикет и набрзина да ти го објасни ишјуто на кое треба да се работи, исто ко што и ја не работам само на еден проект и имам неограничено време и трето не сум ја тој што треба да им кажува на што треба да се работи, тие отвараат ишјуа и за тоа што отвараат за тоа си плаќаат, односно ја за тоа репортирам време. Така да не ти останува ништо друго освен да си легнеш на брашното и да си продужиш со девелопмент ко што е до сега и да си пишуваш посебна логика за секое ново барање ако веќе не можеш да реискористиш веќе постоечки код, што е многу погрешен пристап и е одличен пример како кодот се претвора во чудовиште односно што се случува кога не поштуваш СОЛИД.

Значи ова не е различно од тоа што го кажав, усран код ќе остане усран, па ти каква сакаш додатна имплементација напрај му...

Да, можеби кога ќе ги собереш сите тие луѓе на едно место (што е невозможна работа пошто софтверот се користи во повеќе земји) и да седнете едно месец до два да се замарате и разглобувате што е што можеби и ќе успееш во тоа што ти го викаш, само тоа е нереална ситуација пошто не постои волја од нивна страна и ко што кажа и самиот секој проект си има свој end of life поради икс причини, да земеш да мигрираш толку голем а стар код сигурно ќе искршиш нешто и ќе направиш проблеми, плус што и на сервер ќе треба да инсталираш се од ново. Не дека не може да се направи, се е возможно ако клиентот е спремен да плати. Само во таков случај времето поминато во мигрирање на код е скоро исто со тоа да земеш да напишеш нова робустна апликација.

И ова не го кажав поинаку, имплементацијата на нова апликација, доколку корисниците не се сигурни за бизнис правилата, ќе ја доведе старата апликација како база на дел од бизнис логиката. Па така во во некои случаи, можеби ќе треба да се прави reverse engineering. ти додека почнеш со девелопмент ќе помине можеби повеќе од година, за да добиеш добар UR... а прашање е дали и тогаш ќе го добиеш.. и најинтересниот дел е како тој UR ќе почне да мутира, како што ќе почне имплементацијата...

Пак тресеш глупости, нормално дека имаш конвенции и правила, секогаш кога работиш во некоја платформа, фрејмворк, цмс, црм имаш правила, во самата платформа се втемелени тие патерните за кои ти тврдиш дека се глупости и не мора да се знаат. Ја зборам за кодот кој е пишуван за компанијава и е ужасен.

Не реков дека патерните се глупости, ти изгледа си читаш како што сакаш... реков дека е глупости да се поставуваат прашања на интервју за патерни... јас на интервју не поставувам прашања, за нешто што секој може да го научи... Јас сакам на интервјуто да го запознам капацитетот на човекот, неговите аналитички способности и неговата способност да го поднесе стресот....

 

[Ron Burgundy]

Вака ко поискусни, може да ми објасни некој кои се задачите на јуниор, мид и сениор?

 

[jamajka]

Вака ко поискусни, може да ми објасни некој кои се задачите на јуниор, мид и сениор?

Зависи каде, ако работиш за мене ќе ми бидеш чирак, ќе те тепам по глава и ќе ти се праам паметен...

Автоматски споено мислење: 13 јануари 2020

Зависи од фирма до фирма.. а зависи и од човекот кој ти е директно претпоставен, зависи од тимов во којшто си...
Ако имаш среќа да не се паднеш во токсичен тим, времето ќе го поминеш среќен и мотивиран. Ако имаш добар лид и добри колеги, секогаш ќе се насочуваат правилно... На крајот на краиштата не е ни толку важна титулата што ја имаш, важно е да си задоволен од платата и од колегите и да те исполнува работата ... тоа е тоа што ти дава мотивација.. а со тоа ти носи и напредок.

 

[Lester Freamon]

Ти мене ме заебаваш или што? Еве кажавме дека се работи за огромна апликација, во таа апликација имаш толку многу код кој можеби не се користи и само останува нафрлан по фајловите по функции, можеби некогаш се користел, некој не се замарал и го оставал така, а имаш илјадници фајлови, каде една функција повикува друга функција во друг фајл, работите одат во бескрај. Не е апликацијата за супермаркет каде можам да ја прашам продавачката за цени туку имаш стотици - илјадници sales people и resalers од кои треба да добијам фидбек а во контакт сум само со еден човек кој исто нема многу време да ти објаснува туку само да отвори тикет и набрзина да ти го објасни ишјуто на кое треба да се работи, исто ко што и ја не работам само на еден проект и имам неограничено време и трето не сум ја тој што треба да им кажува на што треба да се работи, тие отвараат ишјуа и за тоа што отвараат за тоа си плаќаат, односно ја за тоа репортирам време. Така да не ти останува ништо друго освен да си легнеш на брашното и да си продужиш со девелопмент ко што е до сега и да си пишуваш посебна логика за секое ново барање ако веќе не можеш да реискористиш веќе постоечки код, што е многу погрешен пристап и е одличен пример како кодот се претвора во чудовиште односно што се случува кога не поштуваш СОЛИД.

Да, можеби кога ќе ги собереш сите тие луѓе на едно место (што е невозможна работа пошто софтверот се користи во повеќе земји) и да седнете едно месец до два да се замарате и разглобувате што е што можеби и ќе успееш во тоа што ти го викаш, само тоа е нереална ситуација пошто не постои волја од нивна страна и ко што кажа и самиот секој проект си има свој end of life поради икс причини, да земеш да мигрираш толку голем а стар код сигурно ќе искршиш нешто и ќе направиш проблеми, плус што и на сервер ќе треба да инсталираш се од ново. Не дека не може да се направи, се е возможно ако клиентот е спремен да плати. Само во таков случај времето поминато во мигрирање на код е скоро исто со тоа да земеш да напишеш нова робустна апликација.

Пак тресеш глупости, нормално дека имаш конвенции и правила, секогаш кога работиш во некоја платформа, фрејмворк, цмс, црм имаш правила, во самата платформа се втемелени тие патерните за кои ти тврдиш дека се глупости и не мора да се знаат. Ја зборам за кодот кој е пишуван за компанијава и е ужасен.

Прашањето не било воопшто за патерни туку примена на интерфејси (иако интерфејси се абстракции кои се во самата срж на некои патерни и со тоа што ќе ја опишеш примената на интерфејсите веќе си објаснил еден патерн), што да очекуваш од човек кој не знае што е интерфејс?

Патерни се само фенси име за добро структуиран и модуларен код, не знам што мислиш дека правам барам усран код и викам аха еве тука патерн ќе искористам. Да, некогаш одам бај да бук ако видам дека ситуацијата ми дозволува, она што ја правам е гледам да напишам код кој ќе го изолирам во една посебна целина која се вика класа која ќе се грижи само за логиката според која сум и дал име. Гледам да направам separation of concerns and responsibilities пошто лично мене ми е многу полесно да работам така.

Проблем е што ретко кој може да ти ја долови големата слика дури и да почнеш од нов софтвер во големите компании.
Дури и да се најде некој паметен да ги собере сите сектори на едно место и да побара сите да ги напишат User Case-ovite, па проект менаџерот да направи еден филтер што се повторува и да направите добра архитектура, додека да го имплементирате барем 20% од тие луѓе што биле во проектот ќе се сменат со други и другите ќе имаат други побарувања. Па иди моментот со притискање на роковите, се е за вчера и завчера, па ајде да се стигнат рокови и кодот ќе стане шпагети.
Па на имплементиран систем не ни можеш да чепкаш секогаш во жив систем, ноќни акции, па си заминал некој од тие што биле од почеток на проектот и се ќе стани бучкуруш.
Колку погломазен систем, толку потешко одржување, може е попаметно и да се подели на посебни модули од сам старт за да има помалку главоболки понатаму.

 

[Емкаа]

Јас последнава година работев на одржување стар код за телекомуникациска компанија.Истата ситуација како погоре наведеното, нема документација, кодот е стар, старите девелопери се сите заминати, и ти седи како теле и чуди се како е се поврзано.
Правиме муабет за огромен монолит. Правевме промена на еден релативно мал модул, но толку е се исплеткано, толку тесна зависност меѓу компонентите...правиш промена во една метода после 2 месеци ти стига баг од скроз трет систем. Домино ефект. Јас не можам да знам дали сите 100 девелопери кои што се смениле на проектот следеле било какви принципи на кодирање бидејќи јас сега сум во тим со 6 девелопери па сеуште не можеме да се договориме околу тоа што е чист код и што заслужува approve на PR, а што заслужува мавање шамарчиња. Се слагам со @jamajka околу делот дека за да функционира еден проект треба да има строго определени правила, од форматирање на код до следење некои принципи на пишување добар код.
Не се слагам со делот дека вистинската умешност на сениорите се познава во такви ситуации како погоре наведената, ниту па мислам дека одговорност на програмерот е да седне и да прави reverse engineering на толкав систем за да стигне до основните use cases. Ниту па сметам дека некој треба да се смета за размазен бидејќи во толкаво море на интересни проекти со нови технологии би одбил да работи на таков проект. Јас работев едно време во Tibco, кој не знае што е подобро за него. Јас сум Јава девелопер, во Tibco последно се куцало можда годината кога сум родена. Се најдов во таква ситуација да не можев да одбијам. Никогаш повеќе не би се нафатила да работам на таков проект. Толку бев исфрустрирана тие 6 месеци додека работев, ми се одмили и работата, и колегите, и професијата.

 

[jamajka]

Не се слагам со делот дека вистинската умешност на сениорите се познава во такви ситуации како погоре наведената, ниту па мислам дека одговорност на програмерот е да седне и да прави reverse engineering на толкав систем за да стигне до основните use cases. Ниту па сметам дека некој треба да се смета за размазен бидејќи во толкаво море на интересни проекти со нови технологии би одбил да работи на таков проект. Јас работев едно време во Tibco, кој не знае што е подобро за него. Јас сум Јава девелопер, во Tibco последно се куцало можда годината кога сум родена. Се најдов во таква ситуација да не можев да одбијам. Никогаш повеќе не би се нафатила да работам на таков проект. Толку бев исфрустрирана тие 6 месеци додека работев, ми се одмили и работата, и колегите, и професијата.

Нема тука што да се сложуваме или не, ниту пак да заклучуваме кој е во право, а кој не.... Факт е дека заостанати проекти постојат и дека треба некој нив да ги оддржува... Има луѓе на коишто им е предизвик да прават reverse engineering, а има и луѓе кои се поконфорни да учат фенси технологии и во конфорт си куцаат класички и во тоа го гледаат напредокот на кариерата. Мој впечаток е дека поголем дел од програмерите се со твоето гледиште... Све си има предности и маани.

Само имам забелешка околу одговорноста... Одговорноста на програмерот е да ја заврши дадената задача, па макар тоа било нешто што не му се допаѓа. Јас го разбирам моментот дека ти си во можност да бираш работа, но тоа не ти ги поместува одговорностите, туку само ти дава избор да не ги почитуваш...

Околу Tibco, тоа се серија на алатки, кои имаат позамашен број на клиенти на ентерпрајс проекти од широк спектар на индустрии насекаде во светот... Незнам точно што си правела на TIBCO и на кој точно производ, но премногу сериозни фирми се ослонуваат на неговите продукти за да речеш дека се срање.. Тоа ти е малтене исто ко да речеш оракл се срање...

 

[zmej gorjanin]

Нема тука што да се сложуваме или не, ниту пак да заклучуваме кој е во право, а кој не.... Факт е дека заостанати проекти постојат и дека треба некој нив да ги оддржува... Има луѓе на коишто им е предизвик да прават reverse engineering, а има и луѓе кои се поконфорни да учат фенси технологии и во конфорт си куцаат класички и во тоа го гледаат напредокот на кариерата. Мој впечаток е дека поголем дел од програмерите се со твоето гледиште... Све си има предности и маани.

Само имам забелешка околу одговорноста... Одговорноста на програмерот е да ја заврши дадената задача, па макар тоа било нешто што не му се допаѓа. Јас го разбирам моментот дека ти си во можност да бираш работа, но тоа не ти ги поместува одговорностите, туку само ти дава избор да не ги почитуваш...

Околу Tibco, тоа се серија на алатки, кои имаат позамашен број на клиенти на ентерпрајс проекти од широк спектар на индустрии насекаде во светот... Незнам точно што си правела на TIBCO и на кој точно производ, но премногу сериозни фирми се ослонуваат на неговите продукти за да речеш дека се срање.. Тоа ти е малтене исто ко да речеш оракл се срање...

Ти што не седнеш да го искуцаш туку бараш аналитични џуниор девелопери?