Пользователь
0,0
рейтинг
18 июля 2010 в 19:53

Разработка → Общие соображения по архитектуре ПО или Пособие для Главного Плотника (часть 3: проекты делают люди)

вторая часть здесь

Архитектура для живых людей



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


Тут можно было бы рассказывать бессчетное количество историй, например о том как лидер QA-команды на стороне заказчика был правоверным иудеем (при этом черным как гуталин, красноглазым ямайцем), и он принципиально не мог работать над тестированием пятничного релиза после обеда пятницы. В результате как ни странно сначала уволили тим-лида на стороне заказчика а уже потом релиз был перенесен на среду. Случай, конечно, скорее анекдотичный (но клянусь ни слова не придумал — чистая правда), чем поучительный, но мораль тут есть: процесс и технология должны учитывать личные особенности команды. А команда может быть очень странной.

Что бы вы ни придумывали, надо понимать, как устроен бизнес у заказчика и как устроена ваша команда. Повторюсь: примеров из реальной жизни тут можно привести массу, но негативные примеры приводить как-то неудобно, т. к. заказчик может узнать себя (случай выше в силу ряда обстоятельств, я считаю, привести можно), так что всем заинтересованным я готов рассказать несколько историй лично, за кружкой чая. А позитивные примеры не так поучительны :-).

Основное правило тут очень простое: «Всегда надо понимать, в чем бизнес заказчика, и делать так, чтобы ваш проект бизнесу шел на пользу. Богатеющий заказчик = добрый заказчик и легкий проект».

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

Несколько примеров и советов россыпью


Внимательно читайте требования, если непонятно, спрашивайте

Если заказчик говорит: «Сделайте мне один сводный отчет», – не надо делать ему 10 маленьких.

image

(с) не знаю чей

Еще раз! Читайте эти проклятые требования!!!

Физика процесса



Компьютер – это железка, в которой есть процессор, память, жесткий диск и сетевой интерфейс. Любая операция занимает какое-то время, надо всегда хотя бы приблизительно представлять себе, сколько именно времени занимает та или иная операция. При этом «быстро» – неправильный ответ, надо знать приблизительную цифру в миллисекундах. На эту тему я не смогу сказать лучше, чем Джефф Дин, инженер Гугл.

Jeff Dean, Numbers every engineer should know

* L1 cache reference 0.5 ns
* Branch mispredict 5 ns
* L2 cache reference 7 ns
* Mutex lock/unlock 100 ns
* Main memory reference 100 ns
* Compress 1K bytes with Zippy 10,000 ns
* Send 2K bytes over 1 Gbps network 20,000 ns
* Read 1 MB sequentially from memory 250,000 ns
* Round trip within same datacenter 500,000 ns
* Disk seek 10,000,000 ns
* Read 1 MB sequentially from network 10,000,000 ns
* Read 1 MB sequentially from disk 30,000,000 ns
* Send packet CA->Netherlands->CA 150,000,000 ns

Что важно, ЛЮБАЯ технология в конце концов сводится к процессору, памяти, диску и сети (я умалчиваю про более экзотически случаи, например, последовательный интерфейс RS-232). Если надо с диска прочитать 1 Мб, то какую технологию ни придумывай, это займет какое-то фиксированное время. Вроде бы банальное утверждение, но, увы, я не раз и не два сталкивался с коллегами, которые использовали технологии NNN и утверждали, что компания KKK придумала эту мегашутку, и там все очень хорошо, и читаться будет в 10 раз быстрее, чем это возможно физически, при этом не понимая, как же оно работает. Естественно, ничего не работало, ибо природу обмануть невозможно.

Вы обязаны понимать, как работает любая использованная вами технология, понимать физику процесса. Т.е вы должны всегда учитывать, что вызов метода abc() ведет к поиску по хэшу и изменению состояния объекта, а def() ведет к обращению к диску.

Байка (довольно грустная)

