×Закрыть

Как быстро вы пишете код?

Вообщем столкнулся с такой проблемой — идет третья неделя нового проекта, а я все еще не могу въехать в том как оно все работает. Проект джава-веб.

Монго, постгрес, реакт и самописный веб-фреймоврк вместо спринга. Все написанно через интерфейсы, абстрактные фабрики и прочие долбанные паттерны. Система распределенная, сервера от амазона. Код плохо документирован, иногда вообще не документирован.

Беру я себе значит фичу, начинаю ее имплементить, и закапывась в 8 уровней модели данных, за трейсами и пошаговым выполнением проходят дни. Можна конечно спросить у арихитектора системы, и тогда он в течении 10 минут делает работу на которую я трачу день или хотябы подсказывает куда смотреть.

А как быстро получается писать код для незнакомой системы у вас?

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

Лучшие комментарии пропустить

неделю на одну строчку. 5 секунд на вторую

Чайка-менеджер прибежал и наорал что надо разбираться в коде? Подумай логически без эмоций — если нет документации, все самописное вместо спринга (опыт свой нельзя применять) такая скорость и будет, ты ж не хакер в фильме, который взламывает Пентагон за 5 минут. Спокойно делай свою работу и отстаивай код и сроки.

Вообще огромную часть времени приходится бороться с отвращением к задачам на таких проектах.

Конструктивный подход — проси QA показывать тебе все flow, записывай это на видео. Потом по флоу ты сможешь дебажить что-то и разбираться по частям == «сьесть слона по кусочкам». Но как правило всем пох на таких проектах, покопайся пока есть возможность и будь готов валить.

Как я писал — бывало на medium баг уходила неделя, а на фичу месяц. 80% времени занимали письма, созвоны и уточнения что таки надо сделать, потому что в JIRA написано: «сделай хорошо» , билды и т.д. А писать код реально 1-2 часа было из недели.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
А как быстро получается писать код для незнакомой системы у вас?

Ну если изолированный кусок, то и в первую неделю может повезти что-то продакшн-готовое выкатить, особенно багов косметических пофиксить. Но чтобы понимать взаимосвязи глубоко, то для себя я лично определил эмпирическим путем 3-6 месяцев на въезд в относительно сложную систему. Включая домен, бизнес, тестирование и операционную деятельность. Ну и всегда можно найти нехоженые углы где снова будет все вновь.

Можна конечно спросить у арихитектора системы, и тогда он в течении 10 минут делает работу на которую я трачу день или хотябы подсказывает куда смотреть.

 не только можно, но и нужно. Особенно хорошо второе, чтобы подсказывал куда смотреть. Собственно этого от тебя на данном этапе и ожидают.

5 сантиметров в секунду.

Да вы же ж батенька плагиатор!

У природы? Это скорость падения лепестков сакуры :)

100 ифов за 60 форов.

Выдайте ему монады вместо зарплаты.

Чтобы все монадой накрылось? %)

Значит проект мёртв с эстимейтом 2-3 года. Почему так: Если даже при наличии архитектора системы ты не можешь у него спросить всё что нужно для кодинга — значит когда [гениальный] «архитектор» завершит работу над проектом, там уже больше хер кто разберётся.

Проблема 100% в архитектуре. Абстрактные классы нужно применять ТОЛЬКО если он представляет собой конкретный шаблон человеческого языка, то что можно понять. Интерфейсы аналогично. Фабрики классов? Да их пользуют исключительно в системных целях, то есть при написании библиотек. В абсолютном большинстве других случаев тебе не нужен класс как продукт, а потому и фабрика классов не нужна — ты вполне довольствуешься интерфейсами.

Я знаю только один способ решить проблему: начинаю безжалостно комментить все переходы, и все гипотезы которые возникают при чтении кода. Это позволяет в большинстве случаев определить, когда ты по лабиринту добираешься в ту же точку, начинаешь ходить кругами.

Бывали случаи, когда логика настолько м-даческая, к тому же неправильно написанная и через задницу работающая (разумеется не так как задумано, а задуманное «забыли» написать в ТЗ). Отдельное спасибо было когда в подобном коде архытегтор решил что код сверхценный и его украдут, и решил писать нинзя-кодингом с переменными типа wf_cckz. Когда код попал ко мне, этот кадр уже свалил в другую компанию. С матюками пришлось переписать всё с нуля — включая с нуля согласование тех.задания — это была реально ключевая логика проекта.

