Я сейчас читаю книгу Code Leader: Using People, Tools, and Processes to Build Successful Software. Автор Patrick Cauldwell - программист с очень большим стажем и разнообразным опытом. Он работал в различных компаниях, и это позволило ему увидеть мир ИТ с разных сторон. Да, смена работы – положительно сказывается на вашем опыте. Я вообще считаю, что на одном месте нужно сидеть от 3 до 5 лет. Меняя работу, вы окунаетесь в новый мир знаний, общаетесь с новыми людьми и получаете новый опыт в новой сфере.
Но я немного отклонился от темы. Сегодня я написал небольшую заметку на блоге Heapar Software: Покупайте компоненты, а не разрабатывайте. На написание это заметки меня подтолкнула первая клава, которая называется Buy, Not Build. В ней описывается очень много интересно, что очень близко связано с работой Heapar Software. Основная идея заключается в том, что программисты не должны разрабатывать код или как еще говорят - писать код. Они должна покупать код. Более подробно о этой теме читай в самой заметке Покупайте компоненты, а не разрабатывайте.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
Интересная заметка, очень интересная... Может, потому, что как раз отражает то, с чем я сейчас мучаюсь. Да, как ни обидно это признавать, но программирование превращается в простую "сборку кубиков", причем зачастую эти кубики очень плохо подходят друг к другу. И после этого люди удивляются, почему же программы тормозят, глючат, вешаются, занимают так много места и т.д.
Не поймите меня превратно, я прекрасно понимаю и осознаю, что покупка какой-то части кода, тех самых "кирпичиков" позволяет солидно сократить время разработки. Сам тоже, скрипя зубами, внедряю уже готовые компоненты в свои разработки. В принципе, если посмотреть под другим углом - что ж теперь, писать все на ассемблере, разрабатывать свои протоколы передачи данных?
Лично я против "изобретения велосипеда". Но я также и против того, чтобы программист умел только элементы по форме расставлять. Наверное, главное для каждого - найти свою золотую середину. Такое вот имхо.
ZeroXor, все правильно, ты должен тратить время на разработку своего приложения, а не на подготовку фундамента. Зачем решать косвенные задачи, если их уже кто-то решил за тебя, причем в большенстве случаев намного лучше. Ты используешь знания специалистов, написавших библиотеку (компонент и тд), которую ты используешь. Эта "сборка кубиков" ООП называется :). Знаешь ли, стенку класть качественно не так просто как кажется на первый взгляд. Может просто эти самые компоненты не правильно выбраны??
Полностью согласен с темой, лучше использовать чужой опыт, а не отвлекаться от основной цели.
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