В одном проекте, не скажу, в каком, некий коллега отвечал за набор данных, связанных с некой областью, скажем, магазином (на самом деле, детали я изменил). Данные в силу того, что заказчик хотел мегагибкую и универсальную модель данных, были завязаны в довольно тугой клубок. Более того, по ходу дела требования довольно радикально менялись. В итоге коллега написал много Java-методов для получения всего подряд. Были методы вида:

* получить данные покупателя по id;
* получить список товаров по id отдела;
* получить получить список отделов;

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

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

Хотя, конечно, вариант с вызовами методов был значительно более расширяемый, простой и реализовывал очень простой и элегантный уровень абстракции. Но, увы, на реальных данных категорически не укладывался в разумное время.


Бойтесь химер



Есть много разных способов обустроить проект.

Можно использовать слой доступа к данным, можно не использовать, обращаться к базе данных через O/R mapping или идти напрямую и так далее. Вариантов много и в принципе, если помнить, что самый популярный движок для создания динамических сайтов – PHP, можно сказать, что, если вы сознательно выбрали Яву, то уже ваш проект в архитектурном плане уже на две головы выше, чем 80 % всех веб-приложений. (Внимание это была провокация :-) )

Но тут есть одна хитрость: если уже вы выбрали какой-то способ обустройства приложения, используйте его последовательно. Одна из самый больших ошибок, которую вы можете совершить, это сначала делать часть приложения одним способом, а потом часть – другим. В этом случае у вас получится химера – существо маложизнеспособное. Например, сначала использовать для доступа к данным plain JDBC, потом – iBatis, а потом – hibernate, при этом не переписывать старые куски кода, а добавлять новые. Если говорить предметно, то проблемы будут следующие:

1. Высокая стоимость сопровождения, мало кто будет способен понять, как оно работает.
2. С высокой вероятностью будут проблемы с производительностью.
3. Очень тяжело или почти невозможно будет добавить новую функциональность.

Приведу несколько примеров.

Пример № 1
2-звенное приложение для мониторинга некоторой коммуникационной аппаратуры. К счастью , не мой проект, знаю о нем из рассказов коллег. Делался более 5 лет многими поколениями программистов – адептов разных платформ, Дельфи и C++. Весь интерфейс пользователя на Дельфи а дальше – как повезет. Как-то все это собирается и заводится, но багов в приложении весьма прилично, в частности, багов, связанных с синхронизацией нитей. Коллега нашел следующий фрагмент: при клике на кнопку в Дельфи срабатывала некая логика, в результате вызывался метод, который через какое-то время уходил в процедуру на C++, там что-то делалось с последовательными портами, ставился callback на получение данных (тут как раз и был потоко-небезопасный код), и дальше вызывался уже код, написанный опять на Дельфи. Найти ошибку отладчиком было категорически невозможно. Помог только последовательный вдумчивый анализ кода в течение довольно длительного времени.

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


Пример № 2

Тут я должен признать: это мой личный самый первый опыт химероводства. Было довольно большое приложение, написанное кучей упорных программистов на стеке Java + Tomcat + JSP + JDBС. Т. е. это был Tomcat, там были JSP-страницы, из которых напрямую шли запросы в БД (ДА! SQL были прямо в коде скриптлета в JSP, там даже пароль к БД хранился прямо в JSP, причем в нескольких местах). Это был довольно большой монстр.

Мне выпал жребий через какое-то время после запуска в уже работавшем приложении прикрутить несколько страниц для администрирования некой подсистемы. Писать код так, как его писали до меня, я не мог чисто физически, честно пробовал, но на десятой минуте начинал биться головой о стену (вот еще мораль: если работа простая, но длинная, не поручайте ее старшим разработчикам, они все испортят и/или со всеми переругаются). На 11-й минуте я прикрутил к приложению Tapestry + Hibernate и довольно быстро и бодренько сделал все, что надо, раза в три быстрее, чем от меня ожидали.

Что тут плохого? Уже после меня люди, сопровождавшие приложение, попытались дописать пару пустяковых фичей. Поскольку об IoC и O/R mapping они даже не слышали, сделали как могли на чистом JDBC и нечеловечески прикрученных скриптлетах. В результате это был самый нестабильно работающий и самый медленный модуль в приложении, и, что особенно обидно, начал писать его я.