Если даже при наличии архитектора системы ты не можешь у него спросить всё что нужно для кодинга — значит когда [гениальный] «архитектор» завершит работу над проектом, там уже больше хер кто разберётся.

Вообще-то не совсем так потому как если «при наличии архитектора» кому-то таки приходится _спрашивать_ «всё что нужно для кодинга» это значит что никакой «архитектуры» и соотв. «архитектора» и нет сколь бы «должность» ни была «оплачена».

На ДОУ уже есть отличные статьи с примерами таких.

Конечно при этом возможен ещё и вариант когда архитектура таки есть и архитектор таки есть но «разрыв коммуникации» состоит в том что рассчитаны они на людей понимающих а набраны ресурсы джуны всякие и прочия (включая «джуны многолетнего опыта на поговорить» ага ага) чисто технически этот вариант конечно можно считать «недоработкой архитектора» но здесь скорее уже «насяльника и процессы агиле» в которых в «массовых реализациях» никаких «артефактов» не предусмотрено а только «ты можешь у него спросить всё» и соотв. никто пользоваться таковыми таки не умеет (да и желанием не горит от слова никак).

Сколько бы ни вышло сверхновых фреймворков в любой стадии загнивания, львиная доля кода никогда не может быть выучена. Кроме того, код чаще всего НЕ ЛОГИЧЕН, независимо от того насколько верит в его логичность автор.

Код — творчество человека. Как он написан, такой он и есть. Потому, будет ли код читаться — зависит в первую очередь от автора.

Человека, который пишет непонятный код — нельзя делать архитектором. Противопоказано. Это убьёт проект, притом убьёт в поздней стадии, когда в него уже дояху денег вложено.

Собственно, если бы действия были логичными — код бы и не понадобился. Просто сложил компоненты в конструктор — и вуаля. Ну а всё что не вуаля, что надо настраивать и программировать — всё это непредсказуемо, и потому должно быть ДОКУМЕНТИРОВАНО.

Понять по коду можно только участки кода.
Понять замысел автора, модель данных, бизнес-процессы и алгоритмы — можно только по документации. По коду зачастую тоже можно, но никакой гарантии что правильно, и на это уходят месяцы. В зрелом процессе ДО НАПИСАНИЯ этой документации даже к основному коду не приступают, пишут только асбстракции, иногда тесты (в случае TDD). Да, документация переписывается в процессе, на всех этапах. Но ещё до набора основной команды она должна быть. Чтобы сразу знать ЧЕГО ХОТЕЛ ПОЛЬЗОВАТЕЛЬ.

Иногда важнее словить проект и быстро показать пилотник, а потом — сделать из него релиз. Иначе не будет денег. И тогда документация точно не пригодится.
Водопад хорош, но тогда, когда заказчик тебе доверяет на 95%.

«Иногда» — это если не будешь его доделывать.
Я не говорю о классическом водопаде. Документация меняется вместе с проектом. Но сам факт что первично документирование, а не исполнение.

Риски уже объяснил: не бывает так, чтобы все друг друга понимали, особенно в мелочах. И те стыки, где происходит непонимание — должны быть очевидны. В данном случае имеем вместо стыка, разрешимого противоречие — размазанную большую проблему, которую никто решить не может, соответственно попытка решить даже частично — вызывает раздражение, вплоть до наказания, вплоть до увольнения.

Документацию нужно писать не прихоти ради. Но чтобы снизить издержки рабочего времени. Особенно при внедрении! Огромное количество неудач при внедрении связано только с тем, что не сделали документации в начале проекта, зато вложились в кучу фич, которые по итогу не связываются в один полезный сервис.

Мені помагало спочатку дні за три перечитати код, щоб зрозуміти, як куски між собою клеються.

Корисні для цього приблуди типу Understand for <мова> від SciTools

А скрины есть? (можно сделать?) Или 1-2 минуты видосик. Чета оно платное + рег для скачки — отбивает желание смотреть, когда вообщем, чуть ли не каждое ИДЕ строит всякие графы.

