Как се програмира в екип

е това не мога да схвана. Някой успял ли е да го реализира?
В нашия екип от 4 човека сядаме, решаваме разни неща ама накрая като се стигне до програмирането винаги задължително се налагат промени в дизайна, защото се оказва, че не е измислен както трябва. Как при това положение може да се програмира от няколко човека просто не знам.
То направо да се затриеш. Тия хора ако не са в една стая и заедно да работят не става да направиш някакъв дизайн и да си бегаш в къщи да си го имплементваш както на нас ни се налага, понеже сме студенти, а не работим заедно на пълен работен ден.
Според вас възможно ли е на всеки да се даде задача да напише определени методи и да си бега дома да си пише?

Ден след ден след ден след ден ПРЕОТКРИВАМЕ КОЛЕЛОТО. Тежко се живее нареден живот.

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

като неможе да се справите сами, просто се взима един дето да ви е лидер, малко микро-мениджмънт и задължително редовни код-ревюта - без код ревю да не се комитва нищо че да опазите репозиторито и така.

а вече ако онзи не го бива за лидер друга работа.

Че и при фрилансерите има екипи. А там е още по весело. Защото екипа може да включва хора на различни континенти.

Bеer? Mоre?
Плацебото

Играла ли си хоро?
Те това е работа в екип.
Правилното е най-добрия да води хорото, а след него да се наредят според това кой колко го умее.
Най-вързаните в краката обикновено се хващат най-отзад. Всеки гледа тези преди него - по-добрите как го правят.
Без такъв отпреде с бяла кърпа да води, хоро т.е. екип не може да стане.

луда ли си, няма такова нещо......... дори в големите фирми с десетки хиляди програмисти всеки работи за себе си

Много е просто. Ще ти дам пример с един бизнес проект с UI и БД.
1.Сядате и уточнявате какви са входните данни, необходими за решаване на задачата.
2. След като са ясни данните се проектира БД - таблици, индекси, ограничения(constraints), съхранени процедури, views и т.н
3. Чертаят се на хартия екранчетата на потребителския интерфейс и се обсъжда как е най-удобно и интуитивно за ппотребителя.
4. И тъй като обикновено зад интерфацето има много дърти уърк се проектират класовете които ще правят обработката на данните. Не е необходимо да се впускате в подробности - достатъчно е да се напишат имената на ф-иите на класовете и резултата който се връща. Класовете за работа с БД - CRUD, също могат да се отделят като отделна работа за свършване.
5. След като заданието е ясно, включително и екраните се прави помощната система - хелп файловете
6. Ако е уеб приложение, някой чете как се инсталира на уеб сървъра и какви доп. настройки ще се правят. Ако е десктоп - как се прави инсталатор - какви ДЛЛ файлове трябва да се включат, къде да се пише в регистъра или ини файлове и какво
7. Дебъг, як дебъг и тестване на входните данни и резултата. Избирате най-простия и заядлив от вас и го правите усерче на програмата.

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


... for a brief moment it seemed that rock 'n roll would inherit the earth.

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




NE SUTOR ULTRA CREPIDAM

направо ме кефите как се втурвате да обяснявате на дамата

В грешка си. Обяснявам на себе си за да ми стане ясно. Ако някой добави нещо умно или се заяде, още по-добре. :)


... for a brief moment it seemed that rock 'n roll would inherit the earth.

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

ами ние точно така правим. Но има няколко проблема.
1. Основният е, че преди да почнем да имплементираме явно не успяваме съвсем да си изясним точно какъв е дизаинът на класовете и методите кво точно ще влиза и излиза. Много от нещата цъфват едва като почнеш да пишеш кода и се налага да се преправя. Ама понеже всеки си е в къщи и ако чакаш до следващата среща да обсъдиш с групата то се затриваш тотално.
2. Другият проблем е, че аз искам всичко да е едва ли не перфектно, нищо че ще бъде направено по труден начин. И хората хем харесват GUI то, което съм предложила, хем им се вижда прекалено сложно за реализация по точно този начин и на всичките бутончета и функции и издават багажа. Аз им казах всеки да си избере какво да прави, а аз ще направя останалото, защото искам в крайна сметка работещ и използваем проект, а не само да ида да отбия номера колко да мина на изпита. Те си избират кой кво ще прави, но явно им се вижда много сложно и никой нищо не прави и се помотват. А времето си върви и ако знам, че ще го направят ще ги чакам. Работата е, че не съм сигурна, че ще успеят и вече на предния проект така ме мота колегата от групата ми до последно и нищо не напраи та пак аз се стресирах накрая яко за да успея да го свърша съвсем сама. В нашата група командир няма да допълня. Сърдят се хората, че не искам да отбием номера с нещо елементарно, а се натискам да правя светно приложение. Но аз съм си такава, не искам да ходя да отбивам номера да ходя там да се излагам с посредсвена разработка и да съм на ръба да мина или не.
Така че и аз си представям нещата точно както ти си ги описал ама на практика излиза съвсем друго и затова мисля, че работа в екип на раб място може и да е възможна ама в нашето положение е неизбежно кодът да бъде написам от 1 или макс двама, а другите да правят вече останалите глупости (javadoc, организационни и бизнес простотии, Power point презентации, оформления и т.под. подробности)

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

