97 Things Every Programmer Should Know
  • 97 Things Every Programmer Should Know
  • LANGS
  • 97 Things Every Programmer Should Know
    • Summary
    • Act with Prudence
    • Apply Functional Programming Principles
    • Ask "What Would the User Do?" (You Are not the User)
    • Automate Your Coding Standard
    • Beauty Is in Simplicity
    • Before You Refactor
    • Beware the Share
    • The Boy Scout Rule
    • Check Your Code First before Looking to Blame Others
    • Choose Your Tools with Care
    • Code in the Language of the Domain
    • Code Is Design
    • Code Layout Matters
    • Code Reviews
    • Coding with Reason
    • A Comment on Comments
    • Comment Only What the Code Cannot Say
    • Continuous Learning
    • Convenience Is not an -ility
    • Deploy Early and Often
    • Distinguish Business Exceptions from Technical
    • Do Lots of Deliberate Practice
    • Domain-Specific Languages
    • Don't Be Afraid to Break Things
    • Don't Be Cute with Your Test Data
    • Don't Ignore that Error!
    • Don't Just Learn the Language, Understand its Culture
    • Don't Nail Your Program into the Upright Position
    • Don't Rely on "Magic Happens Here"
    • Don't Repeat Yourself
    • Don't Touch that Code!
    • Encapsulate Behavior, not Just State
    • Floating-point Numbers Aren't Real
    • Fulfill Your Ambitions with Open Source
    • The Golden Rule of API Design
    • The Guru Myth
    • Hard Work Does not Pay Off
    • How to Use a Bug Tracker
    • Improve Code by Removing It
    • Install Me
    • Inter-Process Communication Affects Application Response Time
    • Keep the Build Clean
    • Know How to Use Command-line Tools
    • Know Well More than Two Programming Languages
    • Know Your IDE
    • Know Your Limits
    • Know Your Next Commit
    • Large Interconnected Data Belongs to a Database
    • Learn Foreign Languages
    • Learn to Estimate
    • Learn to Say "Hello, World"
    • Let Your Project Speak for Itself
    • The Linker Is not a Magical Program
    • The Longevity of Interim Solutions
    • Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly
    • Make the Invisible More Visible
    • Message Passing Leads to Better Scalability in Parallel Systems
    • A Message to the Future
    • Missing Opportunities for Polymorphism
    • News of the Weird: Testers Are Your Friends
    • One Binary
    • Only the Code Tells the Truth
    • Own (and Refactor) the Build
    • Pair Program and Feel the Flow
    • Prefer Domain-Specific Types to Primitive Types
    • Prevent Errors
    • The Professional Programmer
    • Put Everything Under Version Control
    • Put the Mouse Down and Step Away from the Keyboard
    • Read Code
    • Read the Humanities
    • Reinvent the Wheel Often
    • Resist the Temptation of the Singleton Pattern
    • The Road to Performance Is Littered with Dirty Code Bombs
    • Simplicity Comes from Reduction
    • The Single Responsibility Principle
    • Start from Yes
    • Step Back and Automate, Automate, Automate
    • Take Advantage of Code Analysis Tools
    • Test for Required Behavior, not Incidental Behavior
    • Test Precisely and Concretely
    • Test While You Sleep (and over Weekends)
    • Testing Is the Engineering Rigor of Software Development
    • Thinking in States
    • Two Heads Are Often Better than One
    • Two Wrongs Can Make a Right (and Are Difficult to Fix)
    • Ubuntu Coding for Your Friends
    • The Unix Tools Are Your Friends
    • Use the Right Algorithm and Data Structure
    • Verbose Logging Will Disturb Your Sleep
    • WET Dilutes Performance Bottlenecks
    • When Programmers and Testers Collaborate
    • Write Code as If You Had to Support It for the Rest of Your Life
    • Write Small Functions Using Examples
    • Write Tests for People
    • You Gotta Care About the Code
    • Your Customers Do not Mean What They Say
  • 97 چیزی که هر برنامه نویس باید بداند
    • فهرست چیزها!
    • بدهی فنی (Technical Debt)
    • برنامه نویسی تابعی یا Functional Programming
    • نیاز کاربر چیست؟
    • استاندارهای کدنویسی
    • ساده زیباست
    • آشنایی با مفهوم ریفکتورینگ در کدنویسی
    • نظافت را رعایت کنید!
    • پیش از آن که دیگران را متهم کنید، کد خود را چک کنید!
    • انتخاب ابزار مناسب
    • برنامه های خود را به زبان مشتریان بنویسید!
    • طرح‌های خود را بی‌نقص کنید
    • به چیدمان کدها توجه کنید!
    • نقد و بررسی کدها
    • کامنت‌گذاری را فراموش نکنید
    • تنها توضیحاتی را بنویسید که کدهایتان قادر به شرح آنها نباشند!
    • از کدهای قبلی خود در شرایط مناسب مجدداً استفاده کنید
    • همواره در حال یادگیری موضوعات جدید باشید
    • ویژگی‌های یک API با طراحی مناسب
    • از ابتدای کار توسعهٔ اپلیکیشن خود روی فرآیند نصب و دیپلوی آن به طور پیوسته کار کنید
    • مدیریت اکسپشن ها
    • تمرین آگاهانه، لازمهٔ حرفه‌ای شدن است!
    • پشت هر خط از کد شما می‌بایست یک منطق وجود داشته باشد!
    • مفهوم DSL چیست و چرا آشنایی با آن در حوزهٔ برنامه‌نویسی اهمیت دارد؟
    • از ساختارشکنی نترسید!
    • برای تست نرم‌افزار از دیتای واقعی استفاده کنید
    • حتی یک ارور را هم نادیده نگیرید!
    • فرهنگ استفاده از یک زبان برنامه‌نویسی را در کنار سینتکس آن بیاموزید
    • اکسپش‌ها را به راحت‌ترین شکل ممکن هَندل کنید
    • فرایند توسعه یک نرم‌افزار خوب اصلاً شانسی نیست
    • آشنایی با قانون DRY
    • آشنایی با مراحل توسعهٔ نرم‌افزار
    • به‌کارگیری درست از اصول برنامه‌نویسی شیٔ‌گرا
    • اعداد اعشاری با خطای محاسباتی در کامپیوتر ذخیره می‌شوند
    • جاه طلبی خود را با شرکت در پروژه های متن باز برآروده کنید!
    • قانون طلایی طراحی API
    • کسی که چند سال است کدنویسی می‌کند، اصلاً علامهٔ دهر نیست!
    • کار زیاد ضمانت موفقیت در برنامه‌نویسی نیست!
    • چگونه به یک باگ نگاه کنیم؟
    • با حذف کدهای اضافی، سورس‌کد خود را بهبود بخشید
    • برنامه‌هایی که می‌نویسید را کاربرپسند کنید
    • فرایندهای برون برنامه‌ای، زمان پاسخگویی نرم‌افزار را تحت‌الشعاع خود قرار می‌دهند
    • بیلد (Build) اصولی ارائه کنید
    • استفادهٔ بهینه از ابزارهای کامندلاینی
    • یادگیری هم‌زمان بیش از یک زبان برنامه‌نویسی
    • محیط کد نویسی (IDE) خود را مثل موم در دست بگیرید
    • ا محدودیت‌های خود دست و پنجه نرم کنید
    • همواره بدانید چه چیزی را قرار است کامیت کنید
    • آشنایی با نحوهٔ به‌کارگیری دیتابیس‌های رابطه‌ای
    • آشنایی با مهارت‌های ارتباطی و فراگیری زبان‌های خارجی
    • خود را با مهارت تخمین زدن تجهیز کنید!
    • کدام یک؟ IDE یا Editor ، مسأله این است!
    • ارسال پیام خطا به دولوپر توسط نرم‌افزار
    • چیزهای اضافی را لود نکنید!
    • چه‌موقع و چگونه از راه‌کارهای موقتی در کدنویسی استفاده کنیم؟
    • استفادهٔ نادرست از اینترفیس‌ها را غیرممکن سازید
    • تا حد ممکن همه‌ چیز را شفاف‌سازی کنید
    • ضرورت آشنایی با مفاهیم کانکارنسی و پاراللیزم
    • یافتن راه‌کارهای ساده برای مشکلات سخت
    • دولوپری که نداند Polymorphism چیست، دولوپر نیست!
    • تستر‌های نرم‌افزار دشمن دولوپرها نیستند!
    • همواره یک نسخه از نرم‌افزار برای ریلیس داشته باشید
    • فقط سورس‌کد است که حرف اول و آخر را می‌زند
    • فقط کد نزنید بلکه Build Process را نیز مدنظر قرار دهید
    • اهمیت برنامه‌نویسی دونفره
    • آشنایی با تفاوت Static Typing و Dynamic Typing در برنامه‌نویسی
    • تا حد ممکن از نمایش ارورها برای کاربر اجتناب کنید!
    • به چه برنامه‌نویسی حرفه‌ای می‌گویند؟
    • از ورژن کنترل غافل نشوید!
    • ماوس و کیبورد را کنار بگذارید!
    • کدخوانی کنید!
    • تعاملات اجتماعی کلید موفقیت است!
    • تا حد ممکن دست به اختراع مجدد چرخ نزنید!
    • تا حد ممکن از Singleton Pattern استفاده نکنید
    • وابستگی‌های زیاد دشمن ریفکتورینگ هستند!
    • هرچه تعداد خطوط کد کمتر، بهتر!
    • آشنایی با قانون Single Responsibility
    • همه‌ چیز با یک آری شروع می‌شود!
    • تا حد ممکن همه‌ چیز را خودکار کنید
    • شنایی با مزایای ابزارهای تحلیل سورس‌کد
    • در تست نرم‌افزار فقط رفتار مورد انتظار را بسنجید
    • تست‌ها علاوه بر صحیح بودن، می‌بایست دقیق هم باشند
    • تست نرم‌افزار و سورس‌کد را آخر شب‌ها و آخر هفته‌ها انجام دهید!
    • مقایسه‌ای مابین مهندسین نرم‌افزار و دیگر مهندسان
    • از نوشتن کدهای اضافی پرهیز کنید
    • اهمیت برنامه‌نویسی دونفره در کدنویسی را هرگز نادیده نگیرید
    • منفی در مفنی می‌شود مثبت!
    • کدنویسی تمیز و اصولی یک باید است
    • ابزارهای یونیکسی دوست دولوپرها هستند!
    • استفادهٔ درست از الگوریتم‌ها و دیتا استراکچرها
    • با لاگ‌گیری Verbose دچار دردسر خواهید شد!
    • درک تفاوت مفاهیم DRY و WET در کدنویسی بهینه
    • تعامل مابین دولوپرها و تسترها
    • طوری کد بزنید که گویی قرار است تا آخر عمر سورس‌کدتان را ساپورت کنید!
    • تا حد ممکن فانکشن‌های کوچک بنویسید
    • برای دولوپرها تست بنویسید نه برای ماشین‌ها!
    • مراقب سورس‌کد باشید!
    • منظور مشتریان شما چیزی نیست که می گویند!
  • 97 вещей, которые должен знать каждый программист
    • Summary
    • Автоматизируйте стандарт кодирования
    • Будьте предусмотрительны
    • В линкере нет никакой магии
    • Ваш заказчик говорит не то, что думает
    • Взаимодействие между процессами влияет на время отклика
    • Выучить язык - значит понять его культуру
    • Дайте проекту голос
    • Две ошибки могут взаимокомпенсировать друг друга (и найти это - очень тяжело)
    • Делайте невидимое видимым
    • Делайте ревью кода
    • Думаете, это никто не увидит?
    • Единственный исполняемый файл
    • Заботьтесь о коде
    • Золотое правило дизайна API
    • Изучайте гуманитарные науки
    • Изучайте другие языки программирования
    • Изучайте иностранные языки!
    • Изучите ограничения
    • Изучите свой IDE
    • Инкапсулируйте не только состояние, но и поведение
    • Используйте правильные алгоритмы и структуры данных
    • Используйте преимущества анализаторов кода
    • Используйте типы из вашей предметной области
    • Когда программисты и тестеры объединяются
    • Комментируйте лишь то, что не ясно из кода
    • Красота и простота
    • Мины замедленного действия
    • Миф о гуру
    • Много данных? Используйте СУБД!
    • Мыслите состояниями
    • Наблюдайте за пользователями
    • Научитесь пользоваться командной строкой
    • Начинайте с "да"
    • Начните отладку процесса установки как можно раньше
    • Не бойтесь что-нибудь сломать!
    • Не забывайте о "Hello, world"
    • Не игнорируйте ошибки.
    • Не надейтесь на магию
    • Не повторяйтесь
    • Не работайте сверхурочно
    • Не трогай это!
    • Непрерывное обучение
    • Нет ничего более постоянного, чем временное
    • О комментариях
    • О пользе изобретения велосипеда
    • Обмен сообщений вместо разделяемой памяти
    • Одна голова - хорошо, а две - лучше
    • Основы bug tracking-a
    • Осознанная практика
    • Осторожнее с повторным использованием!
    • Осторожно выбирайте внешние модули
    • Отойдите от клавиатуры
    • Перегруженный журнал ошибок может лишить вас сна
    • Перед началом рефакторинга
    • Пишите код так, как будто вы будете сопровождать его до конца жизни
    • Пишите маленькие функции, используя примеры
    • Пишите тесты для людей
    • Планируйте свой следующий коммит
    • Поддерживайте чистоту кода
    • "Подмоченный" код сложнее оптимизировать
    • Подозреваете ошибку в компиляторе? Проверьте получше свой код!
    • Позвольте трупу упасть
    • Помещайте все в систему контроля версий
    • Послание в будущее
    • Правило туриста
    • Предотвращайте ошибки
    • Применяйте принципы функционального программирования
    • Принцип единственности ответственности
    • Программирование - это дизайн
    • Программируйте на языке предметной области
    • Программируйте осознанно
    • Программист - профессионал
    • Простота от уменьшения
    • Разделяйте технические и логические исключения
    • Разметка кода важна!
    • Сделайте процесс сборки своим
    • Сопротивляйтесь использованию Singleton
    • Состояние потока и парное программирование
    • Тестеры - лучшие друзья программистов
    • Тестирование - обязательный этап разработки
    • Тестируйте по ночам и в выходные
    • Тестируйте требуемое поведение, а не случайное
    • Тесты должны быть точными
    • Только код расскажет всю правду
    • Убунту-программирование
    • Удобство?
    • Удовлетворяйте свои амбиции на проектах open source
    • Упущенные возможности полиморфизма
    • Установи меня
    • Учитесь оценивать
    • Хороший интерфейс: легко использовать правильно, сложно использовать неправильно
    • Числа с плавающей точкой - не действительные!
    • Читайте код
    • Чтобы улучшить код, удалите его
    • Шаг назад - и автоматизируйте, автоматизируйте, автоматизируйте!
    • Юникс-утилиты - это ваши друзья
    • Языки предметной области
  • Her Yazılımcının Bilmesi Gereken 97 Şey
    • Summary
    • Sağduyulu hareket edin
    • Fonksiyonel Programlama İlkelerini Uygulayın
    • "Kullanıcı Ne Yapar?" Diye Sor (Kullanıcı Siz değilsiniz)
    • Kodlama Standardınızı Otomatikleştirin
    • Güzellik Sadelikte
    • Yeniden Düzenlemeden Önce
    • Paylaşıma Dikkat Edin
    • İzci Kuralı
    • Başkalarını Suçlamadan Önce Kodunuzu Kontrol Edin
    • Araçlarınızı Özenle Seçin
    • Domain Dilindeki Kod
    • Kod Tasarımdır
    • Kod Düzeni Önemlidir
    • Kod İncelemeleri
    • Akıllı Kodlama
    • Yorumlar Üzerine Bir Yorum
    • Yalnızca Kodun Söyleyemediklerini Yorumlayın
    • Devamlı öğrenme
    • Kolaylık bir yetenek değildir
    • Erken ve Sıkça Dağıtın
    • İş İstisnalarını Tekniklerden Ayırın
    • Bol Bol Kasıtlı Uygulama Yapın
    • Etki Alanına Özgü Diller
    • Bir Şeyleri Kırmaktan Korkma
    • Test Verilerinizle Sevimli Olmayın
    • Hatayı Görmezden Gelmeyin!
    • Sadece Dili Öğrenmeyin, Kültürünü Anlayın
    • Programınızı Dik Konumda Çivilemeyin
    • "Burada Sihir Olur"a Güvenmeyin
    • Kendinizi Tekrar Etmeyin (Don't Repeat Yourself - DRY)
    • O Koda Dokunma!
    • Sadece Durumu Değil, Davranışı Kapsülleyin
    • Kayan Noktalı Sayılar Gerçek Değil
    • Açık Kaynak ile Hedeflerinizi Gerçekleştirin
    • API Tasarımının Altın Kuralı
    • Guru Efsanesi
    • Sıkı Çalışmanın Getirisi Yok
    • Hata İzleyici Nasıl Kullanılır
    • Kodu Kaldırarak İyileştirin
    • Beni Kur
    • Süreçler Arası İletişim Uygulama Yanıt Süresini Etkiler
    • Yapıyı Temiz Tutun
    • Komut Satırı Araçlarını Nasıl Kullanacağınızı Bilin
    • İkiden Fazla Programlama Dilini İyi Bilin
    • IDE'nizi Bilin
    • Sınırlarınızı Bilin
    • Bir Sonraki İşleminizi(Commit) Bilin
    • Büyük Birbirine Bağlı Veriler Bir Veritabanına Aittir
    • Yabancı Diller Öğrenin
    • Tahmin Etmeyi Öğrenin
    • "Merhaba Dünya" Demeyi Öğrenin
    • Bırakın Projeniz Kendi Adına Konuşsun
    • Bağlayıcı Sihirli Bir Program Değildir
    • Geçici Çözümlerin Uzun Ömrü
    • Arayüzlerin Doğru Kullanımını Kolay ve Yanlış Kullanımını Zorlaştırın
    • Görünmezi Daha Görünür Hale Getirin
    • Mesaj Geçişi, Paralel Sistemlerde Daha İyi Ölçeklenebilirlik Sağlar
    • Geleceğe Mesaj
    • Polimorfizm için Kaçırılan Fırsatlar
    • Tuhaf Haber: Testçiler Arkadaşlarınızdır
    • Tek İkili
    • Sadece Kod Gerçeği Söyler
    • Yapıya Sahip Olun (ve Yeniden Düzenleyin)
    • Programı Eşleştirin ve Akışı Hissedin
    • Domain Alanına Özgü Türleri İlkel Türlere Tercih Edin
    • Hataları Önle
    • Profesyonel Yazılımcı
    • Her Şeyi Sürüm Kontrolü Altına Alın
    • Fareyi Yere Bırakın ve Klavyeden Uzaklaşın
    • Kodu Okuyun
    • Beşeri Bilimleri Okuyun
    • Tekerleği Sıklıkla Yeniden İcat Edin
    • Singleton Modelin Cazibesine Kapılma
    • Performansa Giden Yol Kirli Kod Bombalarıyla Dolu
    • Sadelik Azaltmadan Gelir
    • Tek Sorumluluk İlkesi(The Single Responsibility)
    • Evet'ten Başlayın
    • Geri Adım Atın ve Otomatikleştirin, Otomatikleştirin, Otomatikleştirin
    • Kod Analiz Araçlarından Yararlanın
    • Tesadüfi Davranış Değil, Gerekli Davranış Testi
    • Kesin ve Somut Test Edin
    • Uyurken (ve Hafta Sonları) Test Edin
    • Test, Yazılım Geliştirmenin Mühendislik Zorluğudur
    • Durumlarda Düşünmek
    • İki Kafa Çoğu Zaman Bir Kafadan Daha İyidir
    • İki Yanlış Bir Doğru Yapabilir (ve Düzeltilmesi Zordur)
    • Arkadaşlarınız İçin Ubuntu Kodlama
    • Unix Araçları Arkadaşlarınızdır
    • Doğru Algoritmayı ve Veri Yapısını Kullanın
    • Ayrıntılı Log Kaydı Uykunuzu Bozacak
    • WET Performans Darboğazlarını Azaltıyor
    • Programcılar ve Test Uzmanları İşbirliği Yaptığında
    • Hayatınız Boyunca Desteklemek Zorundaymışsınız Gibi Kod Yazın
    • Örnekleri Kullanarak Küçük Fonksiyonlar Yazın
    • İnsanlar için Testler Yaz
    • Kodu Önemsemelisiniz
    • Müşterileriniz Ne Dediklerini Kastetmez
Powered by GitBook
On this page
  1. 97 вещей, которые должен знать каждый программист

Научитесь пользоваться командной строкой

PreviousНаблюдайте за пользователямиNextНачинайте с "да"

Last updated 2 years ago

(В оригинале - Know How to Use Command-line Tools)

Сегодня множество инструментов разработки запакованы в Интегрированную Среду Разработки (IDE). Visual Studio и Eclipse – два популярных примера, хотя их конечно же намного больше. В IDE много хорошего. И это не только удобство использования. IDE помогает программисту не думать о множестве деталей, вовлеченных в процесс сборки.

Простота использования, однако, имеет и обратную сторону. Обычно инструмент легко использовать, потому что он принимает решения за вас, делая множество вещей автоматически, за сценой. Поэтому если IDE – это единственный используемый инструмент, то вы никогда до конца не узнаете, что же именно он делает. Вы нажимаете кнопку – и магическим образом в папке появляется исполняемый файл.

Работая с командной строкой, вы узнаете гораздо больше о том, что происходит во время сборки. Написание собственных make-файлов поможет вам понять все шаги (компиляция, ассемблирование, линковка и т.п.) сборки проекта в исполняемый файл. Экспериментирование с различными опциями этих шагов – не менее ценный опыт. Чтобы начать работу с командной строкой, можете взять open-source GCC или же то, что поставляется с вашим специфическим IDE. В конце концов, хорошо спроектированный IDE – это всего лишь графический интерфейс к набору утилит командной строки.

К тому же, некоторые вещи гораздо проще делать именно из командной строки. Например, поиск и замена при помощи grep и sed предоставляет гораздо больше возможностей, чем обычно присутствует в IDE. Командная строка также поддерживает скрипты, что позволяет автоматизировать задачи из серии ежедневной сборки по расписанию, создания нескольких версий проекта и запуск тестов. При помощи IDE такая автоматизация практически невозможна (или как минимум гораздо сложнее). Если вы никогда не заглядывали за границы IDE, вы могли и не догадаться о возможности подобной автоматизации.

Однако подождите… Разве IDE не предназначены для облегчения жизни разработчикам и повышения их продуктивности? Да, конечно. Предложение поработать с командной строкой не означает, что необходимо отказаться от IDE. Предполагается лишь заглянуть за завесу, чтобы понять, что именно делает IDE для вас. И лучший способ для этого – это изучить командную строку. Потом, когда вы опять вернетесь к IDE, вы будете гораздо лучше понимать, что именно происходит и как вы можете контролировать процесс сборки. С другой стороны, научившись работать с командной строкой, возможно вы и сами не захотите возвращаться к IDE, прельстившись мощью и гибкостью командной строки.

Автор оригинала -

Carroll Robinson