Я користувався траялами, вони на 30 днів були чи щось таке.

Це єдина тулза, яка втягнула була наш проект, і не впала (С++, 2003-й рік)

Глянув — там можна без реєстрації по лінку
scitools.com/download/all-builds
P.S.
Воно дивне трохи: беру java проект, імпортую, кажу побудувати UML діаграму по проекту. Воно будує, але... разом зі всією ієрархією класів стандартних бібліотек Java — отримую гігантську структуру, нафіг нікому не потрібну. Хз, як це настроїти/відключити.

Продукт розробляється з 1986-го року, дивно було б, якби він не був дивним. В ньому є певний шарм, притаманний софту, перенесеного з юнікса. Знову ж таки, з нашим проектом справився тільки він, і проаналізувати структуру було легко. Всі нові загиналися — які на макросах, які на оголошеннях типів. Не пам’ятаю, чи воно втягнуло STL. Якщо і так, то це не дуже заважало.

Для джави можливо є щось своє спеціалізоване. Understand, як з розумію, починався з Ади.

У нас на радиотелефонах на всю стенку висела диаграмма вызовов функций мелким шрифтом. Видимо, тоже кто-то запустил анализатор, а потом жаль было выкидывать.

Как быстро вы пишете код?

80 знаков вминуту, якщо читать,
в слiпу 120, но куйня получаеться

Ну типа несколько советов.
-Если много новых технологий + большая архитектура 3 недели эт немнога вооще
-Не стесняться начинать с заданий по проще, типа починки каких тупых багов, или че. Даже если сырная корона на голове. Тут конечно как с тимлидом\напряженкой повезет.
Баг должен быть прощупываемый — вы должны запустить локально или на каком тест окружении проект и четко знать и видеть какую кнопку нужно нажать чтобы получить багу. А после изменений в коде самостоятельно видеть починилась бага или нет.
-Не стесняться спрашивать более опытных товарищей включая архитектора на проекте о том что и как делать. Если попался чел с сырной короной, который в течении 10 минут делает работу и шлет вас лесом, спрашивайте когото следующего. В нормальных тимах обчно найдеться чел готовый порасказывать. Если такого чела нет, то эт не ваша проблема на самом деле, а менеджмента.
-Формальный код ревью оч рулит на самом деле для этого.

о, я думала я одна такая. У нас код написан очень хорошо + микросервисы, которые реально микро (не нужно тонны перекапывать чтобы понять что куда). Затыкаюсь обычно потому что задачи очень абстрактные, типа «автоматизировать вон тот кусок» и технологии все новые. Из последнего — полтора месяца убила на ресерч и понимание с какого ж боку вообще к задаче подойти, пока архитект не сжалился и не ткнул носом откуда начать. У нас на работе только один чувак мегапродуктивен, но у меня ощущение что он и спит с компом в обнимку + он это все стартовал. Остальные могут ковырять одну фичу (ту, которую я оценила бы в 2 недели хаха) месяца полтора — при том что чуваки очень скиловые и на работе реально работают.

такая же фигня, самый сильный чувак — тот который все стартовал

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

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

Ещё не сталкивался с ситуацией, когда кого-то нанимают рефакторинг делать

Ещё не сталкивался с ситуацией, когда кого-то нанимают рефакторинг делать.

июнь?
станеш синйором — найматимуть

p.s.
не давно даже на доу писали, за що увольняють кейс: чувак создав апликуху, потом набрали команду ii розширять, а он неужився з тiмом -> на мороз

с каких это пор сеньоров с колхоза начали набирать? читая ваш текст можно мозг сломать.

июнь?
станеш синйором — найматимуть

не июнь... просто не видел ни одного заказчика, которого бы волновал код, всегда только новые фичи

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

волновал код, всегда только новые фичи

код не волновав, волновала крива архiтектура, так як фычи нэ лызли

пля, разве сейнор для того, щоб тупо кодить?

пля, разве сейнор для того, щоб тупо кодить?

синьор это уровень квалификации, а не профессия, так что ответ скорее да, чем нет

