Одно из преимуществ — это то, что POM — это структурное описание проекта, тогда как build.xml — просто инструкция по сборке. Это позволяет Maven'у, например, автоматически генерить проект для IDE.
Но у меня от Maven'а остались в основном негативные впечатления. Таки да, шаг влево/шаг вправо — и начинаются дикие трудности. Кроме того, если возникают проблемы, то их очень трудно диагностировать. У меня, например, был случай, когда Maven на нашем билд-сервере незаметно апгрейднулся, и в результате начал использовать библиотеки в немножечко другом порядке. Я убил два с половиной дня, пытаясь понять, почему сборка на моём компьютере и на сервере даёт разные результаты.
На мой взгляд, решение про удаление узла из списка, если есть доступ только к этому узлу — плохое. Оно создаёт неожиданные побочные эффекты, которые потом может быть очень трудно отловить.
(То есть я бы человека, предложившего такое решение и не прокомментировавшего тут же, почему оно плохое, в команду не взял).
Также я всегда использую var никогда не использую явное типизирование (ну только когда выхода нет). Я так же стремлюсь всегда давать очень короткие имена переменным i,d,v,k для меня не проблема, ибо функции маленькие все понятно из контекста. Зачем писать currentNode если можно написать просто n и при это все равно все ясно?
Это, на мой взгляд, просто вредный совет. Типизация позволяет выловить много ошибок, особенно на местах стыковки своего и чужого кода.
Что же касается имен переменных, то «всё ясно» исключительно в случае коротких методов, только автору и только вскоре после написания. А если мне нужно залезть, скажем, в вычисление интереса на банковском счету и кое-что поправить, то мне будет куда проще это делать, если переменная называется «lastMonthInterest».
Однако стоит по возможности стараться все делать как можно проще.
Я бы сказал, не «проще» а «понятнее». Выражение «i = 0 — i» очень простое, но понять, что оно используется для того, чтобы присвоить i единицу, если там был 0, и 0, если там была единица, удается не сразу. (Предположим, что мы уверены, что в этом месте кода i гарантированно равняется или нулю или единице).
Как раз скорее наоборот. Большинству работодателей нужен человек, с которым можно нормально взаимодействовать. Программистам традиционно прощается лёгкая асоциальность, но только до известных пределов.
Истории про безумных асоциальных гениев-программистов, конечно, бывают, но это скорее исключения из правил. Во всяком случае я встречал, пожалуй, одного такого, и я сильно подозреваю, что дело было не в его гениальности, а в том что его по каким-то причинам не могли уволить.
Амазон стал Амазоном вовсе не из-за таких приёмчиков. Я пользовался разными книжными магазинами, но в последнее время в основном заказываю на Амазоне, и вовсе не потому, что там хранится моя курточка, или потому что он первый в выдаче по поиску. Просто у Амазона:
— в большинстве случаев получается дешевле, даже с платной доставкой;
— всегда понятно, есть товар или нет; если товар есть, то он высылается в тот же день;
— количество проблем с заказами минимально.
Мораль простая: в первую очередь важно качество сервиса, а уж потом всякие «манипуляции».
Звучит красиво, но на деле такая схема работать в большинстве случаев не будет.
Прежде всего, как правило, пользователь не может сам определить, что именно ему нужно — во многом потому, что он не знает, а что именно можно сделать. Определение того, что нужно заказчику — это долгая и непростая работа, анализ.
С документацией тоже могут быть проблемы — её может толком не быть, или она может быть очень сложной, так что разобраться с карандашом не получится (представьте себе, например, документацию на систему биржевой торговли....)
Подробное описание в ТЗ, конечно, замечательно, но может занять слишком много времени. Опять-таки, тут нужен аналитик, который знает достаточно и бизнеса, и технологии, чтобы определить необходимый уровень.
Страничку надо взять двумя пальцами и аккуратно, соразмеряя усилие, перевернуть. Мне кажется (хоть я и не специалист), что это гораздо сложнее (и, следовательно, полезнее) малышу, чем провести пальцем по экрану (а то и просто ткнуть пальцем — смотря какая читалка).
Ну а конструктор, конечно… Тут уж и говорить нечего.
О-о-о, я в своё время с этим поразвлекался :) Была одна программка, которая умела перетаскивать их в Аутлук :)
Безусловно, пока что это всё ещё не утеряно навсегда. Но уже извлечение файлов из ChiWritera, хоть и возможно, представляет собой задачу далеко за пределами возможностей рядового пользователя. То есть многие просто плюнут на эти документы и всё.
Да, возможно, в какой-то момент у пятилетнего ребёнка уже будет своя читалка, и родители будут открывать ему доступ к разным «полкам» семейной библиотеки. Однако я думаю, что детям, до определённого возраста, с точки зрения развития куда полезней опреировать реальными а не виртуальными объектами — хотя бы для нормального развития моторики.
Сеть, безусловно, частично решит проблему — но только частично. Проблема устаревших форматов никуда не денется. ВотВам почти что реальный пример. В 1989 году я писал некоторые работы используя ChiWriter — чуть ли не первый WYSIWYG редактор. Если бы я не спохватился в какой-то момент и не перевёл написанное в другой формат, сейчас прочитать те документы было бы весьма и весьма проблематично. А ведь прошло всего чуть больше двадцати лет.
Я не говорю уже про неустойчивость такой системы в случае глобальных катастрофических событий — в случае чего целые области легуо могут остаться совсем без книг :)
Единственное, что не очень ясно — почему в случае рассинхронизации нельзя поставить игру на паузу и, так сказать, голосованием попытаться решить проблему. То есть если игроков больше двух, то скорее всего, как я понимаю, проблема случится у одного. Тогда, сравнивая хеши, можно понять, у кого вариант дефектный, и передать ему полное состояние игры. Да, это вызовет паузу — но всё лучше, чем просто закрывать игру…
Все проблемы, о которых Вы говорите — это, в общем-то, явление временное. Они не то, чтобы исчезнут — скорее, перестанут быть проблемами. Ну, например, пресловутый зоопарк форматов. У цифровых изображений тоже есть десятки различных стандартов, однако, в общем и целом, это мало кого тревожит, поскольку программы для работы с изображениями прекрасно понимают все эти форматы. Когда Вы просматриваете коллекцию фотографий, Вам всё равно, JPG это, PNG или что ещё. Примерно то же самое произойдёт и с книгами.
А вот две другие проблемы, которые Вы обошли вниманием в своёй статье, на мой взгляд, гораздо серьёзнее. Первая проблема — это дети. Когда книги стоят на полках, ребёнок, движимый любопытством, может брать их и просматривать, а, если заинтересует, то и прочитать. Я в своё время именно так и отурыл для себя некоторых авторов — я рассматривал книги на полках всемейной библиотеке, и некоторые меня чем-то заинтересовали. Я взял, открыл, прочитал несколько страниц и увлёкся. Брать и просматривать электронную библиотеку гораздо более затруднительно — как результат, дети могут меньше вовлекаться в чтение.
Вторая проблема, даже более серьёзная — это доступность книг в будущем. Впрочем, это проблема не только книг, но и вообще современных носителей информации. Книгу, изданную 150 лет назад, мы можем читать так же легко, как и современную (ну, допустим, с поправками на яти). Книгу, которую я записал всего 20 лет назад на пятидюймовые дискеты, сейчас прочесть крайне затруднительно. (Да что там 20 лет — 10 лет назад я записал кое-что на Zip-диск… :) ) Интересно, что из наших современных электронных библиотек смогут прочитать наши внуки лет через 100?
Но у меня от Maven'а остались в основном негативные впечатления. Таки да, шаг влево/шаг вправо — и начинаются дикие трудности. Кроме того, если возникают проблемы, то их очень трудно диагностировать. У меня, например, был случай, когда Maven на нашем билд-сервере незаметно апгрейднулся, и в результате начал использовать библиотеки в немножечко другом порядке. Я убил два с половиной дня, пытаясь понять, почему сборка на моём компьютере и на сервере даёт разные результаты.
(То есть я бы человека, предложившего такое решение и не прокомментировавшего тут же, почему оно плохое, в команду не взял).
А также можно напороться на неожиданные идиомы.
Важно только чтобы какая-нибудь похабень случайно не сгенерировалась, а то будет много крика, да и до суда может дойти.
Это, на мой взгляд, просто вредный совет. Типизация позволяет выловить много ошибок, особенно на местах стыковки своего и чужого кода.
Что же касается имен переменных, то «всё ясно» исключительно в случае коротких методов, только автору и только вскоре после написания. А если мне нужно залезть, скажем, в вычисление интереса на банковском счету и кое-что поправить, то мне будет куда проще это делать, если переменная называется «lastMonthInterest».
Однако стоит по возможности стараться все делать как можно проще.
Я бы сказал, не «проще» а «понятнее». Выражение «i = 0 — i» очень простое, но понять, что оно используется для того, чтобы присвоить i единицу, если там был 0, и 0, если там была единица, удается не сразу. (Предположим, что мы уверены, что в этом месте кода i гарантированно равняется или нулю или единице).
Истории про безумных асоциальных гениев-программистов, конечно, бывают, но это скорее исключения из правил. Во всяком случае я встречал, пожалуй, одного такого, и я сильно подозреваю, что дело было не в его гениальности, а в том что его по каким-то причинам не могли уволить.
— в большинстве случаев получается дешевле, даже с платной доставкой;
— всегда понятно, есть товар или нет; если товар есть, то он высылается в тот же день;
— количество проблем с заказами минимально.
Мораль простая: в первую очередь важно качество сервиса, а уж потом всякие «манипуляции».
Прежде всего, как правило, пользователь не может сам определить, что именно ему нужно — во многом потому, что он не знает, а что именно можно сделать. Определение того, что нужно заказчику — это долгая и непростая работа, анализ.
С документацией тоже могут быть проблемы — её может толком не быть, или она может быть очень сложной, так что разобраться с карандашом не получится (представьте себе, например, документацию на систему биржевой торговли....)
Подробное описание в ТЗ, конечно, замечательно, но может занять слишком много времени. Опять-таки, тут нужен аналитик, который знает достаточно и бизнеса, и технологии, чтобы определить необходимый уровень.
Ну а конструктор, конечно… Тут уж и говорить нечего.
Безусловно, пока что это всё ещё не утеряно навсегда. Но уже извлечение файлов из ChiWritera, хоть и возможно, представляет собой задачу далеко за пределами возможностей рядового пользователя. То есть многие просто плюнут на эти документы и всё.
Впрочем, поживём- увидим. :)
Я не говорю уже про неустойчивость такой системы в случае глобальных катастрофических событий — в случае чего целые области легуо могут остаться совсем без книг :)
Единственное, что не очень ясно — почему в случае рассинхронизации нельзя поставить игру на паузу и, так сказать, голосованием попытаться решить проблему. То есть если игроков больше двух, то скорее всего, как я понимаю, проблема случится у одного. Тогда, сравнивая хеши, можно понять, у кого вариант дефектный, и передать ему полное состояние игры. Да, это вызовет паузу — но всё лучше, чем просто закрывать игру…
А вот две другие проблемы, которые Вы обошли вниманием в своёй статье, на мой взгляд, гораздо серьёзнее. Первая проблема — это дети. Когда книги стоят на полках, ребёнок, движимый любопытством, может брать их и просматривать, а, если заинтересует, то и прочитать. Я в своё время именно так и отурыл для себя некоторых авторов — я рассматривал книги на полках всемейной библиотеке, и некоторые меня чем-то заинтересовали. Я взял, открыл, прочитал несколько страниц и увлёкся. Брать и просматривать электронную библиотеку гораздо более затруднительно — как результат, дети могут меньше вовлекаться в чтение.
Вторая проблема, даже более серьёзная — это доступность книг в будущем. Впрочем, это проблема не только книг, но и вообще современных носителей информации. Книгу, изданную 150 лет назад, мы можем читать так же легко, как и современную (ну, допустим, с поправками на яти). Книгу, которую я записал всего 20 лет назад на пятидюймовые дискеты, сейчас прочесть крайне затруднительно. (Да что там 20 лет — 10 лет назад я записал кое-что на Zip-диск… :) ) Интересно, что из наших современных электронных библиотек смогут прочитать наши внуки лет через 100?