Давайте условимся о некоторых вещах, прежде чем конструктивно продолжить беседу.
Будем считать, что оптимальность — это совокупность «кушать-не-болеть-размножаться-самореализовываться». Соответственно робот выбирал бы единственное решение из набора равнозначно конкурирующих. И таки да, люди часто так и поступают, например, алгоритм «работа-дом-семья».
Но этим жизнь не ограничивается. Я могу полночи проиграть в новую игру, а потом с ущербом для организма и в противоречии с оптимальностью, о которой мы условились, не выспаться и идти трудиться.
Я могу купить новую железяку, которая меня не накормит, от болезней не избавит, секса (ну, по крайней мере, в ортодоксальном смысле) не принесет, и самореализацией это не назовешь. А потом полмесяца плохо кушать.
Это примеры примитивные и на поверхности, но, думаю, мысль понятна.
Вряд ли найдется человек, который всегда принимает оптимальное решение (относительно его понятия оптимальности).
Да, всё так. Глубина нововведений зависит от силы менеджера, ну и плюс ко всему — у всех разное видение ситуации (можно по комментариям и плюсам-минусам проследить всю радугу мнений), не факт что случится что-то глобальное.
Ситуация с менеджментом понемногу исправляется, но мне кажется, что одним им не обойдешься. На мой взгляд, нужно внедрять нормальные программистские практики — нужны ревизии кода, юнит-тесты (их, кстати, некоторые относят к «неинтересным» частям проекта), грамотное тестирование, регламенты и пр. Тогда это всё имеет шанс запыхтеть и заворочаться как следует.
Много дней я ходил до метро по большой широкой улице, и тратил на дорогу 20 минут. Однажды, по пути зайдя в магазин, я увидел проход дворами, который раньше не замечал, и решил пойти по нему. Теперь я трачу на дорогу 10 минут, поскольку путь оказался короче. Я совершил акт творчества? Тут есть искусство? Принципиальное отличие от ситуации с добычей угля?
Поскольку сентенция с роботом вызывает, судя по некоторым комментариям, недопонимание, пора бы пояснить.
Имелось ввиду следующее:
На каждом этапе написания программы — от объявления переменной до выбора паттерна — в рамках текущих условий по проекту имеется четко детерминированное решение (или набор равнозначно конкурирующих решений по сумме преимуществ и недостатков), которое следует применить.
Что имеется ввиду под рамками текущих условий — это регламенты написания кода, общий стиль проекта, квалификация программиста и прочие условия — эдакий срез ситуации. Остальные решения неоптимальны, выбиваются из регламентов, не соответствуют уровню кода, потенциально опасны, непереносимы и пр.
Алгоритмизации это не касается.
Хехе, прекрасно вас понимаю.
Никому не собираюсь ничего доказывать и пыжиться, пытаясь набрать вес в обществе, это — всего лишь статья, которая не претендует ни на гениальность, ни на абсолютную истинность излагаемых в ней идей.
Мне приятно, что к ней столько комментариев. Это значит, что тема интересна, и что идея статьи побудила людей высказать своё отношение к затрагиваемому вопросу, о чем то подумать, придти к какому-то выводу для себя, быть может скорректировать что-то. Цель достигнута.
P.S. И всё же, если интересно:
Я Сергей, разработчик ПО, имею два высших образования, участвовал в старте и развитии нескольких (~10) относительно немаленьких проектов, в основном в связках со специфическим оборудованием. Имею опыт тимлида в команде из четырех разработчиков, небольшой, около года, но вполне боевой. Текущее положение дел в плане трудовой деятельности относительно устраивает (хоть и хочется временами в тимлиды вернуться) поэтому я плодотворно и добросовестно работаю и раз в полгода пишу небольшие статьи.
Нет, задачи не сводятся только к поддержке кода — регулярно пишем новое, но со старыми результатами. Как вы и сказали, чтоб остаться на плаву нам приходится быть актуальными, и плюс к этому тащить груз прошлых проектов.
Попробовать высокоуровневые средства было бы любопытно, но мне кажется что дело не в них, а в привычном подходе к разработке. Ведь, окидывая взглядом ситуацию, такой подход кто-то может считать не таким уж и плохим, раз он позволил людям в течение длительного времени быть востребованными в условиях текущей нагрузки.
В комментариях выше я оговорился, что спортивное программирование и изобретательство несколько выбиваются из общей концепции, это правда.
99% времени автор пишет на C/C++.
Хорошее сравнение, спасибо. Грамотно примененные правила построения музыки гарантируют, что слушатель не взвизгнет, например, при разрешении септаккорда в неустойчивую форму, но не гарантируют, что произведение будет приятно на слух. Грамотно же примененные правила построения программ, написания тестов и пр. как раз гарантируют, что программа будет жизнеспособной.
Я бы не стал делить на «хорошо» и «плохо» в смысле абсолюта. С точки зрения тимлида — лучше тот, кто пишет хороший и легкий код. А с точки зрения конкретной личности… Человек — существо довольно сложное, и профессиональные навыки — лишь составляющая часть. Если человека устраивает его материальное положение и душевное состояние, обеспечиваемое всеми аспектами жизни (включая работу) — то это очень здорово. И тут уже вторично, пишет ли он эталонный код за 3000$ или подходит к коду как получится за 500$. Если же что-то не устраивает — то есть смысл задуматься и работать над собой.
Вероятно, тут вступают в игру финансовые аспекты. Задаром хороший движок не отдадут, или же оцененные затраты на то, чтобы с ним разобраться и допилить превышают затраты на разработку своего продукта.
Будем считать, что оптимальность — это совокупность «кушать-не-болеть-размножаться-самореализовываться». Соответственно робот выбирал бы единственное решение из набора равнозначно конкурирующих. И таки да, люди часто так и поступают, например, алгоритм «работа-дом-семья».
Но этим жизнь не ограничивается. Я могу полночи проиграть в новую игру, а потом с ущербом для организма и в противоречии с оптимальностью, о которой мы условились, не выспаться и идти трудиться.
Я могу купить новую железяку, которая меня не накормит, от болезней не избавит, секса (ну, по крайней мере, в ортодоксальном смысле) не принесет, и самореализацией это не назовешь. А потом полмесяца плохо кушать.
Это примеры примитивные и на поверхности, но, думаю, мысль понятна.
Вряд ли найдется человек, который всегда принимает оптимальное решение (относительно его понятия оптимальности).
Имелось ввиду следующее:
На каждом этапе написания программы — от объявления переменной до выбора паттерна — в рамках текущих условий по проекту имеется четко детерминированное решение (или набор равнозначно конкурирующих решений по сумме преимуществ и недостатков), которое следует применить.
Что имеется ввиду под рамками текущих условий — это регламенты написания кода, общий стиль проекта, квалификация программиста и прочие условия — эдакий срез ситуации. Остальные решения неоптимальны, выбиваются из регламентов, не соответствуют уровню кода, потенциально опасны, непереносимы и пр.
Алгоритмизации это не касается.
Никому не собираюсь ничего доказывать и пыжиться, пытаясь набрать вес в обществе, это — всего лишь статья, которая не претендует ни на гениальность, ни на абсолютную истинность излагаемых в ней идей.
Мне приятно, что к ней столько комментариев. Это значит, что тема интересна, и что идея статьи побудила людей высказать своё отношение к затрагиваемому вопросу, о чем то подумать, придти к какому-то выводу для себя, быть может скорректировать что-то. Цель достигнута.
P.S. И всё же, если интересно:
Я Сергей, разработчик ПО, имею два высших образования, участвовал в старте и развитии нескольких (~10) относительно немаленьких проектов, в основном в связках со специфическим оборудованием. Имею опыт тимлида в команде из четырех разработчиков, небольшой, около года, но вполне боевой. Текущее положение дел в плане трудовой деятельности относительно устраивает (хоть и хочется временами в тимлиды вернуться) поэтому я плодотворно и добросовестно работаю и раз в полгода пишу небольшие статьи.
Попробовать высокоуровневые средства было бы любопытно, но мне кажется что дело не в них, а в привычном подходе к разработке. Ведь, окидывая взглядом ситуацию, такой подход кто-то может считать не таким уж и плохим, раз он позволил людям в течение длительного времени быть востребованными в условиях текущей нагрузки.
99% времени автор пишет на C/C++.