сам то я не знаю, но по ходу во многих украинских компаниях этот тайтл дают тем кто будет бить в барабан и задавать темп с которым гребут гребцы)))

неправильно думаешь, 2 случая пришел с улицы и дожил до синьора с мидла в одной фирме, когда пришел с улицы, то кроме часового собеседования и резюме другой инфы нет, дали офер все — синьор, а темп и барабан это как повезет; выростание с мидла в синьоры в одной компании это обычно вместо повышения зп или вот Вася давно работает и таски вроде делает — он синьор! и в этом случае барабан с темпом тоже могут не участвовать, просто тогда больше шансов, что переход затянут

так то жизнь нельзя уместить в два случая )

а как тогда еще можно стать синьором?) в мексике родиться?)

если серезно, то для меня синьер это ряд и совокупность факторов, и просто технической грамотности и знания технологий недостаточно.

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

в барабан бьют тимлиды. правда, зп у тимлида может быть как у синьора

а может и не быть, в обе стороны

И как же это кумарит мля, чуть шо наблоткался на паре фреемверков и давай — ксатомер ориентед, вижен, продукт, деливери, мы все одна большая команда, менторинг...тошнит уже

Это хитрожопые компании пытаются навесить лидские/pm-ские обязанность на сеньйора, не добавив ему зп за это. Бить в барабан — это прерогатива человека, наделенного властью — PM, у лида по сути нет реальной власти.

Таке іноді відбувається, коли клієнту продали 100500 фіч, пообіцявши їх за місяць, а виявляється, що їх можна написати за пів року мінімум.
От тоді, після факапа, з’являється час і гроші на рефакторинг. Але звісно, може й не з’явитися.

Нанимают, но вообще это паскудная работа, т.к. легко все сломать.

Дык рефакторить надо, а не переписывать, тогда шансы все сломать резко падают

Если стартовавший чувак вместо Spring-а делает что-то свое, проперти-файлы делает в XML-ках, логирование свое какое-то, все 23 GOF-паттерна в любой задаче и т.д., то он долбоеб просто, естественно с таким приложением практически невозможно разобраться

Это вы, мадам, не писали плагины под иклипс.
К примеру, нужно сделать чтобы по клику на линк открывался файл. Самая новая статья — 2004 года и там как открыть файл не написано, только вывести алерт. Других статей нет. Так что исходники читать приходится

Я обычно сразу стараюсь читать исходники, я один такой?

Да, один. Если есть статья где четко написано как сделать, лучше ее и прочесть. Исходники читают когда нет учебников

что может быть легче, чем написать плагин под систему, у которой есть открытые исходники и доступ к ним Оо

что может быть легче

написати плагін під систему, у якої добре спроектоване і задокументоване API для плагінів. Незалежно, відкрита вона чи закрита. А якщо API криве і без документації, то заглянути в код не завжди допоможе — ви ж не будете API переписувати.

А якщо API криве і без документації, то заглянути в код не завжди допоможе — ви ж не будете API переписувати.

Было такое «переписывали» правда потом оказалось что это паттерн такой есть даже «адаптер» называется.

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

я уже и забыл когда такие понтовые проекты были
самы тяжелый — месяцев 8 вьезжал в код и предметную область и схемы баз данных( там их было не мало ), пока более менее вышел на уровень средней гребли.
а вообще привыкай, кровавый энерпрайз заставит визжать тебя как сучку )))
pbs.twimg.com/...​media/CdM_TVLWIAEgZGY.jpg
то что на скрине далеко не предел )))

крайние случаи — начинаю рисовать архитектуру — потом можно и всей команде помочь — расшарив ее, но главное что самому станет ясно

на линуксе сидим, так бы я визио уже нарисовал модули с которыми работал

www.gliffy.com/uses/uml-software
не ? если че первой что попалось в поиске

на крайняк можна на бумаге

plantuml, bouml, calligra flow....

Для себе напрацював декілька підходів, в процесі яких вдається вникнути в суть:
1. Написати набір тестів, які максимально покрили б функціонал.
2. Написати новий модуль/елемент до системи.
3. Якщо дописувати нічого нового не треба/не можна, а людини/документації які б підказали що і як нема, тоді тільки дебагати, дивитись що за чим викликається і т.д.