Если вы используете прямой JDBC для обращения к БД, достоинство в том, что все предельно просто, но есть и недостаток: много негибкого повторяющегося шаблонного кода. Если вы добавляете O/R mapping, то теряете простоту

В данном случае приложение сочетало недостатки обоих подходов.

Про книжную мудрость



Читайте книги и статьи умных людей в Интернете (тут уж вам решать, кто умный, а кто нет, как вы относитесь к Джоэлу Спольски? Кто-то его считает мегакрутым, кто-то – вредителем). В них много чего полезного.

Байка

Когда я учился в девятом классе, у меня был компьютер Радио-86РК. Я писал для него какую-то игру на языке Бейсик-Микроша. Хитрость была в том, что я был единственным программистом на планете Земля, которого я знал лично или хотя бы по переписке. Хуже того, Интернета тогда не было (точнее не было у меня). Книги какие-то, наверное, можно было купить, но где (на дворе 1989 г.) и какие?

Так вот, в игре (это была экономическая игра, писалась для себя самого на интерес) был момент, где надо было отсортировать список из 10 элементов. О существовании алгоритмов сортировки я принципе не подозревал. В результате родился монстр из пяти вложенных циклов, работавший для 10 элементов ощутимое время – несколько секунд (частота процессора была 800 кило герц).

К счастью, довольно скоро я встретил доброго человека, объяснившего на пальцах, как работает алгоритм сортировки пузырьком. Это перевернуло мой мир. Сортировка стала работать заметно меньше секунды.


Бог с ней, с сортировкой, но каждый раз, приступая к незнакомой задаче, я пытаюсь как-то выведать: вдруг ею уже кто-то занимался, и на эту тему написано 200 докторских диссертаций. При этом важно всегда про себя понимать, что «я не просто мучаюсь третий день с какой-то ерундой, потому что не колдуется», а «я не знаю, как сделать то-то и то-то», и надо открыть браузер и погуглить, как это делают в большом мире.

Совсем хорошо, если хитрое место идентифицируется и гуглится до подписания договора на стадии продажи.

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

К счастью, лично ошибок подобного рода я не совершал, а приводить в пример коллег поостерегусь, ибо узнают себя и побьют. Просто скажу: книжное знание без практики – мертвое знание. Книги читать крайней полезно, но всегда переосмысливайте то, что там написано. Не говоря уже о двух очевидных фактах

1. Автор книги может банально заблуждаться, не знать, о чем говорит, или опираться на старые факты/опыт. Если кто-то в книге убедительно рекламирует Struts MVC, может быть, просто книга 2001 года издания? Или автор с тех пор просто не изучил ничего нового. Я лично знал двоих людей написавших и издавших книги в издательстве Manning, оба они по профессиональному уровню тянули в лучше случае на мидлов.
2. Совершенно не факт, что написанное в книге применимо в вашем случае, даже если слова звучат похожие. Если вам надо покрыть карту страны разумно минимальным количеством прямоугольников в разумное время, то задача поиска максимального прямоугольника звучит очень похоже, но для вас, скорее всего, бесполезна.

Используйте голову



Есть такой анекдот: «Компанией АвтоВАЗ освоена уникальная западная технология – “сборка трезвым”». При разработке архитектуры такая уникальная технология – использование здравого смысла. Про каждое решение должен быть внятный ответ:

* почему здесь именно так;
* как можно было иначе, и почему я выбрал именно этот вариант.

Иначе говоря, всегда думайте, собственно разработка архитектуры занимает не так уж много времени по сравнению с длительностью проекта, так что каждое решение должно быть обдуманным. Про каждую закорючку вы должны быть готовы ответить, почему сделано именно так, и ответ не должен быть: «Да как-то так рефлекторно» или «А разве можно как-то еще?».

