Comments 37
Все профессии важны, все профессии нужны. И пока еще нужны, и те, кто пишет велосипеды сам, и те, кто на них катается. Так что каждый решает сам, писать ли ему мобильное приложение под iOS или идти придумывать Swift в Apple. И в итоге выбирает материал для изучения в зависимости от интересов и способностей.
На мой, сугубо личный взгляд, следует очень сильно различать инженеров — программистов и «кодеров». Если первым поручить задачу «сделай чтоб это считало так» мы на выходе получим уйму потраченого времени, и уникальное решение которое будет решать эту задачу. Если мы попросим сделать ту же задачу «кодера» то мы получим решение этой же проблемы на основе другого решения, с меньшими затратами труда. НО если мы поручим «кодеру» написать что-то серьезное, мы получим решение быстрее, но сложнее в поддержке и, скорее всего, более уязвимое, ввиду использования большого количества разношерстных библиотек. По итогу, как сказал оратор выше. «Все профессии важны, все профессии нужны.»
UFO just landed and posted this here
Не стоит говорить и «инжинер» — настоящий программист а «кодер» — не программист, по тому что каждый из этих типов может является настоящим программистом, просто один склонен «изобретать велосипеды», другой «приделывать к велосипедам костыли». отличать путем общения и понимания личных предпочтений каждого в отдельности. Опять же скажу что нельзя сказать кто более важен, для процесса разработки нужны оба типа.
По ЧСВ.
Сложное в поддержке решение всегда можно отрефакторить, если это становится причиной ошибок, и получить менее сложное, а вот архитектуру, которая гнется не в тех местах и устарела морально в процессе реализации заменять придется сразу целиком.
Вот только «отрефакторить», в некоторых случаях, означает тоже — заменять сразу целиком. Фатальные ошибки возможны при любых раскладах. Я в своей жизни видел проекты которые до сих пор отлично выполняют поставленные задачи и на fox.pro требующие минимум поддержки и никуда не годящиеся решения которые пришлось полностью менять на yii. Видел и обратное. Но это больше относится не столько к разработчикам, сколько к заказчикам и изменчивости требований к системам.
Все равно лучше за неделю собрать из библиотек рабочее решение, а потом заменить его целиком, чем пол года разрабатывать что-то универсальное, а потом все равно его заменять целиком, потому что требования опять поменялись.
Вот пример из жизни. Нужно было создать потенциально интересный людям сервис обработки и хранения данных, заказчик выбрал компанию которая сказала что сделает быстро и не дорого. В итоге сделала, не очень быстро, но сделала, и через 2 (два) месяца эксплуатации системы её пришлось ПОЛНОСТЬЮ переписывать, по тому что ввиду использования различных левых библиотек — оптимизация проекта была ниже плинтуса, и сервис падал от слова совсем уже при 1000 униках. Да, по итогу мы потратили не 3 месяца на разработку, а больше, зато проект не падает и стабильно развивается, доработки в рамках логики проекта не отнимают огромное количество времени на тестирование «а вдруг что отвалилось, где не ждали».
Понятно что для того чтоб написать визитку — нет смысла делать множество абстракций и каждый раз разрабатывать свою цмс, но для сложных и потенциально высоко нагруженных проектах бездумно использовать кучу чужих библиотек… это далеко не самое правильное решение.
Понятно что для того чтоб написать визитку — нет смысла делать множество абстракций и каждый раз разрабатывать свою цмс, но для сложных и потенциально высоко нагруженных проектах бездумно использовать кучу чужих библиотек… это далеко не самое правильное решение.
Ну а чего вы вообще ожидали? В этой ситуации заказчик сделал ровно все, чтобы проект провалился. Я удивлен, что его вообще смогли закончить.
1) Никогда ничего не заказывайте на стороне. Ну просто потому что аутсорсеру вообще плевать что там будет после сдачи. Исключения можно делать только когда проект типовой, или у компании уже есть конкретные наработки.
2) Сроки, качество, цена — выбери любые два. Хотели быстро и дешево, получили соответствующее качество.
3) Технического задания, как я понимаю, тоже не было. А стоит оно также, как весь проект, и времени на его разработку нужно столько же.
4) Библиотеки помогают только если у команды есть необходимые компетенции. А если их не было, то чего вы ожидали?
1) Никогда ничего не заказывайте на стороне. Ну просто потому что аутсорсеру вообще плевать что там будет после сдачи. Исключения можно делать только когда проект типовой, или у компании уже есть конкретные наработки.
2) Сроки, качество, цена — выбери любые два. Хотели быстро и дешево, получили соответствующее качество.
3) Технического задания, как я понимаю, тоже не было. А стоит оно также, как весь проект, и времени на его разработку нужно столько же.
4) Библиотеки помогают только если у команды есть необходимые компетенции. А если их не было, то чего вы ожидали?
Ну так, чисто для справки, проблемы решали тоже аутсорсеры :)
1) вы будете удивлены, но очень многие проекты в том числе и весьма сложные делаются или на аутсорсе, или с привлечением аутсорсеров, по тому что это правильнее, эффективнее и проще.
2) Заказчик исходил из вашего постулата, быстро собрать, а потом посмотрим.
3) Было, единственное что не было учтено — это нагрузки которые могут возниктнуть, это был стартап и было не понятно взлетит или нет.
4) Нужно понимать что, когда и как использовать. Я не говорю о том, что нужно постоянно изобретать велосипед, но и бездумно пользоваться готовыми решениями тоже не правильно.
Вообще не понимаю, почему вы считаете что заказчик сделал все чтоб проект провалился. ИМХО Заказчик сделал все вполне правильно с точки зрения бизнеса. Потратил часть ресурсов чтоб проверить насколько проект будет востребованным, когда убедился что проект будет востребован — потратил еще ресурсы чтоб сделать его эффективным. Это называется управление рисками :) Ведь проект мог и «не выстрелить»
1) вы будете удивлены, но очень многие проекты в том числе и весьма сложные делаются или на аутсорсе, или с привлечением аутсорсеров, по тому что это правильнее, эффективнее и проще.
2) Заказчик исходил из вашего постулата, быстро собрать, а потом посмотрим.
3) Было, единственное что не было учтено — это нагрузки которые могут возниктнуть, это был стартап и было не понятно взлетит или нет.
4) Нужно понимать что, когда и как использовать. Я не говорю о том, что нужно постоянно изобретать велосипед, но и бездумно пользоваться готовыми решениями тоже не правильно.
Вообще не понимаю, почему вы считаете что заказчик сделал все чтоб проект провалился. ИМХО Заказчик сделал все вполне правильно с точки зрения бизнеса. Потратил часть ресурсов чтоб проверить насколько проект будет востребованным, когда убедился что проект будет востребован — потратил еще ресурсы чтоб сделать его эффективным. Это называется управление рисками :) Ведь проект мог и «не выстрелить»
Ну прямо большую тему вы подняли. Если совсем грубо, то на каждом из этапов заказчик не управлял рисками, а понадеялся на авось, мол, раз уж потеряю деньги, то хоть не очень много. И библиотеки тут вообще ни причем.
3) Вы меняете показания -) То пишете, что было настолько плохо, что пришлось ПОЛНОСТЬЮ переписать, то пишете, что все было учтено, кроме нагрузок. Ну так проблемы с нагрузкой легко лечатся — воткнул побольше памяти, еще парочку серверов, и все ок. Раз уж клиентов так много оказалось, то наверняка ручеек прибыли это должен окупить. А если нет, то тут тогда вообще не в разработке дело.
3б) А если ваша работа окупилась как раз с этой прибыли, тогда вообще не понимаю в чем проблема с библиотеками: их использование позволило вообще запустить проект в таких сложных условиях и нанять более компетентных специалистов которые перепишут все это г*но; Если все так и было, то вы только что привели просто хрестоматийный кейс, как библиотеки помогают бизнесу и почему даже их бездумное использование лучше, чем свои костыли.
3) Вы меняете показания -) То пишете, что было настолько плохо, что пришлось ПОЛНОСТЬЮ переписать, то пишете, что все было учтено, кроме нагрузок. Ну так проблемы с нагрузкой легко лечатся — воткнул побольше памяти, еще парочку серверов, и все ок. Раз уж клиентов так много оказалось, то наверняка ручеек прибыли это должен окупить. А если нет, то тут тогда вообще не в разработке дело.
3б) А если ваша работа окупилась как раз с этой прибыли, тогда вообще не понимаю в чем проблема с библиотеками: их использование позволило вообще запустить проект в таких сложных условиях и нанять более компетентных специалистов которые перепишут все это г*но; Если все так и было, то вы только что привели просто хрестоматийный кейс, как библиотеки помогают бизнесу и почему даже их бездумное использование лучше, чем свои костыли.
Ну так тема то действительно большая и объемная.
Отнюдь, реализация не позволяла ни вменяемо масштабироваться ни держать нагрузку, но задачу свою с небольшим потоком пользователей — решала. На счет ручейка не берусь судить. Ну так я же с самого начала говорил, что прикладное программирование это НЕ ПЛОХО, просто не для всех задач подходит, как и инженерная разработка. Важно понять когда хорошо одно и когда хорошо другое. Причем, зачастую одно не исключает другого.
Отнюдь, реализация не позволяла ни вменяемо масштабироваться ни держать нагрузку, но задачу свою с небольшим потоком пользователей — решала. На счет ручейка не берусь судить. Ну так я же с самого начала говорил, что прикладное программирование это НЕ ПЛОХО, просто не для всех задач подходит, как и инженерная разработка. Важно понять когда хорошо одно и когда хорошо другое. Причем, зачастую одно не исключает другого.
А библиотеки то тут причем? Да, допустили ошибки в архитектуре, не заложили масштабирование, но это претензия исключительно к квалификации конкретного исполнителя.
Инженерная разработка как раз и состоит из использования библиотек. Собственно, весь SICP как раз об этом: как правильно создавать библиотеки, чтобы их можно была переиспользовать. Просто в те времена все думали, что ничего сложного в том, чтобы разработать всю обвязку для бизнес-логики с нуля нет, и этим может заниматься тот же инженер, что и бизнес-логикой (а еще казалось, что такие библиотеки можно наследовать из проекта в проект). Практика показала, что это выходит слишком дорого и сложно, и все равно люди допускают ошибки на других уровнях, и стало понятно что использовать готовые чужие библиотеки гораздо выгоднее. Вот, собственно, и вся история.
Например, во фронтенде, в котором я работаю, доминирующая концепция — убер-модульность, когда даже для простейшего действия нужно скачать и подключить библиотеку из 10 строк кода. И ничего плохого в этом подходе нет, потому что экономит время, и позволяет избежать ошибок.
Инженерная разработка как раз и состоит из использования библиотек. Собственно, весь SICP как раз об этом: как правильно создавать библиотеки, чтобы их можно была переиспользовать. Просто в те времена все думали, что ничего сложного в том, чтобы разработать всю обвязку для бизнес-логики с нуля нет, и этим может заниматься тот же инженер, что и бизнес-логикой (а еще казалось, что такие библиотеки можно наследовать из проекта в проект). Практика показала, что это выходит слишком дорого и сложно, и все равно люди допускают ошибки на других уровнях, и стало понятно что использовать готовые чужие библиотеки гораздо выгоднее. Вот, собственно, и вся история.
Например, во фронтенде, в котором я работаю, доминирующая концепция — убер-модульность, когда даже для простейшего действия нужно скачать и подключить библиотеку из 10 строк кода. И ничего плохого в этом подходе нет, потому что экономит время, и позволяет избежать ошибок.
MIT уже не тот!
Вот поэтому многие бегают от фреймворка к фреймворку, все свое детище хвалят и не любят другие решения. Сами же никто не пишет с нуля и не понимает базовых вещей. Поэтому мало кто пишет свои библиотеки в фреймворках, если текущая не устраивает. Просто пересаживаются на другой и переписывают код. Неосознанная некомпетентность.
Вся прелесть библиотек и фреймворков в том, что их поддерживают и развивают другие люди.
Возможно, чтобы хорошо выбрать Фреймворк надо уметь делать свой — так глубже понимаешь компромиссы и проблемы с которыми столкнутся авторы в будущем
Добавлю 5 копеек — пройдя путь от инженера техподдержки крупнейших украинских хостеров до хостмастера совсем небольших хостингов, перепробовав почти все современные и популярные панели управления хостингом я понял, почему каждый крупный хостер пишет свое решение.
Да, я тоже пишу свою панель управления хостингом, понимая, чем меня не устраивают те решения что тестировал, использовал или запустил в продакшен
Да, я тоже пишу свою панель управления хостингом, понимая, чем меня не устраивают те решения что тестировал, использовал или запустил в продакшен
Понять не поможет — разбираться в мегабайтах чужого кода чтобы выяснить, что они там наворотили — сомнительное удовольствие. А вот пересаживаться на чужой велосипед, после того как собрал свой, где сиденье, руль и педали идеально подогнаны под тебя, уже не захочется.
Разумеется, чтобы стать хорошим специалистом просто необходимо много практиковаться и набивать шишки реализуя свои версии известных штук. Но делать это надо в свободное время в личном проекте, потому что внедрение подобного велосипеда на работе обернется издержками для компании, и выльется в сотни человеко-часов допиливаний, фиксов и поддержки. Фреймворки на то и нужны, что весь этот путь уже пройден другими людьми, а на большинство вопросов найдется ответ на стековерфлоу.
Всегда будут люди которые используют чужое и пишут свое, обе стороны правы, если интересно знать как все работает, когда любопытство спать не дает и охото понять как работает модуль в языке, то что человеку мешает sicp изучить, тем более вроде htdp дают курс еще
Тенденция ясна. Но MIT? Неужели выпускники этого вуза не в состоянии самим научиться прикладному программированию?
По тексту статьи может показаться, что 6.001 (со schema) закончили преподавать совсем недавно. Однако, последний раз 6.001 читали MIT в 2007/2008м году. Уже 7 лет как вместо него читают 6.01 (c python).
Всё-таки Гегель был прав в том, что история развивается по спирали. Старая идея Дейкстры о том, что программное обеспечение получается таким дорогим потому, что его пытаются получить при помощи дешёвого труда, сегодня актуальна как никогда. Происходит, как бы, новый виток в стремлении разрабатывать офигительно сложные системы при помощи труда вчерашних студентов. И поэтому очень хочется, чтобы студентов заранее научили не каким-то там абстракциям, а практическим навыкам использования готовых библиотек. И такой запрос со стороны работодателей рано или поздно будет удовлетворён. Теперь вот и MIT перешёл на сторону зла. К сожалению, идею Дейкстры никто всерьёз не воспринял и выводов не сделал. Поэтому в итоге то программное обеспечение, которое всё-таки удастся заставить работать приемлемо, окажется ещё более дорогим, чем когда-либо раньше.
Конечно надо знать и уметь как можно больше, но за ограниченное время. Прогресс движется по пути усложнения, 15 лет назад не было тех веб сервисов и проблем которые есть сейчас, был веб-мастер всё в одном флаконе, теперь же full-stack девелопера найти как единорога, и есть тысячи библиотек которых раньше не было и в них надо разбираться за то же ограниченное время, потому что так работает индустрия.
Индустрия работает не так. Так работает плесень на её поверхности, которая занимается производством никому не нужных веб-сайтов. Только у этой плесени есть проблема острой взаимной конкуренции за скромный ручеек доходов от рекламы. У тех же, кто финансируется не за счёт рекламы (т.е. производит продукт действительно нужный конечному потребителю, что тот готов подтвердить фактом оплаты), нет никаких проблем с постоянным ускорением прогресса. Этот прогресс проходит мимо них. Они делают продукт, который решает проблемы реально существующие у потребителя. И последний не закапризничает из-за того, что в продукте используются устаревшие технологии. И никуда не денется в том случае, если разработка займёт на год больше, чем планировалось… например, три года вместо двух. Когда разработка финансируется не за счёт крошек со стола онлайн-рекламы, а за счёт денег, которые потребитель платит осознанно и щедро, можно позволить себе с самого начала иметь какую-то тактику и придерживаться её в течение всего срока разработки. И даже если окажется, что решаемая задача требует использования elasticsearch, использование которого очень существенно отличается от использования традиционных баз данных, у разработчиков будет достаточно времени на то, чтобы спокойно и не спеша разобраться с этой технологической новинкой.
Интернет-магазины зарабатывают не с рекламы, и у них есть крайне острая необходимость быстро и качественно внедрять новые фичи, чтобы увеличить конверсию и LTV покупателя. То же самое относится и к агрегаторам, тематическим поисковикам и SaaS-ам. Единственные ребята из веб-области, которым не нужно гнаться за скоростью и качеством внедрения новых фич — это как раз контентные сайты, которые получают доход с рекламы.
При чём тут вообще интернет-магазины или контентные сайты? Это не часть IT-индустрии. Эти виды бизнеса зарабатывают деньги не за счёт разработки софта. Интернет-магазины — это банальная торговля. Хотя и с приёмом заказов через интернет. Сайты, производящие контент, — это часть медиаиндустрии.
Вы бы ещё РЖД или Сбербанк в IT-индустрию зачислили. Между прочим, у РЖД есть «небольшой» вычислительный центр (в Москве, на Красных воротах). Конечно, в нём работают не так много людей, как в Гугле, но я уверен, что счёт идёт на тысячи. В Сбербанке тоже есть IT-департамент, который по числу сотрудников скорее всего превышает 99% российских IT-компаний.
Вы бы ещё РЖД или Сбербанк в IT-индустрию зачислили. Между прочим, у РЖД есть «небольшой» вычислительный центр (в Москве, на Красных воротах). Конечно, в нём работают не так много людей, как в Гугле, но я уверен, что счёт идёт на тысячи. В Сбербанке тоже есть IT-департамент, который по числу сотрудников скорее всего превышает 99% российских IT-компаний.
SICP сейчас всё ещё изучают в MIT под именем Advanced Symbolic Systems. Только уже не на младших курсах, а на старших.
Sign up to leave a comment.
Почему в MIT больше не изучают SICP