| ||
Чего ему должно быть всегда безразлично? Как раз таки очень часто не безразлично, ибо скорее всего есть разница при создании, развитии и поддержке проекта.Сообщение от syan
Последний абзац это нечто субъективное.
В обеих случаях неплохо бы приводить примеры, а то в общих пространственных философских изречениях не разобраться.
Ой, как не все равно.
Все помнят историю с КОБОЛ-ом и Y2K? Когда банкам резко понадобилась поддержка старого кода на КОБОЛЕ, а специалистов давно уж не было, а те, что были стали стоить нереально дорого. Вот и не хотят заказчики повторения подобной истории и выбирают для своих проектов языки, специалистов по которым можно будет найти и через 10 лет.
Это говорит лишь о том, что старый код был неудачным. Инструмент реализации был выбран неверно. Заказчик не проводил техническую экспертизу проекта.... И т.д.
Код который работает по 25 лет, а то и более в такой ответственной области, как банковская сфера неудачный? Причем ВЕСЬ?
Для решения бизнес задач был неудачно выбран язык, специально разработанный для решения этих бизнес задач?
Кстати языку COBOL недавно 50 лет стукнуло. И он еще жив. Единственный живой язык, сравнимый с ним по возрасту - это С (40 лет). Может неудачный инструмент 50 лет прожить?
Последний раз редактировалось oxigen_; 07.05.2010 в 15:59.
Именно - неудачный. О том, что 2000 год наступит и 50 лет назад было хорошо известно.
По поводу С - сильно сказано! Единственный, значит. Чувствуется такой здоровый снобизм.
ПО, которое не переписывалось десятилетиями (хотя, мне кажется, Вы ошибаетесь), говорит только о невменяемости заказчика. Проще - денежки, отпускаемые на модернизацию, попросту "пилили" втихую.
Неудачный инструмент может прожить неограниченное число лет, при наличии искусственного на него спроса (лобби). Мудрость - не обязательный атрибут старости, надеюсь, в этом Вы со мной согласитесь?
О том, что 2038-й год наступит и сейчас известно, да еще и осталось до него значительно меньше 50 лет. И что, кто то чешется по этому поводу?
Эта вот байка про Кобол смешит. У банков нет денег заплатить специалистам? Так и поделом им.
А еще очень занятны провидцы, которые знают на чём писать, что будет и через 10 лет актуально. Ну ну...
Bite my glorious golden ass! © Bender B. Rodríguez
Ты вообще код на COBOLе видел хоть раз?
Еще есть FORTRAN и Lisp (ассемблер языком считается?), которые старше на 5-7 лет, если считать по датам стандартов.Кстати языку COBOL недавно 50 лет стукнуло. И он еще жив. Единственный живой язык, сравнимый с ним по возрасту - это С (40 лет). Может неудачный инструмент 50 лет прожить?
Мое личное мнение: COBOL выжил только из-за огромной массы legacy-приложений. Видел как-то мэйнфрейм, которому лет 15. Его не трогают потому, что, во-первых, на нем критичное приложение, во-вторых, он лет 10 работает без перезагрузок и сбоев, и, что самое интересное, без поддержки (вообще не было специалиста, который мог бы хоть что-то на нем сделать). Все вроде хорошо, но почему-то новые проекты на мэйнфреймах мало кто начинает.
Это потому, что у тебя однобокий взгляд на вещи (как и у всех нас). Для тебя (и для меня, чего уж там), на первом месте стоит красота технической стороны вопроса. Для целевой аудитории техническая сторона - всего лишь один из факторов. Ты, пользуясь языком как инструментом создаешь нечто. Это нечто - в твоем понимании результат, конечная цель, и вполне естественно, что ты стремишься к идеальному процессу получения результата.
Но ведь то нечто, которое для тебя результат, для клиента - инструмент. Он собирается им пользоваться. Лично мне все равно, постился ли, молился ли, медитировал ли слесарь, который сделал мне молоток. Лично меня мало волнует правильность кристаллической решетки металла бойка и фэншуй местности, где росла акация для рукоятки. Мне важен молоток, остальное меня не волнует. Такая позиция, безусловно, оскорбительна для слесаря, который, вероятно, отдал мне кусочек своей души в этом молотке.
Это потому, что у тебя до сих пор был неудачный личный опыт. И наверное потому, что не все в этой жизни шедеврально. Большая часть вещей наоборот - крайне утилитарна. Тот самый молоток урод уродом с точки зрения эстетики, а как гвозди забивает, а? В смысле, любая деятельность может быть и искусством, и ремеслом, это весьма философский вопрос.Мне не нравится то, что программное обеспечение (конечный результат), при кажущемся разнообразии, - суть одинаковое УГ.
Я считаю, что не существует какого-то "Тотального Кризиса Сферы Информационных Технологий". ИТ будет востребованны покуда есть человечество, так как это - инструмент, причем с доказанной полезностью.
Тут говорили про студентов, зарплаты, специалистов и все прочее. Правильно говорили, действительно есть такое. Но это конкретно наши реалии.
О каких студентах можно говорить при фактическом крахе образовательной системы? Система высшего образования давным-давно девальвировала, наши дипломы - это чистая формальность и знак того, что у тебя хватило терпения на 5-7 лет. Ничем другим диплом нашего государства не является.
О каких собственных разработках можно говорить, если у нас всего одна форма ведения хозяйственной деятельности - "украсть и попилить"? Разве кого-то в таких условиях волнует эффективность или автоматизация работы предприятия?
Как вообще можно считать среднюю зарплату по отрасли, если главнокомандующий может получать астрономические суммы, а подчиненные - по два-три месяца вообще ничего не получать?
В общем, в ненормальной среде не могут происходить нормальные явления. А ИТ тут весьма опосредованны.
Я говорю именно об этом. Я говорю о приближении инструмента для клиента к идеалу, а не о способах шедевральной реализации рюшика. Невнимательно читал, коллега.
В сентенции об УГ -я выступал в качестве клиента.
В сентенциях о реализации - в качестве проектировщика.
Моего клиента не должен волновать процесс приготовления яичницы - его интересуют вкусовые качества, правда? Почему же мой клиент навязывает мне способ разбивания яиц? Грубо говоря, если тим-лидер подбирает себе команду для масштабного проекта, ему ни к чему оговаривать язык реализации модулей проекта. Достаточно оговорить интерфейсную часть модуля (скажем, типы вводимых и возвращаемых параметров). Т.е., с моей точки зрения, кризис - в головах.
В основном, мне везло на заказчика в смысле свободы реализации. И, соответственно, крайне не везло в смысле техзаданий.В основном, ТЗ пишу сам. Это везение или невезение?
Без сомнений. Вопрос в степени полезности. ИТ может отдавать гораздо больше. Кризис - в эффективности. Заметь, за 10 лет задачи (общий характер) принципиально не изменились, а техника?
О зарплатах - конечно, бардак в обществе, аберрация ценностей во всем мире и т.д. приводит к кошмарикам в частных случаях. Тут я не возражаю, да и не возражал-то. Меня зарплатная часть интересует менее. За державу обидно (с).
А по-моему, тимлид, который не беспокоится об унификации и единообразии проекта - плохой тимлид.
Охохоо.
Предположим что человек который писал модуль на каком нибудь Хаскеле уволился или умер вообще. Что делать руководителю проекта?
Все было бы здорово, если бы вы с клиентом имели одинаковое понятие "идеально". Так бывает крайне редко, не в последнюю очередь потому, что клиент может вообще не соображать в процессе, а оценки выносить как-то надо. Вот и делаются критериями оценки внешний вид или еще какие-то вторичные вещи, потому что клиент считает, что уж во внешнем виде-то он соображает. Да много всяких вариантов может быть, дело-то житейское.Я говорю именно об этом. Я говорю о приближении инструмента для клиента к идеалу, а не о способах шедевральной реализации рюшика. Невнимательно читал, коллега.
Строго говоря - недостаточно. В смысле, ограничения все же остаются: попробуй передать сериализованный Java-класс в .NET (туповатый пример, но другой придумать не могу). Это потребует значительных усилий, которые бы не потребовались в гомогенной среде. Ясно, что есть решения и на этот счет, но в любом случае наименее ресурсоемкое предпочтительнее, так как это выливается в деньги.Почему же мой клиент навязывает мне способ разбивания яиц? Грубо говоря, если тим-лидер подбирает себе команду для масштабного проекта, ему ни к чему оговаривать язык реализации модулей проекта. Достаточно оговорить интерфейсную часть модуля (скажем, типы вводимых и возвращаемых параметров).
Да и клиенты тоже разные. Одни могут дать тебе на аутсорс только часть проекта. Другие могут оказаться субподрядчиками. Третьи могут быть излишне консервативными или иметь харизматичного консультанта по технологии со своим собственным видением проблематики. Я к тому, что у данного явления есть достаточное количество разумных объяснений.
Нельзя не согласиться.Т.е., с моей точки зрения, кризис - в головах.
Когда как. Если считать тебя опытным и хорошим специалистом - тогда везение.В основном, мне везло на заказчика в смысле свободы реализации. И, соответственно, крайне не везло в смысле техзаданий.
А что такое 10 лет в масштабах отрасли? Программирование стало мэйнстрим-профессией примерно к 90м, с появлением персональных компьютеров. Я считаю, что к 2000ым только-только закончились переходные процессы. В последние три-четыре года появилось (скорее, созрело) достаточное количество новых парадигм (как мышления, так и производства), успевай только следить.Без сомнений. Вопрос в степени полезности. ИТ может отдавать гораздо больше. Кризис - в эффективности. Заметь, за 10 лет задачи (общий характер) принципиально не изменились, а техника?
И мне обидно. Вроде не бездельники и могли бы жить.О зарплатах - конечно, бардак в обществе, аберрация ценностей во всем мире и т.д. приводит к кошмарикам в частных случаях. Тут я не возражаю, да и не возражал-то. Меня зарплатная часть интересует менее. За державу обидно (с).
Если он понял, что у него есть (точнее, был) "незаменимый человек" пост-фактум - только уволится или умереть вообще. Он опозорился еще до этого события.Охохоо.
Предположим что человек который писал модуль на каком нибудь Хаскеле уволился или умер вообще. Что делать руководителю проекта?
Если покойник отладил свой модуль, то вносить изменения тимлиду не понадобится. Покойник работу не закончил и модуль можно отдать другому. Выход есть всегда.Охохоо.
Предположим что человек который писал модуль на каком нибудь Хаскеле уволился или умер вообще. Что делать руководителю проекта?
Плох тот тимлид, который не просчитывает последствия. Плох тот тимлид, который принимает не вылизанный до блеска результат. Обе фразы не следует расценивать, как "тимлид вообще ни на что не годен".
Коллеги, а вы не дробите свои проекты на мелкие части? Я, честно говоря, предпочитаю не копаться в чужом коде, поэтому заставлял (по возможности, конечно) дробить на элементарные функционалы. Да и собственные тексты легче переписать, чем править через два-три года. Нет?
Со временем могут изменится требования к модулю или найтись ошибки спустя годы. Отдать другому его не получится, никто из существующей команды может не знать языка/библитек/фреймворков c помощью которых этот модуль был написан.Если покойник отладил свой модуль, то вносить изменения тимлиду не понадобится. Покойник работу не закончил и модуль можно отдать другому. Выход есть всегда.
Плох тот тимлид, который не просчитывает последствия. Плох тот тимлид, который принимает не вылизанный до блеска результат. Обе фразы не следует расценивать, как "тимлид вообще ни на что не годен".
Также использование "зоопарка" усложняет ревью кода и его поддержку. Да и развертывание самого приложения и его обслуживание.
Так что задача тимлида, а более правильнее его назвать архитектором, тщательно все взвешивать при выборе инструментария или включении нового
Это вы так шутите?
Не согласен совершенно. При описанном подходе, мне ничего, кроме интерфейсной части и ее описания (т.е. документации проекта) не нужно. Ошибка, спустя годы, - это загибаете, коллега. Не об MS Windows ли вспомнили? Вариантов два: а) проект все годы лежал на полке; б) ошибка в генетическом коде заказчика (как в вашем примере с банками).
Это я так всерьез. Я не читаю (почти никогда) код подчиненных. Я только проверяю соответствие результата ТЗ. И то не всегда - у меня есть тестировщики реальной жизни продукта. Видите ли, если я буду разбирать их код, то проще написать самому. И, кстати, деньги тоже получить самому. Каждый член команды, ИМХО, должен отрабатывать свой хлеб.Это вы так шутите?
Ни тот не другой вариант. Так уж бывает что ошибки или иные нюансы всплывают спустя годы даже на активно используемых проектах, и людям свойственно ошибаться. Та же ошибка которая проявляется 29 февраля наглядный тому пример.
И при чем тут заказчик?
Все конечно индивидуально и зависит от сферы проектов но вообще code review считается хорошей практикой
Позвольте полюбопытствовать. Какие проекты вы ведете, в общих чертах, что вам удается придерживаться данных взглядов? Если это конечно не тайна.
Ошибка 29 февраля довольно надуманная причина. Заказчик при том, что используя программу так, как заказал, должен найти все ошибки в довольно короткие сроки. Не через годы.
Да. Считается. Но мне лично не нравится. И для моего психотипа не подходит - я все равно через 10 минут просмотра рабочего кода буду смотреть его по диагонали...
Не секрет, конечно. Но в настоящий момент - ничего интересного. Проект не самостоятельный - переписываем шведскую ERP-систему под себя. Стоящую, так сказать, на боевом дежурстве. Т.е., с тестировщиками проблем нет.
Тут упоминалась необходимость программисту математика.
А что вообще такое математика?
Кто-то может объяснить?
Это абстрактная какая-то левая полулженаука...
Как можно социологию, геометрию, частично физику, тайны мироздания и ещё кучу всего объявить привязанным к одной отрасли науки?
И ещё объявить, что это всё крайне необходимо знать программеру.
А если он не знает ВСЮ математику, то он - программер-позер!
Это бред.
Есть задача - ищется решение.
Нет задачи - не ищется решение.
Программер должен знать язык программирования (ну чем больше тем лучше), средства разработки этого языка (библиотеки, функции, классы и т.д.) и желательно иметь опыт использования этих самых языков, библиотек и прочего барахла.
Стоить задача реализовать чего-то там при помощи каких-то ОПРЕДЕЛЁННЫХ вещей из математики, то надо брать и разбираться с ними, так же как ставится к примеру задача сделать что-то с использованием новой технологии и программер садится и разбирается с конкретной задачей.
А разговоры о том, что программист не знающий математику не программист это глупости.
Программист должен быть специалистом в своей отрасли, а математик в своей.
В конце концов программист не математик.
Не такая уж и надуманная, каждые четыре года в начале марта на тематических ресурсах появляются описания таких случаев.Ошибка 29 февраля довольно надуманная причина. Заказчик при том, что используя программу так, как заказал, должен найти все ошибки в довольно короткие сроки. Не через годы.
Это был всего лишь один из самых простых примеров как баг может спать очень долгое время. Существует масса других случаев как например резкое увеличение нагрузки на определенные участки провоцирует появление ошибок, которые при существующей годами умеренной нагрузке, не происходили ранее.
Заказчик он ведь не тестовая контора чтобы проводить столь доскональные тестирования. На проработку столь детальных ТЗ и также принятии готового продукта с такими доскональными тестами уйдет непомерно много ресурсов. Что само по себе приемлемо только для задач узкого круга.
Поэтому заказчику часто далеко не все равно, на чем, с помощью чего продукт написан и с помощью чего он работает.
И тимлиду не должно быть все равно если большая часть проекта написана скажем на ява а какой-то специалист хочет написать какой либо модуль на руби причем нет существенных плюсов в плане выбора последнего. Руби никто не знает из остальной команды и не планирует его изучать в ближайшее время. Я уже не принимаю во возросшую сложность проекта по увязке всего этого.
PS спасибо за остальную часть ответа.
Ваши права
Тема: 
Ответить с цитированием
Социальные закладки