Доброго времени чтения, уважаемые участники habrahabr.ru
Реакция отхабривания участников habrahabr.ru на три публикации и некоторые вопросы, которые (на взгляд автора) раскрывали идею достаточно полно, привела к мысли, что идею необходимо выразить еще и достаточно наглядно.
Читать полностью »
Вы замечали, что не только окружающие, но и мы сами часто делим задачи и инструменты на «настоящие» — сложные, требующие реально большого объема знаний и работы. И «ненастоящие» — простые, для которых достаточно пары строк кода или 15 минут работы.
Я долгое время совершал эту ошибку и считал ниже своего достоинства делать что-нибудь серьезное на PHP, допустим. Или в десктопе: WinForms — фи. По той же причине всегда пытался быть «на острие» современных технологий, раз за разом переделывая свои продукты на новые фреймворки/технологии.
Помню, когда на одной из последних работ я встретил человека, сделавшего SCADA-систему на Delphi. Я тогда программировал на Visual C++ и посчитал, что это — не серьезно. Вот если бы на C++… При этом его система была реально запущена в продакшен, а моя… ну, вы поняли.
Пишу это для того, чтобы уберечь кого-то от подобной ошибки. После нескольких лет опыта приходишь к тому, что лучше выбрать наиболее простой инструмент из тех, которыми можешь решить текущую задачу.
Оттачивая свои скилы в использовании простых решений, чаще получаешь красивые и эффективные решения, нежели «прыгая» по новым технологиям.
В наши дни методики архитектуры, дизайна и организации процесса разработки ПО размножаются как кролики на стероидах. Фреймворки, компоненты и библиотеки не отстают. Mножество решений основывается на опыте, интуиции или серии проб и ошибок. С усложнением систем, риски выбора неподходящих средств только растут. Я бы хотел обсудить один из возможных способов оценки адекватности инструментов поставленной задаче.
Смысл жизни каждый находит для себя сам. Физики могут сказать, что смысл жизни в борьбе с энтропией: преобразовании хаоса в порядок.
В этом случае, смысл софта в устранении рутины, чтобы cделать создание порядка более эффективным и интересным.
Текст будет длинный. Если вы никуда не торопитесь и удобно устроились в кресле, то давайте попробуем обосновать это утверждение.Читать полностью »
За двадцать лет разнообразного программирования я сформулировал, убежден, главнейший принцип хорошего кода. Опираясь на него, мне и моим коллегам удавалось приводить в порядок самый страшный код, объединять в команде малосовместимых программистов и годами поддерживать системы без лишнего нытья.
Прочтение этой статьи: 15 минут
Осмысление методики: 10 минут
Ощутимые результаты: 30 минут
Удивительно, что такая книга, как эта, до сих пор не была замечена на Хабре. Не могу не попытаться исправить этот недочет.
Итак, хочу представить вам книгу американского информатика Дугласа Роберта Хофштадтера «Гедель, Эшер, Бах: эта бесконечная гирлянда».
Ахилл: Вот если бы книга называлась «Гориллы, серебро, золото» или «Эму, золото…» — тогда бы я еще мог понять…
Черепаха: Может быть, вы предпочли бы «Медь, серебро, бабуины»?
Будучи написано более тридцати лет назад, это невероятное произведение ничуть не утратило своей интересности.
Добрый день уважаемая публика. Хочу представиться — Я — программист.
Почтенные господа хочу написать статью о некоторых моментах, которые мне иногда помогают думать. А думать в наше не простое время приходиться постоянно. Я не хочу слишком сильно углубляться в теорию мышления и построения суждений (это больше относиться к философии), но не могу заметить об одном важном факторе ,- что человек привык думать по протоптанной дорожке. Это и не плохо и не хорошо, так как мы люди — существа социальные и перенимать чужой опыт(хороший или плохой) заложенно в нас детства.Читать полностью »
Преамбула
Доброго дня %user_name%. За годы накопленного опыта в сфере программирования у меня накопились некоторые наблюдения, заслуживающее того, что бы быть структурированными. Сегодня я поговорю о той части работы программистом где он соприкасается с необходимостью обучения. Постараюсь изложить некоторые неоднозначные принципы, а таких в программировании ой как много!
Сегодня существуют разные мнения по поводу успешности объектной технологии. С одной стороны, большинство современных mainstream языков программирования являются объектно-ориентированными, с другой стороны, нередко можно услышать критику ООП, дескать, объектно-ориентированное программирование «провалилось» и не оправдало тех надежд, которые были возложены на нее индустрией разработки ПО. Все, мол, ожидали наступления вселенского счастья в виде увеличения повторного использования, упрощения сопровождения, да и вообще, обещали, что думать придется кому-то другому, а я за это буду деньги получать.
Причин у подобных разочарований тоже несколько. Во-первых, такое отношение к ООП может быть следствием завышенных ожиданий, а ведь Фред Брукс еще двадцать лет назад писал о том, что не стоит ждать «серебряных пуль», способных на порядок увеличить продуктивность труда программиста. Во-вторых, никто из серьезных сторонников ООП (типа Гради Буча или Бертрана Мейера) не обещали, что все будет просто. ООП – это не волшебная палочка, которая сделает из любого УГ конфетку, даже обертку которой можно будет использовать повторно.
Так вот вопрос: как же можно достичь той заветной мечты, когда системы можно будет строить из готовых компонентов, не написав при этом ни строчки кода? Я не уверен, что в таком виде эта мечта вообще осуществима из-за неотъемлемой сложности ПО, а также потому, что часто само решение влияет на решаемую задачу. Тем не менее, если направить энергию, затрачиваемую на повторное использование в правильное русло, то с разумным количеством трудозатрат можно поднять «реюз» кода на достойный уровень.
