Comments 67
В чем конечная цель программирования?
В том, чтобы иметь код, который легко изменять.
Неверно. Конечная цель программирования это программа которая решает поставленные задачи. Дальше все зависит от разных вводных, поставленные сроки, человеческий ресурс, конечная цель. И от этих условий уже будет зависеть как будет выглядеть код. Но заявлять что конечная цель программирования это код, неверно.
С поправкой, что сроки не всегда должны быть, а программист не всегда ресурс. Мы ведь про программирование, а не про бизнес
Чем "программа" отличается от "продукта" в контексте этой статьи? Мне кажется Вы не читали статью
Да. Не всё нормально. Цель программирования же, не разработки)
Люди пишут код на работе, программируют. Не хотят писать много. А зачем пишут, для чего. Чтоб красивый был. Страшно представить какие библиотеки или фреймворки способны создать такие программисты.
Про деление на программистов и разработчиков уже все позабыли. Программистов всё больше... им и код изменяемый и супер простой подавай. Гнать их в с++ или ассемблер надо. Пусть познают хоть что есть компьютер. А то как ни спросишь на собесе так про планировщик в ОС мало кто помнит уже, не говоря уже почему двоичка кругом
А зачем пишут, для чего. Чтоб красивый был. Страшно представить какие библиотеки или фреймворки способны создать такие программисты.
Какие фреймворки? Наверное красивые))
А то как ни спросишь на собесе так про планировщик в ОС мало кто помнит уже
Да и хер бы с ним, если с ОС не работаешь) А - абстракции
Да и хер бы с ним, если с ОС не работаешь
Ну об этом и речь. О том - что все начинают забывать, что они делают и где. Вы все в основном работает в ОС в IDE. Собираете и запускаете код в ОС. Облака - там ОС. Кубренеты они на ОС. Андроид = ОС. В докер-контейнерах всё тоже самое что и в ОС с поправкой на докер, потому что они виртуализируют что - правильно ОС.
Не работают они с ОС... Да, все создают умные розетки поголовно на чистом C + какой-нибудь ардуино или что по мощнее. Даже там есть в некотором виде подобие ОС а иногда и целые ОС с планировщиками как ни странно или хотябы циклами событий на интерраптах.
Абстракции у них... Которые в голове видимо запускаться будут. Красивые фреймворки...
Абстракции для того и нужны, что бы для того, чтобы писать на любимом питухончике не нужно было уметь в уме переводить питон в ассемблер, а ассемблер в машинный код, понимаете о чем я? Я перекладываю JSON из запроса в базу данных и отдаю какой-то другой JSON в ответе. Похеру мне на планировщик операционный системы на работе, честно!
Это я говорю при том, что я интересовался тем, как все и работает и книжки читал, но эта информация была полезна мне в работе не больше, чем знание аэродинамики.
Интересно что за работа такая. Где похеру на всё. Это очень похоже на позицию ребенка, который сидит на шее у родителей и ему также похеру откуда они на него деньги берут.
Так наверное некоторым и похеру как там оно всё работает. Я нашкодил абстракцию. Я крутой 500 000 мне платите.
Абстракции над этим всем, слава богу, придумали разработчики языков программирования, виртуальных машин, библиотек и прочие умные люди, которым это все очень интересно. А мне интересно бизнес-задачи решать. Еще раз повторю: я неплохо знаю, как все устроено) И свой язык программирования в универе делал и Таненбаума читал, так что не пойму при чем здесь ребенок\не ребенок. При этом я еще раз повторяю, что эти знания в работе были не более полезны, чем аэродинамика. Даже более страшную вещь скажу, для того, чтобы быть бэкенд-разработчиком сегодня, чаще всего не обязательно даже знать как работает TCP/IP, достаточно понимания HTTP.
Вы вот используете буквы и слова, предложения складываете, а понимаете при этом что такое фонемы и морфемы? Похоже на позицию ребенка, знаете ли. Или вот вы чай завариваете, а понимаете ли все химические и физические процессы, которые при этом происходят? А вы уверены?
Ну у бизнеса бюджет не резиновый. И его задачи они примитивны в рамках абстракций, про которые Вы говорите. И тот же питончик любимый можно разгонять именно благодаря тому что в ОС есть планировщик, который переключается между процессами. И на питоне cpu bound можно умеренно по скорости именно поэтому. Незнание используемых инструментов приводит к тому что вы несёте в мир дивиз "Пофигу как оно работает. Оно работает". Но бро! Давай подумаем на сколько быстро оно работает. Хостинг то он не бесплатный. Выполнение программы можно даже разогнать правильно настроив ОС. Где этим пользуются - в играх, ё мае. Говорят мы слепили чудо хрень много жрет настройте там чего в виндовсе и драйвере чтоб ФПС был больше. Смекаешь ;-) Надо копать. Надо)
Я ни в коем случае не несу посыл "пофиг, как оно работает". Я говорю о том, что в каждом моменте можно копать очень глубоко и жизни не хватит, чтобы все раскопать даже до атомов, не то что до кварков. Пример с планировщиком ОС отличный именно потому, что это вообще никак не влияет на код, который я пишу на питоне. Именно по этому мне не важно, как это работает. Это уже инкапуслировано, я пользуюсь интерфейсом. Все. Зачем тебе знание, которое никак не влияет на твои дейсвтия?
Хватит код писать. Создавай программные продукты. Влияет, просто ты не замечаешь или не хочешь. Ты ещё скажи что OOM Killer никак не влияет на код который ты пишешь. Или ты до сих пор не понял что у винды и линукса пути разные к файлам. Хоспаде. Копать нужно ровно на столько на сколько нужно. Чтобы понимать хотя бы поверхностно происходящее. А то дальше пет проекта не уехать с таким подходом, типо за меня всё придумали. Та придумали всё обычные люди, да умные. Но люди, а люди совершают ошибки. Всё надо проверять и копаться, чтобы было понятно хотя бы примитивно что и где
Это бесполезный диалог, вы меня не слышите :)
Да, не слышу. Потому что мы переписываемся. Но в предыдущем сообщении я отчасти с Вами согласен. Что жизни не хватит всё копать. Копать нужно столько, сколько нужно. А если совсем не копать, то можно забыть как 2+2 складывается. И за калькулятором бежать. Для этого. Совсем не копать/разбираться - это плохо для мозга)
Так никто не спорит с тем, что копать нужно! Но лучше копать в то, что интересно, а не во все подряд. Ну или хотя бы в то, что нужно, как вы сказали) По этому и говорю, что пример с планировщиком - хороший. Особенно, например, для разработчика смарт-контрактов на Solidity. Там вот это прям вообще бесполезное знание, вообще никак и ни на что не повлияет и повлиять не может. А для кого-то другого это может быть частью ежедневной работы
В том, чтобы иметь код, который легко изменять.
А я-то думал в том, чтобы иметь код, который решает задачи. А код, который легко изменять, получить легко. Давайте покажу:
int main()
{
return 0;
}
выходит, что даже в таком простейшем случае не так уж легко, так как тут магическое число.
Код действительно должен решать задачу - но этого недостаточно, это первая половина работы. Вторая половина работы - сделать код готовым к изменениям в будущем.
Поэтому, код из примера не является рабочим (ничего не делает), но готов к изменениям в силу своей простоты.
Что если для написании программы вам нужно не код писать, а, например, рисовать картинку, или танцевать? Процесс создания такой программы(рисование\танец) уже не будет являться программированием? По моему будет. Будет ли его результат кодом? Ну нет же(если только машинным на выходе). То есть получается, код все-таки не является целью и результатом программирования?
О! Цели vs средства!
В чём конечная цель молотка или отвёртки? Ни в чём, это инструмент. Не цель, а средство достижения цели. Одно из многих.
Гибкость кода - размер молотка. И да, минусовой отвёрткой можно закрутить плюсовой шуруп, а кувалдой - забить его аки гвоздь. Уж простите за аналогии. И не забывайте, что аналогия это тоже всего лишь средство, а не цель.
В контексте цели ценность любого кода околонулевая если он не решает задачу для достижения цели. А цели бывают самые разные. Круглые, квадратные, наземные, подводные...
К примеру, когда сварщики варят какую-то конструкцию на стройке, они знают, что эта конструкция необходима для того, чтобы был построен дом. Используют сварку, потому что очень важно, чтобы дом был крепким. Чтобы не было крушения дома. Чтобы люди не погибли при крушении. Это жизненно важно.
Они знают какой шов использовать и почему(прям чуствую что там есть ГОСТы и прочее, включая какие нибуит наряды и ТЗ). А также технику безопасности которую надо соблюдать. Остальное не думается не его дело, а какого нибудь архитектора, или проектировщика я в стройках не силен. И за это он получит деньги, это он хорошо знает.
Но спросите себя: о чем думают программисты, когда пишут код? Какова конечная цель их деятельности?
Закрою задачу вовремя, не огребу люлей, получу зарплату, может даже премию. И буду отдыхать спокойно на выходных, и заниматься своими хобями.
Мысль здесь очень проста: не существует такого понятия как «законченный продукт» в программировании. Наша работа не бывает закончена
Очень даже бывает, бывает работа по заказам, заказ выполнен всё до свидания.
Наверняка есть исключения из этого правила, но прошу вас обратить внимание, что это именно исключения, подтверждающие правило.
За последние 5 лет было 7 исключений, и всего 3 правила.
В чем конечная цель программирования?
Рубить бабло и/или получать удовольствие. Всё остальное, попытки менеджеров вытянуть из работников больше продуктивности, из заказчиков больше денег.
Интересно, программист, программирующий контроллеры для лифтового оборудования, тоже закладывает идею о том, что он будет постоянно свой код изменять? Или главное получить надёжное и безопасное решение, которое будет способно работать годами без изменений?
Хорошо программистам лифтов. У них код получается сразу без багов, и железо никогда не меняется.
Баги случаются, но ловятся они ещё на стадии отладочного стенда. Ну и железо да, не меняется. Разве что вместе с лифтом или контроллер сгорит. Однако цель программиста в данном случае — это не наплодить абстракций с целью упрощения рефакторинга кода в дальнейшем, а именно получить надёжный код, который решает конкретные задачи. Желательно, чтобы этот код ещё и в контроллер влез. Я вот, помнится, проходя срочную службу в СА запрограммировал сигнализацию на релейной логике, при этом не написав ни строчки кода. Только паяльник и реле. Сильно сомневаюсь, что кому-нибудь захочется изменять программу.
Цель программирования — это программа, удовлетворяющая потребности пользователя с минимальными затратами.
Частые изменения в коде — это особенность именно мобильной разработки (и некоторых других областей) — во‑первых, потому что сама область достаточно молодая, и общепринятые практики и фреймворки ещё не до конца устаканились, а во‑вторых, потому что распространение новых версий очень дешёвое.
Для сравнения, в случе критического косяка ембедщика может потребоваться отозвать партию проданных автомобилей. Поэтому подобные вещи обычно делают в рамках waterfall‑а, а к разработке переходят только после полного описания требований.
Поэтому подобные вещи обычно делают в рамках waterfall‑а, а к разработке переходят только после полного описания требований.
Не совсем и не всегда. Часто делается прототип на избыточном мк, который в процессе разработки неоднократно перепаивается и вообще причудливо изменяется, а когда заказчик говорит "это оно" — делается итоговая плата, с новым минимальным (ну, почти минимальным, мало ли) мк, с выглаженным и написанным по стандартам кодом. Я был бы рад работать по чистому водопаду, но часто человека. который имеет окончательное правильное понимание о том, как изделие должно работать и как не должно, не существует в природе, всегда получается небольшой НИР/НИОКР.
процессе разработки неоднократно перепаивается и вообще причудливо изменяется
В автопроме электроника обычно делается по ASPICE, там такого практически не бывает.
Да и в менее критичном к надёжности эмбеддеде изменений в требованиях обычно на порядок меньше, чем в типичной мобильной разработке.
в менее критичном к надёжности эмбеддеде изменений в требованиях обычно на порядок меньше, чем в типичной мобильной разработке.
С этим полностью согласен. Не в последнюю очередь потому, что заказчику при изменении требований нужно оплачивать не только время разработчика, но и комплетующие с платами, иногда еще и стенд, лабораторию и сертификацию. Дополнительные затраты времени и денег режут желание посоветовать поиграть со шрифтами)
там такого практически не бывает
Обычно в эмбеддеде требований меньше, точнее они наследуемые: модернизируем устройство или делаем аналог. Если что-то новое и небывалое, то начинается великолепное...
В том, чтобы иметь код, который легко изменять.
Ну вот это утверждение, на котором строится вся статья - явно очень спорное. Кому нужен код, который не работает? Кому нужен код, который легко изменять, но не решает свои задачи? Зачем нужно изменять код, который хорошо решает свою задачу? Из неверного посыла сформирована статья.
Вообще посыл о том, что программист это человек, который пишет код, а программирование === написание кода - очень вредно и для вас и для читателя. Это приведет вас в карьерный тупик. Программист должен решать задачи бизнеса, используя для этого, в том числе, разработку ПО. Задача программиста - не КОД. Задача программиста - решение бизнес-задачи. Иногда решение заключается в том, чтобы НЕ ПИСАТЬ КОД вообще.
Работал и технологом в банках - в основном решал задачи реализации какого либо продукта в виде процесса, проходящего через действия людей и работу средств автоматизации и программ.
Соответственно на выходе - инструкции для операционистов и бухгалтеров, тз для разработчиков, регламенты для суппорта/админов
Ну и не с "чистого листа" - надо увязать с имеющимся по возможности
А в чём тогда задача бизнесмена? Найти такого программиста?
IMHO, автор статьи прав, что в некоторых случаях лёгкость изменения существующего кода становится, по сути, бизнес-задачей разработки ПО. Continuous Deployment/Delivery - это об этом. Кстати, в соседней теме про лунный модуль говорится, что тот внештатно прилунился вследствие программной ошибки и что теперь тамошние разрабы стали опытнее. Так-то может оказаться, что никакой "модели водопада" не существует. Вернее, существует в рамках лишь одной итерации. И это относится и к автопрому, и прочему эмбеддеду. Просто у них итерации идут годами.
Бизнес не интересует и не должен интересовать КОД вообще ни в каком виде. И про изменяемость вы подменяете понятия. Бизнесу пофигу насколько легко изменять код, его интересует, насколько программа может быстро и легко адаптироваться к новым бизнес-требованиям. Программма может адаптироваться к новым бизнес-требованиям без измнения в коде. Код никого, кроме непосредственно программиста вообще не интересует. Если завтра придумают инструмент, где ты не пишешь код, а рисуешь блок-схемы в Figma и из этого получаешь рабочие программы, все внезапно перейдут на такой инструмент - то и программисты про код забудут.
Бизнесу пофигу насколько легко изменять код, его интересует, насколько программа может быстро и легко
ОК, что в вашем понимании "код" и что в вашем понимании "программа"? Существует ли программа без кода и кто исполняет такую программу?
Программа это некий исполняемый файл. Что значит исполняемый файл? То, что он содержит набор инструкций, который может быть выполнен компьютером. Должен ли этот набор инструкций быть понятень человеку? Нет! В моем понимании машинный код не является кодом в том смысле, в котором идет рассуждение в статье. Его уж точно нельзя назвать ни легко изменяемым, ни легко читаемым.
Continuous Deployment/Delivery - это об этом
Они не об этом, они о сокращении time-to-market, и это совсем не факт что изменение существующего кода. Это и о новых фичах, когда идет дописывание кода, например.
Возможно, это неочевидно, но добавление новых фич - это тоже "изменение существующего кода", как и удаление устаревших фич.
Я давно в IT и наблюдал эволюцию подхода к кодированию своими глазами. Начиная от "программа должна правильно выполнять свою задачу" (write), через "программа также должна быть ещё и понятна" (read) и до "программа, до кучи, должна быть ещё и легко изменяемой" (modify).
Потому что главной задачей разработчика ПО является как раз таки поддержание кодовой базы в актуальном состоянии, чтобы она могла продолжать решать задачи бизнеса. Не просто создать приложение "согласно ТЗ" и свалить в закат, а дать инструмент, способный эффективно работать в изменяющейся среде продолжительное время, и поддерживать этот инструмент в актуальном состоянии. Баг и секьюрити фиксы - они ведь тоже про актуализацию состояния ПО в изменяющемся мире.
Автор поста не побоялся привнести свет в массы и заслуженно получил минусов, потому что массы не любят, когда их просвещают ;) Я-то за его ответ сразу плюс статье поставил, ещё не читая, но я уже больше двадцати лет в IT.
добавление новых фич - это тоже "изменение существующего кода", как и удаление устаревших фич.
Все верно, с этим никто не спорит, тезис про time-to-market это никак не отменяет. Нас одинково интересует time-to-market как изменения старых фич, так и добавления новых, так и удаления) Это очевидно.
Я давно в IT и наблюдал эволюцию подхода к кодированию своими глазами. Начиная от "программа должна правильно выполнять свою задачу" (write), через "программа также должна быть ещё и понятна" (read) и до "программа, до кучи, должна быть ещё и легко изменяемой" (modify).
Хорошо, но как игнорирование тестов в определенной ситуации, или, например, непрохождение code-review улучшает показатели write/read/modify?
Потому что главной задачей разработчика ПО является как раз таки поддержание кодовой базы в актуальном состоянии, чтобы она могла продолжать решать задачи бизнеса
Абсолютно верно. Но упущена КРИТИЧЕСКАЯ деталь. Бизнес бывает разный. Это не единая сущность. И у разного бизнеса мало того, что есть разные потребности, бывают еще и разные стадии жизненного цикла. Невероятно странно было бы использовать теже подходы, что используются при разработке банковского ПО для создания лендинга сельского цветочного магазина, не так ли?
Не просто создать приложение "согласно ТЗ" и свалить в закат, а дать инструмент, способный эффективно работать в изменяющейся среде
Тут все верно, но опять же нужно уточнить, что понятие "эффективно" для каждой бизнес-задачи будет свое. У всех будут свои метрики. Именно из-за этого уточнения ломается следующая часть утверждения.
продолжительное время, и поддерживать этот инструмент в актуальном состоянии.
Далеко не всему бизнесу нужна поддержка ПРОДОЛЖИТЕЛЬНОЕ время. В качестве самого яркого примера я приведу стартап. Вот вы с другом сели и придумали классную идею проекта. Какой бы классной она ни была, с вероятностью примерно в 95% она никому кроме вас с другом нахер не нужна. На этом этапе ваша бизнес-задача не состоит в том, чтобы создать легко поддерживаемый продукт с высоким качеством кода. Почему? Потому что это существенно удорожает разработку именно на ранних стадиях проекта. А у вас нет еще ни одного клиента, прибыли и вы не знаете, сможете ли вообще отбить свои затраты на разработку. Оверинжиниринг на этом этапе - крайне распространенная причина провала проекта вообще. Многие просто даже до рынка не доходят.
При всем при этом, есть компания, ну, скажем Ericson, которая поставляет в том числе софт для вышек сотовой связи с каких-то бородатых годов, когда еще JavaScript даже в зародыше не было. Очевидно, что в такой корпорации для того софта, подходы к разработке должны быть совершенно иные. И там как раз нельзя делать все то, о чем тут пишет автор. Там надо именно что СТРОГО придерживаться принятых стандартов.
Автор поста не побоялся привнести свет в массы и заслуженно получил минусов, потому что массы не любят, когда их просвещают ;)
По причинам, которые я описал выше, я поставил автору минус. Автор посчитал, что суть программирования не в том, что приносить пользу бизнесу исходя из задач, потребностей и жизненного цикла бизнеса, а в какой-то его субъективной красоте кода.
Для меня это примерно как если бы психолог на сеансе мне сказал, что суть психологии не в том, чтобы помочь клиенту, а в том, что бы за его деньги убедить его в своих(психолога) представлениях о жизни.
Вот тут мне сложно вам что-то ответить. Вы почему-то решили, что "легкость изменения кода" подразумевает отказ от тестов и code review. Ни у себя в комментах, ни у автора статьи я не видел такого утверждения. Автор говорил, что писать код нужно так, чтобы тестов нужно было меньше. Вполне здравое утверждение, как по мне.
Потому что главной задачей разработчика ПО является как раз таки поддержание кодовой базы в актуальном состоянии, чтобы она могла продолжать решать задачи бизнеса
Прочитайте это ещё раз. Если вы выдающий девелопер, который может написать с одного захода приложение, которое будет работать всегда, то и то вы укладываетесь в это определение. Просто ваши усилия на поддержание после выпуска продукта равны нулю, вы их все вложили до. Никакой КРИТИЧЕСКОЙ детали я не упустил, это вы выдумали её существование. Даже лендинг в сельском магазине со временем нуждается в обновлениях, вот только они уже будут искать другого разраба, потому что имеющийся не берёт телефон. Некоторые могут сказать, что другой разраб сделает другой продукт, вот только решать он будет те же самые бизнес-задачи - лендинг сельского магазина.
Далеко не всему бизнесу нужна поддержка ПРОДОЛЖИТЕЛЬНОЕ время. В качестве самого яркого примера я приведу стартап.
И что? Много вы видели стартапов, которые завелись с одной итерации по методу водопада? В стратапах, как правило, народ плохо представляет, что именно он хочет, и пробует различные варианты, иногда параллельно (A/B-тестирование, например). Там требования к изменяемости кода ничуть не меньше. Кстати, а ПРОДОЛЖИТЕЛЬНОЕ (большими буквами) время - это не меньше скольки? Обычно, продолжительное - это больше нуля. А у вас?
По причинам, которые я описал выше, я поставил автору минус. Автор посчитал, что суть программирования не в том, что приносить пользу бизнесу исходя из задач, потребностей и жизненного цикла бизнеса, а в какой-то его субъективной красоте кода.
Ну, вы поняли, как смогли понять, и отреагировали, как смогли отреагировать. Только и всего.
Continuous Deployment/Delivery это о том, что workflow и архитектура всего продукта сделана таким образом, что каждый или практически каждый коммит в мастер можно деплоить в продакшен (вплоть до автоматического деплоймента в продакшен).
Без запланированных релизов раз в месяц с шатдаунами, без бюрократических ручных аппрувалов от пачки менеджеров.
Это не о том, что код легко модифицировать, это о том, что автотестами покрыть надо и код ревью проходить.
То что при этом коммит может представлять собой кучи реверсинженеринга в легаси, а не легкое изменение - совершенно не очевидно.
Вот что я хотел сказать про тайм-ту-маркет.
TTM - это про то, как каждый коммит (изменение) задеплоить в продакшн максимально быстро. А лёгкость изменения существующего кода - оно разве не про то же? Чем проще тебе менять исходный код, тем быстрее ты выведешь в продакшн новую версию продукта. Просто это один из первых этапов в workflow, но он тоже работает на ту же цель - сокращение TTM. Именно поэтому я и упомянул про Continuous Deployment/Delivery.
Continuous Deployment/Delivery - это слон, а легкость изменения кода - ну не знаю, бантик на его шее, что ли. Слона видят все, а бантик ещё разглядеть нужно. Если вам "слон" заслонил "бантик", возможно вы просто смотрите на него со стороны хвоста.
не каждый коммит, а конкретную фичу вывести.
Легкость изменения кода - не совсем про тоже. Это про технологический долг и архитектуру.
Но вокруг изменения кода, есть еще куча моментов, касающихся организации процесса. Например просто корпоративное решение сверху, что каждый релиз должен утвердить хай-левел менеджер (не технический), а для этого ему нужно предоставить доказательство что все ок в виде многостраничного документа о проведенном тестировании.
А затем еще нужно согласовать время даунтайма со всеми зависимыми компонентами и клиентами.
И так далее.
ПОэтому Continouous Delivery это в первую очередь об архитектуре проекта, как его сделать в принципе таким. Далеко не везде это возможно.
Автор поста не побоялся привнести свет в массы и заслуженно получил минусов, потому что массы не любят, когда их просвещают ;)
Большое спасибо что поделились такой формулировкой. С такой перспективой получать минусы гораздо менее обидно :)
Мне кажется, уже сам вопрос в заголовке уводит автора не туда :)
Код пишется для решения задачи. Сорян, но такова правда жизни. Именно за это платятся деньги. Но чтобы перейти к тому, как именно ее решить, надо использовать простую вещь.
Задача == требования. И эти требования делятся на функциональные и нефункциональные. Первые более менее понятно. А вот вторые - и есть собственно "проблематика" :)
Нефункциональные требования многообразны и тоже влияют на код. Безопасность, отказоустойчивость, нагрузка, совместимость, сопровождаемость, ... Категорий очень много, и нет смысла перечислять. Что весело, часто одни требования противоречат другим. Просто по своей природе, как например безопасность и юзабилити. Чтобы правильно понимать задачу, и соответственно - написать код, который ее решит оптимально, надо просто не полениться и их собрать до того в общем.
А потом, при возникновении ситцуации "налево пойдешь" / "направо пойдешь" открыть собранные требования, и мысленно, или на бумажке проработать оба варианта. И выбрать тот, который удовлетворяет требования лучше. Если не поможет, наапример, оба варианта равны - спросить заказчика, или подкинуть монетку :)
Но основное - это понимание, что нефункциональные требования так же важны, а именно они позволяют осознанно выбрать оптимальное решение.
У самурая нет цели, есть только Путь :-D
На такой вопрос нельзя дать один ответ, т.к. целей много. Заработать, получить удовольствие.... Это как спрашивать о смысле жизни.
К примеру, когда сварщики варят какую-то конструкцию на стройке, они знают, что эта конструкция необходима для того, чтобы был построен дом. Используют сварку, потому что очень важно, чтобы дом был крепким. Чтобы не было крушения дома. Чтобы люди не погибли при крушении. Это жизненно важно.
Сварщики варят чтоб потом было удобно переварить другому сварщику?
Конечная цель любого программирования - достичь цели, которая решается программированием. Потому что, программирование - это процесс, а результат программирования - программа. Цель любого программирования, как бы это странно для вас не звучало, - программа.
То, какой код будет написан, насколько удобно его будет нужно менять зависит от многих факторов. Помимо всего этого, если у нас будет совершенный язык и совершенный код, то его вообще не нужно будет менять. Т.е. ваше утверждение априори не верно.
Идеальный код — это отсутствие кода. В нём нет багов, его не нужно поддерживать, он не превращается в легаси.
Лично я всегда смотрю — есть ли альтернативы написанию кода — например использовать уже установленную библиотеку, может быть интегрировать сторонний сервис, или даже уговорить клиента купить готовое решение. И только если все эти варианты отпадают — мы садимся писать код.
Я не хочу вас запутать этими рассуждениями. Мысль здесь очень проста: не существует такого понятия как «законченный продукт» в программировании. Наша работа не бывает закончена. Мы можем долго поддерживать текущий продукт, нас могут перебросить на другой или же нас могут попросту уволить. Например, потому что закончились деньги. Но ситуация, когда продукт построен и закончен, случается крайне редко. Наверняка есть исключения из этого правила, но прошу вас обратить внимание, что это именно исключения, подтверждающие правило.
То есть не существует?
Написал программу, она работает - все, продукт закончен.
Может быть вы по какой-то причине считаете, что однажды написанная программа должна работать вечно? Но это далеко не всегда так. Если вам нужно чтобы ваша программа работала вечно, это нужно добавлять в тех.задание и соответственно после написания программы ее будут поддерживать. А вот каким способом - их очень много. Можно через время переписать с нуля. Можно изначально разбить программу на микросервисы, что облегчит переписывание. Можно просто патчить под новые версии ОС, или наоборот запускать ее в эмуляторах. Вариантов много
Или вы хотите сказать что какой-нибудь сварщик, всегда знает зачем нужно сваривать? Так я вас разочарую. Швы портятся. Их периодически нужно переваривать. А то и делать капитальный ремонт. Просто да, мир компьютерных программ слишком молод и слишком быстро меняется. Но программа не обязана быть вечной.
IMHO ваши очевидные открытия, на самом деле еще одно заблуждение.
Программисты пишут программы, чтобы решить конкретные задачи. Если за эти задачи платят, то нужно писать так, чтобы заказчик принял написанное. То есть надо выполнять указанное в ТЗ. Опыт позволяет упростить/улучшить контракт на этапе обсуждения ТЗ или условия работы. Но в целом программист или решает задачу или выполняет условия по контракту.
Ваше представление скорее основано на программистах, которые работают в большой команде, и которым неинтересно разбираться с архитектурой большого проекта - они делают свой маленький кусочек, не особо претендуют на быстрый путь в сеньоры и техлиды. Таких много, может быть даже большинство. Но в любом таком проекте есть тот программист который делает саму задачу, строит архитектуру и делегирует простые задачи вниз, а вы обобщаете поведение джунов и мидлов до самой профессии.
Написанный однажды стартап, если он взлетел и заработал денег, может оказаться проще переписать с нуля, чем модифицировать. Тем более что на заработанные деньги, можно развернуться, нанять больше разработчиков, и переписать с нуля на основании полученного за это время опыта.
В моей практике мы делали один из первых интернет магазинов. В начале 2000х. И я помню как писалось ТЗ, как обсуждалось, чтобы прям все учесть. Как с трудом запустилось и наконец принесло прибыль.
Через год мы заказали новый магазин С НУЛЯ, который написали гораздо быстрее, потому что из ТЗ мы повыкидывали кучу вещей, которые не пригодились. Дописали то, что потребовалось. И новый продукт оказался гораздо более легковесным, отбился в три раза быстрее. Какое-то время его поддерживали, потом все в веб изменилось настолько, что через 3-4 года заказали с нуля еще раз, уже на каком-то общем движке. В данном случае это был правильный путь, более корректный, чем поддерживать легкомодифицирующийся код.
Таким образом преждевременная оптимизация и продумывание ВСЕГО-ВСЕГО наперед - такое же зло, как и отсутствие опыта при написании понятного и легко поддерживаемого кода. Любой шаг в максимализм - это преступление, а удержать баланс можно только за счет опыта, навыков и проектировании конкретного текущего проекта, а не обобщение опыта, полученного из одной программы на все случаи.
5 лет назад, я, будучи зеленым солдатиком джс войск, на фрилансе нашел интересный заказ и написал ужасный, плохо поддерживаемый, трудноизменяемый, но работающий код.
Он решает задачи заказчика уже 5 лет.
И вот спустя 5 лет я узнаю, что так и не достиг цели(
в примере со списком надо было переставить sublist(0,1) на sublist(0,3) - как я понял списко меняли в одном месте. если была бы ситуация, когда у вас были два списка с длиной один и три, то тут надо поставить заметку "если будет еще такой список то тут уже пора делать параметризованный список".
читат я где то то ли методика то ли подход - на такие вещи реагируем только по третьему преценденту
Цель такова, как и во всем в принципе, сделать так, чтобы с программой было лучше, чем было до программы. Какому-то узкому кругу лиц или более широкому. Вопрос филосовский.
немного вспомнилось о докладе - "Simple Made Easy" - Rich Hickey (2011)
Единственная цель программирования — автоматизация. Больше нет.
Программирования нет, где можно нанять и посадить человека.
Например, было так, при приеме ордеров на бирже, записывали ставку в книжку, если цена покупки и продажи совпадали, происходил обмен. Но с автоматизацией быстрее и больше.
Остальное красивости.
У программирования нет цели, у программирования есть только путь.
1) Хорошо работающий код, полностью удовлетворяющий требованиям не надо менять. Так что целью программирования не может быть код, который легко менять. Более высшая цель - код который не надо менять.
2) как это не грустно , но в большинстве случаев программисты хотят мого тысяч денег, а платят их не другие программисты, а т. н. "Бизнес". Исходя из этого , максимально честно ставить приоритетом экономическую целесообразность с учётом рисков. А тут уже на разных этапах жизненного цикла разная стоимость и разные риски - и вполне себе допускает что может быть ситуация что сделать "плохое" решение за час окажется правильнее чем "хорошее" за неделю.
3) субъективизм, но чем больше компания, те больше времени разработчиков уходит на чтение кода, чем на его написание и изменение.
И ещё на вентилятор немного - слабо связанный код , с классами в три строки менять очень легко и быстро, но читать такой, особенно если не знаком с предметной областью или нейминг не на высоте - занятие для сильных духом)
В чем конечная цель программирования?