Есть безумно простое, но очень полезное упражнение: возьмите очень простую задачу часа на два кодирования. И сделайте ее так, чтобы про каждую строку кода, т. е. буквально каждую, в могли сказать, почему здесь написано именно так, какие еще варианты были, почему вы выбрали именно этот, и что было бы, если бы вы выбрали другой вариант. Упражнение очень утомительное, но очень полезное, т.к. сильно расширяет ваш горизонт.

Human engeneering



Увы, программы пишутся не сферическими seniour-разработчиками в вакууме, а вполне реальными людьми, довольно часто совсем зелеными. Людям свойственно ошибаться, и это не страшно, для этого есть команда QA, но людям присущи еще множество других пороков, и о них хочется сказать пару слов

Я пишу программу наугад



Один из типичных случаев, когда после чтения документации, консультаций с коллегами и т. п. джуниор все равно не понимает, как сделать тут или иную штуку. Бывает, что он начинает писать программу наугад. Часто после нагромождения множества строк кода оно начинает как-то работать, хотя бы на тестовом наборе данных. Например, я своими глазами видел примерно такой код:

update user_data set name= :newName where user_id = 1

Это был код для изменения имени пользователя. Он работал, но почему-то только для пользователя с id == 1. На тестовом наборе данных все было ОК. При этом в реальном коде (HQL выражение было чуть длиннее) единица была где-то в 120-й позиции экрана и простым просмотром кода не обнаруживалась, т. к. была за правой границей экрана.

Можно ли с этим бороться? В общем случае нельзя, но автоматической тестирование со случайными данными, совместное владение кодом и другие трюки такого рода повышают ваши шансы.

Повторное использование кода



Как ни странно? в ряде случаев, это – один из самых вредных и тяжело искореняемых антипаттернов. Да, код надо повторно использовать. Но всегда надо понимать, что ты используешь, и к чему это ведет. Если есть готовый метод «купить “Бентли”», не надо покупать новый “Бентли” каждый раз, как вам требуется вырезать кусочек кожи 5х5 см из сидения.

Иначе говоря, если есть метод, выбирающий из БД данные пользователя, то логично пользоваться именно им всегда, чтобы избежать ошибок. Но есть случаи, когда этого делать не следует.

int count = 0;
for (Item item : selectFromDBAllItems() ) //выбирает все 100.000 items
{
User user = getUserData(item.getOwnerId()); //выбирает данные из 5 таблиц в которых хранится информация о пользователе
if (user.getGender() == GENDER.MALE )
{
count++;
}
}



Скажем так: этот код работает совсем не быстро. Понятно, что тот, кто это писал, делал это не самым лучшим образом. Но хитрость тут в том, что использование таких библиотек, как Hiberante, например, сильно увеличивает разрушительный потенциал одного разработчика. Бороться с этим в общем виде бессмысленно, но надо всегда знать, как та или иная технология может быть использована во зло. И каков минимальный «порог вменяемости» для ее использования.