1. Прави се работещо. А не идеално. После, на база какво искат юзърите се дооправя.
2. По малко цвъчки. Много цвъчки, означава че не знаете как да организирате.

Bеer? Mоre?
Плацебото

Където и да работиш, най-вероятно ще ти се налага да работиш с хора
работиш с хора от други континенти.

The last good thing written in C was Franz Schubert's Symphony No. 9.

Абсолютно вярно.

The last good thing written in C was Franz Schubert's Symphony No. 9.

Ники.


На твойта ситуация му се вика "направи-си-сам" положение.

Седваш за колкото там часа, колкото ти държи гъза, ама молим те, не 70 часа на седмица, това определено не е ефективно

Начи. Седаш, праиш си го от-до 4-5-6- и даже 7 пъти, колкото толкова, Иисус бил казал, 70 пъти по 7 и още ако требва


И така, заминаваш подготвена. По логиката на поФтурението, другите ще минат по твоите пътища, аку изопщу, защото господ не е дал много пътища, а ако е дал, е ти ще си хванала първите 77 пъти по 7 поне


И така, явяваш се, покрила първите 77 пъти по 7 и се молиш да не ти дадат 77777 милионния път по 77 ...


Тофа и само тофа е начина да бачкаш като дрийлансър.... нема други начини


Иначе, работа в екип, мола мола! ако има такава, аз ше си пусна телафона на запис

ПС: после връзваш конци дето требе, и ...се молиш да са същиа цвет...

Програмиране в екип е много лесно. Сетваш соурс контрол, всеки почва да чекира нещо като код. В началото се карате, понеже има 2-3-4 файла с код, кой го е ънчекнал, какво да се мърждне и ли не. После след няколко месеца кода става толкова много, че има стотици/хиляди файлове и вече всеки почва да си чекаута по нещо дето му скимне и няма нужда да си говорите особено много. Често дори не се засичате по офиса.

Всичко изглежда хаос и затова винаги се намира някой много умен, дето да мисли "правила". Но те реално правилата са си измислени - ако пишеш на С# - копираш правилата на Майкрософт дето са шеърнати на МСДН, ако е на Джава - на Сън, ако е на Релси - на ХайнеМайне правилата. Естествено винаги някой от Лом ще си мисли, че е по-добър от тях и ще иска "специфични за нашия процес промени". Ако си под 30 години се караш с него и спориш за нещата. Ако си над 30, женен, с деца - просто ги гледаш и ги игнорираш, ако оцелеят в професията и те ще се оправят.

Накрая се рилийзва/отива в QA. Има 5000 бъга и следващите 5 години си говорите през тикет системата за бъгове и пак не си говорите лично. Клиентите, QAs, шефчета почват да мрънкат и да "ескалират" в опит да се решат нещата и единственото дето може да обедени екипа е омразата към тия три типа хора. Само че дотогава има такова текучество, че реално няма вече нищо от оригиналния екип и пак нищо не става.

Това общо взето е професионалното писане на код в екип.

--
One day it will make sense.

О, и понеже всичко изглежда хаос (и е, но не е по-различно от хаоса навсякъде другаде), тук там се появяват гении с методологии, които спасяват процеса, като те се сменят на всеки 4-5 години - като спрат да се продават книгите и конференциите за "старите" неща.

Waterflow, Agile, Kanban (!?), Lean, Enterprise, Rational.

Общо взето "методологиите" се правят от същия тип хора, дето пишат книгите "How to become rich and successful in 5 easy steps".

--
One day it will make sense.

програмираш в екип - редовно трясваш тук поредната боза с косми и идва някой залупен да откосмява и отбозява