и закапывась в 8 уровней модели данных, за трейсами и пошаговым выполнением проходят дни

Стандартна схема, в більшості так.

Можна конечно спросить у арихитектора системы, и тогда он в течении 10 минут делает работу

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

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

Краще питати колег, якщо пів-години не можеш чогось зрозуміти. Тоді робота буду швидко рухатись, і швидко сам навчатимешся.

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

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

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

У java-проектах середовище розробки полегшує розбирання в коді. А уяви собі, що було б, якби це був код на Scala, де, наприклад, «Find Usages» в IntelliJ IDEA нічого корисного не знаходить, якщо використовуються @typeclass-анотоції. ;)

Я сегодня только удОлял.

У меня на ДОУ 13,105 commits / 150,087 ++ / 313,274 --.

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

Благодаря этому перестало работать листание новых комментариев на айпаде.

Многократное нажатие на число новых комментариев (42) ведет только на первый новый комментарий, и не перелистывает дальше.

preview.ibb.co/iS9YU5/IMG_3790.jpg

Странно, только что проверил в Chrome и Safari — работает.

До речі, коли вибираю «Еще N комментариев» у стандартному браузері Android 4.0.4, перекидає на початок сторінки, але коментарі не розкриваються. JavaScript дозволений. Колись коментарі розкривалися.

Дивно, а в Chrome працює? Чи на тому Android 4.0.4 доступний стандартний браузер замість нього?

Поставив Chrome під Android — все працює. Але, якщо можливо, було б класно, якби ще і в стандартному браузері працювало.

Можливо, це глюк браузера, раз у всіх браузерах крім цього працює, чому не працює чи перестало працювати поки що складно зрозуміти, здається в Google Play немає стандартного браузера, а в мого Nexus 5 стандартний браузер це Chrome, ну і там не Android 4.0.4. Взагалі Android 4.0.4 — не дуже популярна зараз версія, на неї припадає всього 0.23% від усіх Android-відвідувань сайту.

Ну тоді ок, з цим глюком можна жити... Використовую трохи стару модель (Sony Ericsson Xperia Pro), бо не зміг серед сучасних знайти смартфона з апаратною клавіатурою, а набирати на екранній після років користування апаратною мені було незручно. Тому трохи мало внутрішньої пам’яті (не поставив Chrome) і стара версія Andoid (планую занести, щоб оновили).

А Firefox не ставили? Можливо, він буде краще Chrome працювати, раз мало пам’яті:
play.google.com/...​ls?id=org.mozilla.firefox

А, я зрозумів, Android browser мабуть не видаляється, а 2+ браузерів займають забагато місця :(

Може, і видаляється (я рутував телефон), але вбудованої пам’яті дійсно мало. Розмір Apk+Dex+Lib: для Chrome — 67.82 MB, Firefox — 46.81 MB, Browser — 3.07 MB. На додачу до всього, ні Chrome, ні Firefox не хочуть переноситися на карту пам’яті (програмою Link2SD).

Функціонал Browser-а для мене достатній (вкладки/закладки/пошук/...), за винятком бага з нерозгортанням коментарів.

У Firefox теж коментарі розгортаються.

Ну печатаю быстро-быстро. А вот думать перед этим что печатать могу долго.

— Сколько знаков в минуту вы печатаете?
— Около 2000, но..., знаете — ТАКАЯ ФИГНЯ ПОЛУЧАЕТСЯ!

Из последнего 7500 строк юнит тестов для блек-бокс системы за 5 дней на питоне (язык учил на ходу)

Чайка-менеджер прибежал и наорал что надо разбираться в коде? Подумай логически без эмоций — если нет документации, все самописное вместо спринга (опыт свой нельзя применять) такая скорость и будет, ты ж не хакер в фильме, который взламывает Пентагон за 5 минут. Спокойно делай свою работу и отстаивай код и сроки.

Вообще огромную часть времени приходится бороться с отвращением к задачам на таких проектах.

Конструктивный подход — проси QA показывать тебе все flow, записывай это на видео. Потом по флоу ты сможешь дебажить что-то и разбираться по частям == «сьесть слона по кусочкам». Но как правило всем пох на таких проектах, покопайся пока есть возможность и будь готов валить.

Как я писал — бывало на medium баг уходила неделя, а на фичу месяц. 80% времени занимали письма, созвоны и уточнения что таки надо сделать, потому что в JIRA написано: «сделай хорошо» , билды и т.д. А писать код реально 1-2 часа было из недели.

Как я писал — бывало на medium баг уходила неделя, а на фичу месяц. 80% времени занимали письма, созвоны и уточнения что таки надо сделать, потому что в JIRA написано: «сделай хорошо» , билды и т.д. А писать код реально 1-2 часа было из недели.

 ну так это и есть суровый мир кровавого ынтерпрайза)))