И последняя часть
Denis Tsyplakov @Semenych
карма
182,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (20)

  • НЛО прилетело и опубликовало эту надпись здесь
  • +4
    Очень хорошие статьи (4ю ещё не прочёл, но думаю там тоже всё хорошо) НО
    зачем так восхвалять джаву и ругать остальное?
    я понимаю что жава нравится, но это вредит тексту
    лично я читал текст перекладывая на свой опыт разработки на PHP и Си, встречались знакомые ситуации(тем более что всё описанное от языка никак не зависит), я тихо посмеивался и прихлёбывал чай и тут ОП, в 2х предложениях мне объясняют что PHP SUXX JAVA RULEZ

    ощущение что вдумчиво читаешь книгу про дорогу, о том как надо класть асфальт, ставить знаки и наносить разметку, а потом натыкаешься на главу «и вот мы покрасили потолок»

    я не к холивару JAVA vs PHP а к тому что я чаем подавился, нельзя так с читателем
    • +3
      Нашел, где написано. В общем-то писалось специально с целью провокации. Есть минус кто-то может принять все за 100% чистую монету и обидится.
      В общем подавиться чаем это была та реакция на которую я рассчитывал.
      А по поводу холивара — нет тут никакого холивара. Есть разные области применимости технологий. Каждая хороша для своей цели.
      У Явы есть своя ниша, есть ниша у PHP. Пересекаются они плохо. Так что важно понимать что и для чего надо использовать.
      • +1
        да ладно, вы раньше вылили порцию грязи на руби и рассказали столько гадостей про java, так что пэхапэшники довольны ;)
        насколько знаю, в мире java существует несколько уровней сертификации, как получается что к работе допускаются совсем уж необстреленные люди, результаты работы которых проверяются лишь тестами, а не code review?

        • 0
          И где там был наезд на Руби? Если автору лично не нравится Руби, это не значит, что резкое высказывание не было, опять-таки провокацией.

          Все языки важны в своих нишах. А пример неокрепшего опытом неофита- шаблонный, можно будет через лет 3-5 Руби заменить какой-то другой новомодной технологией или языком.
          • +1
            да я как бы и намекал, что автор не предвзят, не факт даже что ему «не» нравится руби. он прошёлся по всем описанным языкам, а его примеры легко переносятся на любой другой язык который есть или появится. в неправильных руках даже микроскоп становится ударным инструментом. проблема когда ты не знаешь с какой стороны браться за дело или пытаешься есть суп не тем столовым прибором.
  • 0
    Про «за чашкой чаю»: это был литературный оборот, или наоборот? )
    • 0
      оборот
  • 0
    При разработке архитектуры такая уникальная технология – использование здравого смысла. Про каждое решение должен быть внятный ответ:
    О, тут Вы немного переоцениваете людей вообще. В эзотерике описываемое Вами поведение называется «осознанность», и на это способны очень немногие. И большинство из способных не будут работать в фирме программистами — уйдут во фриланс или откроют свою фирму. Ибо осознанность, как правило, идёт вместе с принятием ответственности за себя, а одна из основных причин работы в фирме — потребность большинства людей переложить ответственность за себя на других (в данном случае — на фирму).
    • 0
      Ну немногие. Но стремиться то надо к этому.
    • 0
      Я бы не согласился. Насчет большинства.

      Бывает и потребность в интересной совместной непростой работе. За достойное вознаграждение. Вполне осознанная.

      Ну не напишете вы будучи ну хоть суперфрилансером правильный большой веб-портал в одиночку в зачастую требуемые сроки. Небольшой — напишете. Или большой, но за сроки, в полтора-два раза превышающие требуемые. Немалая часть знакомых, «осознавших» — вполне себе программисты и во фрилансеры или хозяев фирмы их как-то не тянет.

      А профессиональным коллективом все сделается во вменяемое время, ещё и будет перекрестный контроль, как некая гарантия от «замыленного глаза».

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

      Т.е. участвовать в жизни фирмы, подавать советы и даже, возможно, получить некий пост — вполне можно, но при этом менять своё призвание на то, чем, возможно, и не стоит заниматься (исходя из личных качеств/привычек) — увольте.
      • 0
        Я бы не согласился. Насчет большинства.
        Я не вижу смысла спорить — статистических данных по этому вопросу ни у Вас ни у меня нет, так что мы просто не можем знать, что, на самом деле, делает большинство. Я сужу по своим знакомым — практически все, кто хоть минимально занимался эзотерикой и развил осознанность — либо фрилансеры либо владельцы компаний.
        Бывает и потребность в интересной совместной непростой работе.
        Безусловно. Я хоть и фрилансер, но постоянно работаю совместно с другими фрилансерами (которых подключил к своему текущему проекту), в т.ч. активно практикую парное программирование.
        За достойное вознаграждение.… Ну не напишете вы будучи ну хоть суперфрилансером правильный большой веб-портал в одиночку в зачастую требуемые сроки.
        А вот что касается оплаты и сроков — с этим всё совсем не так очевидно. Деньги как мотиватор не работают в принципе — я физиологически уже давно не способен писать (необходимую заказчику или менеджеру) хуйню, ни за какие деньги. Это — моя жизнь, и растрачивать её на то, что лично мне кажется бессмысленной и неправильной деятельностью, даже за большие деньги, я не собираюсь.

        Что касается сроков — да, я зачастую работаю дольше, но и качество полученного результата получается намного выше. Моего заказчика это устраивает. А если Вашему важнее сроки — ищите другого заказчика, это фриланс, мир большой, заказчиков бесконечно много и всем нужно разное, Вы всегда можете найти таких заказчиков, с которыми Вам будет комфортно работать.

        Когда вы работаете в офисе, вы находитесь под постоянным давлением, вам пропагандируют идеи, важные для выживания и развития бизнеса владельца фирмы. Вам рассказывают, что настоящий «профессионал» ДОЛЖЕН то, это, пятое десятое — в т.ч. делать даже не интересную ему работу, писать то и так, как требует заказчик, укладываться в сроки и бюджет жертвуя в том числе качеством (кстати, зачастую даже не очень-то и нужным заказчику)… и почти все в результате начинают в это искренне верить. По сути это ничем не отличается от пропаганды через СМИ, которая практикуется всеми государствами: вам в голову пытаются вложить приоритет чужих (фирмы, государства) потребностей над вашими личными. Фриланс полностью решает эту проблему: я занимаюсь тем, чем хочу, и так, как хочу, и нахожу себе таких заказчиков, которым нужно именно то, что я делаю.
        Времени на разработку интересных вещей здесь просто может не остаться.
        Стопудово не останется. Это единственная причина, по которой я не стал делать свою фирму — мне нравится программировать, а владелец фирмы не сможет одновременно нормально развивать бизнес и продолжать активно писать код.

        У меня была года три назад возможность ещё раз убедиться, что делать свою фирму — это не моё: я примерно пол года поработал в роли зам.гендира в софтовой компании примерно на 200 чел, помогал товарищу (владельцу компании) справиться с кризисом. С работой-то я справился достаточно хорошо, но, как только кризис был преодолён, я моментально вернулся к фрилансу, хоть мне и предлагали работать дальше, и по деньгам это было выгоднее фриланса.
  • 0
    Сделайте, пожалуйста, байки в ваших статьях сделать шрифтом побольше ибо тяжело читать. Спасибо за статьи.
    • 0
      Ctrl-+ в браузере?)
      • 0
        т.е. по-Вашему (если утрировать) можно писать все мелким шрифтом ибо все можно увеличить средствами браузера?
        • 0
          Да ладно, не такой уж там аптекарский шрифт, чтобы перетрудиться, читая.
          А если зрение плохое, то лучше очками пользоваться или весь шрифт побольше сделать.

          (у меня плохое)
          • 0
            Клянусь, как будет время разобраться с редактором буду писать крупнее :-)
  • 0
    Продолжим нашу дискуссию (http://habrahabr.ru/blogs/development/90880/#comment_3075501), благо проявился новый интересный момент :)

    Вот вы говорите: «Писать код так, как его писали до меня, я не мог чисто физически, честно пробовал, но на десятой минуте начинал биться головой о стену...»;

    а потом: «На 11-й минуте я прикрутил к приложению Tapestry + Hibernate и довольно быстро и бодренько сделал все, что надо, раза в три быстрее, чем от меня ожидали.».

    А опять же это субъективная оценка. Возможно ли пристыдив свое желание писать правильно вы бы просто написали этот код на JSP. И получилось бы так же быстро, или не сильно медленнее, а может даже и быстрее. Да и первоначальные оценки могли быть завышены.

    То есть у программиста есть всегда выбор пути разработки, и в связи с тем что точно оценить продолжительность очень сложно, то он использует второй критерий для выбора пути — комфортность технологии (удовлетворение амбиции).

    Я сам не против этого, но просто по моему мнению это надо честно признавать и принимать.
    • 0
      Кстати, пример от инженера Гугла просто превосходен :) Спасибо.
    • +1
      Об том и говорю в той ситуации надо было пеерсилить себя и тупо написать что надо. Или пойти и сказать ну его нафиг не могу, давайте в другой проект пойду.

      То, что я сделал было явно во вред. Хотя передовые технологии, чистый код и все такое.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.