А потом еще твоя фича не попадает в релиз, потому что в итоге оказалась никому не нужна.

да и пофиг, сами идиоты, лишь бы не приходилось самому выпиливать коммиты своих фич из релизной ветки за день до релиза

и самописный веб-фреймоврк вместо спринга

А цель? Почему отказ от спринг мвц / джерси в пользу самописного?

Что бы писать за 10 минут то, что другие будут на нем же писать сутки )))

Из моего опыта — самописные спринги/хайбернейты — или проект очень древний (спринги всякие не были мейнстримом и не было доверия в опенсорс) — или всевозможные секьюрити ризоны.

Медленно. Потому и не пишу! )))))

Крайности:
1) Делали поддержку параллельных звонков (DECT CAT-iq 2) для 16-битной DSP системы. 2-3 недели рисовали sequence diagrams чтобы убедиться, что архитектура рабочая. Потом 3 недели ждали аппрува. Потом 2-3 недели кодили. В этих условиях получалось 1000 строк С за пол-дня. Но это С, и все уже было продумано и зарисовано в диаграммах, и модули «с нуля» писались.
2) Неделю трейсил хромиум, чтобы понять, почему в новой версии не работает режим рендеринга, задепрекейченный пару месяцев назад. Нашел 1 строчку кода, которой не хватало.

Потом 3 недели ждали аппрува. Потом 2-3 недели кодили.

Я в этом месте давно подставу задумал жуткую лютую карочи берём и пока 3 недели ждём апрува сидим и кодим соотв. апрув пришёл а у нас всё готово! профитЪ!

ЗЫ: что занимательно схема всегда 146% срабатывала технически и всегда 146% была непонимаема по сути и видимо по менталитету идеологически аутсорсерами отечественными обыкновенными «ну это же ж блокер» (к) (тм)

берём и пока 3 недели ждём апрува сидим и кодим соотв. апрув пришёл а у нас всё готово! профитЪ!

i отгребаем звiздюлей, за аматорску дiяльность без апрува

А ну ок. ))

Там другие задачи были в параллель. Это, типо, развитие одного проекта, но у каждого еще поддержка и доделка своего... Ну и кастомеру стремно было соглашаться перекраивать архитектуру своей системы, которая до этого жила спокойно 10+ лет наверное. Но другого никто ничего не предложил, а сиквенс диаграммы — все-таки доказательство работоспособности. Для чего их и рисовали.

Потом 3 недели ждали аппрува. Потом 2-3 недели кодили.

Точно, неделю кодишь, месяц ждешь аппрувов, и т.д. по этой схеме, потом прибегает чайка-менеджер и орет почему еще ничего не готово? О_о

Если системы написана с правильной реализацией паттернов от банды четырех, то быстро. Иначе — как повезет.

Иначе — как повезет.

Дык это же ж оно и есть «если _повезло_ написать систему с _правильной_ в конкретном случае реализацией паттернов...» и далее по тексту причина и следствие спутаны... ))

неделю на одну строчку. 5 секунд на вторую

— вот бл [вот каким оказывается было техзадание, которое мне сообщили уже после выполнения!]

интерфейсы, абстрактные фабрики и прочие долбанные паттерны

ну так это ж Java

java.lang.Object
extended by org.springframework.aop.framework.ProxyConfig
extended by org.springframework.aop.framework.AbstractSingletonProxyFactoryBean

В плюсах часто не лучше. За что их и любят.

Ну это же кишки спринга)

обычно день думаешь, а потом за пару сек пишешь 2 строчки.

600 знаков в минуту

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